Skip to main content

JMS හි ප්‍රායෝගික යෙදීම්...

මේදවස්වල ටිකක් වැඩ වැඩි හන්දා අලුතෙන් දෙයක් ලියන්න උනේ නැතිවුන නිසා මම ලගදි කියවපු ලිපියක් අනුසාරයේන් පොඩි ලිපියක් ලියන්න හිතුනා.මේ ලිපිය ලියල තිබුනේ Java messaging Service එහෙමත් නැත්නම් JMS පිලිබදව. නමුත් මම මෙහි ලියන්න බලාපොරොත්තු වෙන්නේ JMS පිලිබදව පැහැදිලි කිරීමකට වඩා එහි යේදීමක් පිලිබදවයි.මෙ පිලිබදව විශේෂයෙන් ලියන්න හේතුවක් වුනේ මේ කියන්න යන කාරණය පිලිබදව බොහෝදෙනා යොමු නොකරණ කාරණයක් නිසා.බොහො විට සිද්දාන්තමය කරුනු පිලිබදව අවබෝදයක් තිබුනත් එහි යෙදීම් පිලිබදව ඇත්තේ අඩු අවබෝදයක්.මම පැහැදිලි කරන්න හදපු කාරණය ගැන කතාකලොත් සාමාන්‍යයෙන් යම්කිසි මෘදුකාංගයක් නිර්මාණයේදී අපි එය තුල සිදුවන සිදුවීම් සියල්ල Log එකක් තුල ලිවීම්ට සලස්වනවා.එහිදී method execution වල සිට Exception throwing දක්වා සියලුම සිදුවීම් එය තුල සටහන් කිරීම සිදුකරණු ලබනවා.සමහර විට මෙමගින් ඇතිවන වාසි පිලිබදව ඔබට ප්‍රශ්නයක් මතුවීමට පුලුවන්..ඇත්තටම මෙහිදී මෙය සිදුකරණු ලබන්නේ මෘදුකාංගය තුල සිදුවු දෙ පිලිබදව පසුව අවබෝදයක් ලබාගැනීමටයි.සමහර අවස්තාවලදී මෘදුකාංගයේ සිදුවන Error එකක් වුවද එය සිදුවුයේ කොතැනද කුමන වේලාවේදීද යන්න පිලිබදව ඉතාම පහසුවෙන් මෙම log සටහන් නිසා දැනගත හැකී.මෙය මෘදුකාංගය පවත්වා ගැනීමේදී ඉතාම ලොකු පහසුවක් වෙනවා.විශේෂයෙන් මෙම log සටහන් ක්‍රමය Web Application වලදී බහුල වශයේන් යොදාගනු ලබයි. දැන් අපි සටහනක් තමන්ගේ මෘදුකාංගයට යොදාගැනීමේ ක්‍රියාවලිය පිලිබදව ප්‍රායෝගික කොටස පිලිබදව උදාහරණයක් මගින් පැහැදිලි කරණවනම් Struts Framework එක යොදාගන කරණු ලබන Web Application එකක් සලකා බැලුවහොත් එහිදී මෙම Log ලිවීම සදහා අපට Interceptor එකක් පහසුවෙන් යොදාගත හැක. එහිදී සිදුවන්නේ Struts Action න් execute වීමට ප්‍රතම(pre-processed) මෙම request, Interceptor එකක් හරහා යැවීමයි.පහත රූපයෙන් එය නිරූපණය වේ.


