Process Automation Facet in WSO2 BPS, Mechanizes Human Interaction

Every heterogeneous business revolves around tasks that need human interactions. There are computerized procedures that execute much of these bulky tasks. Still they have to be incorporated with human communications. In a business process flow, there are multiple tasks performed by multiple Human Roles and Human Users. Some need to be synchronized, while some needs the pipeline implementation.

For an instance, consider Tasks A and B and Human Roles X and Y that would be completed synchronously. Task A will be accomplished by Human Role X. For the invoke of next task, Task B in line which will be handled by Human Role Y needs a trigger after the completion of Task A. This activator should be prompted for the particular Role Y; not for the Task B.  

WS-BPEL standards facilitated the integration of Human Interaction onto the Process flow. This has been demonstrated by a sample implemented for the WSO2 Product Pack Release Process Automation flow. 

Existing Work Flow of Product Release Process

Build Manager is a person who triggers this process at first place. A build manager can play any role within any product team. He is solely responsible for building products for testing. In the milestones that development teams come across routinely, the build manager builds the products and releases the built pack for the QA for testing. 

Once the issues are being tracked in the product, those are reported and assigned to a developer to resolve. When the issues are fixed by the assignees and after thorough sessions of testing, those products are released as Release Candidates (RC). These RCs too are built by Build Manager and notifications are sent through mails to Carbon – Dev. If they come across any more issues or bugs, then again they are fixed and build the packs again. There can be versions of RCs like RC1, RC2 etc. These package builds are being uploaded to a location where accessible via web. This is followed by checking published packs which includes, ensuring that the binaries are functioning appropriately and completing preparation of documentation and release notes. Then a notification is sent to the relevant groups informing that the particular RC is equipped for the release. 

Then the product managers download the packs and sign them using their private key and upload the signature in a separate location different from the RC hosting site. When that task is completed, the infrastructure people upload the RCs to the relevant correct server where all the finalized releases are maintained. 

Subsequently Oxygen Tank (OT) staff takes up the task of creating a page for the newly done RC and publish it on OT and host the pack there as showed in [1].

Ultimately the Product Release Process comes to an end when the release notes are sent to the relevant mailing lists and forums and blogs are properly updated.

 

Automated Product Release Process

Currently no means of automation is involved with this Product Release Process. Synchronization issues and tracking issues engrossed in the manual release process, will be easily resolved by this automation initiative making the process flow less complicated.

The process is triggered or initialized when an RC is being finalized for the release by the Build Manager. Then the normal work flow will be followed and tasks will be assigned to various members. There will be a “TASK” list for each party who is involved with the process which will display the tasks that have been assigned to each ‘User Role’. This has become a convenient and efficient way of tracking the tasks that takes place during the process. Even the bottle necks of the process, the current progress etc. too can be identified without much difficulty through this system. 

Once a member finishes a task, the system generates a notification saying that the task is ‘COMPLETED’ and the task next in-line will be triggered for the relevant User Role with the ‘READY’ tag. Then all the synchronizations take place and the relevant places get updated appropriately with the proper notices. 

The detailed configuration for Human Task related process automation will be posted soon...

References

[1]. http://dist.wso2.org/downloads/bps/2.0.1/wso2bps-2.0.1.zip

New Angle to look at SOA...

--- essence from Ganesh Prasad's Practical SOA 

Among numerous trends that has struck the IT industry, SOA holds an important place. Service Oriented Architecture has been a buzz word, for a certain period of time. Most of the enterprises and businesses proudly announce that they "MOVE to SOA"; or their "Business is SOA compliant". But when we take a look at their implementation, still it resides in the complex, spaghetti kind of set up. This complexity and non SOA existence can majorly cause

• performance drawbacks
• single point of failure

 If a proper SOA implementation has been executed, it ideally should have

• loosely coupled components
• good governance
• re-usability of components

In a proper SOA architecture, there are 3 main lego blocks namely

• Service Container
• Message Broker
• Process Coordinator 

Service container - Holds the service logic (eg: WSO2 AS)

Process Coordinator - Run time / dynamic process evaluations based on state is handled here. (eg: WSO2 BPS)

Broker - Acts as an adapter, mediator and transformer. Sits in between two applications perform the tasks. (eg: WSO2 ESB)

In any kind of complex deployment environment, first it should be clearly identified what is needed where, out of the above 3 main components.

