Popular Posts

Wednesday, April 28, 2010

WS-Discovery with WSO2 Carbon

WS-Discovery defines a protocol to locate web services on a network, more specifically in a SOA.
The newest release of WSO2 Carbon platform (version 3.0.0) provides a complete implementation of the WS-Discovery managed mode.
This post demonstrates an end-to-end workflow of WS-Discovery support in WSO2 Carbon. With WS-Discovery components for WSO2 Carbon, any Carbon server can act as a WS-Discovery client, a WS-Discovery proxy or a WS-Discovery target service. We will use three products from WSO2 Carbon product suite, namely WSO2 Governance Registry (G-reg), WSO2 ESB and WSO2 WSAS.
WSO2 G-reg acts as the central repository in which the discovered services and the related meta data are stored. WSO2 WSAS is used to host the target services. WSO2 ESB participates in the scenario as a discovery client which looks for services and endpoints.

Lets start with setting up the environment.

Pre-requistes:

Install and run each product. In this demonstration, I will run G-reg in http port 9763 and https port 9443. WSAS on http port 9764 and https port 9444. ESB on http port 9765 and https port 9445. In this way, I can run all three products in single machine.

Step 1

As I explained initially, WSO2 Governance Registry acts as the discovery proxy. If you access the https://localhost:9443/services/DiscoveryProxy?wsdl, you will find out the wsdl of the discovery proxy service. Make a note of the DiscoveryProxy service endpoint (https://localhost:9443/services/DiscoveryProxy)

Step 2

Now, we need to configure WSAS instance, so that it takes part in service discovery scenario. WSAS is used to host target services. Therefore, it sends a unicast Hello messages to a Discovery Proxy when the services join a network. So, we must configure the Discovey Proxy service endpoint in WSAS.

Open WSAS_HOME/repository/conf/axis2.xml and add the following parameter.

<parameter name="DiscoveryProxy">https://localhost:9443/services/DiscoveryProxy</parameter>

Save the file and restart WSAS. This will enable WSAS to send unicast hello messages when the services are deployed.
Now, access the management console of WSO2 Governance Registry instance and go to Metadata-->List-->Services page. You will see that 3 discovered services are listed there.
These are the three default services included in WSAS. When starting WSAS, those three services have sent the hello messages to the discovery proxy and register them in G-reg.



Image:- Discovered services in G-reg

Now, log in to WSAS management console and deploy a new service. If you refresh the above service list page, you will see a new service is discovered by G-reg and it is assigned a unique service name.

Step 3

The third member participates in our scenario is WSO2 ESB, which acts as a discovery client. WSO2 ESB provides you with a user interface to mange the client aspects of WS-Discovery. Using that, you can connect to remote WS-Discovery proxies and probe them for any services and service endpoints which have been already discovered.

Log in to ESB management console and select Configure > WS-Discovery from the left navigation menu to access WS-Discovery Control panel.



Image:- WS-Discovery Control Panel in ESB

In order to connect to the remote DiscoveryProxy (in G-reg) and make use of the discovered services, we should configure a discovery proxy in ESB. 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 https://localhost:9443/services/DiscoveryProxy). 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.



Here, you will see that 4 service are discovered and shown with a UUID and associated endpoints of each discovered service.
Click on a discovered service UUID. You will be directed to a new page with more information about the service. Using this page, either you can create an ESB endpoint or directly create an ESB proxy service referring to the discovered service.

We have seen the basic workflow of WS-Discovey implementation of WSO2 Carbon platform. If you have any issues with the above steps, drop me a mail or contact WSO2 ESB forum at www.wso2.org

Sunday, April 25, 2010

How to setup binary relay in WSO2 ESB-3.0.0

The latest version of WSO2 ESB will be out by few days and the final set of release candidate builds are currently going through the test process. WSO2 ESB-3.0.0 consists of a set of new features as well as enhancements to the existing features. Binary relay feature has been included since the previous ESB release (WSO2 ESB-2.1.3) however many bug fixes and enhancements are included in the new release.
Binary relay allow users to send messages to a different party efficiently at byte level while making decisions using transport headers. It enables ESB to pass through SOAP messages without performing heavy XML parsing. You can find more information about the architectural details of binary relay in this article written by Dr. Srinath Perera.

