Current implementation of dynamic SOAP header handling is not that much perfect in WSO2 BPS’ ODE integration layer. There is a bug when you don’t have a SOAP header element specified in source message(Message we extract the SOAP header element to copy in to other message), so you must be careful when using this feature. But there will be more fixes to this in the future and this feature is available on WSO2 BPS 2.0.2. Please feel free to report any issues you found in this feature.

You can download a sample from here. This sample shows how you can copy incoming SOAP Header in request message to the response message. But you can use this same mechanism to copy SOAP Header elements from request message to external service invokes and also to copy SOAP Header elements in the responses from external services to other out going messages from the BPEL process. The above sample expect you to send a SOAP header element with the local name “ActivityId”.

WSO2 Carbon Studio - BPEL Editor

WSO2 tooling team recently released the 14th milestone of Carbon Studio with numerous features like;

• Support for creating Carbon Application(cApp) projects which includes Axis2 services, BPEL processes, ESB proxy services, Gadgets, Data Services and etc..
• Also it includes Governance Registry plugin which will helpful when working with WSO2 Governance Registry

Please refer documentation for installation guide and guides on various tools integrated in to Carbon Studio.

• Create business processes from Web Services and Human Activities which span across organizations
• Create complex services from other less complex services from heterogeneous environments
• Create application integration flows from various existing and new applications based Web Services

In most cases we utilize the existing services available, to implement business processes. And there can be situations that those available services are secured using WS-Security.

WS-BPEL 2.0 specification doesn’t define a standard way of handling this type scenarios. And WS-BPEL handles the Web Services at the port-type level. So BPEL engine implementations has there own ways to handle this kind of situation.

We use Apache ODE in WSO2 BPS and we have separate integration layer written based on ODE-Axis2 integration layer. There is a slight difference between WSO2 BPS 1.1.1 and WSO2 BPS 2.0.0 when it comes to configuring WS-Security for partner services. In WSO2 BPS 1.1.1, user needs to create a separate file called package-config.xml which contains endpoint configuration information while in 2.0.0 we have extended deploy.xml to support these configuration. But both these mechanisms share same configuration elements and only difference is the place we keep them.

Users can use Policy XML compatible with Apache Rampart or services.xml file which compatible with Axis2 and contains security policies compatible with Rampart to configure WS-Security for partner services.

How to configure security for partner endpoints?

WSO2 BPS 1.1.1

You need to create a separate file called package-config.xml which looks like following, and put it in the root of your BPEL package.

In this package configuration file we have ‘endpoints’ element which contains configurations of all the endpoints exposed by BPEL process and invoke by BPEL process. When configuring endpoints you need to specify serviceName, servicePort and serviceNS attributes according to the configurations in deploy.xml. For example if you want to call secured CreditRatingPL partner link(CreditRating service partner service) in following deploy.xml file, endpoint configuration will look like above example.

To configure security you can use either a policy XML or services.xml file. And policy configurations are same as configuring security for normal Axis2 based service clients using Rampart. There are Rampart specific policy extension elements which let you configure key stores, user name – password pairs and password callback classes.

You can put the policy XML files and services.xml files in BPEL package or in anywhere in the file system and put the correct location in location attribute. If your password callback classes are in a separate JAR, you can put them on the BPS_HOME/repository/components/lib directory.

You can download sample BPEL package for WSO2 BPS 1.1.1 which shows you how to configure security from here.

WSO2 BPS 2.0.0

The main difference in version 2.0.0 is you can specify security and other endpoint configuration parameters directly in deploy.xml file. For example to configure security for CreditRatingPL partner link, you can directly specify endpoint configuration inside ‘service’ element as follows. In this case you don’t need to specify service name or port name, because they are already available in the parent element(‘service’).

You can download sample BPEL package from here.

Resources

• Secure Web Services with Apache Rampart
• Rampart FAQ blog

Now you can write your own custom XPath extension functions as described in Saxon’s extensibility documentation, deploy them on WSO2 BPS and use them in you process definitions.

To deploy your XPath extensions in WSO2 BPS, you need to copy them into the BPS_HOME/repository/components/lib directory.

When writing XPath extension functions, there are some special cases. For example, if you want to pass a BPEL variable(WSDL Message or XSD Element type) into your extension functions, in simplest way, you need to use net.sf.saxon.om.NodeInfo as the parameter type. According to Saxon documentations DOM Node as the input parameter also should work when you want to get a XML element as the input. but I couldn’t get it to work when I am doing tests. And if you need to access XPath processing context, you need to have XPathContext as the first parameter to your function. When you want to return XML elements from your extension functions, you can use return type as org.w3c.dom.Node.