When the coarse grain analysis is over, in the fine grain analysis, supporting SOA elements such as Rule components, Data services components, Presentation components, Governance components, Registry/repository components etc. can be identified and then deploy the relevant systems appropriately. 

SOA is NOT EASY. But SIMPLE. So plan well & handle with care.

WSO2Con 2011 - Hub of Expertise, Experience and Knowledge

All are keen; lots of enthusiasm; late night hours; ideas coming from every nook and corner; constant follow ups - sync ups; from the topmost head of the office to all the colleagues and subordinates and even the machinery are busy; focused on one main thing. WSO2Con 2011, the BIGGEST IT Conference in Sri Lanka is being held for the second consecutive time with splendor and glamour.

As almost all the WSO2ers too, I am so excited to be a part of this Gala event, rather to be an active participant this time. Because by the time that the last year's WSO2Con 2010 was happening, I was just a mere spectator/ audience there because I was a 'just joined' to WSO2 and had no clue at all what were there around. 

Things started with I getting involved with Undergraduate Registration for the Con. Having a round of lengthy calls with all the Heads of the local and foreign Universities to pass the SPECIAL STUDENT OFFER message, mailing e-flyers around and visiting all the universities to distribute promotional printed material was an enjoyable experience indeed. 

And now looking forward to execute the selection process on the 120+ undergrad registrants and select the TOP 50 who will be lucky participants to witness and be a part of this event. 

Indeed one should be lucky to witness this event because this will have an eminent set of key note speakers from enterprise giants such as Dr C. Mohan from IBM  (Former IBM India Chief Scientist), Sastry Malladi form eBay (distinguished Architect), Gregor Hohpe from Google (Engineer). Also another 20+ speakers who deal with immense industry know how will share their thoughts about the industry trends, customer experiences with WSO2 and expertise with the audience. 

The event which comprise of 3 conference days and 2 tutorial days will be a spring of knowledge to the participants. The registrants have the choice of selecting the speech and tutorial sessions according to their interest out of the multiple available tracks. Have a look at the program line up. 

This time the Conference will be from September 12th - 16th at Waters Edge, Sri Lanka, one of the picturesque locations which is enriched with natural beauty of Sri Lanka. 

Log in to WSO2Con 2011 page and register. Still you are not late to get hit from the IT storm of Sri Lanka. 

See you there!!!

Dynamic WS-Discovery of WSO2 ESB

Web Services Discovery (WS-Discovery) is a protocol that locates web services in a network. As the name implies, the actual communication between nodes is done using web services standards (WS standards) especially in SOAP-over-UDP.
In WS-Discovery, services that are hosted in an Application server or any other service hosting environment can be exposed via a Discovery Proxy (which is default available in products like WSO2 Governance Registry), to another external Discovery client.

Example Use Case
Actual services are hosted in WSO2 Application Server (AS).
WSO2 Governance Registry (G-Reg) acts as the central repository with Discovery proxy, where all the discovered service related metadata are stored.
Discovery client would be WSO2 Enterprise Service Bus (ESB) where it consumes the discovered services and create endpoints and proxy services using them.

Two ways exist that WS-Discovery can be configured in WSO2 Carbon products.

• Static Discovery
• Dynamic Discovery

Static Discovery

In this aspect of WS-Discovery, the services are located and referenced via the service's actual URI. More details on Static Discovery can be read from here. 

Dynamic Discovery

In service discovery, each service is obtained a unique ID (a.k.a UUID) Dynamic Service Discovery uses the uuid to refer the actual services instead of the actual URI of the hosted service. 

Following the steps below will take you to a successful dynamic WS-Discovery environment set up.

Step 1 - Set up environment
Download WSO2 AS, WSO2 G-Reg and WSO2 ESB. 

Change the offset parameter which resides in each of the above products' $CARBON_HOME/repository/conf/carbon.xml, so that, ESB runs in port 9763, AS in 9764 and G-Reg in 9765.

    eg. Open $AS_HOME/repository/conf/carbon.xml and change the offset parameter to 1. 

Step 2 - Start up Discovery Proxy
Start up the G-Reg. If you access through this http://<ip_address_greg>:9765/services/DiscoveryProxy?wsdl, URL, you will observe that the Discovery proxy service is started up and running, and the service is accessible via the endpoint, http://<ip_address_greg>:9765/services/DiscoveryProxy (make a note of this endpoint URL, for the ease of usage in further steps. )
    eg. http://localhost:9765/services/DiscoveryProxy

