Tuesday, July 16, 2013

[Webinar] Extending WSO2 Carbon for Your Middleware Needs

I am going to conduct a webinar on the $title. In this webinar we are going to cover the possible usages of the extension points provided by Carbon platform. Carbon is a very powerful middle-ware platform as it is... , however it provides enough flexibility to the developer if he/she wants to alter the default behavior.



Carbon Runtime View - diagram by sameeraJayasoma.































In this webinar we are going to cover topics such as ,

1. Authentication framework in Carbon
2. Deployment engine and how to introduce your own artifact deployment model
3. Component architecture in Carbon, and how it benefits.
4. How to make use of extension points to achieve monitoring requirements
5. etc.

I am going to take few use-cases and explain how we can achieve them using Carbon extension points. If time permits i'm hoping to do some demos as well. Interested ? :) Please register via this link,

http://wso2.com/library/webinars/2013/07/how-to-extend-wso2-carbon-for-your-middleware-needs



Saturday, June 29, 2013

Enabling SAML2 SSO for WSO2 Carbon Server, OpenSSO/OpenAM as the IDP

WSO2 Carbon products comes with in-built web-SSO authenticators. Within minutes, you can enable web-SSO for any WSO2 Carbon server using WSO2 Identity Server as the IDP. In this blog post we are using, OpenSSO/OpenAM as the IDP and do the configuration.

Pre-requisites


1. Download and install openAM/openSSO [download the war file from here]
2. Download the WSO2 product.

Setting up the environment

Configuring OpenSSO/OpenAM


openSSO provides two mechanisms to register an service provider,
  • Creating a SP fedlet
  • Setting up a SP using a meta file called sp.xml
In this post I'm using the latter approach.

  1. Configure the sp.xml file.

  • The given sp.xml sample file uses, https://localhost:9443/acs as the redirection URL. Configure it according to your environment. https:///acs
  • EntityID element of the sp.xml should match the corresponding value of ‘ServiceProviderID’ in the authenticators.xml file
  









urn:oasis:names:tc:SAML:2.0:nameid-format:transient







   


2. Go to Common Tasks -> Register Remote Service Provider link and select the sp.xml as the file    to uploaded and select a Circle of Trust.




   


3. Go to Federation ­> entity providers in the openSSO management console and select the
newly registered service provider.Select/tick response signing attribute.






















Under name ID format list, make sure you specify, ‘transient’ and ‘unspecified’ name ID
formats.

Setting up WSO2 Carbon Server

1. Enable the SSO authenticator and configure the IDP URL in authenticators.xml found under
$CARBON_HOME/repository/conf/security/authenticators.xml

10

/carbon/admin/login.jsp
https://localhost:9443/acs
http://localhost:8080/opensso/SSOPOST/metaAlias/idp<
/Parameter>
opensso





Change the following params accordingly,
  • ServiceProvideID - This can be any identifier. Doesn’t have to be a URL. However the configured value should be equal to the value we configured in the ‘’ in sp.xml
  • IdentityProviderSSOServiceURL - The URL of your IDP
  • idpCertAlias - This is the certificate that get used during response validation from the IDP. OpenSSO servers’ public key should be imported to the Carbon servers keystore with the alias name ‘opensso’

Exporting/Importing Certificates

Add the public key of the selected circle of trust in to the Carbon keystore(wso2carbon.jks) found
under $CARBON_HOME/resources/security/wso2carbon.jks. You can use Java keytool to do that.

-Exporting a public key

Here we will be using the default shipped openSSO keystore certificate. It has the alias name of ‘test’
and typically located in /home/opensso/opensso/keystore.jks. The default password is ‘changeit’. To
export the public key of ‘test’,

keytool -export -keystore keystore.jks -alias test -file test.cer

The public key will get stored in ‘test.cer’ file. you can view the certificate content with the command,

keytool -printcert -file test.cer

- Importing a public key to the wso2carbon.jks

Now import the ‘test.cer’ into Carbon key stores found under $CARBON_HOME/repository/resources/security/wso2carbon.jks

keytool -import -alias opensso -file test.cer -keystore wso2carbon.jks

view the imported certificate using the command
keytool -list -alias opensso -keystore wso2carbon.jks -storepass wso2carbon

Testing the Environment