When returning XML elements, please make sure to create them using DOM AI tried to create DOM from a string like following. But failed when evaluating XPath on the return value as well as converting that DOM to AXIOM OM when sending response back to the BPEL process caller at the integration layer.

Here is the final sample extension source.

And here is how you can use that extension inside BPEL process definition. In this sample, I am creating the response XML using this custom XPath function.

If you have any questions on custom XPath function in WSO2 BPS, please feel free to put comment on this post. You can use extension written following above guidelines in Apache ODE also. In Apache ODE case you need to copy extension JAR into Apache ODE web application’s lib directory or relevant place in your JBI based Apache ODE deployment.

• BPEL4People and WS-HumanTask Support(Experimental)
• Instance cleanup scheduled task for production deployments
• Component manager to install and uninstall features (provisioning support)
• External service invocation via JMS
• XPath extension support

in addition to various bug fixes to underline BPEL engine(Apache ODE). You can download new release from Oxygen Tank’s download page.

To provide users with more convenient instance cleanup mechanism, we introduced a new scheduled task which do instance cleanup,  to the next release of WSO2 BPS. You can find this feature on latest WSO2 BPS 2.0.0 previews. This task will delete successfully completed instances and instances with faulty completions at a given time, and users can configure time of day which instance cleanup task should run. In addition to schedule time, users can configure life time of instance data for successful completions and faulty completions. These configuration parameters must be specified in bps.xml file located in BPS_HOME/repository/conf directory.

Sample bps.xml file with instance cleanup enabled will look like following;

Future of instance cleanup

We are planning to implement support process vise configuration for instance cleanup, where users can specify instance data life time for each and every process.

When process instance start it’s execution, there are various types of information needs to be tracked and stored. For example when process receives a message process engine will create a process instance for execution and process engine must store the input message to it’s during the life time of process instance to use in intermediate steps. Like that there are various informations stored in WSO2 BPS‘s persistence storage or when process is in-memory those information will be maintained as normal Java Objects.

Process instance in WSO2 BPS keep tracks of instance state, instance variables, messages, message properties, information about message exchanges, correlations and information about execution events. So when persistence is enabled for processes all the above information will be stored in the WSO2 BPS persistence storage. So during their life time process instances will accumulate considerable amount of data in persistence storage.

From the above process instance data, messages and variable take a large percentage of space from persistence storage or from memory. BPEL processes heavily depends on the message they exchanged between partners and clients. In the middle of the process life cycle there can be various data manipulations and all those information also stored in persistence storage. These XML messages can be sizable ones some times.

So during the life time of the process engine, it can accumulate huge amount of data and this will directly effect the database performance and then to performance of BPEL engine it self. This happens because WSO2 BPS BPEL engine is tightly coupled with persistence storage for persistence processes.

To preserve the performance level we want, we may some time need to clean the above described instance data from WSO2 BPS BPEL engine’s persistence storage.

Configuring Instance Data Cleanup

BPEL packages deployed in WSO2 BPS must contain configuration file called “deploy.xml” which is local to that BPEL package and contain configuration information related to processes. In that file we can specify process instance data cleanup configuration per process.

In the WSO2 BPS 1.1.1 we only provide support for deletion of instance data after process instance is finished. And you can specify whether to delete instance data at successful completion or completion with failure or in both cases. And you can also fine tune the instance data cleanup based on instance data categories.

There five different categories of instance data:

• instance – Contains informations like created date, last active date, process id, instance state, root scope id and execution state(Data in ODE_PROCESS_INSTANCE table of WSO2 BPS persistence storage). Execution state column of ODE_PROCESS_INSTANCE contains JACOB Execution Queue as a byte array.
• variables – Process instance scope information, XML values of the variables and partner link variables. Contents of the tables ODE_SCOPE, ODE_XML_DATA and ODE_PARTNER_LINK
• messages – Information about incoming and out going messages, message exchanges information and message exchange properties. Contents of the tables ODE_MESSAGE, ODE_MESSAGE_ROUTE, ODE_MEX_PROPS and ODE_MESSAGE_EXCHANGE
• correlations – Information about correlations.Contents of the DE_CORRELATION_SET, ODE_CORSET_PROP tables.
• events – Contents of the ODE_EVENTS table.

How to Configure

Here is a sample deploy.xml file.

As shown in the above example you can specify the ‘cleanup’ configuration under ‘process’ element of deploy.xml file. And the cleanup configuration’s XML schema is given below.

Let’s look at some examples of instance data cleanup.

Cleaning up all the data on successful or failed instances

Cleaning up all the data on successful completion of instances

Cleaning up all the data on successful completions and messages and correlations of faulty completions

Effect of process instance data cleanup

If you run WSO2 BPS without any cleanup of process instance data, it’ll effect the performance of database and then the throughput of WSO2 BPS. Response time of the process instances will also increase due to this. The best way to avoid this type of performance degradation is by configuring processes to cleanup process instance at completion. You can also write your own tools using instance management API to delete process instances periodically.