I'm going to demonstrate the steps to configure binary relay in WSO2 ESB-3.0

Pre-requisites:
Download WSO2 ESB-3.0.0 from here (I'm using the latest release candidate which can be downloaded from here)

Step 1

First we must enable the relay module in the ESB management console so that it unwraps the messages received by the admin services.
Log in to management console and go to Manage --> Modules --> List and click on engage icon associated with relay module to engage the module globally.

Step 2

Now, we should configure the necessary message formatters and builders in axis2.xml configuration file.
Go to ESB_HOME/repository/conf/axis2.xml and locate the messageFormatters and messageBuilders section.
Uncomment the relay message formatters and builders as follows. Also, comment out the other (default) formatters and builders.

<messageFormatters>
<!--<messageFormatter contentType="application/x-www-form-urlencoded"
class="org.apache.axis2.transport.http.XFormURLEncodedFormatter"/>
<messageFormatter contentType="multipart/form-data"
class="org.apache.axis2.transport.http.MultipartFormDataFormatter"/>
<messageFormatter contentType="application/xml"
class="org.apache.axis2.transport.http.ApplicationXMLFormatter"/>
<messageFormatter contentType="text/xml"
class="org.apache.axis2.transport.http.SOAPMessageFormatter"/>
<messageFormatter contentType="application/soap+xml"
class="org.apache.axis2.transport.http.SOAPMessageFormatter"/>-->
<messageFormatter contentType="application/x-www-form-urlencoded"
class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
<messageFormatter contentType="multipart/form-data"
class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
<messageFormatter contentType="application/xml"
class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
<messageFormatter contentType="text/html"
class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
<messageFormatter contentType="application/soap+xml"
class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
<messageFormatter contentType="text/xml"
class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
<!--messageFormatter contentType="x-application/hessian"
class="org.apache.synapse.format.hessian.HessianMessageFormatter"/-->
<!--messageFormatter contentType=""
class="org.apache.synapse.format.hessian.HessianMessageFormatter"/-->
<!--
class="org.apache.axis2.format.PlainTextFormatter"/>-->
</messageFormatters>


<messageBuilders>
<!-- <messageBuilder contentType="application/xml"
class="org.apache.axis2.builder.ApplicationXMLBuilder"/>
<messageBuilder contentType="application/x-www-form-urlencoded"
class="org.apache.axis2.builder.XFormURLEncodedBuilder"/>
<messageBuilder contentType="multipart/form-data"
class="org.apache.axis2.builder.MultipartFormDataBuilder"/>-->
<messageBuilder contentType="application/xml"
class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
<messageBuilder contentType="application/x-www-form-urlencoded"
class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
<messageBuilder contentType="multipart/form-data"
class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
<messageBuilder contentType="application/soap+xml"
class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
<messageBuilder contentType="text/plain"
class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
<messageBuilder contentType="text/xml"
class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
<!--messageBuilder contentType="x-application/hessian"
class="org.apache.synapse.format.hessian.HessianMessageBuilder"/-->
<!--messageBuilder contentType=""
class="org.apache.synapse.format.hessian.HessianMessageBuilder"/-->
<!-- <messageBuilder contentType="text/plain"
class="org.apache.axis2.format.PlainTextBuilder"/>-->
</messageBuilders>
Save axis2.xml file and restart the server. Now, the server will be running with binary relay enabled.

Step 3

In order to verify how message mediation happens with binary relay, create a simple pass through sequence and send few SOAP requests. If you enable DEBUG level logging for org.apache.synapse, you will notice the message with binary content as follows.
<ns:binary xmlns:ns="http://ws.apache.org/commons/ns/payload">PD94bWwgdmVyc2lvbj0nMS4wJyB
lbmNvZGluZz0nVVRGLTgnPz48c29hc</ns:binary>