Try accessing the carbon management console. (eg. https://localhost:9443/carbon) The call will
redirect you to IDP (openSSO login page). Enter username and the password in the openSSO login
page. Once you properly authenticated you will redirect back you to the WSO2 Carbon product login
page as a logged in user.
Please note: The authenticated user has to be in the Carbon servers’ user-store for authorization
(permission) purposes. Since the above described test environment does not share the same user
store between IDP (openSSO server) and SP (Carbon server) i created a user called ‘amAdmin’ in
Carbon server user store. Otherwise there will be a authorization failure during the server login.

"[2013-06-17 10:22:04,601] ERROR
{org.wso2.carbon.identity.authenticator.saml2.sso.SAML2SSOAuthenticator} - Authentication
Request is rejected. Authorization Failure."

Please Note: As of this writing, there are interop issues with released version of Carbon servers and OpenSSO. I have created a JIRA here, along with the patch to rectify the issue. Future Carbon releases will fix this issue.



Friday, April 26, 2013

Multiple Profiles and Shared Bundles With Eclipse P2 : Case Study


WSO2 Carbon is an OSGi based server framework. Number of WSO2 middleware products use Carbon as their base platform. Carbon make use of Eclipse Equinox as its OSGi framework implementation and use Eclipse P2 as its provisioning framework.

Problem Description

Some of the Carbon products has their own deployment patterns during actual production deployments. However to give a smooth evaluation experience the same product is available as a 'ready to go' all in one zip distribution. For an example, WSO2 Business Activity Monitor(BAM) allows enterprises to batch process their collected enterprise data and present it by means of human readable graphs/etc. A real production deployment includes, three main parts.

Figure 1



















1. Receiver component responsible for receiving the events
2. Storage and Analyzer will analyze the stored data in batch mode.
3. presentation component will present the processed data by means of dashboard elements.

Even though these components are distinct by their functionality and by their deployment, they are all part of an one product. The first experience of the middleware developer should be seamless, means Business Activity monitor product should include all these components. However having all the components in the product resolves to a larger memory footprint during the run-time. During an actual deployment users have to deploy three seperate BAM instances even though they are interested only in one functionality of the product at a given time - they can't deploy only the receiver bit of BAM.

All of WSO2's Carbon based middleware products are available in the cloud as a multitenanted PAAS offering. This resolves to a atleast one product instance from each of the product types (Enterprise Service Bus, Application Server,etc). If we take per product distribution size to be ~100MB, then ten product instances will resolve in to 1GB. However we want to make our cloud offering available to users as a downloadable archive. This will enable them to easily download/setup their own private PAAS and evalute it - means total distribution size matters.

Solution 1 : Handling multiple profiles

Figure 2




















There is one important aspect in the above described BAM scenario. All the different deployment entities can share the same configuration. Being differnt component of BAM server, the configuration requirement of the three different components are more or less the same. If we can selectively activate some of these functionalities using a switch mechanism, that would do the trick. The Eclipse P2 has a concept called profiles. Once you provision your OSGi application using P2, the application get assigned a profile. During the server startup, only the bundles that were provisioned under a particular profile get started. We created seperate profiles for each BAM component, namely receiver, analyzer and dashboard. During the server start-up user can select the profile by means of a system property. The default profile contains functionality of all of the BAM components just like good old days. The notion of profile is a logical partition that works with server provisioning framework. Each of these profiles share the same set of bundles in a shared repository, hence there is no increase in the distribution size.

Solution 2 : Shared bundle pool during run-time

Figure3


The solution for the second problem, can be addressed using P2 profiles and shared bundle pools as well. However there is a suttle difference in the approach. Unlike the BAM use case, each of these different products have their own configuration area and data/persistance locations. We can tackle this requirement by completely removing the bundle pool location from the product distribution and placing it outside of all products. Each product will have their own configuration/distribution area and all the products will point to the same bundle location, hence distribution size will be much much less. The use case demands runtime isolation (running two or more products parallely using the same bundle location) and we can successfully achieve the same using P2 profiles and bundle pooling.

Pitfalls

P2 bundle pooling functionality coupled with roaming (the ability to move your provisioned application from your original location - relies on relative paths) seems to be broken. However with the help from P2 dev-list we figured out a workaround.

Images
http://cdn3.iconfinder.com/data/icons/humano2/128x128/mimetypes/application-x-jar.png
wso2 BAM product presentation slides


Monday, April 15, 2013

MQTT Transport for Axis2/Synapse

MQTT is an application layer broker based pub/sub protocol built on top of TCP/IP. It is very lightweight and hence ideal for usage in network/memory/computing power constrained environments. If I quote the MQTT spec, the protocol features,
  1. Pub/Sub message pattern
  2. Small transport overhead, fixed length header being only 2 bytes
  3. Supports three QOS for message delivery, at-least once, exactly once and at-most once
  4. etc.
The ability to operate under constrained environment make this protocol an ideal candidate for embedded device communication/pervasive computing.  However smaller footprint is always better. Why not MQTT in enterprise integration ? :)