Future of instance data cleanup

In the latest version of WSO2 BPS we only provide deletion of process instance data after process instance execution is finished. But this is not enough in production environment. Users may need to keep the instance data for some time for auditing purposes and delete process instance data after several days. For example they may want to keep successful process instance information 3 days and failed process instance information 5 days. Also they may want to change this configuration process wise. So we are planning to introduce this support in next version(2.0) of WSO2 BPS.

WS-Discovery defines a discovery protocol for locating services. The primary scenario for discovery is a client searching for one or more target services. There are two modes of operations define in WS-Discovery protocol, named ad-hoc and managed.

In ad-hoc mode clients send probe messages to multicast group and services that match the probe send a response directly to client. To reduce the network load, there is a another way of doing this by service sending announcement to the same multicast group when he joined the network. In this case clients who listening to the multicast group can detect  newly available service without repeated probing.

In managed mode this protocol introduces discovery proxy which resides in-between client and the service. And this method extends the reach of protocol beyond ad-hoc network. In managed mode, target services send unicast announcement messages to discovery proxy and clients send unicast probe and resolve messages to discovery proxy. Also there are ways to reduce the network traffic also in managed mode.

WS-Discovery in WSO2 Carbon

WSO2 Carbon’s latest release has separate component which take care about discovering services deployed in other WSO2 Carbon based products and which implements WS-Discovery specification, a discovery protocol for locating services. Even though earlier I said you can discover services deployed in other WSO2 Carbon based servers, if you have a service deployment environment from another vendor and it has discovery protocol implements you’ll be able to discover service deployed in that server through this component.

You can find a tutorial describing how to use WS-Discovery feature comes with latest WSO2 Carbon based products.

Benefits for WSO2 BPS

WS-Discovery becomes handy, when it comes to service orchestration product like WSO2 BPS. WSO2 BPS can utilize the functionality provides by the WS-Discovery component to auto discover endpoints which implement certain type of service. Also we can come up with a deployment wizard where users can dynamically discover and change the service endpoints at deployment time. And these kind features will be really helpful when migrating processes from development environment to production environments.

If we can integrate discovery proxy with the BPEL editor, user will be able to directly search the services he wants and compose a process out of those services.

We are planning to integrate WS-discovery into a future release of WSO2 BPS(not to the upcoming release), so that our users will get a fully dynamic deployment experience.

WSO2 BPS 1.1.0 uses revision of Apache ODE trunk which is going to be the future of Apache ODE BPEL engine as it BPEL engine. In addition to that there are several bug fixes to the Apache ODE like fixing E4X extension support when using OpenJPA data access objects. WSO2 BPS 1.1.0 comes with a completely new integration layer for Apache ODE which integrated ODE with WSO2 Carbon platform. Now the previously unsecured BPEL management API is completely secured based on WSO2 Carbon authentication mechanism and new version has a completely re-written Web service API for managing your BPEL engine. There are some improvements to be done on the management API and those will be available with the upcoming releases.

By leveraging the extension mechanism of new ODE engine, now you can extend WSO2 BPS’s BPEL language by introducing your own extension to BPEL language and deploying them on WSO2 BPS.

This version of WSO2 BPS has the provisioning support based in Equinox P2; now users can extend the BPS by installing features available in WSO2 Carbon P2 repositories. For example by installing mediation feature, you’ll be able to do service mediation using WSO2 BPS.

Here is the list of new features available in WSO2 BPS 1.1.0

• Apache ODE trunk’s revision is used as the BPEL Engine
• New WSO2 Carbon integration layer for Apache ODE
• BPEL Process Versioning Support
• Support for invoking secured(Using WS-Security) partner services.
• Experimental clustering support
• Invoke activity recovery support through management console
• E4X based data manipulation support for BPEL assignments
• BPEL Extension support for extending WS-BPEL language
• Equinox P2 based provisioning support –  extend your BPS instance by installing new P2 features [5].

You can download this release at http://wso2.org/downloads/bps.

Apache ODE has this nice feature called activity recovery support for BPEL invoke activities. If external service invoke failed due to unavailability of end point, due to a SOAP fault or domain name resolution error, user can retry this activity after the errors in external services are fixed.

If the process operations are synchronous, client will get time out error if invoke activity failed during execution in normal case. This not good thing for synchronous operation. Client must get a fault as a response if invoke activity failed during synchronous operation. So you if your process operations are synchronous and you need fault reponse if invoke activity failed during process execution, you need to disable activity recovery feature and set fault on failure to true. This can be done using following code snippet in a BPEL scope which has invoke activity.

Here is a sample BPEL process that use the above feature.