Step 3 - Configure service hosting environment
Go to $AS_HOME/repository/conf/axis2.xml and add the following parameter.
<parameter name="DiscoveryProxy">http://localhost:9765/services/DiscoveryProxy</parameter>
When we add this discovery proxy endpoint to AS, for all the existing services and new services that are getting deployed in AS, it sends a unicast hello message to the network. 
Restart AS with this addition. 
Go to G-Reg management console and go to Metadata --> List --> Services page. It will show up all the services that are available in AS as discovered services. If you deploy a new service in AS, that will also get reflected in the Metadata service list in G-Reg since all these services send a unicast hello messages to discovery proxy and register them selves in G-Reg. 
You will notice that each and every service is assigned with a unique service name as well. 

Figure 1: G-Reg Service List displays the Discovered Services

Step 4 - Configure Discovery client for 'Dynamic' mode
As mentioned above, WSO2 ESB will act as the discovery client where it can invoke the discovered services via the Endpoints and Proxy services created utilizing the Discovered services itself. 
  4 (a).  Install the WS-Discovery Mediation Extensions feature

Start up the ESB and go to Configure --> Features. In 'Feature Management' wizard, click on 'Add Repository'. Give a name to the repo, and as the URL specify the below and click Add
    eg: http://dist.wso2.org/p2/carbon/releases/3.2.0
From the populated feature list, select the following feature
    WSO2 Carbon - WS-Discovery Mediation Extensions
Install it and Restart the ESB server. 


   4 (b). Configure the synapse registry to pick the new features
Log into ESB. Go to Manage --> Service Bus --> Source View. To the configuration, add the following two parameters. 

<parameter name="discoveryProxy">http://localhost:9765/services/DiscoveryProxy</parameter>
<parameter name="extensions">org.wso2.carbon.discovery.mediation.ext.WSDiscoveryRegistryExtension</parameter>
And save the configuration. (No need to restart)
The same thing can be done from the file system as well. 
Go to $ESB_HOME/repository/conf/synapse-config/registry.xml. Add the above two parameters to the file, save and restart ESB. 
   4 (c). Enable WS - Discovery
