RiftSaw 2.3.0.CR1 released with further BPEL console improvements and support for JBossAS 6

The RiftSaw team are pleased to announce the availability of version 2.3.0.CR1. The release includes:

- Storage of BPEL process instance activity events in BPAF format
- Query UI for BPEL process instances based on various criteria
- Process instance activity event viewer, provides detailed trace of the execution of a process instance
- Support for JBossAS 6
- Inline variable initialization
- Many bug fixes

Full details available from: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310843&version=12315290

Getting started with RiftSaw/BPEL.

Here are some links of blog entries/aritcles to get you started with RiftSaw, or BPEL quickly.

1. An Impatient Start with JBoss Riftsaw - 5 steps in 5 minutes
2. A screencast of using Bpel Editor to create&run an example on riftsaw.
3. A set of labs on BPEL process design and execution.  They were referred to be deployed on Apache ODE, but all of examples can be run successfully on RiftSaw.
4. Technical overview on the WS-BPEL 2.0
5. RiftSaw examples, we've had a bunch of examples in our riftsaw distribution, including the BluePrint examples.

If you have some other good links/articles  on the BPEL/RiftSaw, please leave it on comments, and I will try to add them in.

RiftSaw 2.2.0.Final released

The RiftSaw team are pleased to announce the release of version 2.2.0.Final. The summary of the main changes  are:

- BPEL Console improvements, to enable visualisation of running instances
- Clustering support
- WS-Security support when using ESB BPELInvoke action
- More examples
- Many bug fixes
- Now dependent upon ESB 4.9 or higher (instead of ESB 4.8)
- Updated to ODE 1.3.5
- Database migration scripts from 2.1.0.Final

The detailed report for this release can be found at:
https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310843&version=12315821

RiftSaw 2.2.0.CR2 released

The RiftSaw team are pleased to announce the second release candidate for the 2.2.0 release series.

This is a bug fix release, including resolutions for issues related to process undeployment and use of dynamic partner links.

The detailed release notes can be found at:
https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310843&version=12315545

RiftSaw 2.2.0.CR1 released with clustering support and more management functionality

The RiftSaw team are pleased to announce the first release candidate for the 2.2.0 release series.

In this release, we've made great improvements on the BPEL console. By enabling the logging of events in the deploy.xml file,  administrators are able to see the execution path of process instances in the console.

Secondly we've used the JBoss Cache as our cache provider in the RiftSaw clustering environment.  This enhancement now enables administrators to log in to the BPEL console on any node to activate or retire a process.

Other changes include:
- BPELInvoke supports WS Security and SAML support.
- Upgrade juddi to 3.0.4 release.

And of course, with a bunch of bugs fixed.

The detailed report for this release can be found at:
https://jira.jboss.org/secure/ReleaseNote.jspa?projectId=12310843&version=12315480

RiftSaw Release 2.2.0.M1

The RiftSaw team are pleased to announce the release of RiftSaw 2.2.0 M1 release.

This is the first milestone release for the 2.2.0 release series.

This release's main feature is the 'clustering support'. Now users are able to deploy Riftsaw
within a clustered environment using a shared database. The BPEL artifact is deployed using the
farm capability, by placing the BPEL process jar into $Server/all/farm folder, which will result
in it being automatically copied to all nodes in the clustered environment.

Other changes include:
- Added JPA based implementation for SimpleScheduler module DAO.
- Using deploy.xml as preference over bpel-deploy.xml as the bpel artifact descriptor.
  (It supports both at the moment, but bpel-deploy.xml is deprecated, may gets removed in the near future.)

Last but not least, we've fixed a bunch of bugs.

The detailed report for this release can be found at:
https://jira.jboss.org/secure/ReleaseNote.jspa?projectId=12310843&version=12314155

The release can be downloaded from: http://www.jboss.org/riftsaw/downloads.html

The RiftSaw Team
http://www.jboss.org/riftsaw

Using WS-Security with RiftSaw and JBossWS-CXF: Part 1 – Securing the BPEL process

In these posts we will explain how to add security to a BPEL process deployed in RiftSaw when using jbossws-cxf. This first post will explore how to make a BPEL process secure. To demonstrate how to achieve this, we will use the secure_service quickstart example, included in the RiftSaw distribution.

