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 Kumara, Denis 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.

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.

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

• BPEL4People Activity - Enables human interactions based on WS-HumanTask specification via BPEL processes using BPEL4People specification.
• Business Activity Monitor Activity - Enhances real time KPI(Key Performance Indicators) monitoring via WSO2 BAM

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 https://svn.wso2.org/repos/wso2/people/denis/org.wso2.carbon.bpel.extension.activity.sample/.

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.

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 -
  SHOULD BE
  

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.

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

• Manipulating HTTP headers via Unified-Endpoints
• Unified endpoints for BPEL Processes

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

• Unified endpoints for BPEL Processes
• How to invoke a secured web-service through BPEL

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...

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.

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 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.

Enabling logging for various components in WSO2 BPS

This blog post explains how to log the messages come into and sent out from WSO2 BPS server.
This feature is extensively used in BPEL development to figure out the problems in the message sequences and in latency analysis during BPEL process invocations.

Tested Environment

     wso2bps-2.1.2

Instructions

1. Add the following entries to the $CARBON-HOME/lib/log4j.properties
       log4j.logger.org.apache.ode.bpel.messagetrace=TRACE
       log4j.logger.org.wso2.carbon.bpel.messagetrace=TRACE
2. Then the preferred log4j appender should be configured such that it has a threshold of TRACE level. If CARBON_LOGFILE is the log4j appender, it should be changed as follows. By default this is set to DEBUG.
       eg - log4j.appender.CARBON_LOGFILE.threshold=TRACE
3. Then re-start the WSO2 BPS server.
4. The log files can be found as $CARBON-HOME/repository/logs/wso2carbon.log 

Note - You can configure this via Management console as well.

Business Process Hosting in the Cloud

I wrote an OT article named "Business Process Hosting in the Cloud". This article discusses multi-tenancy aspect in a cloud computing environment and some of the concerns of hosting business processes in the cloud. WSO2 Business Process as a Service supports development and easy deployment of business processes modeled using the WS-BPEL standard in a multi-tenanted environment. Also it provides functionality for business process management and hosting in the cloud.

How to send email notifications via BPELs

When business process modeling, there can be requirements to send notifications to some external parties regarding the run-time state of the business process. One general example would be when a particular task is completed, the relevant parties is sent a email.
This functionality is supported by WSO2 BPS via Axis2 mail transport.  So using a activity you can send a request to a particular email address.

There 3 steps involved in setting up the environment.

• Configure Axis2 mail transport in BPS_HOME/repository/conf/axis2.xml
• Create WSDL which has mail address as the service address
• Implement the BPEL process with a invoke activity which sends a mail to configured e-mail address

Configuring Axis2 Mail Transport
In this process we only use mail sending functionality, so we don't want to configure transport receiver. To configure mail transport sender first open up the axis2.xml file which resides in BPS_HOME/repository/conf directory in a text editor and add the following mail transport sender configuration to axis2.xml. Place this after other transport sender configurations.
In the above configuration we have used gmail account we have created for testing purposes. But in production deployment you have to use your own e-mail account.

After you save the axis2.xml after adding above configuration, mail transport configuration is done. Now you can use addresses in mailto: format to as the service endpoint address in WSDL and use Axis2 client API to send e-mails.


Create WSDL which has mail address as the service address
So you can create a partner WSDL which has a service endpoint to a email address. As mail sending act as out-only operation, make sure to modify the portType for sending mails accordingly.


Implement the BPEL process with a invoke activity which sends a mail to configured e-mail address
Now you can use an activity to invoke email sending operation with relevant portType and partner-Links.

Avoiding network overhead when interacting a partner services via BPEL

If you have deployed your BPEL process and it’s partner services on the same WSO2 Carbon instance, you can avoid the network overhead using usePeer2Peer=”false” for the particular partner interaction in deploy.xml. The default value is “true”. Here’s a sample.

Business Process hosting in Cloud

Introduction
In this post I’m going to discuss about some concerns of hosting business processes in cloud. First we’ll discuss around the concept of multi-tenancy and a multi-tenancy architecture for business process executions. Then we’ll move on to our main topic of hosting business processes in cloud and the concerns wrapped around it.
WSO2 Stratos BPS is a WS-BPEL compliant business process run-time PaaS whose architecture supports multi-tenancy in the cloud. So the users can host the enterprise level WS-BPEL business processes in WSO2 Stratos BPS and manage them. So we’ll refer it to elaborate more on some of the following sections.

Table of Content

• Introduction
• Terminology

• Multi-tenancy
  
  • What’s multi-tenancy?
  • Virtualization
  • Goals?
  • Importance
  • What’s in it for business processes?