Log into ESB Management Console and go to Configure --> WS-Discovery. Click on "Add Discovery Proxy" link to add a new proxy. You will be directed to discovery proxy settings screen in which you can give a name for the proxy and the remote DiscoveryProxy URL (In our case http://localhost:9765/services/DiscoveryProxy). 

Figure 2: Discovery Proxy Configure page in ESB

You will be redirected to the home page of WS-Discovey Control Panel once the proxy is created. The created proxy will be listed in the control panel home page. Click on "View" to find the target services and endpoints discovered by the proxy. You will be directed to a page as shown below. 

Figure 3: ESB displays Dynamically discovered services

Step 5 - Create ESB Proxy etc using the Discovered Services
In the same WS-Discovery service stat page, click on a preferred service ID. It will redirected to a Service Summary page, where all the statistics regarding the particular service is listed. Also it will facilitate you to create ESB Proxy Services and ESB Endpoints using the particular service, which is very convenient in user point of view.  

Figure 4: Create EPs, Proxies using Discovered Services

WSO2 Releases Carbon 3.2.0 platform

Whoa!!!!
For the first time in history, WSO2 released all of its incredible products to the SOA world. Keeping a full stop for the chunk mode releases, where in each release only 3-4 products get released, this time WSO2 succeeded the dream of releasing THIRTEEN products all together.
It was a time that all the engineers spent sleepless nights and restless weekends; With all their whole hearted spirit, effort, commitment and dedication, it was a dream come true.

Focusing on a bunch of new features that were put out with this release, the complex platform has solved many of the earlier problems that were existing in the carbon platform. With the new enhancements and fixes, the platform has improved by leaps and bounds in its stability, availability and scalability aspects.

The ESB has increased its competitive advantage by introducing

• Deployment Synchronizer which synchronizes the deployed archives arcoss all the nodes in a clustered environment
• HL7 transport which comes as an optional feature that is pluggable to an existing ESB
• Event mediator which publishes events to topics defined in the built in event broker
• HTTP Relay transport which streams pure HTTP messages based on Java NIO for ultra fast HTTP routing

and the list grows. You can refer to the latest ESB download and experience the novel difference and super performance.

WS02 Business Process Server has come up with couple of enhancements in order to cater competitive business environments

• Clustering support which comes as a in-built feature of BPS 
• BPEL package hot update which facilitate automatic versioning of uploaded BPEL packages etc 

where you can download the product and try it on your own and feel the new difference.

Across the platform there are several improvements done on stabilizing the middle-ware platform.

• Kerberos support as a new security policy
• ApacheDS LDAP usage as the default user store
• RememberMe feature where the current session is kept cached
• Embedded Tomcat 7 integration that makes the performance faster and smoother. 

With all the matured products like EBS, AS (which was earlier known as WSAS), G-Reg and BPS, two newly adopted kid products too were released. To name, they are Complex Event Processor (CEP) and Message Broker (MB).
Out of them, CEP supports Drools Fusion runtime engine where it comes as a built in engine with CEP and a pluggable Esper runtime engine. These are query processing engines where it handles complex processings of events published on CEP buckets. Also this has the capability of creating a range of brokers from local, WS-Event and JMS-Qpid.

Download the WSO2 Carbon 3.2.0 products from here and experience the ease and comfort of working with the perfect matching middleware solution to your enterprise.

Communicating with WSO2 App Server via JMS-using JMS transport

 Introduction

Messaging is a live wire of the modern enterprises. In Enterprise messaging, a messaging client shoule be facilitated with both sending messages to and receiving messages from any other messaging client or a messaging broker. In an era where businesses take place in various platforms, platform interoperability is a key factor in heterogeneous working environment. Various services may use various communication protocols such as TCP, CORBA, RMI etc. JMS is one such communication protocol that a general SOA business possess.

JMS is a standard protocol for reliable enterprise messaging and is enriched with

    * asynchronous messaging - A JMS broker can deliver messages to a client as the messages arrive, without any special request made by the client in order to receive them

    * reliable messaging - JMS messaging ensures that a message is delivered only once with respect to one request.

In a communication channel, the distinct endpoints may be working in different protocols. The challenge of transforming the message protocols is taken up by message brokers. Therefore the sender or the receiver are free from the hassle of knowing each other end point's communication medium.

WSO2 Carbon Framework supports establishing such JMS connections with brokers such as Apache ActiveMQ. This capability is available in every WSO2 product, but with slightly different configurations. Except that, following a similar procedure, one can easily set up a JMS client communicating with an HTTP server or vice versa.

In this article, we will look at a use case where a JMS client communicate with an HTTP enabled server. There the client will first talk to JMS Queue on ActiveMQ. From there, the message will be directed to the server's respective service.

In here, we will select WSO2 Application Server as our deploying environment as an example.

JMS Configuration for AS

    Step 1

Download the latest version of AS from here . Extract the downloaded binary distribution to a preffered location of your file system. We will refer this as AS_HOME.

    Step 2

Download Apache ActiveMQ 5.2.0 from here. Extract the downloaded distribution to a location in your file system. We will call this ACTIVEMQ_HOME.

    Step 3

First it is required to start the ActiveMQ broker. Navigate to ACTIVEMQ_HOME/bin directory in a terminal. Execute the script named 'activemq'. In Linux, you have to give the command 'sh activemq'. More information on starting ActiveMQ in various platforms can be found here. This will activate the JMS broker with the following status message log.

    INFO TransportServerThreadSupport - Listening for connections at: tcp://localhost:61616

    INFO TransportConnector - Connector openwire Started

    INFO TransportServerThreadSupport - Listening for connections at: ssl://localhost:61617

    INFO TransportConnector - Connector ssl Started

    INFO TransportServerThreadSupport - Listening for connections at: stomp://localhost:61613

    INFO TransportConnector - Connector stomp Started

    .......................................

    .......................................

    INFO TransportConnector - Connector vm://localhost Started

   

    Step 4

Now the Carbon server also should be enabled with JMS. To achieve that, copy the following jars which resides in ACTIVEMQ_HOME/lib to the AS_HOME/lib/core/WEB-INF/lib directory.

    1. activemq-core-5.2.0.jar

    2. geronimo-jms_1.1_spec-1.1.1.jar

    3. geronimo-j2ee-management_1.0_spec-1.0.jar

        

    This action should follow with modifying the axis2.xml of Application Server (AS_HOME/repository/conf/axis2.xml) in such a way that the server is configured to JMS transport.

    The JMS listener or the JMS transport Receiver configuration should be as follows

   

    <transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener">

<parameter name="myTopicConnectionFactory">

    <parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>

    <parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>

    <parameter name="transport.jms.ConnectionFactoryJNDIName">TopicConnectionFactory</parameter>

</parameter>

<parameter name="myQueueConnectionFactory">

    <parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>

    <parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>

    <parameter name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactory</parameter>

</parameter>

<parameter name="default">

    <parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>

    <parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>

    <parameter name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactory</parameter>

</parameter>

</transportReceiver>

This only will not fulfill the requirement of JMS configuration for the server. Since the server needs to do the responding as well via JMS transport , it should have the following line too uncommented in the axis2.xml file.

<transportSender name="jms" class="org.apache.axis2.transport.jms.JMSSender"/>

These configurations allow the user to use the JMS Transport of the WSO2 AS with Apache ActiveMQ JMS broker.

    Step 5

    Start the WSO2 AS. This can be done by running the sh wso2server.sh within the AS_HOME/bin directory in a terminal. If you have successfully configured the WSO2 AS, you should see the following lines being printed on your console as the log.

    [2011-03-13 12:26:37,931] INFO {org.apache.axis2.transport.jms.JMSSender} - JMS Sender started

    [2011-03-13 12:26:37,932] INFO {org.apache.axis2.transport.jms.JMSSender} - JMS Transport Sender initialized...

    ...

    [2011-03-13 12:26:40,406] INFO {org.apache.axis2.transport.jms.JMSConnectionFactory} - JMS ConnectionFactory : myTopicConnectionFactory initialized

    [2011-03-13 12:26:40,407] INFO {org.apache.axis2.transport.jms.JMSConnectionFactory} - JMS ConnectionFactory : myQueueConnectionFactory initialized

    [2011-03-13 12:26:40,408] INFO {org.apache.axis2.transport.jms.JMSConnectionFactory} - JMS ConnectionFactory : default initialized

    [2011-03-13 12:26:40,408] INFO {org.apache.axis2.transport.jms.JMSListener} - JMS Transport Receiver/Listener initialized...

    ...

   

   

    This ensures that the JMS transport has successfully started by connecting to the ActiveMQ broker. When the AS has fully started up, it will print an info log as shown below.

    [2011-03-13 12:26:56,216] INFO {org.wso2.carbon.core.internal.StartupFinalizerServiceComponent} - WSO2 Carbon started in 37 sec

   

    Login to AS and navigate to Manage menu. Under Services, you will see List menu. Go to List, then a list of deployed services will be displayed. There you will see a various services. Click on any service and you will be directed to particular service's dashboard.

    Let's take the version service. Under Endpoints, you will see the following endpoint.

    jms:/version?transport.jms.DestinationType=queue&transport.jms.ContentTypeProperty=Content-Type&java.naming.provider.url=tcp://localhost:61616&java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory

This confirms that Version service is now exposed over JMS transport as well after the above configurations.

    Now you should be able to communicate via JMS to the WSO2 Application Server.

   

Real World Scenarios

    You can try by your own how this JMS broker works with Application Server. What you need to do is create a message client that communicates with the JMS broker and do the above configurations. This will facilitate a remote client that uses JMS to talk to a Carbon server which the service was only exposed through http/https earlier and now exposed in JMS. For this we will consider WSO2 AS 4.0.0

    As shown in the image below, the JMS transport will be taken care by the JMS broker. (Also, if the service is not exposed in JMS, the client can do a general http/s GET request from the service deployed in the AS. )

First you need to do the above actions and configurations stated in Step 1-4. Now it is required to create a client that will talk to the AS. To generate the client, go to AS_HOME/bin from a console. From there type the following command to generate a client stub. We will do this for the version service available in AS. In a console, give the following command.

    sh wsdl2java.sh -uri http://localhost:9763/services/version?wsdl out -uw

This will generate the client stub in the directory AS_HOME/bin/out.

Or else you can go to the version service, from the service listing of AS and click on 'Generate Client' option there. Tick only on the unwrapping(uw) command. This too will generate a client stub for you in your preffered directory.

    Now you can import these generated stub classes to any IDE that you prefer. You can create a project in Eclipse using the generated Build.xml or import to IntelliJIDEA  using the built  pom.xml

Now, write a client in the project that you created importing the stub classes. A sample client will be as below.

    package org.apache.ws.axis2;

    import org.apache.axis2.AxisFault;

    import org.apache.axis2.context.ConfigurationContext;

    import org.apache.axis2.context.ConfigurationContextFactory;

    import java.rmi.RemoteException;

    public class JMSClient {

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

        ConfigurationContext cc = ConfigurationContextFactory.createConfigurationContextFromFileSystem(null,

         "/home/manisha/program_Files/wso2appserver-4.0.0/bin/client/repo/axis2.xml");

        String url = "jms:/version?transport.jms.DestinationType=queue&transport.jms." +

         "ContentTypeProperty=Content-Type&java.naming.provider.url=tcp://manisha:61616&java.naming.factory." +

         "initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&transport.jms." +

         "ConnectionFactoryJNDIName=QueueConnectionFactory";

        VersionStub stub = new VersionStub(cc, url);

        try {

         System.out.println("====Connected to App Server====");

         System.out.println("\t"+stub.getVersion());

         System.out.println("===============================");

        } catch (RemoteException e) {

         e.printStackTrace();

        }

     }

    }

