Monday, November 14, 2011

Patterns in Science


In science we see problems , solutions and explanations . Most interesting thing about this is we can see same solutions get repeated in different ways in different branches of science.

In this blog i’m going to explain a common solution pattern we see.

Recently i wrote and published an article named “Implementing Store and Forward Messaging Patterns With WSO2ESB Part 1” which explains how to implement store and forward messaging patterns using WSO2 Enterprise service bus.

One problem solved using Store and forwarded messaging patters is integrating systems that accepts different message rates or traffic patterns. As an example say there is a system that provides a service but that service can accept messages below a certain rate say 500msg/sec.
Requirement is to integrate it with another system. Now say if that system produces messages at average rate of 400msg/sec but it can have message rate spikes (ex : 800msg/sec). So One way to solve this problem is to have an intermediate storage for messages inside the message flow where message will get stored and then forwarded it to the destination at a constant rate. (Above mention article gives an example to implement this kind of a scenario).

But if we look around we can see same generic problem is solved using the same generic solution in different scenarios.

Scenario 1.

Irrigation systems :

Problem : In rain season we get lot of excess water which can’t be applied to the cultivation directly.
Solution : Store water in tanks and release them in a slow rate throughout the year.









Scenario 2

AC to DC conversion :

Problem : How to deliver a smooth constant DC voltage output from a AC source when we use a full wave or half wave rectification circuit using a diode bridge to do the conversion.

Solution : After rectification use a Capacitor to store the charges and let it discharge at its slow discharge rate which will results a somewhat smooth DC current.







And also the same pattern is indirectly used on old Sri Lanken irrigation systems to reduce the output water pressure of the Water Tanks.We call it “Bisokutuwa”. see http://www.sinhalaya.com/network/index.php?topic=557.0






So we can see in all these scenarios we have used the generic solution “store and forward” to solve the generic problem of “integrating different output rates with different input rates”.

Saturday, August 20, 2011

Understanding and Terminating the Enemy- Deadlocks

Concurrent programming is hard. And its even hard when you do it badly. Deadlocks are one of the classical enemies you must try to avoid when writing a concurrent program. Because if you face any deadlocks in your program its really hard to find and fix them.

In this post i’m trying to explain what deadlocks are and I’ll explain how to debug a program to find and fix deadlocks.

There are different definitions for deadlock personally i prefer the following definition since i feel its the perfect one.

“A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause (including itself)” [1]

There are four necessary conditions to be there in a program if its leading to a deadlock. Which means if a program ended up in a deadlock state it that program will satisfy following four conditions.

  1. Mutual exclusion : The resources that must involve in the problem must only have mutually exclusive access. Which means only an one thread/ process can have the access to the resources at one time.
  2. Hold and wait : There are threads / processors that hold resource/s and wait for another.
  3. Non preemptive - The resources that are held by one processes can’t be forcefully released.
  4. Circular wait condition : The processes in the system form a circular list or chain where each process in the list is waiting for a resource held by the next process in the list
There will be no deadlocks in a program if it does not satisfy all these conditions .

I’ll explain a simple programming example that will demonstrate a simple deadlock.

public class Resource {


private Object lockA = new Object();

private Object lockB = new Object();


public void accessA() {
synchronized (lockA) {

//Access resource A
System.out.println("GOT A waiting for B");
synchronized (lockB) {
//Access resource B
}

}
System.out.println("Done accessA");
}

public void accessB() {
synchronized (lockB) {
//Access resource B
System.out.println("GOT B waiting for A");
synchronized (lockA) {
//Access resource A
}
}
System.out.println("Done accessB");
}
}




Look at the above Resource class. It got two public methods accessA and accessB. and two locks that protect resources A and resource B from accessing them in parallel.

if two threads try to invoke this two methods in parallel there can be a deadlock scenario where thread 1 will get the lock for A and waiting for B without releasing the lock for A and other thread will get lock for B and wait for the lock for A. This is the simplest scenario that a deadlock can happen between two threads.


If we look at the program you can see all the necessary conditions are satisfied by that program.

  1. Mutual exclusion : resource A and B are Mutual exclusive resources ( Only one thread can access a resource at one time).
  2. Hold and wait : The threads that invoke accessA and accessB methods will hold one resource and wait for another.
  3. Non preemptive : In this program there is not way for us to signal a thread to release a resource forcefully.
  4. Circular wait condition : thread1 <-> thread2

