Category — SOA

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.

Each and every WSO2 Carbon 3.0.0 based product contains a “Registry” which we used to store data. There three main partitions of this registry space which used to store different kind of data namely, Local Data Repository, Configuration Registry and Governance Registry. This registry space partitions are there to allow share resources and configuration replication.

Local Data Repository

Contains system configuration as well as runtime data that is local to a single instance of a product. This partition of the registry space is not for sharing among multiple servers.

Configuration Registry

This is the most widely used partition and contains product specific configurations intended to be shared across multiple instances of the same product(for example, a cluster of ESB instances sharing set of proxy service configurations).

Governance Registry

Contains data and configuration shared across the platform. The WSO2 Governance Registry makes use of this partition of the registry space to store services and related metadata such as WSDLs, schemas, policies and endpoints. The governance registry partition has been designed in a way that it can be made use of by multiple instances of various Carbon based products.

You need to be careful when using these separate partitions when designing you solutions and “Sharing Registry space across Multiple Product Instances” article describes how you can leverage the registry partitions to successfully implement highly scalable SOA based solutions using WSO2 Carbon based products.

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.

Last year’s WSO2 SOA Summer School helped more than 1000 enterprise IT architects and developers to become more familiar with SOA concepts, technologies, and best practices—expanding the expertise they bring to their current or prospective employers. This year we are offering a completely new weekly series of sessions ranging from SOA to Cloud. Summer School 2010 runs for two months starting 10^th June and ending on 29^th July. Join us this Summer to learn the ultimate tips, techniques and practical advice on SOA and Cloud.

• Understanding the Cloud Landscape
• Understanding Enterprise Middleware – Build an Agile Architecture
• SOA Essentials – Getting your ESB and Governance right
• Business-facing SOA
• Extending SOA with CEP, Eventing and Rules
• Security in SOA
• Under the WSO2 Hood
• The Best of the Summer

Read more…

Read more…