Monday, November 12, 2012

Dynamic Performance Management in Multi-tenanted Business Process Servers Using Nonlinear Control

This conference paper "Dynamic Performance Management in Multi-tenanted Business Process Servers Using Nonlinear Control" is our latest publication which discusses the detail on our work on performance isolation aspect in a multi-tenanted business process execution runtime. It was recently published in 10th International Conference on Service Oriented Computing (ICSOC 2012), pp. 206-221. Authors of this paper are Tharindu Patikirikorala, Indika Kumara, Alan Colman, Jun Han, Liuping Wang, Denis Weerasiri and Waruna Ranasinghe.

Abstract of the paper is
The methodologies to develop multi-tenanted architectures have been investigated in the recent literature due to the popularity of cloud computing. A number of challenges need to be overcome if multi-tenanted architectures are to be effective and efficient. Among the challenges is the management of performance properties while effectively sharing the limited resources between the tenants. This work presents an approach to design such a management system for a multi-tenanted business process server. This approach not only enables performance to be maintained at different levels for different tenants depending on their priorities, but also autonomously detects the overloads of aggressive tenants and dynamically changes the control objectives to safeguard the business operations of other tenants. The novelty of the proposed approach is the use of the nonlinear feedback control. The experiment results indicate that the proposed nonlinear control approach achieves the objectives much better compared to the existing fixed and linear control techniques.

This paper can be accessed from here.

Relavant articles

Friday, September 14, 2012

The New Beginning

Two years back on 13th of September, I joined WSO2 after my undergraduate studies from University of Moratuwa. WSO2 was a wonderful place for me (as a fresh graduate) to start my career. And I have been to several software companies in different parts of the world and I haven’t experience such a friendly culture and a freedom from any other places.

Yesterday, after exactly two years I officially started my PhD studies at University of New South Wales with an induction for postgraduate researchers. I still feel like I am entering to a pitch black tunnel and I am still not sure when/how I will find the other end of the tunnel :).

Anyway my life is not all about computer engineering. There are several other stuff on my bucket list like being a photographer, traveler, licensed scuba diver, etc. The following picture of me is a tryout of all above :).

Scuba diving at Hikkaduwa
Scuba diving at Hikkaduwa
So looking forward to pursue the happiness with a new set of challenges :).

Wednesday, August 29, 2012

A Scalable Multi-tenant Architecture for Business Process Executions

The journal paper “A Scalable Multi-tenant Architecture for Business Process Executions” is our latest publication which discusses in detail our work on extending scalability and multi-tenancy support to Business Processes. It was recently published in International Journal of Web Services Research (IJWSR), vol. 9(2), pp. 21-41, April-June 2012. Authors of this paper are Milinda Pathirage, Dr. Srinath Perera, Indika KumaraDenis Weerasiri and Dr. Sanjiva Weerawarana.

Abstract of the paper is
Cloud computing, as a concept, promises cost savings to end-users by letting them outsource their non-critical business functions to a third-party in pay-as-you-go style. However, to enable economic pay-as-you-go services, the end-users need Cloud middleware that maximizes sharing and support near-zero cost for unused applications. Multi-tenancy, which let multiple tenants to share a single application instance securely, is a key enabler for building such a middleware. On the other hand, Business processes capture Business logic of organizations in an abstract and reusable manner, and hence play a key role in most organizations. This paper presents the design and architecture of a scalable Multi-tenant Workflow engine while discussing in detail the potential use cases of such architecture. Primary contributions of this paper are motivating workflow multi-tenancy, and the design and implementation of a scalable multi-tenant workflow engine that enables multiple tenants to run their workflows securely within the same workflow engine instance without modifications to the workflows. Furthermore, the workflow engine supports process sharing and process variability across the tenants and discusses its ramifications.

Paper can be accessed from here.

Monday, August 27, 2012

A journey through the history of computers

Computer History Museum, a place I like a lot in Mountain view, California. It’s the world’s largest history museum which explores the computing revolution and its impact on our lives. The journey starts from earliest calculating devices like "Abacus" to every landmark in the modern digital era.

Some of the pictures from the visit.

