WSO2 Stratos - Introducing WSO2 middleware Platform as a Service (PaaS)

Yesterday we released our newest integrated cloud middleware platform, WSO2 Stratos. It is now online and ready for use!

For the past few years, WSO2 has been doing many releases based on revolutionary Carbon platform, which helped to consistently improve the platform with introducing latest state-of-art technologies. The initial releases of Carbon product platform intended to improve the features of the individual products. For example, a lot of core features were introduced to WSO2 ESB, WSAS, Governance Registry etc.. Then we focused on ease of integration and more component based model. We introduced Equinox based provisioning model to build your SOA platform by picking and choosing the components as and when you need.
Then, the core product platform has been enhanced to support multi-tenancy. With the multi-tenant supported architecture at hand, our brilliant development team was able to introduce the first ever comprehensive middleware PaaS. Why is this so important?
Now, WSO2 Carbon middleware platform is available on Cloud. Anybody can try out it online by accessing http://cloud.wso2.com
Not only that, the code is 100% opensource! As far as I know, this is the first ever opensource cloud PaaS offering.

Without digging in to more details, lets try WSO2 Stratos out.

Step 1

As most of you are familiar with Google Apps, without any guidance you will be able to start using WSO2 Stratos. However, I will start from the scratch. Access http://cloud.wso2.com. This will bring up WSO2 Stratos Manager, which is the is the point of entry for all WSO2 Cloud Services such as Application Server, Business Activity Monitor, Gadget Server, Governance, Identity and Mashup Server. Click on "Register" in order to create an account for you (your organization).



This will direct you to "Select a domain for your organization" page. Specify the domain for your organization and check its availability by clicking on "Check Availability". Select "Next" to sign up your organization.



Enter the required information in "sign up your organization" page. If your registration is successful, you will see a confirmation message. With this, you just created the administration account for your organization. You will receive an email to validate Email instructions specified by you. Click on the link given in the email to access the Stratos Manager login page.
Now, you can log in to the Stratos Manager, by giving the admin credentials you have just specified during the registration process.

Step 2

After log in to Stratos Manager, you will see the cloud services list offered by WSO2 Cloud service platform.



In addition to the cloud services, you can configure a new theme for your account or you can manage new user accounts (add new users, grant necessary permissions to them etc..) through the Stratos Manager.

Suppose, you need to use cloud application server out of the seven cloud services enabled by default. Click on "Cloud Application Server" link. This will bring up "WSO2 Stratos Application Server" login page as follows.



Log in to app server by providing the same admin credentials given above. (You may question why a separate login is required. We have not provided Single Sign On support between Stratos Manager and Cloud services in the alpha1 version. This will be available soon)
The Cloud application server Home page will be shown as follows after you log in to the application server.



If you are already familiar with WSO2 WSAS, this will not make you feel strange. You could either deploy services, secure them, monitor and do a lot of tasks. In addition to that, WSO2 Cloud Application Server, is now provides with web application deployment support. You could use this as your servlet container!

Similarly, you can try out the rest of the cloud services.

How to specify a custom scope for WS-Discovery target service

As I explained in a previous blog post, WS-Discovery support is included in the latest WSO2 carbon release (3.0.0).
WSO2 WSAS can be considered as a target service hosting provider. A default scope is assigned to all the target services discovered by a Discovery Proxy.
If a discovery client looks for a service based on the service type, or some scopes, the client sends probe message to the DiscoveryProxy. Then the proxy responds back to the client with the appropriate service metadata.
Suppose we need to specify a scope for the services deployed on WSAS (target services). How can we do that?

You can specify the service scope(s), by adding a parameter in the services.xml of the Axis2 Service archive (*.aar) as follows.

<parameter name="wsDiscoveryParams">
<Scopes>http://wso2.org/engineering</Scopes>
</parameter>

Then, you can probe the services either through WS-Discovery Control Panel in WSO2 ESB management console as shown here or using WS-Discovery Client API as follows.

DiscoveryClient client = new DiscoveryClient(cfgCtx, discoveryProxyURL);
TargetService[] services = client.probe(types, scopes, matchingCriteria);

Hierarchical service deployment support in WSO2 WSAS-3.2.0

WSO2 WSAS-3.2.0 is the latest version of WSO2 Web Services Application Server which consists of some new features as well as a lot of bug fixes. Hierarchical service deployment is one of the new features included in the latest WSAS.
Hierarchical service deployment model allows you to deploy two (or more) different versions of the same service in a very easy manner.
Lets see how multiple versions of the same services can be deployed on WSAS-3.2.0

Pre-requisites:
Download WSO2 WSAS-3.2.0 from here

Step 1

Start WSO2 WSAS by running wso2server.sh{bat} from WSAS_HOME/bin
Access management console using https://localhost:9443/carbon and log in with the default credentials(admin/admin)

Select Axis2 Service from the left navigation menu.



You will notice there is an input text box, Service Hierarchy. Here you can specify a service path. eg:- /marketing/test
Browse a service archive (eg:- Axis2Service.aar) in your local file system and click on Upload.
The service will be deployed successfully, go to the service list page and you will the service is listed there as follows. The service name is prefixed with the hierarchy path you have given when deploying the service (marketing/test/Axis2Service)



Step 2

Now, we are going to deploy a different version of the same Axis2Service. Access the Manage --> Services --> Add --> Axis2 Service page and specify a new service hierarchy (eg:- /sales/test)
Browse the same service archive which have deployed in the previous step (Axis2Service.aar) and click on upload.

