How to add mediation to WSO2 WSAS

In a previous post I spoke about how service hosting capabilities can be added to WSO2 ESB. Now its time to do the reverse and show how mediation capabilities can be added to WSO2 WSAS.

This article from Ruwan explains the process in details. If you feel that you would like to see it in action instead of reading it then you could follow this screen case as well.

Using Eventing and EDA with the WSO2 ESB

In a previous post I mentioned of an Article that explains about Eventing, EDA and how it could be used in an SOA environment. This time Asanka goes on to explain the usage of Eventing and EDA with the WSO2 ESB 2.0.

Using EDA in an SOA environment

Support for eventing was one of the new features that came with WSO2 Carbon based products. Eventing support which is powered by the Apache Savan project is available in both the WSO2 ESB as well as WSO2 WSAS.

This article by Asanka, titled "Fusion : Eventing with SOA - Introduction" gives an overview of eventing and EDA (Event Driven Architecture) together with an illustration on how it can be used in an SOA environment.

How to create a Proxy Service in WSO2 ESB 2.0

The ability to host proxy services is a key feature of the WSO2 ESB. In this post I will explain how a Proxy Service can be created in the new WSO2 ESB 2.0 release.

As its name suggests a Proxy Service is a virtual service that hides the actual service. When defining a Proxy Service in the WSO2 ESB you could provide a inSequence, outSequence, faultSequence and a target endpoint (Not all of these are required).

A sequence as its name suggests send the message through a sequence of mediations. Hence users could perform mediation on requests heading into a Proxy Service (using the inSequence) as well as responses it receives (using the outSequence).

When an endpoint is defined in a Proxy Service, messages that are directed to it goes through the inSequence before been sent to the actual endpoint.

Now that we've covered a few basic ideas on the terms used in Proxy Services lets go ahead and create one. Its always advisable to declare entities in your configuration as reusable components (Just as you do it in OOP). Hence lets define our sequences and endpoints as reusable entities and use them in the creation of the Proxy Service.

For this example I would be creating a proxy service for the digit2image service which can be found on mooshup.com (The community site of the WSO2 Mashup Server).