At the entrance
Who invented the computer?
The evolution of programming languages
An early IBM server
An early Google server
Some thoughts about .com boom and bust
On the way to the museum 

Saturday, August 25, 2012

WSO2 BPS v3.0.0 Beta is out

WSO2 BPS v3.0.0 Beta is out The release candidate of WSO2 BPS v.3.0.0 was released with lot of long awaited features and with a load of bug fixes.

Some of the new features in the Beta release are
  • WS- Human Task support 
  • WS- BPEL4People support 
  • BPEL Instance Illustrator 
  • BPEL deployment descriptor editor 
  • Improved BPS management console and BPS documentation 

You can download the binary distribution from here.

Monday, August 20, 2012

1st Google+ Hangout

This is cool and runs smooth with an average 3G cellular connection.

Thursday, August 16, 2012

Configuring a log4j logger to WSO2 ESB main sequence

Configuring separate loggers to different proxy services is a useful feature in WSO2 ESB.
You can do this by setting a log appender as follows.

Here “__SynapseService” is the SERVICE_LOGGER for the main sequence. Similarly you can use the name of your proxy service as the SERVICE_LOGGER to manage logs separately for each of those proxies.

Thursday, April 19, 2012

WS-BPEL 2.0 Extension Activity Development for WSO2 BPS

There are several ways to extend WSO2 BPS runtime functionalities such as
  • BPEL extension activities
  • Custom XPath extensions
  • Message Exchange Interceptors etc.

BPEL extension activities enable a pluggable architecture that allows for registering third party functionality to the WS-BPEL 2.0 execution runtime.
There are several BPEL extension activities supported by WSO2 BPS and with the upcoming WSO2 BPS 3.0.0 release, we are going to introduce several new BPEL extension activities such as

Here I have written a simplest extension activity implementation with a sample BPEL process so, a BPEL developer can re-use and extend it to have their own implementation.
The extension activity implementation can be found from

To come up this implementation, I followed this blog-post from Waruna Ranasinghe and it brings you more in-depth knowledge on BPEL extension activity development.

Friday, April 13, 2012

Wishing you a very happy new year 2012!

Since it is the festive season of Sinhala and Hindu new year for all Sri Lankans, I wish you all a happy and prosperous New Year 2012!. Also my team is celebrating the new year dawn with their loved ones except for few guys at on-site work outside LK.

With just the beginning of the vacation, we spent few days at Heritence Ahungalle, a beach hotel on the west coast of Sri Lanka. I had a luxury suite thanks to a good old friend from school days :). But we spent most of the time in the swimming pool and the beach due to the hot and humid weather.
Also the hotel is quite renowned for its sustainable building architecture by Geoffrey Bawa.

Related Posts

Thursday, April 12, 2012

Development and Deployment Best Practices for WSO2 BPS

This post contains an updated version of best practices related to developing and deploying business processes on WSO2 BPS (Business Process Server).

Table of Content
  • Deployment best practices
  • Development best practices