Now lets look at how we can eliminate deadlocks. I do not think there is such mechanical way to remove deadlocks from programs. And some times we will have to understand the lock access order of the program and change them in a such a way that they won’t endup in a cycle/s.If its not possible one thing we can do is track the lock order and detect possible deadlocks and forcefully terminate that thread or resource access.(Preemption)

When writing a complex concurrent program with lot of locks its hard to keep track of the lock order. So identifying possible deadlocks in program can be really useful when writing complex program. And it will be a great advantage if we can have a tool that can be used to identify possible deadlocks. I came across this tool JCarder[2] which i find really useful when analyzing programs for deadlocks. And the major advantage i see here is i could integrate it with integration tests.


JCarder detect possible deadlocks by instrumenting programs byte code and tracking the lock order in runtime. Which means it may not detect all the deadlocks in your program as a given execution will not cover all the code.

you can run your program with jcarder by passing vm parameter -javaagent:path/to/jcarder.jar

ex :

java -javaagent:path/to/jcarder.jar -jar yourprogram.jar


Then when your program executes jcarder will dump logs to a file which can be used later to analyze the deadlocks.

Then you can stop the program when you want and run the analyzer with command

java -jar jcarder.jar



Following is the report i got when i execute the above explained program.

Loaded from database files:

Nodes: 2
Edges: 2 (excluding 0 duplicated)

Cycle analysis result:
Cycles: 1
Edges in cycles: 2
Nodes in cycles: 2
Max cycle depth: 2
Max graph depth: 2

Ignoring 0 gated cycle(s).
Ignoring 0 almost identical cycle(s).

Finally if deadlocks are found it will generate a .dot file which can be visualized using dotty

ex :
$dotty jcarder_result_0.dot
or
$dot -T png -o example.png jcarder_result_0.dot


Following is the output i got for my program which clearly shows the deadlock.




Deadlocks are hard to debug and terminate so its always better to write programs carefully so that there won’t be any deadlocks :)


[1]http://homepages.uel.ac.uk/u0214248/Harriet3.htm
[2]http://www.jcarder.org/

Sunday, June 12, 2011

WSO2 Enterprise Service Bus 4.0.0 Released!

The WSO2 ESB team is pleased to announce the release of version 4.0.0 of the Open Source Enterprise Service Bus (ESB).

WSO2 ESB is a fast, lightweight and user friendly open source Enterprise Service Bus (ESB) distributed under the Apache Software License v2.0. WSO2 ESB allows system administrators and developers to easily configure message routing, intermediation, transformation, logging, task scheduling, fail over routing and load balancing. It also supports transport switching, eventing, rule based mediation and priority based mediation for advanced integration requirements. The ESB runtime is designed to be completely asynchronous, non-blocking and streaming based on the Apache Synapse mediation engine.