We need to enable JMS in client side too. Therefore, create a client repository (Just create a directory as AS_HOME/bin/client/repo/ and copy the axis2.xml in there). Make sure to enable JMS transportReceiver and TransportSender in client's axis2.xml.

Run the created client. You will get the response back with axis2 version as follows.

   

        ====Connected to App Server====

        WSO2 AppServer-4.0.0

    ===============================

   

    Similarly you can try out with any service that can be deployed in AS and access them with a JMS client via a JMS broker.

In most of the real world scenarios, the above communication takes place through a firewall proxy. The following two images depicts different instances that JMS communication occurs via a proxy.

This is an example of a user that uses JMS and requests for an http service deployed in an AS. There the proxy service should be exposed via JMS and a transformation occurs within the ESB where JMS is transformed into an http request and sent to the AS. When the proxy hits with the AS's response in http, it translates to JMS and sent back to the client.

Here the ESB's axis2.xml needs to be configured to send and receive JMS requests and responses.

The above image displays how a client that uses http requests to access a service that is exposed in JMS via a proxy. Here also the transformations of http to JMS and vice versa takes place inside ESB proxy. This is an instance where AS should be configured to send and receive JMS request and responses.

Likewise you can simply achieve any complex communication network with heterogeneous transport protocols via this simple configuration.