Deployment best practices
Default distribution of WSO2 BPS comes with embedded H2 database as BPEL engine's persistence storage and other settings which are suitable for use in development environment. But when you are going to production with WSO2 BPS, there are several configurations you need to change according to your production requirements. These configurations will change based on how much requests BPS is going to handle per second, your auditing and monitoring requirements, performance requirements and nature of your process. Following are the main things you should do before going production with WSO2 BPS.
  • If the deployed BPEL processes has any conflict like
        - Same BPEL process is deployed under several different package names
        - When a deployed BPEL process has an existing service name
    Those deployment issues are displayed under the relevant package in "Deployed Packages" page.
  • Configure external database server like MySQL as your persistence storage instead of embedded H2 database. You may experience slight performance gain for simple BPEL processes with H2 database, but when it comes to multiple concurrent requests and complex processes H2 can't server your performance needs.
  • Configure multi-threaded Http connection manager connection pool settings to suits to your BPEL processes. There are two configurations in Http connection manager. One is max total connections and other is max total connection per host. These settings will depend on number of concurrent requests BPS needs to handle and number of external service calls incorporated per process instance.
  • Configure BPEL process persistence - If you are implementing processes with request-response interaction model use in-memory processes instead of persistence processes. Whether to use in-memory or persisted processes will mainly depends on your business use-case.
  • Configure even-filtering at process and scope level. So you can save lot of database resources by reducing number of events generated.
  • Use process-to-process communication, if you are calling one BPEL process from another BPEL process deployed in the same BPS instance, it's better to use process-to-process communication to reduce overhead introduce by additional network calls.
  • In the default WSO2 BPS distribution, the size of a fault message (which is stored in BPEL DB) is limited to ~4KB.

    eg - See the following BPEL database SQL script
    So if a deployed BPEL process is expected to handle larger size of fault messages, the above database script should be modified and re-built from the source distribution accordingly.
  • Also make sure to configure process instance cleanup. Large number of process instance data will be accumulated in the BPEL engine persistence storage if you persisted processes, so to reduce performance overhead introduced by database size you should configure instance cleanup.
  • In addition to above things you should be careful when deploying WSO2 BPS in virtualized environments. We have seen random increase of network latency and random performance degradation when running on VMs.
  • If the BPEL is going to be deployed as a WS-secured service then, it's recommended to remove all the http endpoints from the process WSDL. Else the WSDL generation for the particular BPEL process will get failed.

    eg -
Note 1: Above mention configuration optimizations are true for Apache ODE also.

Note 2: Above mention best practices are valid for WSO2 BPS 3.0.0-SNAPSHOT and upward. You can do the above optimizations to older versions WSO2 BPS, but configurations and configuration mechanisms will be different. All of the above optimizations are supported by Apache ODE, but configuration is very different from WSO2 BPS.

Development best practices
When it comes to BPEL development in WSO2 BPS, BPEL developer need to aware some scenarios which could lead to some conflictions. Those are listed as follows.
  • It's not encouraged to refer the same variable as the input(in <receive/>) and output(in <reply/>) of the process. This could lead to problems if the message headers (<Header/> in SOAP <Envelope/>) in output variable are processed at the client-end. One possible use-case is when the process is secured if the input and output variables are same then the headers of the input will be used when the output is sent back to the client. So it could prone to errors if those security headers are not expected at the client end.

Sunday, March 25, 2012

RESTful API access via Business Processes

This is something I wrote for fun :). These samples demonstrate on how to invoke REST API methods like GET and POST from a BPEL process running on WSO2 BPS.
Here I used a RESTful API which is enabled by GoodReads, a social networking site for book readers.
You need to attain your own API key to access GoodReads REST API. So make sure to read the README.txt which explains on how to get your own API key.
I’m working on BPEL samples which use PUT and DELETE methods and will update the post once they are done.

Related Posts

Friday, March 23, 2012

Manipulating HTTP headers via Unified-Endpoints

WSO2 Carbon platform supports unified-endpoints(UEPs) to configure partner endpoints which are used in the BPEL processes. In more general terms, UEPs facilitate for a generalized way of configuring endpoints taking quality of service into the picture.
The following sample provides a guide on how to manipulate HTTP headers for an request message of the given endpoint.

Related Posts

Sunday, March 18, 2012

BPEL activity failure and recovery

In Business/Scientific work-flows, activities like invoking a partner service end-point could failed due to several reasons like network inconsistencies(non-deterministic), erroneous configurations(deterministic) etc. So the work-flow administrator should be able to retry and cancel those activities.
The administrator can retry activity any number of times, so the business logic related to the particular activity gets repeated until the particular process instance leads to “completed” or “fault” state.
Or the administrator can cancel the failed activity, so the particular process instance leads directly to “fault” state.

BPEL activity recovery is an in-build feature comes with WSO2 BPS and at the moment the implementation supports for failed <invoke/> activities. So a process administrator can monitor activity states via the BPEL visualization and retry or cancel them based on their preference.

An screenshot of a failed <invoke/> activity named “InvokeCreditRating” and its recovery options...

Thursday, March 15, 2012

BPEL Deployment Descriptor Editor