WSO2 ESB 4.0.0 is developed on top of the revolutionary WSO2 Carbon platform (Middleware a' la carte), an OSGi based framework that provides seamless modularity to your SOA via componentization. This release also contains many new features and a range of optional components (add-ons) that can be installed to customize the behavior of the ESB. Further, any existing features of the ESB which are not required to your environment can be easily removed using the underlying provisioning framework of Carbon. In brief, WSO2 ESB can be fully customized and tailored to meet your exact SOA needs.

You can download this distribution from http://wso2.org/downloads/esband give it a try.

Brand New Features in this Release

  • HTTP relay transport - Pure streaming HTTP transport based on Java NIO for ultra fast HTTP routing
  • Deployment synchronizer - Easily synchronize the configuration across a cluster of Carbon Servers
  • Message stores and processors - For advanced enterprise messaging and QoS enforcement (eg: in-order delivery, exactly once delivery)
  • Mediation templates - The concept of reusable functions to the ESB configuration language
  • Message broker - Built-in JMS provider/broker powered by Apache Qpid
  • FTPS support via file transport - Transfer files over SSH connections
  • Conditional router mediator - Implement advanced and complex routing logic at ease
  • URL rewrite mediator - Rewrite URLs and URL fragments efficiently
  • Custom XPath extensions - User defined custom XPath extensions support
  • New HL7 transport (optional) - Send and receive HL7 messages over MLLP and other transports
  • New eventing implementation - A powerful event broker with extensive support for WS-Eventing and topic management
  • Event mediator - Publish events to topics defined in the built-in event broker
  • LDAP user store - Built-in LDAP service based on Apache Directory Server
  • Dynamic registry keys and endpoint URL support - Construct registry lookup keys and endpoint URLs dynamically at mediation time
Enhancements in this Release
  • Improved Smooks mediator
  • Enhanced support for service chaining with the receiving sequence support in the send mediator
  • Improved weighted round robin algorithm for the load balance endpoint
  • Improvements to caching
  • Automatic schema imports from the WSDLs added to the registry (for proxy services)
  • Automatic schema imports from the schema files added to the registry (for validate mediator)
  • Support for setting properties at the endpoint level
  • Enhanced Enrich Mediator
  • Improved support for batch transfers in FIX transport
  • Validation support for the ESB configuration editor (source view)
  • Proxy service UI enhancements
  • Enhanced menu layouts
  • Local transport for fast in-VM service calls
Key Features of WSO2 ESB

  • Proxy services - facilitating synchronous/asynchronous transport, interface (WSDL/Schema/Policy), message format (SOAP 1.1/1.2, POX/REST, Text, Binary), QoS (WS-Addressing/WS-Security/WS-RM) and optimization switching (MTOM/SwA).
  • Non-blocking HTTP/S transports based on Apache HttpCore-NIO for ultra-fast execution and support for thousands of connections at high concurrency with constant memory usage.
  • Built in Registry/Repository, facilitating dynamic updating and reloading of the configuration and associated resources (e.g. XSLTs, XSD, WSDL, Policies, JS configurations ..)
  • Easily extendable via custom Java classes (mediator and command)/Spring configurations, or BSF Scripting languages (Javascript, Ruby, Groovy, etc.)
  • Built in support for scheduling tasks using the Quartz scheduler.
  • Load-balancing (with or without sticky sessions)/Fail-over, and clustered Throttling and Caching support
  • WS-Security, WS-Reliable Messaging, Caching & Throttling configurable via (message/operation/service level) WS-Policies
  • Lightweight, XML and Web services centric messaging model
  • Support for industrial standards (Hessian binary web service protocol/ Financial Information eXchange protocol and optional Health Level-7 protocol)
  • Enhanced support for the VFS (File/FTP/SFTP), JMS, Mail transports with optional TCP/UDP transports and transport switching among any of the above transports
  • Support for message splitting & aggregation using the EIP and service callouts
  • Database lookup & store support with DBMediators with reusable database connection pools
  • WS-Eventing support with event sources and event brokering
  • Rule based mediation of the messages using the Drools rule engine
  • Transactions support via the JMS transport and Transaction mediator for database mediators
  • Internationalized GUI management console with user management for configuration development
  • Integrated monitoring support with statistics, configurable logging and tracing
  • JMX monitoring support and JMX management capabilities like, Graceful/Forceful shutdown/restart
Bugs Fixed in this Release

This release of WSO2 ESB comes with a number of bug fixes, both in the base framework and the ESB specific components. All the issues which have been fixed in ESB 4.0.0 are recorded at following locations:

Known Issues

All the open issues pertaining to WSO2 ESB 4.0.0 are reported at following locations:

How to Run
  1. Extract the downloaded zip
  2. Go to the bin directory in the extracted folder
  3. Run the wso2server.sh or wso2server.bat as appropriate
  4. Point your browser to the URL https://localhost:9443/carbon
  5. Use "admin", "admin" as the username and password to login as an admin
  6. If you need to start the OSGi console with the server use the property -DosgiConsole when starting the server. The INSTALL.txt file found on the installation directory will give you a comprehensive set of options and properties that can be passed into the startup script
  7. Sample configurations can be started by the wso2esb-samples script passing the sample number with the -sn option (Please have a look at the samples guide for more information, on running samples)

How to Contribute

Mailing Lists

Join our mailing list and correspond with the developers directly.

Reporting Issues

We encourage you to report issues, documentation faults and feature requests regarding WSO2 ESB through the public ESB JIRA. You can use the Carbon JIRA to report any issues related to the Carbon base framework or associated Carbon components.

Discussion Forums

Alternatively, questions could be raised using the forums available.

WSO2 ESB Forum: Discussion forum for WSO2 ESB developers/users

Support

We are committed to ensuring that your enterprise middleware deployment is completely supported from evaluation to production. Our unique approach ensures that all support leverages our open development methodology and is provided by the very same engineers who build the technology.

For more details and to take advantage of this unique opportunity please visit http://wso2.com/support.

For more information about WSO2 ESB please see http://wso2.com/products/enterprise-service-bus.

-- The WSO2 ESB Team --

Tuesday, February 15, 2011

Web Service Orchestration with an ESB

Web service orchestration can be thought as a process of combining and coordinating of different web services based on a predefined pattern to give a desired result.

Web Service Orchestration is one of many features that comes with an ESB (see [1]). Even though Business process servers can be used for this kind of tasks , using a business process server for a simple service orchestration scenario will be a waste of time. So in this blog post i’ll explain how we can use an ESB for service orchestration which will be a much simpler task.. I’ll be using WSO2 ESB 3.0.1 for this.

Let’s 1st come up with a scenario.

There are consultants who can give us some advices on life when we are in need. So lets try to have a consulting service.



But to consult a “Life guru” or the consultant 1st we need to get a ticket and then go to the “Life guru ” with that ticket.

Following is the high level message flow for this scenario




1) Client invoke ESB proxy service with Parameters name and age
2) ESB store the details and invoke Ticketing Service
3) Ticketing service return a ticket
4 ) ESB invoke consulting service with details name , age and ticket number
5) Consulting service returns the life advice
6) ESB pass the life advice to the client.