Now, you will notice a different version of the same service, sales/test/Axis2Service listed in the service management page.

Likewise, you can deploy many versions of the same service and make use them in your SOA infrastructure. Hierarchical service deployment facility can be used in Spring, Jax-WS and Jar services as well.

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:

Download WSO2 Governance Registry-3.5.0, WSO2 WSAS-3.2.0 and WSO2 ESB-3.0.0

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

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>

How to invoke a secured web service without maintaining a policy at the client side

When we call a secure web service, the most common way of invocation is to use a policy which is compliant with the service policy at the client side. Usually, the client side policy is placed at the client file system. We have observed how this is done in few posts which published earlier.
However, there is a major drawback in this method, user has to change the client policy whenever the service policy is changed.
In order to overcome this limitation, we can use Axis2 DynamicClient to derive client policy by referring to the service WSDL which essentially keeps the service policy.

Lets see how this can be done using WSO2 WSAS-3.1.*

Pre-requisite:

Download and install WSO2 WSAS-3.1.*

Step 1

We are going to secure the default HelloService shipped with WSAS. We configure HelloService with "Sign and Encrypt - X509 Authentication" policy. In order to do that, first start WSO2 WSAS server by running wso2server.sh which is located at WSO2WSAS_HOME/bin directory.
Then, log in to the management console by accessing https://localhost:9443/carbon

Select the default HelloService and navigate to the service dashboard. Click on Security and configure Sign and Encrypt - X509 Authentication security scenario as shown below. Make sure to use wso2carbon.jks as trusted key store and private key store.



Thats all we have to do at the server side. Lets write a client to invoke the service.

Step 2

Here we are going to use Axis2 Dynamic Client which is an extension of the ServiceClient class.
First, instantiate a dynamicClient object using RPCServiceClient by passing ConfigurationContext, WSDL Url of the service, the QName of the service and the port name as parameters.

RPCServiceClient dynamicClient = new RPCServiceClient(null, new URL("http://localhost:9763/services/HelloService?wsdl"),
           new QName("http://www.wso2.org/types", "HelloService"), "HelloServiceHttpSoap12Endpoint"); 

Then, we can engage rampart module as follows.

dynamicClient.engageModule("rampart");

Now we should update the client side policy with the rampart-config programatically.

      RampartConfig rc = new RampartConfig();

      rc.setUserCertAlias("wso2carbon");
      rc.setEncryptionUser("wso2carbon");
      rc.setPwCbClass(SecureClient.class.getName());

      CryptoConfig sigCryptoConfig = new CryptoConfig();

      sigCryptoConfig.setProvider("org.apache.ws.security.components.crypto.Merlin");

      Properties prop1 = new Properties();
      prop1.put("org.apache.ws.security.crypto.merlin.keystore.type", "JKS");
      prop1.put("org.apache.ws.security.crypto.merlin.file", "/home/charitha/products/wsas/wso2wsas-3.1.3/resources/security/wso2carbon.jks");
      prop1.put("org.apache.ws.security.crypto.merlin.keystore.password", "wso2carbon");
      sigCryptoConfig.setProp(prop1);

      CryptoConfig encrCryptoConfig = new CryptoConfig();
      encrCryptoConfig.setProvider("org.apache.ws.security.components.crypto.Merlin");

      Properties prop2 = new Properties();

      prop2.put("org.apache.ws.security.crypto.merlin.keystore.type", "JKS");
      prop2.put("org.apache.ws.security.crypto.merlin.file", "/home/charitha/products/wsas/wso2wsas-3.1.3/resources/security/wso2carbon.jks");
      prop2.put("org.apache.ws.security.crypto.merlin.keystore.password", "wso2carbon");
      encrCryptoConfig.setProp(prop2);

      rc.setSigCryptoConfig(sigCryptoConfig);
      rc.setEncrCryptoConfig(encrCryptoConfig); 

Next, we can add the above rampartConfig to the service policy derived from the wsdl as follows.

       Map endPoints = dynamicClient.getAxisService().getEndpoints();
       AxisBinding axisBinding = ((AxisEndpoint) endPoints.values().iterator().next()).getBinding();
       Policy policy = axisBinding.getEffectivePolicy();
       policy.addAssertion(rc);
       axisBinding.applyPolicy(policy); 

Now, we can invoke the service using dynamicClient by passing the parameters as an object array and return types as an class array.

Object[] returnArray = dynamicClient.invokeBlocking(new QName("http://www.wso2.org/types", "greet"),
                new Object[]{"hello"}, new Class[]{String.class});

        System.out.println(returnArray[0]); 

Thats all! To complete our scenario, make sure to have callback handler method similar to the one below.

public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {

        WSPasswordCallback pwcb = (WSPasswordCallback) callbacks[0];
        String id = pwcb.getIdentifer();
        if ("wso2carbon".equals(id)) {
            pwcb.setPassword("wso2carbon");
        }

Visits to this blog - 2009 (significant increase of visitors)

I published a stat report about this blog in February 2009, which showed 30037 unique visitors during 2008-2009. Here is the StatCounter report for 2009-2010.




There were 55,839 unique visitors, 25000 increase compared to last year. I could not write much blog posts during the last year due to frequent project releases. However which did not seem to affect my user community. This blog was started to help novice users in SOA/Web Service space and Software Quality Assurance community to share my ideas, tips and specially How-Tos. I always refrained from posting any non-technical subject matter in here. I was able to reply most of the questions raised in blog posts, however there were situations that I could not follow the comments and reply. I will try my best to continue writing much more useful blog posts and help users.