In previous releases, a BPEL Deployment Descriptor Editor was available only for BPEL developers via BPEL editor of WSO2 Carbon Studio. So BPEL process administrators had to change the deployment descriptor configuration file (deploy.xml) by hand and re-deploy back to the system.

The next major release of WSO2 BPS will be out with BPEL Deployment Descriptor Editor Support via WSO2 BPS administration console. So BPEL process administrators can configure process/instance/scope event generation, instance cleanup etc. at run-time. Also it represents the other configuration details like MEX interceptors, process properties, provided services, partner service etc. which make the BPEL process administrator’s life much easier.

BPEL deployment descriptor editor for WSO2 BPS administration console is a contribution from Ishara Premadasa from University of Moratuwa.

A screen shot of the BPEL Deployment Descriptor Editor.

Tuesday, March 6, 2012

BPEL visualization - WSO2 BPS

Initial version of BPEL visualization feature was added to WSO2 BPS as a result of my first internship project at WSO2. It had some functional requirements like,
  1. BPEL process instance details visualization
  2. BPEL process visualization with different abstractions etc.
  3. BPEL activity filtering
With the next release of WSO2 BPS, its new BPEL visualization feature is going to be a completely new design to meet the requirements as mentioned above. This work was a result of research related to Process views carried out by Dr. David Schumm and his research group from University of Stuttgart.
The presentation on this work by Dr. David Schumm at WSO2Con-2011 can be found from here.

Some of the screen shots of the unfinished work...

Process Management View

Instance Management View

Process Management View for a Complex Workflow

Instance Management View for a Complex Workflow

How install the BPEL features via Feature Manager

This blog post explains how to install BPEL specific features to WSO2 ESB.

Tested Environment
  • WSO2 ESB 4.0.2 (Based on WSO2 Carbon 3.2.2 release)

If you consider WSO2 products like WSO2 BPS, WSO2 ESB, WSO2 AS etc. all those products can be considered as a collection of solution specific features included on top of WSO2 Carbon platform. As an example, WSO2 BPS is a collection of features which facilitate BPEL process/instance management, BPEL process runtime management etc. included on top of some other features provided by WSO2 Carbon platform. So theoretically you can convert a WSO2 Carbon distribution to WSO2 BPS by including those BPEL specific features.

How to determine the correct BPEL version compliant with the target server
We can do this easily via the feature manager provided by WSO2 Carbon platform. Here, the tricky part is user have to specify the correct version of BPEL feature to be installed on target server. This is solely depend on the version of the WSO2 Carbon platform in which the target server was released. Let me elaborate this with an example. eg - To install BPEL features to WSO2 ESB 4.0.2, first find the related WSO2 Carbon platform version. This can be determined by the version of $ESB-HOME/repository/components/plugins/org.wso2.carbon.core-x.x.x.jar. So if WSO2 ESB 4.0.2 is the target server, then the version of org.wso2.carbon.core jar would be 3.2.2. So the relevant BPEL feature version is 3.2.2.

Step by step guide to install a feature via feature manager
Once we figure out the right BPEL feature version we can add it via the Feature Manager. Please refer the following documentation on how to install a feature via feature manager. Once all the BPEL 3.2.2 features are installed in WSO2 ESB 4.0.2 and once the server restarted, there’ll be a separate menu item is appeared for BPEL features as follows.

Monday, March 5, 2012

How to invoke a secured webservice through BPEL

Engaging Quality of Service(QoS) for a partner web service endpoint in WSO2 BPS is facilitated by Unified Endpoint(UEP) feature. Not only QoS, but also, protocol specific properties like setting “ReplyTo” header for the outgoing message can be configured via UEPs. To get some more idea on UEPs please refer this post.

This post describes how to invoke a secured web service through a BPEL process using an UEP.

Tested Environment
  • WSO2 BPS 2.1.2 (based on WSO2 Carbon 3.2.0) release and WSO2 BPS release based on WSO2 Carbon 4.0.0
A sample of referring the security policy in the Unified-Endpoints can be found via this Unified Endpoint  in this sample BPEL Loan Process
This policy can be maintained outside from the BPEL artifact as well.