Communicating with WSO2 App Server via JMS-using JMS transport

       

Introduction

Messaging is a live wire of the modern enterprises. In Enterprise messaging, a messaging client shoule be facilitated with both sending messages to and receiving messages from any other messaging client or a messaging broker. In an era where businesses take place in various platforms, platform interoperability is a key factor in heterogeneous working environment. Various services may use various communication protocols such as TCP, CORBA, RMI etc. JMS is one such communication protocol that a general SOA business possess.
JMS is a standard protocol for reliable enterprise messaging and is enriched with
    * asynchronous messaging - A JMS broker can deliver messages to a client as the messages arrive, without any special request made by the client in order to receive them
    * reliable messaging - JMS messaging ensures that a message is delivered only once with respect to one request.
In a communication channel, the distinct endpoints may be working in different protocols. The challenge of transforming the message protocols is taken up by message brokers. Therefore the sender or the receiver are free from the hassle of knowing each other end point's communication medium.
WSO2 Carbon Framework supports establishing such JMS connections with brokers such as Apache ActiveMQ. This capability is available in every WSO2 product, but with slightly different configurations. Except that, following a similar procedure, one can easily set up a JMS client communicating with an HTTP server or vice versa.
In this article, we will look at a use case where a JMS client communicate with an HTTP enabled server. There the client will first talk to JMS Queue on ActiveMQ. From there, the message will be directed to the server's respective service.
In here, we will select WSO2 Application Server as our deploying environment as an example.

JMS Configuration for AS

    Step 1
Download the latest version of AS from here <http://wso2.org/products/download/app-server/4.0.0/wso2appserver-4.0.0.zip>. Extract the downloaded binary distribution to a preffered location of your file system. We will refer this as AS_HOME.

    Step 2