When making a standard JAX-WS service secure, jbossws-cxf simply requires a CXF based configuration file to be bundled with the deployed service [1]. This file is called jbossws-cxf.xml, and for our example, this would have the contents:

<beans xmlns='http://www.springframework.org/schema/beans' 
  xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' 
  xmlns:beans='http://www.springframework.org/schema/beans' 
  xmlns:jaxws='http://cxf.apache.org/jaxws' 
  xsi:schemaLocation='http://cxf.apache.org/core 
    http://cxf.apache.org/schemas/core.xsd 
    http://www.springframework.org/schema/beans 
    http://www.springframework.org/schema/beans/spring-beans-2.0.xsd 
    http://cxf.apache.org/jaxws 
    http://cxf.apache.org/schemas/jaxws.xsd'> 
   
  <bean id="UsernameTokenSign_Request" class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor"> 
    <constructor-arg> 
      <map> 
        <entry key="action" value="UsernameToken Timestamp Signature"/> 
        <entry key="passwordType" value="PasswordDigest"/> 
        <entry key="user" value="serverx509v1"/> 
        <entry key="passwordCallbackClass" value="org.jboss.test.ws.jaxws.samples.wsse.ServerUsernamePasswordCallback"/> 
        <entry key="signaturePropFile" value="etc/Server_SignVerf.properties"/> 
        <entry key="signatureKeyIdentifier" value="DirectReference"/> 
      </map> 
    </constructor-arg> 
  </bean> 
   
  <bean id="UsernameTokenSign_Response" class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor"> 
    <constructor-arg> 
      <map> 
        <entry key="action" value="UsernameToken Timestamp Signature"/> 
        <entry key="passwordType" value="PasswordText"/> 
        <entry key="user" value="serverx509v1"/> 
        <entry key="passwordCallbackClass" value="org.jboss.test.ws.jaxws.samples.wsse.ServerUsernamePasswordCallback"/> 
        <entry key="signaturePropFile" value="etc/Server_Decrypt.properties"/> 
        <entry key="signatureKeyIdentifier" value="DirectReference"/> 
        <entry key="signatureParts" value="{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body"/> 
      </map> 
    </constructor-arg> 
  </bean> 
 
  <jaxws:endpoint 
    id='SecureHelloWorldWS' 
    address='http://@jboss.bind.address@:8080/Quickstart_bpel_secure_serviceWS' 
    implementor='@provider@'> 
    <jaxws:inInterceptors> 
        <ref bean="UsernameTokenSign_Request"/> 
        <bean class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/> 
    </jaxws:inInterceptors> 
    <jaxws:outInterceptors> 
        <ref bean="UsernameTokenSign_Response"/> 
        <bean class="org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor"/> 
    </jaxws:outInterceptors> 
  </jaxws:endpoint> 

</beans>

To make the BPEL process secure, this file has to be included alongside the BPEL deployment descriptor and process at the top level of the BPEL deployment. This particular configuration uses UsernameToken and digital signature authentication on both the request and response.

The only difference between the contents of this file, and one that would be deployed with a JAX-WS service, is the implementor attribute on the jaxws:endpoint element. In the file above, the value of this attribute is @provider@. In a standard JAX-WS configuration, this value would be the class name implementing the JAX-WS service. The reason RiftSaw uses this alternative value, is that the class implementing the JAX-WS service is not known until deployment time, as it is dynamically created, and so it's class name will be substituted during deployment.

As you will note, the configuration references some property files in a relative sub-folder called etc. These property files also reference some keystore files stored in another relative sub-folder called keystore. Both of these relative sub-folders simply need to be stored at the top level of the BPEL deployment jar.

The configuration also defines a passwordCallbackClass, which must specify a class that implements the javax.security.auth.callback.CallbackHandler interface. In the secure_service example, this class is bundled with the BPEL deployment jar. However this property can reference any implementation that may already exist within the JBossAS server.

So to summarize, securing a BPEL process only requires the addition of a jbossws-cxf configuration file with supporting property and keystore information, and access to an appropriate CallbackHandler implementation.

[1] http://community.jboss.org/wiki/Jbossws-stackcxfUserGuide#WSSecurity