eg - Referring to a policy maintained in the file system - Use the absolute path for the policy in UEP.

eg - Referring to a policy maintained in the configuration registry - Use the registry specific path for the policy in Unified Endpoint.

Maintaining an policy outside from the BPEL artifact becomes very useful when governing policies which are used by multiple BPEL processes in multiple WSO2 BPS instances.

Unified endpoints for BPEL Processes

WSO2 Carbon platform supports unified-endpoints(UEPs) to configure partner endpoints which are used in the BPEL processes. In more general terms, UEPs facilitate for a generalized way of configuring endpoints taking quality of service in to the picture. So a particular UEP configuration can be used across the carbon platform to configure security in a partner endpoint in BPEL process and to configure WS-Addressing in a WSO2 ESB endpoint.

This post provides a guide on how to properly configure a partner endpoint in a BPEL process.
Tested Environment :
  • WSO2 Carbon 4.0.0 based releases 

Please take a look at Async-Server sample which is a sample BPEL process which uses an UEP to configure the target endpoint of a partner service.

If you are interested in other supported constructs by UEPs, please refer this xml schema which provides the current supported functionality like setting “ReplyTo” header.

So where is this UEP configuration actually engaged to a partner endpoint?. This is configured at the deploy.xml which declares the particular partner service as follows. Please refer the same sample mentioned above.

If you look at the mentioned sample above, UEP configuration is located inside with the BPEL artifact.
But on the other hand, an UEP can be maintained outside from the BPEL artifact. So it can be located in the file system or registry. Maintaining an UEP outside from the BPEL artifact becomes very useful when governing endpoints which are used by multiple BPEL processes in multiple WSO2 BPS instances.

eg - If the UEP to be maintained in the file sytem - Use the absolute path for the UEP in deploy.xml

eg - If the UEP to be maintained in the registry - Use the registry specific path for the UEP in deploy.xml

Please refer this UEP on configuring security for a partner service via a UEP. More information on this can be found from this post as well.

Monday, January 30, 2012

Diving into the blue - Sri Lanka

I was diving in a 10-12 meters depth of down the ocean floor where roughly 1km away from Hikkaduwa coast line. My ultimate target was to capture some cool pics of coral reefs and fish. So I stopped for a while and took some and moved on. After a few seconds I got a bad leg cramp and I looked around for my buddy for the help. At that moment I just realized my buddy has already swam out of my visible range. It was also dangerous to swim to surface suddenly due to huge pressure difference. I waited for a while and little by little reached to the surface. I met my buddy there and he helped me to recover back.
That’s my most recent experience and a foolish mistake I made while diving.
Sometimes unexpected could happen anytime. On the same dive some thing that happened to me twice was, the camera in my hand was tangled with the air regulator without knowing and the regulator popped out from the mouth when I swung the hand :).
And here are some uncut clips from the dive.

Anyway there’s a whole new world under the ocean. But it’s something hard to predict from outside and feel it. You have to go underwater and see what’s out there.

Getting things ready

Horizontal Format Data Mining with Extended Bitmaps - Extended version

We (Buddhika De Alwis, Supun Malinga, Kathiravelu Pradeeban and I) published the extended version of our research paper titled “Horizontal Format Data Mining with Extended Bitmaps” at International Journal of Computer Information Systems and Industrial Management Applications.
You can find it from .

Initial publication can be found from here and the presentation from here.

Related Posts : Horizontal Format Data Mining with Extended Bitmaps 

Sunday, January 8, 2012

2012 has arrived

2012 has arrived. It’s quite late but a belated Happy new year everybody!. My 2012 started with my friends and some Kiribath.

Starting 2012 at WSO2 was also a decent gathering of all folks at WSO2 LK office. It’s more than one year since I joined WSO2 and I always freshen up by learning something new everyday.

Aha, One small good thing on the side about WSO2 is, it’s within walking distance to Lionel Wendt art theatre. No, not kidding. During last three days, I watched three plays by Jayalath Manorathne at Lionel Wendt. It helps me to see things that I don’t see or to remember things that I forgot.

Related post - Happy new year Sri Lanka-2010!