Download Apache ActiveMQ 5.2.0 from here<http://mirror.candidhosting.com/pub/apache//activemq/apache-activemq/5.2.0/apache-activemq-5.2.0-bin.tar.gz>. Extract the downloaded distribution to a location in your file system. We will call this ACTIVEMQ_HOME.

    Step 3
First it is required to start the ActiveMQ broker. Navigate to ACTIVEMQ_HOME/bin directory in a terminal. Execute the script named 'activemq'. In Linux, you have to give the command 'sh activemq'. More information on starting ActiveMQ in various platforms can be found here. <http://activemq.apache.org/getting-started.html#GettingStarted-StartingActiveMQ> This will activate the JMS broker with the following status message log.

    INFO TransportServerThreadSupport - Listening for connections at: tcp://localhost:61616
    INFO TransportConnector - Connector openwire Started
    INFO TransportServerThreadSupport - Listening for connections at: ssl://localhost:61617
    INFO TransportConnector - Connector ssl Started
    INFO TransportServerThreadSupport - Listening for connections at: stomp://localhost:61613
    INFO TransportConnector - Connector stomp Started
    .......................................
    .......................................
    INFO TransportConnector - Connector vm://localhost Started
   
    Step 4
Now the Carbon server also should be enabled with JMS. To achieve that, copy the following jars which resides in ACTIVEMQ_HOME/lib to the AS_HOME/lib/core/WEB-INF/lib directory.
    1. activemq-core-5.2.0.jar
    2. geronimo-jms_1.1_spec-1.1.1.jar
    3. geronimo-j2ee-management_1.0_spec-1.0.jar
        
    This action should follow with modifying the axis2.xml of Application Server (AS_HOME/repository/conf/axis2.xml) in such a way that the server is configured to JMS transport.
    The JMS listener or the JMS transport Receiver configuration should be as follows
   
    <transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener">
<parameter name="myTopicConnectionFactory">
    <parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
    <parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>
    <parameter name="transport.jms.ConnectionFactoryJNDIName">TopicConnectionFactory</parameter>
</parameter>

<parameter name="myQueueConnectionFactory">
    <parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
    <parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>
    <parameter name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactory</parameter>
</parameter>

<parameter name="default">
    <parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
    <parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>
    <parameter name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactory</parameter>
</parameter>
</transportReceiver>

This only will not fulfill the requirement of JMS configuration for the server. Since the server needs to do the responding as well via JMS transport , it should have the following line too uncommented in the axis2.xml file.

<transportSender name="jms" class="org.apache.axis2.transport.jms.JMSSender"/>
These configurations allow the user to use the JMS Transport of the WSO2 AS with Apache ActiveMQ JMS broker.

    Step 5
    Start the WSO2 AS. This can be done by running the sh wso2server.sh within the AS_HOME/bin directory in a terminal. If you have successfully configured the WSO2 AS, you should see the following lines being printed on your console as the log.

    [2011-03-13 12:26:37,931] INFO {org.apache.axis2.transport.jms.JMSSender} - JMS Sender started
    [2011-03-13 12:26:37,932] INFO {org.apache.axis2.transport.jms.JMSSender} - JMS Transport Sender initialized...
    ...
    [2011-03-13 12:26:40,406] INFO {org.apache.axis2.transport.jms.JMSConnectionFactory} - JMS ConnectionFactory : myTopicConnectionFactory initialized
    [2011-03-13 12:26:40,407] INFO {org.apache.axis2.transport.jms.JMSConnectionFactory} - JMS ConnectionFactory : myQueueConnectionFactory initialized
    [2011-03-13 12:26:40,408] INFO {org.apache.axis2.transport.jms.JMSConnectionFactory} - JMS ConnectionFactory : default initialized
    [2011-03-13 12:26:40,408] INFO {org.apache.axis2.transport.jms.JMSListener} - JMS Transport Receiver/Listener initialized...
    ...
   
   
    This ensures that the JMS transport has successfully started by connecting to the ActiveMQ broker. When the AS has fully started up it will print a info log as shows below.
    [2011-03-13 12:26:56,216] INFO {org.wso2.carbon.core.internal.StartupFinalizerServiceComponent} - WSO2 Carbon started in 37 sec
   
    Login to AS and navigate to Manage menu. Under Services, you will see List menu. Go to List, then a list of deployed services will be displayed. There you will see a various services. Click on any service and you will be directed to particular service's dashboard.
    Let's take the version service. Under Endpoints, you will see the following endpoint.

    jms:/version?transport.jms.DestinationType=queue&transport.jms.ContentTypeProperty=Content-Type&java.naming.provider.url=tcp://localhost:61616&java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory

