Friday, May 17, 2013

Dequeue from a JMS queue and send as a SOAP message using WSO2 ESB

When you providing a solution for a enterprise you may need to dequeue from a JMS queue and send it to a SOAP endpoint. For this solution the service operation we going to invoke should be one way. So here I am explaining how you can do that easily using WSO2 ESB. Its all about a matter of creating a proxy service. You can download WSO2 ESB from here.



Before starting the WSO2 ESB you need to enable the JMS listener by setting the configuration details of JMSListener in $WSO2ESB_HOME/repository/conf/axis2/axis2.xml. WSO2 ESB supports most of the JMS message brokers and its a just a matter of simple configuration. Here are some configuration document links.

Start the WSO2 ESB using executing the following command using command line inside $WSO2ESB_HOME/bin.
  • Windows - wso2server.bat 
  • Linux - sh wso2server.sh
Now lest see a short diagram of what we are going to do.

Here red lines show the message flow. 

Now lets see how to create the proxy service to achieve this functionality. First go to WSO2 ESB Management Console which you can access using the URL https://localhost:9443/carbon which is the default URL.  
Now you need to login to the Management Console and the default username and password are admin and admin.

Now select the Main ==> Manage ==> Services ==> Add Proxy Service ==> Custom Proxy as shown in the figure below.



In the first page of the proxy configuration add a Proxy name, set the transport to jms and add the following Service Parameters categorize under General Settings.

  transport.jms.ContentType : 
      <rules>         
         <jmsProperty>contentType</jmsProperty>         
         <default>application/xml</default>      
      </rules>
   transport.jms.ConcurrentConsumers : 1
   transport.jms.ConnectionFactory : myTopicConnectionFactory
   transport.jms.SessionTransacted : false
   transport.jms.Destination : myQueue
   transport.jms.MaxConcurrentConsumers : 1

You can find more details for these parameters on here.

After filling the page will look like as following figure.



Now you are done with the first page. Click Next to go to the next page.

Here you need to configure the inSequence to send the SOAP message to your service endpoint. Here we are going to add it in line. Click Edit in Define Inline in Define In Sequence.

And add a Log mediator. You can do it by click on Add Child ==> Core ==> Log and set to log level to full. Which will log the messages comes to this Proxy endpoint.

Then add the Send mediator where we invoke the endpoint of our service. This can be done by clicking  Add Child ==> Core ==> Send. Then edit the Send mediator configuration by defining the In Line endpoint and selecting address endpoint and add your service endpoint there.

Now it will be look like as following figure.


Save and Close the In sequence, then click Next.
Then click Finish and we are done with the configuration.

So if we add a message to the myQueue, then this proxy will dequeue it from the queue and send it to your endpoint. 

Here is my full configuration in xml format and my service endpoint is http://localhost:7611/sample/ep1

<proxy xmlns="http://ws.apache.org/ns/synapse" name="jmsReaderProxy" transports="jms" statistics="disable" trace="disable" startOnLoad="true">
   <target>
      <inSequence>
         <log level="full"/>
         <send>
            <endpoint>
               <address uri="http://localhost:7611/sample/ep1"/>
            </endpoint>
         </send>
      </inSequence>
   </target>
   <parameter name="transport.jms.ContentType">
      <rules>         
         <jmsProperty>contentType</jmsProperty>         
         <default>application/xml</default>      
      </rules>
   </parameter>
   <parameter name="transport.jms.ConcurrentConsumers">1</parameter>
   <parameter name="transport.jms.ConnectionFactory">myTopicConnectionFactory</parameter>
   <parameter name="transport.jms.SessionTransacted">false</parameter>
   <parameter name="transport.jms.Destination">myQueue</parameter>
   <parameter name="transport.jms.MaxConcurrentConsumers">1</parameter>
   <description></description>
</proxy>

Exception sending context initialized event to listener instance of class org.springframework.web.util.Log4jConfigListener