To implement this 1st we need to have some Services. So i’ll be creating two axis2 pojo services [2] for this.

1. TicketCounterService - input : void output : ticket number
2. ConsultingService - input : name , age , ticketnumber output : life advice

After having those service created and deployed (i used axis2 for service deployment).
Having those services deployed we can go in to the implementation of the ESB logic.

In WSO2 esb we will be creating a proxy service that excepts users name and age.It will then invoke the other services and then return the life advice back to the user.

We can use WSO2 ESB console to create the proxy service. I have choose to create a custom proxy and named it as ConsultingProxyService. and also i’m publishing a wsdl from this proxy so that there will be contract between ESB and the client.

Since ESB proxy must only accept users name and age. I edited the ConsultingServices wsdl by removing the ticket number input parameter.




Final Proxy service configuration will look like this.



<proxy name="ConsultingProxyService" transports="https http" startOnLoad="true" trace="disable">
<target>
<inSequence>
<property xmlns:char="http://charith.wickramarachchi.org" name="cname" expression="//char:name" scope="default"/>
<property xmlns:char="http://charith.wickramarachchi.org" name="cage" expression="//char:age" scope="default"/>
<enrich>
<source type="inline">
<p:getTicket xmlns:p="http://charith.wickramarachchi.org"/>
</source>
<target type="body"/>
</enrich>
<property name="count" value="1" scope="default" type="STRING"/>
<send>
<endpoint name="endpoint_urn_uuid_29C989B1BAE1F0A05F46088096875141764187336">
<address uri="http://localhost:8080/axis2/services/TicketCounterService"/>
</endpoint>
</send>
<log level="custom">
<property name="Status" value="TicketCounterService Invoked"/>
<property name="cname" expression="get-property('cname')"/>
<property name="cage" expression="get-property('cage')"/>
</log>
</inSequence>
<outSequence>
<switch source="get-property('count')">
<case regex="1">
<property name="count" value="2" scope="default" type="STRING"/>
<xslt key="consultingServiceTransfrom">
<property name="cname" expression="get-property('cname')"/>
<property name="cage" expression="get-property('cage')"/>
</xslt>
<log level="full">
<property name="Status" value="Case2 Invoked"/>
</log>
<send>
<endpoint name="endpoint_urn_uuid_29C989B1BAE1F0A05F44795543807521144284854">
<address uri="http://localhost:8080/axis2/services/ConsultingService"/>
</endpoint>
</send>
</case>
<case regex="2">
<send/>
</case>
</switch>
</outSequence>
</target>
<publishWSDL uri="file:///home/charith/Public/blogg/ServiceChaining/ConsultingProxyService.wsdl"/>
</proxy>


When a message comes to the proxy service 1st it will go in to the insequence of the proxy service. Where 1st it will store the name and age details in the message context. and then we will replace the body of the message with getTicket request message to invoke the Ticketconuter service. and then invoke the TocketCounter service. We also add the property named count to track the status of the service orchestration process.