1. Lets create our endpoint. An Endpoint can be created by visiting the Endpoints link (Located under Manage).
   
   There are four distinct kind of endpoints, Please refer the documentation on endpoints for there detail. For this example I will create a simple Address Endpoint.
   
   
   When creating a address endpoint I simple specify its name and an Address (Having a look at the wsdl of our actual service, I find that the endpoint URL is http://mooshup.com/services/system/digit2image.SOAP12Endpoint/


2. Lets create a sequence. A sequence can be created by visiting the Sequences link (Located under Manage)
   
   
   
   When it comes to sequences, you could create complex sequences using one or more of the inbuilt mediators or using your own custom mediators. For simplicity I will be creating a sequence with a simple Log mediator. All it does is log the message to the console.
   
   
   
3. Now that we have our reusable components in place its time to create the actual Proxy Service. This can be done by visiting the Proxy Service link (Located Under Add).
   
   
   This will take you through a 3 step wizard.
   
   1. In the first step I provide a name for my service. Additionally I could configure several properties on a Proxy Service, for simplicity I will be sticking to the defaults. You could refer the documentation on Proxy Service creation for more details.
      
      
   
   
   2. step 2 asks for an Insiquence and a targetEndpoint. Its mandatory that you have at-least one of these. You could optionally have both as well. In our example lets use the sequence we created in Step 2 (DemoSequence) as the inSequence and the endpoint we created in Step 1 (digit2ImageServiceEndpoint) as our target endpoint.
      
      
   
   
   3. step 3 asks us for an outSequence and a faultSequence, both of which are optional. So lets use the default of none.
      
      
   Once you've done hit finish. Now we have created our new Proxy Service on WSO2 ESB 2.0.
   

Note : If you want this proxy service to be saved dont forget to go to the synapse link and hit save so that this Proxy will be available when you restart the server.

How to Cluster WSO2 Carbon based Products

Clustering for high availability and scalability is one of the main requirements of any enterprise deployment. As an Enterprise SOA offering WSO2 Carbon based products are capable of running in a clustered environment.

Well if that's the case how does one configure WSO2 products so that they can be clustered? Azeez, an Architect and Product Manager of WSO2 WSAS and Mr clustering at WSO2 has written a couple of articles that explain this in details. In the first article titled "Introduction to WSO2 Carbon Clustering" he explains some of the core concepts associated with WSO2 Carbon clustering. In his second article titled "WSO2 Carbon Cluster Configuration Language" he goes on to explains in detail the clustering configuration language used by WSO2 Carbon based products.

These articles apply to WSO2 WSAS (Web Services Application Server), WSO2 ESB (Enterprice Service Bus), WSO2 BPS (Business Process Server) as well as Apache Axis2.

WSO2 ESB (Enterprise Service Bus) 2.0 Released!

The 2.0 version of the WSO2 ESB (Enterprise Service Bus) is now available for download. This version of the ESB is built on the revolutionary WSO2 Carbon Framework which brings compartmentalization into SOA.

New features in this release include,

• Transactional JMS transport and the Transaction mediators
• Integrated graphical user management
• Integrated graphical key store management
• Configurable logging through the management console
• Graphical data source declaration
• WS-Eventing support and Event Sources making it an event broker
• Enhanced sequence and proxy service editor
• Module management capability
• Transport configuration management through the graphical console
• Graceful/Forced shutdown/restart
• Enhanced integrated registry and search functionalities
• User permissions support
• Enhanced monitoring tools for statistics and tracing
• Try-It tool to try an existing service
• Graphical policy editor
• Administration console fully internationalized
• Better modularity and extendability through OSGi component architecture

The ESB is the product that gained the most from the carbonization effort. With this new release proxy services can be secured using a common set of security scenarios with a click of a button. The ability to try proxy services has also been added.

The WSO2 ESB is released under the Apache Licence version 2.0. Download it tryit out and give us your feedback.

How to deploy services on the WSO2 ESB

Whether or not an ESB should host services is a debatable topic and there is no right answer to it. Some do like to host services on their ESB while the others like to have their service deployment separated from service mediation. I personally like the idea of having my services separated from the mediations.

The WSO2 ESB (Enterprise Service Bus) did not allow deploying services on it right up to the 1.7 release. But we did have a few customers who wanted that feature. Now with the revolutionary WSO2 Carbon framework (Which all future generations of WSO2 products will be built on) users can have their ESB just the way they want. The traditionalist who prefer to have there services separate from mediations could use WSO2 WSAS and the WSO2 ESB. For those who want service deployment on their ESB, its just a matter of grabbing the service deployment components and dropping it into your ESB. Charitha has written a nice little blog post that explains how this could be done.

Apache Synapse/WSO2 ESB calling a REST Endpoint

One of the features of Apache Synapse and the WSO2 ESB (Which is Apache Synapse + Monitoring + Management + WSO2 Registry Integration) is that it can change message formats.

There was a question on the ESB-USER mailing list recently asking how you could receive a SOAP message and send out a REST message (HTTP POST serialized as application/x-www-form-urlencoded) to another service. In order to do this you simply need to set two properties on the message. The HTTP_Method to be used and the messageType to be used. The following is a complete synapse.xml

<syn:definitions xmlns:syn="http://ws.apache.org/ns/synapse">

    <syn:registry provider="org.wso2.esb.registry.ESBRegistry">

        <syn:parameter name="root">file:registry/</syn:parameter>

    </syn:registry>

    <syn:proxy name="RESTProxy" startOnLoad="true">

        <syn:target>

            <syn:endpoint name="RESTEndpoint">

                <syn:address uri="http://localhost:7763/services/keith/test/foo"/>

            </syn:endpoint>

            <syn:inSequence>

                <syn:property name="messageType" value="application/x-www-form-urlencoded" scope="axis2"/>

                <syn:property name="HTTP_METHOD" value="post" scope="axis2"/>

            </syn:inSequence>

        </syn:target>

    </syn:proxy>   

    <syn:sequence name="main">

        <syn:send/>

    </syn:sequence>

    <syn:sequence name="fault">

        <syn:log/>

    </syn:sequence>

</syn:definitions>

Here is the request sent into the ESB:

POST /soap/RESTProxy/mediate HTTP/1.1

Content-Type: application/soap+xml; charset=UTF-8; action="urn:anonOutInOp"

User-Agent: WSO2 Mashup Server - Version 1.5.1

Host: 127.0.0.1

Content-Length: 191



<?xml version='1.0' encoding='UTF-8'?>

   <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">

      <soapenv:Body>

         <foo>

            <param>keith</param>

         </foo>

      </soapenv:Body>

   </soapenv:Envelope>

Here is its response (or Request sent out to the REST service):

POST http://localhost:7763/services/keith/test/foo HTTP/1.1
Host: 127.0.0.1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8;action="urn:anonOutInOp";
Transfer-Encoding: chunked
Connection: Keep-Alive
User-Agent: Synapse-HttpComponents-NIO

b
param=keith
0

How to Create a Mock Web Service using the WSO2 ESB

One of the key features of the WSO2 ESB (Enterprise Service Bus) are Proxy Services. This post explains how you could use the proxy services feature in the WSO2 ESB to create Mock Services. These services could offer a REST interface as well as a SOAP interface.

Customer uses WSO2 products to Increase Productivity

This article shows how Concur used the WSO2 Enterprise Service Bus (WSO2 ESB) and the WSO2 Web Services Application Server (WSO2 WSAS) to increase there productivity. It also states that the solution was build in a mere 3 hours whereas it took 3 weeks to build it with pure Java. The following is a quote from the article,

"In the initial deployment, the WSO2 data services technology was able to access the database and convert data into a SOAP message in "literally two minutes," according to Svee. During a training session with WSO2, the Concur team used the "WSO2 ESB to replicate a data synchronization system in three hours that the group had previously taken three weeks to build in Java.""

Training on Apache Synapse & WSO2 ESB

Last week I had a great opportunity to attend a two day training on Apache Synapse and the WSO2 ESB (Enterprise Service Bus). This was an internal training conducted by Asankha. The first day of the training focused on what the WSO2 ESB is and how users would use it. He also took us through all the in built mediators of the ESB. The second day of the training focused on how the ESB Works. For me this was the most interesting part of the training.

Transports are a major part of an ESB. Asankha took us into detail of each transport, the most interesting was the JMS transport and the NHTTP Transport (Non Blocking HTTP Transport). I had played around with the JMS Transport in the mashup server. I even wrote an article on how the JMS Transport can b used in the mashup server. Knowing how to use something is different from knowing how it works.

Next in line was the most anticipated NHTTP Transport. This was the major component of the ESB and all its great performance was due to it. It was s pleasure to get to know how it works.

Prior to this i had used the WSO2 ESB on a customer project and getting to know how it works was really intriguing.

HTTP Content Negotiation with Apache Axis2

Since the 1.3 release of Axis2, it supports HTTP Content Negotiation. It is not turned on by default but can be done so by adding the following parameter to your axis2.xml.

<parameter name="httpContentNegotiation">true</parameter>

Axis2 does not honor the content-type text/xml when its in the Accept Header. This is because the content-type text/xml is primarily used for SOAP 1.1 but when a request is sent via the browser it has the Accept header as "Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 ". If we were to honor text/xml this would result in a SOAP 1.1 response. Not too good for a REST scenario ha! This is the result of the same content-type (text/xml) been used for two message formats (SOAP 1.1 and POX).

Now lets get back to HTTP Content Negotiation with Apache Axis2. Performing a GET request on the version service would result in the following request and response. You could capture them by using TCPMonitor.


Now try editing the Accept header to "application/json/badgerfish". You should have enabled JSON support for this to work. This would result in,


A blog post on how to enable JSON on Axis2 will follow. This configuration can be used to enable HTTP Content Negotiation on WSO2 WSAS as well as the Mashup Server. It should work with Synapse and the WSO2 ESB too but I haven't checked it.