There can be special cases where you may not able to deploy a web application in your application server because of the $subject exception but it may worked in Apache Tomcat. So you may misunderstand that its a bug in your web app or bug in the application server. Fortunately its not, but its a problem of your configuration. Will explain the solution later, but lets see how I get to the solution.

So in the first case I have no idea about this and I was digging in to bit further for a solution. As in the exception say it should be a problem of initialization of log4j. Hmmm.... what could be the course of this? In my case the web application was successfully deployed in Apache Tomcat, but not in WSO2 Application Server. Knowing the fact that WSO2 Application Server build on top of Apache Tomcat it should be something done to the web application archive by WSO2 Application Server before deploying it in the Apache Tomcat. So what is could be? Oh.. it is exploded....


Now I found the difference between deploy in the Apache Tomcat and Deploy in the WSO2 Server, So I need to find the solution how the exploding causing the above problem. Then I search on it and found the following.

In a web archive (.war), Tomcat expect everything to be at the same place. If it it exploded then all the files have their own paths. Tomcat itself explode the web archive, but before that it reads some of the configurations from the war file like log4j listeners. 

When the war file have the following configuration in its web.xml,

    <context-param>
        <param-name>log4jConfigLocation</param-name>
        <param-value>/WEB-INF/log4j.xml</param-value>
    </context-param>


Apache Tomcat expect log4.xml in its a war file in the given location. But since the war exploded it could not find the log4j.xml. So it fails.

Now what we need to be done is we need to change the configuration so that it will read from a file system. For that you need to change the above configuration to the following.

    <context-param>
        <param-name>log4jExposeWebAppRoot</param-name>
        <param-value>false</param-value>
    </context-param>

My problem Solved... Hope you too solve yours...

Saturday, March 16, 2013

Lifecycle transition using WSO2 Governance Registry - Governance API

[NOTE] This article is not recommended for a beginner of WSO2 Governance Registry. If you are a beginner you can refer WSO2 Governance Registry documentation and come back to this article.

In SOA Governance lifecycle management of a SOA artifact is playing a major role. In WSO2 Governance Registry 4.6.0 which is oncoming release there are several ways of manipulating Lifecycle of an artifact. 

  1. Using Governance Registry Management console
  2. Using set of administrative services 
    • LifeCycleManagementService
    • CustomLifecyclesChecklistAdminService
  3. Governance API
Here I am discussing about lifecycle manipulation using Governance API which is introduced for the release. For all the details related to Governance API you can visit WSO2 Governance Registry documentation here.

Here I am using the term artifact for any SOA Governance artifact defined in WSO2 Governance Registry. E.g. Service, WSDL, Policy, Schema, WADL, URI, API which is already there default and any other generic artifact defined by the users.

You can use Governance API to invoke the following operations,
  1. Associating a lifecycle to a artifact
  2. Checking associated lifecycle name of an artifact 
  3. Checking the current state of the lifecycle associated with the artifact
  4. Get the checklist item list
  5. Checking checklist item
  6. Checking whether a checklist item is checked
  7. Unchecking checklist item
  8. Get voting event list
  9. Voting for an event
  10. Checking whether the current user already voted for an event
  11. Unvoting for an event, current user already voted
  12. Get all action list
  13. Invoking action
Now lets look at what each operation do and how it can be done.

Associating a lifecycle to a artifact
This method is use to associate a lifecycle to a artifact. If you want to know about creating a lifecycle please refer this. 
artifact.attachLifecycle(lifecycleName);
Here you need to set the lifecycle name as the parameter. This will throw GovernanceException if the operation failed.

Checking associated lifecycle name of an artifact
This method is use to get the lifecycle name of the associated lifecycle of an artifact.
String lifecycleName = artifact.getLifecycleName();
Checking the current state of the lifecycle associated with the artifact
This method is use to get the current state of the artifact in its lifecycle.
String lifecycleState = artifact.getLifecycleState();
Get the checklist item list
This method is use to get all the check list item names of the current state of the associated artifact.
String[] checklistItems = artifact.getAllCheckListItemNames();