මෙම Interceptor එක තුලදී එම Log එකට අදාල සියලුම තොරතුරු database එකක් තුල හෝ Log file එකක් තුල සටහන් කරගත හැකියි.මෙහිදී බහුලව භාවිතා වන්නේ Log file එකක් තුල සටහන් කර ගැනීමේ ක්‍රමයයි.මෙහිදී මෙම අවස්තාවට අදාල බොහෝ තොරතුරු log සටහනේ සටහන් කරනව.මෙම ක්‍රමයේදී ඇතිවන ප්‍රශ්නය තමයි සියලුම Action execute වීමට ප්‍රතමව මෙසේ log සටහනක ලිවීම. මෙය සෘජුවම මෙම මෘදුකාංගවල කාර්යක්ෂම තාවය කෙරෙහි බලපෑමක් සිදුකරනවා ඊට හේතුව interceptor එක වෙතට පැමිනෙන request නැවතත් ඊට අදාල action එක වෙත යොමුවන්නේ ඊට අදාල තොරතුරු මෙම log සටහන ලිවීමෙන් අනතුරුවයි.මෙම කාර්යක්ෂම තාවය අඩුවීම බොහෝවිට Web Application සදහා විශේෂයෙන් බලපානවා.එහි දල ආකාරය පහත රූපසටහනේ නිරූපණය වේ.රූප සටහනේ දැක්වෙන්නේ එක ගමන් කරන ආකාරය පිලිබදව අවබෙදයක් ගැනීමට පමණක් බව සලකන්න.මෙහිදී මෙම කාර්යක්ෂම තාවය අඩුවීමට බලපාන හේතුව මගහැරවා ගැනීමට අපට JMS යොදාගැනීමට පුලුවන්.මෙහිදී ප්‍රශ්නයට හේතුව වන්නේ (interceptor එක වෙතට පැමිනෙන request නැවතත් ඊට අදාල action එක වෙත යොමුවන්නේ ඊට අදාල තොරතුරු මෙම log සටහන ලිවීමෙන් අනතුරුවයි).මෙහිදී මෙම තත්වයෙන් මිදීමට අපට Interceptor එක ඉවත්කිරීමට හැකියාවක් නැහැ.නමුත් මෙහිදී අපිට Interceptor එක මගින් log සටහන ලිවීමේ කාර්යය කරණ අවස්තාව සදහා කුමක් හෝ පිලියමක් යෙදිය හැකියි.මෙහිදී මෙම කාර්යය වෙන කෙනෙකුට පවරා request එක කෙලින්ම Action එක වෙත යොමු කල හැකිනම් මෙම කාර්යක්ෂමතාවය පිලිබදව ප්‍රස්නයට පිලිතුරක් ලබාගත හැකියි.මෙහිදී මෙම පහත රූපයේ ආකාරයට අපට මෙ සදහා ලෙහෙසියෙන්ම පිලිතුරක් සොයාගත හැකියි.
මෙහිදී ඉහත රූපයේ ආකාරයට Interceptor එක තුල ඇති Message sender function එක යොදාගෙන අපට log එකෙහි සටහන් කිරීමට අවශ්‍ය තොරතුරු message එකක්(Interceptor එකෙහි ඇති message sender එක යොදාගෙන) මගින් Message queue එක වෙතට යොමු කර request එක පමාවකින් තොරව නියමිත Action එක තුලට යොමු කල හැක.මෙහිදී log එක write කරන තෙක් බලාසිටීමෙන් අපතේයන කාලය ඉතුරුකර ගැනීමට හැකිවෙනවා.මෙම queue එකට යොමුකල message පිලිවලින් message receiver තුලට යොමුකරනු ලැබේ.මෙම receiver එක තුල අපට log සටහන් ලිවීම සදහා අවශ්‍ය කේත සටහන් ලියාගත හැකියි.මෙම ක්‍රමය නිසා කලින් තිබු කාර්යක්ෂමතාවය පිලිබදව ගැටලුව මගහරවා ගතහැක.මීට අමතරව JMS යොදාගත හැකි අවස්තා විශාල ගණනක් දක්නට ලැබෙනවා.මම සරළ උදාහරණය මගින් ඔබට මෘදුකාංග නිර්මාණයේදී අපට මතුවන ගැටලු සදාහා අපි ඉගෙන ගන්නා සිද්දාන්තමය කරුණු යොදාගන්නා ආකාරය පිලිබදව යම්තරමක හෝ අවබෝදයක් ලැබෙන්නට ඇතැයි සිතමි.

Comments

හොඳ ලිපියක්..
Pradeep said…
This is a good article about JMS and its basics. But if u can extend this to other usages of JMS, that will be cool.
chamika deshan said…
hmm... I would suggest to my company to use JMS instead of conventional logging technique.
The article is really good.
Thanx prabath...
Ken... said…
This comment has been removed by the author.

Popular posts from this blog

Java Source Code to Change Local IP Address

Hi guys..

Try This code to change your Local IP address.


import java.io.IOException;
import java.lang.Runtime;
public class Chang_Ip {



public static void main(String args[]) throws IOException
{

String str1="192.168.0.201";
String str2="255.255.255.0";
String[] command1 = { "netsh", "interface", "ip", "set", "address",
"name=", "Local Area Connection" ,"source=static", "addr=",str1,
"mask=", str2};
Process pp = java.lang.Runtime.getRuntime().exec(command1);

}


}

How to preserving HTTP headers in WSO2 ESB 4.9.0 ?

Preserving HTTP headers are important when executing backend services via applications/middleware. This is because most of the time certain important headers are removed or modified by the applications/middleware which run the communication. The previous version of our WSO2 ESB, version 4.8.1, only supported “server” and “user agent” header fields to preserve with, but with the new ESB 4.9.0, we’ve introduced a new new property (http.headers.preserve) for the passthru (repository/conf/passthru-http.properties) and Nhttp(repository/conf/nhttp.properties) transporters to preserve more HTTP headers.
Passthru transporter – support header fields LocationKeep-AliveContent-LengthContent-TypeDateServerUser-AgentHostNhttp transport – support headersServerUser-AgentDate
You can specify header fields which should be preserved in a comma-separated list, as shown below. http.headers.preserve = Location, Date, Server Note that properties(http.user.agent.preserve, http.server.preserve), which were used …

How Schedule failover message processor helps for the guaranteed delivery ?

Before we talk about the failover message forwarding processor, it’s better to understand the big picture of the concepts and use cases. The Scheduled Failover Message Forwarding Processor is part of the bigger picture of themessage store and message processor.

Message Store Message Processor. WSO2 ESB’s Message-stores and Message-processorsare used to store incoming messages and then deliver them to a particular backend with added Quality of Services (QoS), such as throttling and guaranteed delivery. The basic advantage of the MSMP is that it allows you to send messages reliably to a backend service. These messages can be stored in a different reliable storage such as JMS, JDBC message stores. The MSMP powered by three basic components:



1. Store Mediator.
The Store mediator is the synapse mediator and can be used to store messages in the message store.

2. Message Store.
A message store is storage in the ESB for messages. The WSO2 ESB comes with four types of message store implementations …