Category — BPEL

WSO2 Carbon Studio is a fully tooling environment which facilitate you to develop, test, deploy and test WSO2 Carbon Artifacts.

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.

WS-BPEL is used in Web Services based Service Oriented Architectures to

• 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

What is a business process? A series of steps that need to be performed in order to provide goods or services. Processes that used to be performed by humans are becoming increasingly automated by enterprise IT, allowing them to be performed more quickly and reliably and at much greater scale. But there can be unintended consequences – reverberation of failures, lack of accountability, an inability to handle situations outside the norm.

So why are business processes challenging to get right? Getting it right often means striking a good balance between automation and using the wisdom and flexibility of the human mind. But the technologies and systems for automating interactions which include humans differs substantially from automating interactions among software applications. This gulf has been difficult to bridge. Until now.

The recent introduction of two new standards in this space – BPEL4People and WS-Human Task – enables organizations to extend automated systems smoothly to include human interaction. WSO2 supports these new capabilities in the latest release of the WSO2 Business Process Server.

Your presenter, Milinda Pathirage, will cover the following topics:

• Scenarios highlighting business process involving humans
• Insights into BPEL4People and WS-Human Tasks
• Overview of the WSO2 Business Process Server
• Review of the new human-interaction features of the latest version of the WSO2 BPS

Who should attend:

• Architects and developers expanding their toolkit to include business processes
• Business process analysts
• Consultants and analysts specializing in SOA

Register here.

Latest release(version 2.0.0) of WSO2 BPS, includes a fix for supporting custom XPath functions based on Saxon. There was a class loading issue in the previous releases of WSO2 BPS, which breaks the custom XPath function support.

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.

WSO2 released the latest version of it’s BPEL based process server, last Saturday(12th June 2010). WSO2 added WS-Human Task based BPEL4People support to this version of WSO2 BPS. Currently BPEL4People support is at it’s early stage and upcoming releases will provide users with comprehensive human and process integration through improved human task engine. New features in this release includes,

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

Previous releases of WSO2 BPS provides facilities to, configure instance cleanup upon successful or faulty completion of process instances. But this is not suitable for production environments, because business people often need to look back and investigate their process flows, specially in failure scenarios.

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.

What is process instance data?

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.

What is WS-Discovery?

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.

SOA is not only about service hosting(implementing Web Services that expose certain business functionality over network). It’s about enhancing efficiency, agility and productivity of an enterprise by applying service oriented design paradigm and service oriented architecture concepts to when implementing information systems which are critical to business functionality of enterprises.

So when it comes to implementing SOAs, there is a need for several technologies, products, APIs, supporting infrastructure and various other parts. In a typical SOA implementation at least there will be a service hosting environment, an ESB, a service governance tool, a business process management system, a portal server and set of monitoring tool which used to monitor the whole system real-time for fine tuning business processes, service APIs and etc.. There are lot of tools and products available which provide the above mentioned functionalities. Some provide set of functionalities and some has several products that provides most of the functionalities separately. The problems with those existing products and platforms are they are not very well fit together even though they are from same vendor or most of the time those platforms are heavy weight and required lot of time to getting started with them and getting familiar with the tools.

For a long time IT departments heavily suffered from drawbacks of the available products. The cost, complexity, time need to getting familiar with the products and the maintenance issues became a real pain to the enterprises use these products.

With the recent announcements on availability of WSO2 Gadget Server and WSO2 Business Activity Monitor, WSO2 SOA Platform has become the most complete and comprehensive open source SOA platform which provides all the functionalities required to full fill SOA implementors requirements while keeping it’s simplicity intact.

I can assure you that it is the most light weight, high performance, extensible and most user friendly SOA platform out there. Because of the power of OSGi based WSO2 Carbon platform, we were able to build unified, consistent and fully componentized SOA platform out there in the market.

If you want to know how WSO2 come here to the state where we are now, read the recent blog post from Samisa, director of engineering WSO2. Also this not the end, this is only the start of becoming world’s best SOA platform provider.

WSO2 Business Process Server team released the latest version(1.1.0) of WSO2 BPS yesterday 19th November 2009.  As the successor of WSO2 BPS 1.0.1, WSO2 BPS 1.1.0 comes with handful of new features which will make process developer’s life easier.

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.