Checking checklist item
This method is use to check a check list item of the current state of the associated artifact.
artifact.checkLCItem(checkListItemIndex);
Here checkListItemIndex is the index of the checklist name in the checklist items list returned by  artifact.getLCCheckListItemNames() method.

Checking whether a checklist item is checked
This method is use to check whether a checklist item of the current state is clicked or not.
boolean lcItemChecked = artifact.isLCItemChecked(checkListItemIndex);
Here checkListItemIndex is the index of the checklist name in the checklist items list returned by  artifact.getAllCheckListItemNames() method.

Unchecking checklist item
This method is use to reverse a checked check list item of the current state of the associated artifact.
artifact.uncheckLCItem(checkListItemIndex);
Here checkListItemIndex is the index of the checklist name in the checklist items list returned by   artifact.getAllCheckListItemNames() method.

Get voting event list
This method is use to get the event list which need certain amount of votes before it invoke.
String[] votingEvents = artifact.getAllVotingItems();

Voting for an event
This method is use to vote for an event.
artifact.vote(eventIndex);
Here eventIndex is the index of the voting event in the voting events list returned by  artifact. artifact.getAllVotingItems() method.

Checking whether the current user already voted for an event
This method is use to check whether the current user is already voted to an event.
boolean currentUserVoted = artifact.isVoted(eventIndex);
Here eventIndex is the index of the voting event in the voting events list returned by  artifact. artifact.getAllVotingItems() method.

Unvoting for an event, current user already voted 
This method is use to reverse the vote for an event.
artifact.unvote(eventIndex);
Here eventIndex is the index of the voting event in the voting events list returned by  artifact. artifact.getVotingItems() method.

Get all action list
This methods is use to get all the actions for current lifecycle state.
artifact.getAllLifecycleActions();

Invoking action
These methods are use to invoke an action in current lifecycle state.
artifact.invokeAction(action);
artifact.invokeAction(action, parameterMap);
Here the second method allows to parse a parameter map which can be use in transition executors.

So, that's all with the lifecycle transitions using WSO2 Governance Registry Governance API. 

Monday, January 21, 2013

Registry based Deployment Synchronizer for WSO2 ESB

Deployment Synchronizer or Dep-Sync is use to synchronize artifacts within nodes in a cluster. Here we are going to see how we can use registry based deployment synchronizer to sync artifacts within  two WSO2 ESB nodes. There are other synchronization methods available in WSO2 servers such as Subversion (svn) based deployment synchronizer and git based  deployment synchronizer, but they need third party software and bit hard to configure compared to registry based deployment synchronizer.

Before doing the actual registry based deployment synchronizer configurations we first need to mount ESB's  /_system/config collection to a single database. To get a clear idea on registry mounting read this.

[NOTE] You can't use Embedded H2 database for this since H2 allows one connection at a time in its Embedded mode. So I am using MySQL here to do the registry mounting.  

To be more clear for you, here I am pasting the configurations I used for my setup.

Node 1: Master

$CARBON_HOME/repository/conf/datasources/masterdatasource.xml
Local datasource configuration.

            WSO2_CARBON_DB
            The datasource used for registry and user manager
            
                jdbc/WSO2CarbonDB
            
            
                
                    jdbc:mysql://x.x.x.x:3306/master?autoReconnect=true
                    root
                    root123
                    com.mysql.jdbc.Driver
                    50
                    60000
                    true
                    SELECT 1
                    30000
                
            
        
Mounted datasource configuration.

            WSO2_CARBON_MOUNTED_DB
            The shared datasource used for registry
            
                jdbc/WSO2CarbonSharedDB
            
            
                
                    jdbc:mysql://x.x.x.x:3306/shared?autoReconnect=true
                    root
                    root123
                    com.mysql.jdbc.Driver
                    50
                    60000
                    true
                    SELECT 1
                    30000
                
            
        