There are number of MQTT broker implementations out there (you can find the original spec here). Right now, MQTT transport is undergoing OASIS standardization process. Mosquitto is one such broker implementation of MQTT. Eclipse Paho project provides MQTT client library in Java. 

Apache Synapse is  a popular open source enterprise service bus (ESB). Synapse mediation engine relies on Axis2 transport framework to receive messages. Axis2/Synapse  supports many transports out  of the box. I set out to implement a MQTT transport for Axis2/Synapse so that MQTT transport is available for EIP scenarios/etc with Synapse ESB.

The sample message flow,


Setting up the environment and running the code,

1. Download the MQTT broker from Mosquitto.org and install
2. Download Apache Synapse and install. Due to some API compatibility reasons, the code only works with trunk version of Synapse (1.7.0-SNAPSHOT) as of this writing.
3. Deploy the provided proxy service configuration 'SampleProxy.xml'
The provided proxy service read from a Mosquitto broker topic and writes to a publicly hosted MQTT broker topic.



         
Next configure the MQTT transport definition in axis2.xml transports section. Here we configure the transport listener and transport sender.

        
                localhost
                1883
                esb.test.listener
                esb.test2
        
    


    

simply copy replace the original axis2.xml file found in synapse distribution with provided axis2.xml.
Now add the eclipse Paho MQTT client jar and the axis2-mqtt transport jar to synapse classPath. That is to $synapse_home/lib/

4. Start Synapse and Mosquitto broker
5. Publish message to topic1 using provided client. Edit the endpoint addresses and payload accordingly.

Once you publish the message to the topic, the listening ESB transport will get notified and proxy service will write the message to the target endpoint.

6. Read/Observer the output in topic2 using the provided receiver. The online hosted MQTT broker is configured as the target endpoint. The http bridge allows you to see the currently published topics to the broker.

I have only demonstrated, MQTT -- > MQTT scenario. The Axis2 transport framework allows you to transport switch messages. Hence X --> MQTT / MQTT--> X is possible. (X is a Axis2 transport). The code is very much in its initial state. The next step would be to improve this and contributing to Axis2 project.

Thursday, April 11, 2013

Dealing with Occasional Message Bursts : Message Broker Use Case

Recently I came across the following requirement,

An organization has a message delivery network and an application that makes use of those messages (process them). The delivery network directly communicates with the message processing application. Things seems to be working fine on a regular day. However if the load(incurred by the delivery network) is high, some of the messages may get lost before they get processed (overflow of applications' task queue).

Message brokers are designed to cater the exact scenario. Enterprises rely heavily on their legacy systems and changing all existing integration points may not be the right solution and will never work. In the above scenario, we can place a message broker in between the message producer and message consumer. By introducing a message broker we,

1. Decouple producer/consumer in time and space (two parties need not to be functioning at the same time and the don't have to know each others existence )   
2. Reliable message processing/delivery by means of persistence and transactions.



I implemented the POC scenario using WSO2 ESB and WSO2 MB. Please find the configuration files and source code in the this location. ESB used for its JMS transport support (you don't have to change the producer code).

How to use POC config/code;

1. replace the the original axis2.xml and jndi.properties file found in WSO2ESB distribution with provided ones. Here I have enabled JMS sender in axis2.xml and configured connection factory params in jndi.properties file.
2. Create a proxy service in WSO2 ESB using provided StockQuoteProxy.xml. This proxy will accept HTTP request and write them in to a MB queue.
3. Create a new queue named 'StockQuotesQueue' in WSO2MB: this is the queue we are writing to and reading from.
4. Start server and run the servers, send some soap messages to proxy services, so that those get written to MB. 
5. Run the Receiver to retrieve messages from MB queue.

please configure ports and hosts accordingly. Refer WSO2 MB documentation as well.

Application Profiling for Memory and Performance

Inspired by the experiences gathered during recent application profiling sessions at WSO2, we did a webinar on memory and performance tuning. Below are the slides.