<inSequence>
<property xmlns:char="http://charith.wickramarachchi.org" name="cname" expression="//char:name" scope="default"/>
<property xmlns:char="http://charith.wickramarachchi.org" name="cage" expression="//char:age" scope="default"/>
<enrich>
<source type="inline">
<p:getTicket xmlns:p="http://charith.wickramarachchi.org"/>
</source>
<target type="body"/>
</enrich>
<property name="count" value="1" scope="default" type="STRING"/>
<send>
<endpoint name="endpoint_urn_uuid_29C989B1BAE1F0A05F46088096875141764187336">
<address uri="http://localhost:8080/axis2/services/TicketCounterService"/>
</endpoint>
</send>
<log level="custom">
<property name="Status" value="TicketCounterService Invoked"/>
<property name="cname" expression="get-property('cname')"/>
<property name="cage" expression="get-property('cage')"/>
</log>
</inSequence>



The reply to the getTicket request will comes to the out sequence of the proxy service. Where we use the count value to determine the response type. If the count value is 1 then its a response from the ticket counter service.

<case regex="1">
<property name="count" value="2" scope="default" type="STRING"/>
<xslt key="consultingServiceTransfrom">
<property name="cname" expression="get-property('cname')"/>
<property name="cage" expression="get-property('cage')"/>
</xslt>
<log level="full">
<property name="Status" value="Case2 Invoked"/>
</log>
<send>
<endpoint name="endpoint_urn_uuid_29C989B1BAE1F0A05F44795543807521144284854">
<address uri="http://localhost:8080/axis2/services/ConsultingService"/>
</endpoint>
</send>
</case>



There we set the proerty count to 2 which means we are now going to invoke to ConsultingService. But for that we need to create the request message for that. Thats were we need the message transformation feature in an ESB. WSO2 ESB have few ways of transforming messages.(Ex : Enrichmediator , XSLT mediator) since i have used Enrich mediator before i’ll use XSLT mediator in this.

The request for CunsultingService must contain name , age and ticket number. But we only have ticket number with in the response message body. That’s where we are going to use the message context properties we added in the in-sequence. Since we are in a single communication session that message context properties will be preserved. So I m going to pass them as XSLT mediator properties so that i can use them in the xslt transformation .

following is the xslt transformation .



<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fn="http://www.w3.org/2005/02/xpath-functions" exclude-result-prefixes="fn" version="2.0">
<xsl:param name="cname"/>
<xsl:param name="cage"/>
<xsl:template xmlns:char="http://charith.wickramarachchi.org" match="//char:getTicketResponse ">
<char:consult>
<!--Optional:-->
<char:name>
<xsl:value-of select="$cname"/>
</char:name>
<!--Optional:-->
<char:age>
<xsl:value-of select="$cage"/>
</char:age>
<!--Optional:-->
<char:ticket>
<xsl:value-of select="//char:return"/>
</char:ticket>
</char:consult>
</xsl:template>
</xsl:stylesheet>



The response of the Consulting service will also come to the out sequence but now it will hit the case 2 of the switch since we have set the property count to 2 in the case 1 . In that case we just send the response back to the client


<case regex="2">
<send/>
</case>


Now we are done with the implementation.

Now i m going to invoke the Proxy service with SOAP request


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:char="http://charith.wickramarachchi.org">
<soapenv:Header/>
<soapenv:Body>
<char:consult>
<!--Optional:-->
<char:name>Charith</char:name>
<!--Optional:-->
<char:age>25</char:age>
</char:consult>
</soapenv:Body>
</soapenv:Envelope>


and i received the response


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns:consultResponse xmlns:ns="http://charith.wickramarachchi.org">
<ns:return>Hello Charith Since your age is 25 Now its a good time to have some fun</ns:return>
</ns:consultResponse>
</soapenv:Body>
</soapenv:Envelope>



I have uploaded all the source codes , configurations , xslt file , and web service archives to [3] so that you can try out your self.

[1]http://en.wikipedia.org/wiki/Enterprise_service_bus#Salient_characteristics
[2]http://axis.apache.org/axis2/java/core/docs/pojoguide.html
[3]http://rapidshare.com/files/448188843/esb-service-chaining.zip