$CARBON_HOME/repository/conf/registry.xml

        SharedRegistry
        wso2registry
        false
        true
        /
  root@jdbc:mysql://x.x.x.x:3306/shared
    

    
        SharedRegistry
        /_system/config
    
 
 
        SharedRegistry
        /_system/governance
    

Node 2: Worker
$CARBON_HOME/repository/conf/datasources/masterdatasource.xml

Local datasource configuration.

            WSO2_CARBON_DB
            The datasource used for registry and user manager
            
                jdbc/WSO2CarbonDB
            
            
                
                    jdbc:mysql://x.x.x.x:3306/worker?autoReconnect=true
                    root
                    root123
                    com.mysql.jdbc.Driver
                    50
                    60000
                    true
                    SELECT 1
                    30000
                
            
        
Mounted datasource configuration.

            WSO2_CARBON_MOUNTED_DB
            The shared datasource used for registry
            
                jdbc/WSO2CarbonSharedDB
            
            
                
                    jdbc:mysql://x.x.x.x:3306/shared?autoReconnect=true
                    root
                    root123
                    com.mysql.jdbc.Driver
                    50
                    60000
                    true
                    SELECT 1
                    30000
                
            
        
$CARBON_HOME/repository/conf/registry.xml
 
 
        SharedRegistry
        wso2registry
        true
        true
        /
  root@jdbc:mysql://x.x.x.x:3306/shared
    

    
        SharedRegistry
        /_system/config
    
 
    
        SharedRegistry
        /_system/governance
    

[NOTE] If the registry mount configured correctly you can see following type of server start up log.



Now registry mounting is done. So let's do the registry based deployment synchronizer configurations.

In deployment synchronize setup not all nodes can configure but one or two which we called them as Master nodes,  while others change their configurations according to the Master nodes which we called them as Worker nodes.

In registry based dep-sync mechanism it uses mounted registry and registry checkin-checkout functionality to synchronize artifacts. Following figure shows you how the registry based deployment synchronizer works.


[NOTE] Red arrows direct how the data flow to worker node.
[NOTE] Any number of worker nodes can be connected via JDBC mount.

Now lets see how to configure Master and Worker nodes.

In both nodes we need to enable to tribes clustering which is use to communicate within nodes. To do that you need to set the enable attribute of the clustering to true in $CARBON_HOME/repository/axis2 /axis2.xml as follows.

    

You can alter the other cluster configuration values to fine tune the cluster. E.g. Membership Scheme- multicast or well known address, domain, Maximum retries (More details on these can be found in the axis2.xml)

Configure Manager Node
Enable the following configuration with the correct values as follows.

        true
        true
        false
    

Here Enable is set to true to indicate that the registry based deployment synchronizer is enabled. AutoCommit is set to true to indicate that this node can commit the changes to registry. AutoCheckout is set to false to indicate that this node is not needed to checkout since this is the only node which do the changes to the configurations.

[NOTE] : AutoCheckout should be set to true if there are more than one Manager nodes.

Configure Worker Node
Enable the following configuration with the correct values as follows.

        true
        false
        true
    
Here Enable is set to true to indicate that the registry based deployment synchronizer is enabled. AutoCommit is set to false to indicate that this node cannot commit the changes to registry. AutoCheckout is set to true to indicate that this node needed to checkout since this node needed to sync up with the Manager node.

That's it with the configuration...  Quite simple.

Now lets see how this works.

First start Manager node.
If the cluster well configured in this node, a log similar to following will be appeared.


Then start Worker node.
If the cluster well configured in this node, a log similar to following will be appeared.

As you can see in the log the Manager node should appear as a Member of the cluster.

Now the servers are up and ready. Lets add a endpoint to the Manager node.


[NOTE]: You should always add/update/delete artifacts using the Manager node.