• Hosting business processes in cloud
  
  • Advantages
  • Concerns
    
    • QoS
      
      • Throttling
      • Security
  • Billing, Metering, Logging and Business intelligence for Business Processes
    
    • Billing and Metering
    • Logging
  • Tooling support

• References

Advanced Concepts in WS-BPEL 2.0

Waruna and I’ll be doing a post-conference tutorial session on “Advanced Concepts in WS-BPEL” in WSO2 Con 2011.
Summary of the session is as follows.

BPEL is the de-facto standard for modeling executable Web services orchestrations. It is an XML-based language used for the definition and execution of business, as well as scientific work flows using Web services. WSO2 Business Process Server (WSO2 BPS) and Apache Orchestration Director Engine(ODE) are two WS-BPEL compliant business process executable work-flow engines, which support composition of Web services by orchestrating service interactions.
In this tutorial, Warauna and I will elaborate on some advanced concepts in WS-BPEL 2.0 and extensibility in WSO2 BPS like

• fault handling
• compensation handling
• event processing   
• selective event processing
• multiple event processing
• concurrent event processing
• message correlation
• parallel processing
• Introduction to ODE extensions
• Future improvements with extensions

Introducing New Sample Guide for BPS 2.1.0

From WSO2 BPS 2.1.0 onwards, we have introduced a new sample guide and documentation which explain some of the basic concepts involved in WS-BPEL 2.0. You can find the documentation over here .

Also we have introduced few samples for complex BPEL scenarios like

• Compensation handlers - SampleCompensationHandlers
  
  • This samples demonstrates a flight reservation process with the functionality of with a basic compensation handler will work. Also it involves the which are required in compensation handling.
• Event-handlers - SampleEventHandlers
  
  • This sample has an event-handler implementation is capable verifying the functionality and reliability of construct.
• Asynchronous processes SampleAsynchronousProcess
  
  • This sample contains two processes. One acts as a client (Async-Client.zip) for the server (Async-Server.zip). Message correlation is used to maintain the asynchronous interaction between client and server.
   

 We will add the documentation to explain those scenarios as well. You can find those other samples over here.

WSO2 BPS 2.1.0 Available for Download

The WSO2 Business Process Server(BPS) team is pleased to announce the release of 2.1.0 version of the Open Source Business Process server. WSO2 BPS 2.1.0 is based on WSO2 Carbon 3.2.0 which is the OSGi-based component framework allows the complete set of WSO2 products to leverage shared components, ensuring a consistent set of features between products, a consistent user experience, and reusing of identical components. You can find the release note for WSO2 BPS 2.1.0 from here.

Two fresh products; WSO2 MB and WSO2 CEP also were released with the existing set of products.

Few excerpts from the WSO2 BPS 2.1.0 release note...

• WSO2 Business Process Server (BPS) is an easy-to-use Open Source Business Process Server that executes business processes written following WS-BPEL standard. WS-BPEL is emerging as the defacto standard for composing multiple synchronous and asynchronous web services into collaborative and transactional process flows which increase the flexibility and agility of your Service Oriented Architecture. WSO2 BPS is powered by Apache ODE and available under Apache Software License v2.0. WSO2 BPS provides a complete Web based graphical console to deploy, manage and monitor business process and process instances.
  
• WSO2 BPS is developed on top of the revolutionary Carbon platform (Middleware a' la carte), and is based on the OSGi framework to achieve the better modularity for you SOA. Carbon platform contains lots of new features and many other optional components that can be used to customize or enhance the functionalities provided by BPS to suits you SOA needs. In addition to installing optional components you can uninstall unwanted features without any trouble.
  WSO2 team recently released 3.2.0 version of WSO2 Carbon platform which is the OSGi-based component framework allows the complete set of products to leverage shared components, ensuring a consistent set of features between products, a consistent user experience, and reusing of identical components.
  
• An open source product, WSO2 BPS is available under the Apache Software License (v2.0) . This includes all of the extra integration and management functionality as well.

Monitoring multiple WSO2 server instances via a single front-end

Any WSO2 product like WSO2 BPS, WSO2 AS, WSO2 ESB etc is based on WSO2 Carbon platform. One inherent characteristic of this platform is, it's easily front-end and back-end separated.

As well this is an interesting deployment pattern which is very useful in many scenarios. In this post what I tried to do is monitor two WSO2 back-end server instances (ESB and BPS) via a single front-end server instance.

Table of Content

• What's front-end(FE) and back-end(BE) separation?
• Advantages
• Tested Environment
• How to separate FE and BE features of a product
• Configure ports to connect FE and BE
• How to compose a FE of two products
• Configurations steps to connect FE and BE