This confirms that Version service is now exposed over JMS transport as well after the above configurations.

    Now you should be able to communicate via JMS to the WSO2 Application Server.
   

Real World Scenarios

    You can try by your own how this JMS broker works with Application Server. What you need to do is create a message client that communicates with the JMS broker and do the above configurations. This will facilitate a remote client that uses JMS to talk to a Carbon server which the service was only exposed through http/https earlier and now exposed in JMS. For this we will consider WSO2 AS 4.0.0
    As shown in the image below, the JMS transport will be taken care by the JMS broker. (Also, if the service is not exposed in JMS, the client can do a general http/s GET request from the service deployed in the AS. )
First you need to do the above actions and configurations stated in Step 1-4. Now it is required to create a client that will talk to the AS. To generate the client, go to AS_HOME/bin from a console. From there type the following command to generate a client stub. We will do this for the version service available in AS. In a console, give the following command.

    sh wsdl2java.sh -uri http://localhost:9763/services/version?wsdl out -uw

This will generate the client stub in the directory AS_HOME/bin/out.
Or else you can go to the version service, from the service listing of AS and click on 'Generate Client' option there. Tick only on the unwrapping(uw) command. This too will generate a client stub for you in your preffered directory.
    Now you can import these generated stub classes to any IDE that you prefer. You can create a project in Eclipse (http://www.eclipse.org/downloads/) using the generated Build.xml or import to IntelliJIDEA (http://www.jetbrains.com/idea/download/) using the built (http://maven.apache.org/plugins/maven-idea-plugin/usage.html) pom.xml
Now, write a client in the project that you created importing the stub classes. A sample client will be as below.
    package org.apache.ws.axis2;

    import org.apache.axis2.AxisFault;
    import org.apache.axis2.context.ConfigurationContext;
    import org.apache.axis2.context.ConfigurationContextFactory;

    import java.rmi.RemoteException;

    public class JMSClient {

     public static void main(String[] args) throws AxisFault {
        ConfigurationContext cc = ConfigurationContextFactory.createConfigurationContextFromFileSystem(null,
         "/home/manisha/program_Files/wso2appserver-4.0.0/bin/client/repo/axis2.xml");
        String url = "jms:/version?transport.jms.DestinationType=queue&transport.jms." +
         "ContentTypeProperty=Content-Type&java.naming.provider.url=tcp://manisha:61616&java.naming.factory." +
         "initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&transport.jms." +
         "ConnectionFactoryJNDIName=QueueConnectionFactory";

        VersionStub stub = new VersionStub(cc, url);
        try {
         System.out.println("====Connected to App Server====");
         System.out.println("\t"+stub.getVersion());
         System.out.println("===============================");
        } catch (RemoteException e) {
         e.printStackTrace();
        }
     }
    }

We need to enable JMS in client side too. Therefore, create a client repository (Just create a directory as AS_HOME/bin/client/repo/ and copy the axis2.xml in there). Make sure to enable JMS transportReceiver and TransportSender in client's axis2.xml.
Run the created client. You will get the response back with axis2 version as follows.
   
    ====Connected to App Server====
        WSO2 AppServer-4.0.0
    ===============================
   
    Similarly you can try out with any service that can be deployed in AS and access them with a JMS client via a JMS broker.

In most of the real world scenarios, the above communication takes place through a firewall proxy. The following two images depicts different instances that JMS communication occurs via a proxy.

This is an example of a user that uses JMS and requests for an http service deployed in an AS. There the proxy service should be exposed via JMS and a transformation occurs within the ESB where JMS is transformed into an http request and sent to the AS. When the proxy hits with the AS's response in http, it translates to JMS and sent back to the client.
Here the ESB's axis2.xml needs to be configured to send and receive JMS requests and responses.

The above image displays how a client that uses http requests to access a service that is exposed in JMS via a proxy. Here also the transformations of http to JMS and vice versa takes place inside ESB proxy. This is an instance where AS should be configured to send and receive JMS request and responses.

Likewise you can simply achieve any complex communication network with heterogeneous transport protocols via this simple configuration.