Every 10 seconds (This value is default and can be configured) of time worker check whether there are changes in the deployed artifacts. If there are changes then they will commit to the registry and send a cluster message asking worker nodes to synchronize. Following is a log message which logged when the synchronization message sent.


When the worker receive that message it will update the artifacts from the registry. When updating Worker node logs following log messages.

New artifact addedregistry.xml

Artifact updated

Artifact deleted

Here I only tried with endpoints. But you can try with other artifacts such as sequence, templates, message stores etc...

So here is the end result in the worker node......


[NOTE] This is only recommend for small deployments only.

Tuesday, January 15, 2013

Governing WADLs with WSO2 Governance Registry A-Z

WSO2 Governance Registry team ready to release WADL support(Web Application Description Language) with oncoming release WSO2 Governance Registry 4.6.0 in mid February.
Web Application Description Language(WADL) is a XML which describes HTTP-based web applications. Most popular usage of WADL is describe REST(Representational state transfer) web services. WADL have the ability to represent model resources provided by the service and  relationships between them. For more read and specification.
Here I am trying to give you a full description on how to govern WADLs using WSO2 Governance Registry. I am using G-Reg for WSO2 Governance Registry for ease.

Let me first start with adding WADL into G-Reg. To do that click on the Metadata => Add => WADL as shown in following figure.


There are two methods  to add a WADL.

  • Importing WADL from a URL.
This allows you to import a WADL file to G-Reg using a WADL URL. Following figure shows how it could be done.


  • Uploading from file system.
This allows you to upload a WADL which located in your file system. You can simply browse the file system to locate WADL file. Following figure shows how it could be done.



Now you uploaded some WADL files and you want to list them down.  To do that click on the Metadata => List => WADL as shown in following figure.


Click on above link will redirect you to list of WADLs as follows.


As you can see in the above figure you can filter WADL by its name. Also there is an option where you can search WADLs by its Lifecycle or Lifecycle state as shown in figure below.


Ok, now you have uploaded some WADLs list them up. Now lets see how its look like. Click any wadl you want in the list to see it. You will get a pretty nice view which has different sections/portals for different purposes. Let me explain one by one.

1. Content
Content has two different views,

  • Custom view : Where we used a tree structure to show how the resources are organized in the WADL file. See the figure below.

  • Standard View: This view you can use to view the full WADL file, edit it or download. See the figure below.


2. Metadata
In this section you find the metadata of the WADL file as described below.

  1. Created : Created time and author
  2. Last updated : Last updated time and author
  3. Mediatype : Mediatype which we used to identify as a WADL which is always application/wadl+xml for WADLs (Which is not finalize and may subjected to change).
  4. Checkpoints : Use to create a new version of WADL.
  5. Versions : Use to view the existing versions of the WADL.
  6. Description : Description of the WADL.
For more general details of metadata click here.

3. Properties
You can use this to keep WADL related properties. See the figure: adding a property.


For more general details of properties click here.

4. Associations and Dependencies
Associations and Dependencies list down the relationships of WADL with other artifacts in G-Reg.
When uploading/importing a WADL to G-Reg it will automatically download the schema files used in WADL and add them to the G-Reg and set them as dependencies of the WADL file. Also G-Reg create a service for the WADL where the WADL is used by that service. See how the Associations and Dependencies are automatically generated for Sample3.wadl in the following figure.


Here listing3.xsd is a dependency of Sample3.wadl and it is used by sample3 service as its dependency. 
For more general details of associations and dependencies click here.

5. Lifecycle
WADL can associate a lifecycle using the lifecycle portal. You can associate any lifecycle which is currently in the G-Reg using this portal as shown in figure.


For more details on adding a lifecycle to G-Reg click here and for more details on associating lifecycle click here.

6. Community features
A WADL can have Comments and Ratings where users can comment on a WADL or rate a WADL. You can add comments and rate using the Comments and Ratings portals as shown in the figure below.

In Ratings it shows, My Rating where current user rating for the WADL and Rating where average rating for the WADL.

For more details on comments and rating click here.

7. Retention
Retention is use to restrict users from Reading and/or writing to a certain WADL. You can add a retention as shown in the figure below.


For more details on retention click here.

8. Subscription
Subscriptions are use to subscribe different WADL events for notification. Following figure shows how to subscribe to a different events.
There are several events you can subscribe a WADL for.
  1. Check LC Item
  2. Uncheck LC Item
  3. Delete
  4. Create LC
  5. Delete LC
  6. Change LC state
  7. Update
Also there are several notification types G-Reg support.
  1. E-Mail
  2. REST
  3. SOAP
  4. User Profile
  5. Role Profile
  6. Management Console
  7. JMX
For more details on subscriptions click here.

9. Tags and Tag Search
You can tag WADLs with different tags where you can search WADLs according to their tags. Following figures shows how to add a tag and how to use the tag search portal to search WADLs.


For more details on tags and tag search click here.

10. Permissions
Permissions are use to set the authority to different roles to read/write or delete WADLs. You set the permissions to different roles using permission section as shown in the figure.


For more details on adding a users and roles click here and for more details on managing permissions click here.

That's it for Governing WADLs in WSO2 Governance Registry. 

Monday, January 2, 2012

Configurable Governance Artifacts with Governance API

Previously I discussed about how to extend WSO2 Governance Registry. Now lets see how we can access those extensions using governance API.

Adding a new Artifact
To create a new Artifact you can use the following code. Here registry refers to valid org.wso2.carbon.registry.core.Registry object and projectKey refers to shortName in the registry extension file.
import org.wso2.carbon.governance.api.generic.GenericArtifactManager;
import org.wso2.carbon.governance.api.generic.dataobjects.GenericArtifact;

GenericArtifactManager artifactManager = new GenericArtifactManager(registry, projectKey);
GenericArtifact artifact  = artifactManager.newGovernanceArtifact(new QName("http://www.example.com","event"));
artifactManager.addGenericArtifact(artifact);
Update a Artifact
To make further changes to a Artifact which already in the registry you can use updateGenericArtifact() method.
artifact.addAttribute("EventName","Running");
artifactManager.updateGenericArtifact(artifact);
Remove a Artifact
To remove a Artifact you should have the reference to that Artifact, which can be retrieve using artifact.getId(). Then you can use removeGenericArtifact() method to remove the Artifact.
String artifactId = artifact.getId();
artifactManager.removeGenericArtifact(artifactId);
Retrieve a Artifact
To retrieve a Artifact you can use getGenericArtifact method().
GenericArtifact artifact = artifactManager.getGenericArtifact(artifactId);
NOTE: In ordered to use getGenericArtifact method you have to have the Artifact reference ID. If you don't have it you can use the discovery method discussed below.

Discover a Artifact
Using the service discovery methods, you can retrieve Artifacts that match a given criteria. Here is an example on how to retrieve a set of Artifacts that has the attributes:
  • Key - EventName
  • Value - Running
GenericArtifact[] artifacts = artifactManager.findGenericArtifacts(new GenericArtifactFilter() {
    public boolean matches(GenericArtifact genericArtifact) throws GovernanceException {
        String attributeVal = artifact.getAttribute("EventName");
        if(attributeVal != null && attributeVal == "Running"){
            return true;
        }
        return false;
    }
});
Associate a Lifecycle to the Artifact
To associate a Lifecycle to the Artifact you can use attachLifecycle() method.
artifact.attachLifecycle("LifeCycleName");
artifactManager.updateGenericArtifact(artifact);
Retrieving Dependents And Dependencies
To get the dependents and dependancies of an Artifact you can use getDependents(), getDependencies() methods.
GovernanceArtifact[] dependents = artifact.getDependents();
GovernanceArtifact[] dependencies = artifact.getDependencies();