RiftSaw Open Source BPEL

RiftSaw 3 - A new direction

2011-12-06T01:42:00.000-08:00

As of version 3, Riftsaw will no longer be directly distributed as part of this project. The aim of version 3 is to provide a core embeddable BPEL engine and associated management console.

Instead, Riftsaw 3 will now be distributed as the BPEL component within the Switchyard ESB. Switchyard provides an ESB that uses the SCA component assembly model. We have developed a SCA-BPEL compliant component implementation, that uses the Riftsaw 3 embeddable BPEL engine, for use within Switchyard.

The Riftsaw project will continue to be responsible for the Embeddable BPEL engine (based on Apache ODE), the GWT based management console and the SCA-BPEL component.

The integration is currently at an early stage, with a couple of quickstarts available to demonstrate its usage. The current version only works with a H2 embedded database, but the next version will support the same range of databases supported by Riftsaw 2, as well as the same database schema (so no migration required).

Please feel free to try out the BPEL component in Switchyard 0.3 and provide us with your feedback.

There are also some developments on the tooling, as part of the Savara project (see http://jboss-savara.blogspot.com/2011/10/generating-switchyard-bpel-applications.html), based on RiftSaw 3 running in Switchyard 0.3.

Riftsaw 2.3.0.Final released

2011-07-12T02:07:00.001-07:00

The RiftSaw team are pleased to announce the release of version 2.3.0.Final of our open source BPEL engine.

This release includes:

1) Enhanced BPEL UDDI integration, following the recommendations outlined in the OASIS Technical Note on "Using BPEL4WS in a UDDI registry" (http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-bpel-20040725.htm)

2) Enhanced BPEL console features, including querying historic instances

3) JBossAS 6 support

4) Dependency upgrades include ESB (4.10), jUDDI 3.1 and Spring 3.0.3

5) Many bug fixes

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

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

2011-03-28T08:42:00.000-07:00

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.

2011-02-07T22:21:00.000-08:00

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

2011-01-20T05:51:00.000-08:00

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

2010-12-14T04:36:00.000-08:00

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

2010-11-10T07:21:00.000-08:00

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

2010-10-01T05:14:00.000-07:00

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

2010-08-11T03:01:00.000-07:00

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

Links of RiftSaw/Ode architecture

2010-07-27T05:17:00.000-07:00

I've composed a series blog entries on Ode architecture, because riftsaw leverages the Ode's bpel runtime, so it applies to the riftsaw project also, hope it will help you easily understood how riftsaw works.

1. Bpel Compiler and its internal model.
2. Jacob framework.
3. Ode's architecture and module introduction.
4. BpelServer API illustration.
5. Architecture of simple scheduler module.

RiftSaw Release 2.1.0.Final

2010-07-16T07:22:00.000-07:00

The RiftSaw team are pleased to announce the release of RiftSaw 2.1.0.Final.

The summary of the main changes between 2.0.0.Final and 2.1.0.Final are:

- Support for WS-Security when RiftSaw used in conjunction with JBossWS-CXF
- UDDI registration and lookup
- Migration of persistence layer to a pure JPA approach, enabling any JPA compliant persistence provider to be used. RiftSaw uses Hibernate as its default JPA provider
- Update from ODE1.3.3 to ODE1.3.4
- ODE project has now been mavenized
- More examples
- Many bug fixes
- Now dependent upon ESB 4.8 or higher (instead of ESB 4.7)

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

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

First screencast on Riftsaw

2010-07-14T04:40:00.000-07:00

A screencast showing Riftsaw and JBoss Tools BPEL Modeling in action has just made it into the JBoss Tools Movies. The video shows how to create, assemble, deploy and test a simple BPEL process. In fact it shows how to create an existing sample which is shipped with Riftsaw - the say_hello process.

This process is a modification of a well-known Hello World sample type. User sends his name to the process and gets a "personalized" greeting back. So the BPEL would concat a name, e.g. Dolly with a string Hello and would reply with "Hello Dolly".

You can watch the screen cast at the JBoss Tools Movies.

RiftSaw Release 2.1.0.CR2

2010-06-25T07:32:00.000-07:00

The RiftSaw team is pleased to announce the release of 2.1.0.CR2.

This is a bug fix release.

The main change with this release is the migration to the pure JPA persistence layer from the native Hibernate layer. Moving to the JPA persistence layer has resolved a number of long standing bugs.

Hibernate is still used as the JPA provider. However to align the database schema with the ODE community project, it has been necessary to make some schema changes. Therefore it will be necessary to drop the current database (or simply
remove the $AS/server/default/data folder). This JPA work is being contributed back to the ODE project, and should be available in ODE 1.4.

The other main change is the simplification of the ESB examples, both in terms of how they are run, and also in terms of their complexity. Previously the primary ESB/Riftsaw example was too complex, making it difficult to use and follow. Instead this has been replaced by a couple of new simpler examples that demonstrate the specific integration points between JBossESB and RiftSaw.

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

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

RiftSaw Release 2.1.0.CR1

2010-06-04T07:24:00.000-07:00

The RiftSaw team is pleased to announce the release of 2.1.0.CR1.

This is primarily a bug fix release, with additional support for configuring the Apache CXF web service endpoints used by a BPEL process.

WS-Security features, supported by Apache CXF, can now be configured for RiftSaw when the jboss-cxf Web Service stack is installed. The User Guide provides information on how to include the CXF based configuration with the BPEL deployment, and there are some quickstarts available to demonstrate username and digital signature authentication.

JAX-WS handlers can now be installed to intercept/observe messages sent and returned from the web service representing a BPEL process.

The version of ODE used by RiftSaw has been updated to ODE 1.3.4.

NOTE: Database schema changes occurred when moving to the ODE 1.3.4 release. If you have a previous version of RiftSaw installed, then you will need to drop the existing tables (or delete the database), before installing and running this version of RiftSaw.

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

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

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

Interview on RiftSaw at DZone

2010-04-02T05:46:00.000-07:00

Check it out: http://soa.dzone.com/articles/introduction-riftsaw-open

RiftSaw Release 2.0.0.Final

2010-03-31T13:16:00.000-07:00

Today the RiftSaw team released 2.0.0.Final. This release packs the following feature set:

WS-BPEL 2.0 OASIS standard and the legacy BPEL4WS 1.1 vendor specification.
JBossWS Native and CXF Web Service stack support.
UDDI registration of BPEL endpoints, and Runtime UDDI Endpoint lookup as preview feature.
Enterprise quality GWT based BPM console to manage process definitions and instances.
High level API to the engine that allows you to integrate the core with virtually any communication layer.
JBoss deployment architecture, enabling hot deployment.
Compiled approach to BPEL that provides detailed analysis and validation at the command line or at deployment.
Short-lived and long-running process executions.
Process persistence & recovery.
Process versioning.
Ant-based deployment.
Integrated with the JBoss ESB.
Eclipse-based BPEL designer and deployment, supported through JBoss Tools.
Runs in JBoss Cluster.
A good set of examples to help you get started quickly, including Sun's BPEL Blueprint examples.

Some good resources for this release are the Release Notes, the Getting Started Guide, the User Guide and JBoss Tools. To download this release see our download page: http://www.jboss.org/riftsaw/downloads.html.

The RiftSaw team,

http://www.jboss.org/riftsaw

RiftSaw Release 2.0-CR2

2010-03-02T09:35:00.000-08:00

We are proud to announce that the second Candidate Release for RiftSaw 2.0 has just been released. This release runs on JDK-1.6, JBAS-5.1 and JBossESB-4.7 or SOA-Platform-5. You can download the release from here.

The RiftSaw Team

Release Notes - RiftSaw - Version 2.0-CR2

Bug

[RIFTSAW-56] - Error when deploying webservice_esb_bpel as single .esb

[RIFTSAW-123] - ArrayIndexOutOfBounds exception with jbossws-cxf

[RIFTSAW-127] - Handling SOAP header binding to WSDL message part

[RIFTSAW-136] - Admin console displays instances for all versions associated with a select process definition

[RIFTSAW-137] - Undeploy needs to check if other bundles exist with same name before deactivating WS endpoint

[RIFTSAW-141] - HelloWorld throws UDDI related exception

[RIFTSAW-142] - Quickstart HelloWorldODE does not run if HelloWorld is still deployed

[RIFTSAW-153] - Re-deploying bpel script leads to continuous stream of error messages in server log

[RIFTSAW-154] - Exception on one-way requests

[RIFTSAW-157] - Instance data not displayed correctly

[RIFTSAW-159] - More than two correlated interactions causes exception

[RIFTSAW-162] - jbossws-cxf returns SOAP fault via an exception, whereas jbossws-native appears to return the SOAPMessage with fault inside

[RIFTSAW-163] - Problem invoking a third part partner link (WS at JBossWS) with header value

[RIFTSAW-165] - IncompatibleClassChangeError in SOA-P 5.0

Feature Request

[RIFTSAW-143] - Add information to user guide on Full Publish and versioning from JBoss Tools

[RIFTSAW-144] - BPELInvoke action should use MessagePayloadProxy

[RIFTSAW-160] - Auto-registration of BPEL process endpoint should work with other supported registries

Task

[RIFTSAW-140] - Change UDDI integration over to use the jUDDI-3.0.1 libs when those are released.

[RIFTSAW-149] - Oracle support.

[RIFTSAW-150] - sqlserver support.

[RIFTSAW-151] - Document UDDI configuration

[RIFTSAW-156] - Add configuration for mex.timeout

[RIFTSAW-166] - Only turn on UDDI integration when the esb-registry is installed.

Using BPELUnit for testing processes in Riftsaw - Part 2

2010-02-25T04:23:00.000-08:00

In the first part we showed how to run a BPEL test for a process deployed in Riftsaw from the Eclipse environment. Today we will use the possibility to run this tool via Ant tasks to include it in the Riftsaw integration tests. Currently, the request-response tests are performed via Java code using the standard JUnit framework. In this post I will show you how to transform some of them into BPELUnit automated tests to make them more flexible and transparent.

On top of what we have from Part 1 we need:

The prerequisites are:

Clean install of JBoss Application Server 5.1.0 GA
JBoss ESB 4.7 GA installed into the clean installation of App Server
Installed Ant at version 1.7.1 or higher
Installed Maven at version 2.2.1 or higher
Installed BPELUnit 1.1.0 Standalone version

In case you need help with the first two prerequisites please refer to the first part of this article to find instructions on how to properly install JBoss + ESB. As for the other three the instructions are provided on the products' websites.

Preparation

If you navigate to the directory with Riftsaw source code you will see a sub-directory called “integration-tests” which contains sources of the tests, build scripts for running them and the generated test reports. Take a look in the RIFTSAW_SRC/integration-tests/src/test/resources/samples/ directory where you can find sub-directories for each test, containing BPEL and WSDL files, XML files with messages and the ant build script (build.xml) that compiles the test and makes everything ready for its execution.

To prepare the integration test to use BPELUnit we need to set up a few things:

Create a “bpelunit” folder in the test sub-directory.
Create a BPELUnit test suite file in this folder.
Create a build file that deploys, runs and undeploys the new tests and generates the reports.
Modify the “deploy” target of the existing build script to compile the BPELUnit tests and deploy them into appropriate directory.
Add an “antcall” command to integration-tests' pom.xml maven script to call bpelunit build file during the integration-tests phase.

Result of this modifications will be that during the execution of Riftsaw integration tests the BPELUnit test suite along with required files will be copied into the “target” directory and later the new test will be executed and the generated report will be saved in a directory along with other test reports.

In the first part we were using the quickstart Hello World sample, so we will stick to this one and show how to test it via BPELUnit automatically during the integration tests.

First we create a BPELUnit test suite file "Quickstart_bpel_hello_world.bpts" in RIFTSAW_SRC/integration-tests/src/test/resources/samples/Quickstart_bpel_hello_world/bpelunit/. We will use the very same file we created using Eclipse, so you can just copy it. In case you didn't follow the first part of this article you can find the test suite source code there and just paste it into the new file.

Next we need to create the build script for this new test. Open a new file “bpelunit_build.xml” and paste the code below.

<project name="Quickstart_bpel_hello_world" default="test" basedir=".">
 <description>
     ${ant.project.name}
     ${line.separator}
 </description>
 <property name="version" value="1" /> 
 <property name="server.dir" value="${org.jboss.as.home}/server/${org.jboss.as.config}"/>
 <property name="conf.dir" value="${server.dir}/conf"/>
 <property name="deploy.dir" value="${server.dir}/deploy"/>
 <property name="server.lib.dir" value="${server.dir}/lib"/>
 <property name="test.dir" value="${basedir}/target/tests/${ant.project.name}" />
 <property name="reports.dir" value="${basedir}/target/bpelunit-reports" />
 <property name="sample.jar.name" value="${ant.project.name}-${version}.jar" /> 
 <path id="lib.path">
     <fileset dir="${bpelunit.home}/lib">
         <include name="*.jar" />
     </fileset>
 </path>
 <condition property="reportsDir.unavailable">
     <not>
         <available file="${reports.dir}" type="dir" />
     </not>
 </condition>
 <target name="deploy">
     <echo>Deploy ${ant.project.name}</echo>
     <copy file="${test.dir}/${sample.jar.name}" todir="${deploy.dir}" />
     <echo>Waiting 5 seconds to ensure proper deployment</echo>
     <sleep seconds="5" />
 </target>
 <target name="undeploy">
     <echo>Undeploy ${ant.project.name}</echo>
     <delete file="${deploy.dir}/${sample.jar.name}" />
     <echo>Waiting 5 seconds to ensure proper undeployment</echo>
     <sleep seconds="5" />
 </target>
 <target name="create.reportsDir" if="reportsDir.unavailable" >
     <mkdir dir="${reports.dir}"/>
 </target>
 <target name="test">
     <antcall target="deploy" />
     <echo>Running BPEL Unit test for ${ant.project.name}</echo>
     <tstamp>
         <format property="timestamp" pattern="yyyy-MM-dd_HH:mm:ss" />
     </tstamp>  
     <typedef name="bpelunit" classname="org.bpelunit.framework.ui.ant.BPELUnit">
         <classpath refid="lib.path" />
     </typedef>
     <antcall target="create.reportsDir" />
     <bpelunit testsuite="${test.dir}/${ant.project.name}.bpts" bpelunitdir="${bpelunit.home}">
         <output style="PLAIN" file="${reports.dir}/${ant.project.name}.${timestamp}.txt" />
         <output style="XML" file="${reports.dir}/${ant.project.name}.${timestamp}.xml" />
     </bpelunit>
     <antcall target="undeploy" />
 </target>
</project>

The important target in this script is “test” which first deploys the process into Riftsaw running in JBoss AS, then runs the test and generates reports (in plain-text and XML format) and then undeploys the process.

Now we have two files in the Quickstart_bpel_hello_world/bpelunit directory, the test suite and the build script we've just created. We want these files to be copied into the deploy directory for the test to be properly executed. On top of that we need to copy the WSDL file as well. To do this, open the "build.xml" file located in the test's root directory and at the end of the first "target" element add:

<echo>Deploy BPELUnit files for ${ant.project.name}</echo>
<copy todir="${deploy.dir}/${ant.project.name}">
 <fileset dir="${test.dir}/bpelunit"/>
</copy>
<copy todir="${deploy.dir}/${ant.project.name}">
 <fileset dir="${test.dir}/bpel">
     <include name="*.wsdl" />
 </fileset>
</copy>

This ensures that the WSDL file, the test suite and the BPELUnit build script will be copied into the deploy directory, which is RIFTSAW_SRC/integration-tests/target/tests/Quickstart_bpel_hello_world/.

One last thing remaining is modifying the "pom.xml" in integration-tests root directory. Open this file and in the project/build/plugins/plugin/executions element create a new "execution" node that will look like this:

<execution>
 <id>test-riftsaw-bpelunit</id>
 <phase>integration-test</phase>
 <configuration>
     <tasks>
         <ant antfile="${basedir}/target/tests/Quickstart_bpel_hello_world/bpelunit_build.xml" />
     </tasks>
 </configuration>
 <goals>
     <goal>run</goal>
 </goals>
</execution>

Running the automated tests

First we need to build Riftsaw itself, so from the RIFTSAW_SRC directory we run:

mvn clean install

Now in the final step we are going to execute the automated test by running this command from the "integration-tests" directory:

mvn -Dorg.jboss.as.home={path_to_jboss_as}
-Dbpelunit.home={path_to_bpelunit}
-Dorg.jboss.esb.home={path_to_jboss_esb}
-Dorg.jboss.as.config=default
-Ddatabase=hsql -Dws.stack=default -Dreplace.qa.jdbc=false clean install

In the log file you can find the report of the test that was made. It should look similar to this:

deploy:
[echo] Deploy Quickstart_bpel_hello_world
[copy] Copying 1 file to /opt/local/jboss/jboss-5.1.0.GA/server/default/deploy
[echo] Waiting 5 seconds to ensure proper deployment
[echo] Running BPEL Unit test for Quickstart_bpel_hello_world

create.reportsDir:
[mkdir] Created dir: /opt/local/jboss/riftsaw-2.0-CR1-src/integration-tests/target/bpelunit-reports
MEASURECOVERAGE=FALSE
ROOTPATH=/ws/
Test Run Completed. 1 run (0 failures, 0 errors)

undeploy:
[echo] Undeploy Quickstart_bpel_hello_world
[delete] Deleting: /opt/local/jboss/jboss-5.1.0.GA/server/default/deploy/Quickstart_bpel_hello_world-1.jar
[echo] Waiting 5 seconds to ensure proper undeployment

During the test the reports (in TXT and XML format) will be generated in the target/bpelunit-reports directory. The XML report contains extensive information that describe what message were sent to the BPEL engine, what was the expected and received outcome and how it affected the result of the test.

In the log you can see the build waits 5 seconds before and after the test run. This is to ensure the proper deployment. Of course in case there are more tests the deployment wouldn't be made for each single test separately, but for efficiency reasons a deployment of all processes would happen at one moment. In the presented example we use the approach just to make it as simple as possible.

Conclusion

We've just managed to successfully test the Quickstart Hello World process using a simple request-response test via BPELUnit. Transforming other samples to use this tool will be now even more easy, because now after we create the test suite (for example using the Eclipse wizard), we only need to copy the build script file with one small modification – changing the project name. The second piece of code also stays the same and as for the "pom.xml", we just need to add one line for each test.

Using BPELUnit for testing processes in Riftsaw - Part 1

2010-01-22T05:35:00.000-08:00

BPELUnit (http://www.bpelunit.net) is a testing framework intended for testing BPEL processes on a request-response basis. It comes with a plug-in for Eclipse for creating and running BPEL test suites as well as a possibility to run automated tests via Ant tasks. This makes it possible for including BPELunit tests in the Riftsaw integration tests. In this post I'll try to give you some tips and instructions on how to test a process deployed on Riftsaw using the BPELUnit Eclipse plug-in.

Preparation:

If you start from the scratch you will need:

Unzip JBossAS, JBossESB and Riftsaw to appropriate directories.
Set the environment variable JBOSS_HOME to point to JBossAS directory.
Edit ESB_HOME/install/deployment.properties to modify org.jboss.esb.server.home to point to JBOSS_HOME directory
Edit RIFTSAW/install/deployment.properties to modify AS and ESB home directories.
From ESB_HOME/install run “ant deploy” - this deploys ESB to the application server.
From RIFTSAW/install run “ant deploy” - this deploys Riftsaw to the application server

BPELUnit 1.1.0 Eclipse plug-in

Run Eclipse and choose a workspace directory.
Go to the URL above and follow instructions on how to install BPELUnit into Eclipse.

Last thing remaining is to verify that Riftsaw has been deployed, start the server and deploy the sample project that we are going to test:

In Eclipse, select to add a server and choose your installation of JBoss AS
Start the server
After the start-up navigate to http://localhost:8080/bpel-console.
If a login dialog comes up, Riftsaw was installed successfully.
Log in with “admin”/”password” credentials, you will see that no processes are deployed.
From RIFTSAW/samples/quickstart/hello_world directory run “ant eploy”.
Refresh the Process Definitions window. A Hello World process should appear.

Creating a test:

Now that everything is ready it's time to finally do some testing. On the BPELUnit website there is a Hello World tutorial which I strongly recommend to go through as the following example will be very similar. The only difference will be that we're going to use a Hello World sample that we have just deployed on the server. With BPELUnit we can create and run a test that will verify that the sample is working correctly. Here are the steps for setting up this project in Eclipse:

Create a new project in you workspace using File -> New -> Other -> General -> Project
Name it “bpelunit_test”
Copy RIFTSAW/samples/quickstart/hello_world/bpelContent/HelloWorld.wsdl to the “bpelunit_test” directory in your Eclipse workspace
Refresh the project to see the WSDL file has been added
Add a test suite into the project via File -> New -> Other -> BPELUnit -> BPELUnit Test Suite

The test suite we've just created is an xml file that defines which process is going to be tested and how. This Hello World process functionality is that it takes a string input, connects it with “ World” and sends it back. So if the input is “HELLLO” the output should be “HELLO World”. And this is what we're going to test. Now fill the details as following:

Base URL: http://localhost:7777/ws (prefix for mock service url, unimportant for now)
PUT Name: HelloWorld
PUT Type: Fixed deployer
WSDL: Click “Browse” and select the HelloWorld.wsdl file

Now save (Ctrl+S). Change the view under the form to “Source” and verify that it looks like the code below. If not, you can modify it so it does.


<?xml version="1.0" encoding="UTF-8"?>
<tes:testSuite xmlns:tes="http://www.bpelunit.org/schema/testSuite">
<tes:name>suite.bpts</tes:name>
<tes:baseURL>http://localhost:7777/ws</tes:baseURL>
<tes:deployment>
   <tes:put name="HelloWorld" type="fixed">
       <tes:wsdl>HelloWorld.wsdl</tes:wsdl>
   </tes:put>
</tes:deployment>
<tes:testCases/>
</tes:testSuite>

This is in fact how the test suite file really looks like. Now let's switch back to the “Test Suite” view and finally add a test case that will let us test the functionality of the process. In the section “Test Cases and Tracks” click “Add”, fill “SayHello” as a name and confirm. The SayHello test case is created which you can see in the list. Under this test case is a “client” node. This represents a client partner that will invoke the process. Now we will specify what message is going to be sent and what we are expecting to get. To do this follow these steps:

Select the “client” node under the SayHello test case.
In the “Activities” panel on the right click the “Add” button.
Select “Send/Receive Synchronous” - this is the most basic a request-response activity.
Notice that service, port and operation are already filled as there's only one operation - “hello”.
Check the box “Enter XML literal” and switch to “XML to be sent” tab.

We've done this because we want to specify what data will be sent to the process in the XML format. Now to the windows that appeared paste this code:

<TestPart>HELLO</TestPart>

This means the input string will be “HELLO”. Now click “Next” so we can specify what outcome we are expecting. Let's add a condition to check by clicking on the appropriate button. The “Expression” here is an expression in XPath format that will select the proper response XML node, in our case the outgoing message. Fill in these:

Expression: //TestPart
Value: 'HELLO World' (including the apostrophes)

Now click “Finish” and save the test suite (Ctrl + S). Switch back to the “Source” view and inspect the code that has been created. It should look like this:


<?xml version="1.0" encoding="UTF-8"?>
<tes:testSuite xmlns:tes="http://www.bpelunit.org/schema/testSuite">
<tes:name>suite.bpts</tes:name>
<tes:baseURL>http://localhost:7777/ws</tes:baseURL>
<tes:deployment>
  <tes:put name="HelloWorld" type="fixed">
      <tes:wsdl>HelloWorld.wsdl</tes:wsdl>
  </tes:put>
</tes:deployment>
<tes:testCases>
  <tes:testCase name="SayHello" basedOn="" abstract="false" vary="false">
      <tes:clientTrack>
          <tes:sendReceive service="wsdl:HelloService" port="HelloPort" operation="hello" xmlns:wsdl="http://www.jboss.org/bpel/examples/wsdl">
              <tes:send service="wsdl:HelloService" port="HelloPort" operation="hello" fault="false" delaySequence="">
                  <tes:data>
                      <TestPart>HELLO</TestPart>
                  </tes:data>
              </tes:send>
              <tes:receive service="wsdl:HelloService" port="HelloPort" operation="hello" fault="false">
                  <tes:condition>
                      <tes:expression>//TestPart</tes:expression>
                      <tes:value>'HELLO World'</tes:value>
                  </tes:condition>
              </tes:receive>
          </tes:sendReceive>
      </tes:clientTrack>
  </tes:testCase>
</tes:testCases>
</tes:testSuite>

That's it, we've just created a test case that will call the “hello” operation with the “HELLO” string as input and then it will check that the return value is “HELLO World”. The process itself is already deployed so the only thing that's left is to launch this test on it.

Running the test suite:

In the Project Explorer window right click on the “suite.bpts” file and choose “Run As” -> “BPELUnit TestSuite”. Now a new left tab should appear that will show the test results. If everything works correctly, the bars are going to be filled with green color. You can expand the nodes to see the SOAP messages that have been sent and received.

This tutorial presented how can be processes that are deployed on Riftsaw simply tested thanks to the BPELUnit framework. In the next blog post we will use the other way of using this tool – Ant build script. We are going to include BPELUnit testing into the present integration tests which will give us the opportunity to automate testing via this framework.

So have fun testing BPEL and please share your thoughts in comments :-)

-- Petr

We hang out at the ODE IRC channel

2009-12-17T10:26:00.000-08:00

Since RiftSaw is part of the larger ODE community we tend to hang out at the ODE IRC channel. Come find us at irc.codehaus.org #apache-ode. The logs can be found at http://echelog.matzon.dk/logs/browse/apache-ode, and don't forget to check out the stats. They are pretty funny.

RiftSaw Release 2.0-RC1

2009-12-16T20:34:00.000-08:00

Release Candidate 1 has landed. All targeted features have been implemented and we were able to port lots of examples from the jBPM BPEL project. Note that this release is tested to run on the combination of JDK-1.6, JBAS-5.1 and JBossESB-4.7 only. This release supports any JAX-WS compliant WS stack, but at this time we could only test running with JBossWS (the default WS provider in JBAS-5.1). You can download the release from here.

Cheers,

the RiftSaw team

One more RiftSaw post on DZone!

2009-12-03T07:41:00.000-08:00

http://soa.dzone.com/news/impatient-start-jboss-riftsaw-0

RiftSaw Release 2.0-M2

2009-11-25T08:06:00.000-08:00

The RiftSaw team is pleased to announce the availability of 2.0-M2.
This release provides early access to the new JAX-WS (using JBossWS) based integration, that replaces the Axis2 transport layer in the previous release, and the new admin console based on GWT.
This release is based on Apache ODE 1.3.3, and therefore if you had previously installed RiftSaw-2.0-M1, you will need to undeploy that version prior to installing M2. This is because M1 was based on the ODE 2.0 branch, which does not yet have a stable release. As the database schema changed between ODE1.x and ODE2.x, it will also be necessary to remove any database that had been configured for RiftSaw-2.0-M1 (BPELDB in the default/data folder if using derby).
Full release notes are available in the binary distribution.

One more time - the other post is on DZone too

2009-11-18T09:39:00.000-08:00

The link is: http://soa.dzone.com/news/esb-bpel-continuing-riftsaw

DZone Picked up The Post on JBossESB Integration

2009-11-13T07:48:00.000-08:00

And here it is:

http://soa.dzone.com/news/bpel-esb-and-back-introduction

From ESB to BPEL - Continuing with the RiftSaw-JBossESB Integration

2009-11-12T20:08:00.001-08:00

In the previous post to this blog, we looked at orchestrating JBossESB services from a RiftSaw BPEL process. In this post, we'll look at the other side of the RiftSaw-JBossESB integration; invoking a RiftSaw BPEL process from an ESB service.

Invoking a RiftSaw BPEL Process - From the JBossESB's Perspective, it's a Web Service

There are a couple of ways to do this. Remember, that from the JBossESB's perspective, a RiftSaw BPEL process is a web service. This means that a JBossESB service action can invoke a BPEL process in the same way that it can invoke any other web service that exposes a WSDL definition. There are multiple examples of this approach illustrated in the JBossESB quickstarts. For example, in the "webservice_consumer1" quickstart, the action used to invoke a web service is defined as:

In jboss-esb.xml:


  <actions mep="OneWay">
  <action name="request-mapper"
    class="org.jboss.soa.esb.samples.quickstart.webservice_consumer1.MyRequestAction">
  </action>
  <action name="soapui-client-action"
    class="org.jboss.soa.esb.actions.soap.SOAPClient">
      <property name="wsdl"
        value="http://127.0.0.1:8080/Quickstart_webservice_consumer1/HelloWorldWS?wsdl"/>
      <property name="responseAsOgnlMap" value="true" />
      <property name="SOAPAction" value="sayHello"/>
  </action>
  <action name="response-mapper"
        class="org.jboss.soa.esb.samples.quickstart.webservice_consumer1.MyResponseAction">
    </action>
    <action name="testStore" class=
      "org.jboss.soa.esb.actions.TestMessageStore"/>
  </actions>

Line 6: The SOAPClient class makes the call to the webservice.
Line 9: The parameter responseAsOgnlMap tells the JBossESB move the SOAP reponse data into that OGNL-based map and attach it to the message.
Line 10: The reference to the method to be invoked in the web service.

OK. That was easy. We completed the cycle of orchestrating JBossESB services from a RiftSaw BPEL process and invoking JBossESB service actions from a RiftSaw BPEL process.

But wait! We're not done yet. The RiftSaw-JBossESB integration also supports another way to invoke JBossESB service actions from a RiftSaw BPEL process without using HTTP, web services and WSDL.

A Different Way - the BPELInvoke Action

One of the JBossESB's features is an extensive set of predefined ("out of the box") actions that can be incorporated into your applications. These actions support a wide variety of tasks including:

Transformers and Converters - converting message data from one form to another
Business Process Management - integrating with JBoss jBPM
Scripting - automating tasks in supported scripting languages
Services - integration with EJBs
Routing - moving message data to the correct services
Notifier - sending data to ESB unaware destinations
Webservices/SOAP - the name says it all - support for Webservices

(There's also a Miscellaneous group that includes only one action - org.jboss.soa.esb.actions.SystemPrintln. This action prints of a message.)

JBossESB also supports a new out-of-the-box action that can be used to directly invoke a RiftSaw BPEL process. This action (org.jboss.soa.esb.actions.bpel.BPELInvoke) can be used if RiftSaw is installed and running in the same Java VM as the JBossESB and if the target BPEL process is deployed to the local RiftSaw instance. If your configuration meets these requirements, then it can be simpler to use the BPELInvoke action. You should also see better performance than using web services, as the RiftSaw BPEL process and JBossESB service actions are running in the same JVM.

The BPELInvoke action enables you to specify not just the RiftSaw process to be invoked, but also the specific operation within that process. You configure the BPELInvoke action with these properties:

service - This mandatory property references the service name, as defined in the WSDL, for the target RiftSaw BPEL process.
operation - The name says it all. This mandatory property references the operation, also defined in the target Riftsaw BPEL process WSDL, to be invoked.
requestPartName - This property defines the WSDL message part that the message content for the JBossESB-aware message processed by the JBossESB action should be mapped to. This property is optional and is used when the incoming JBossESB message does not already represent a multi-part message.
responsePartName - And finally, this property is used to extract the content of a response multi-part WSDL message, and insert it into the JBossESB-aware message that is passed to the next JBossESB action in the action pipeline. This property is optional and if it is not defined, the complete multi-part message value will be used in the JBossESB-aware message.

The BPELInvoke action can handle incoming messages with two types of content:

Document Object Model - If the content in the incoming message is a DOM document or element, then it can be used as the complete multi-part message, or as the content of a message part as defined with the optional requestPartName action property. If, however, the message content is a DOM text node, then it can only be used if a multi-part name has been defined in the optional requestPartName action property.
Java String - If the content in the incoming message is a string representation of an XML document, then the requestPartName property is optional. If this property is not defined, then the document must represent the complete multipart message. If, however, the message content is a string that does not represent an XML document, then the requestPartName is not optional and must be specified.

Let's take a look at the BPELInvoke action in action by running a quickstart example program.

BPELInvoke in a Quickstart

I can't say it often enough; the quickstarts are a great resource for learning how JBoss products work, and as a starting point for developing your own code. The BPELInvoke action is used in the "bpel_helloworld" quickstart. This quickstart is installed into your JBossESB server's /samples/quickstarts directory as part of the RiftSaw installations we walked through in this blog post: (hint - it's in step 6).

This quickstart relies on the riftsaw-2.0-SNAPSHOT/samples/quickstart/hello_world quickstart. Specifically, the bpel_helloworld quickstart invokes the RiftSaw BPEL process defined in the hello_world quickstart. So, before you run the bpel_helloworld quickstart, you have to deploy the hello_world quickstart.

The interesting part of the bpel_helloworld quickstart for us is this section of the jboss-esb.xml file:


<service
  category="HelloWorldBPELESB"
  name="SayHello"
  description="Hello World">
  <listeners>
    <jms-listener name="JMS-Gateway"
      busidref="quickstartGwChannel"
      is-gateway="true" />
    <jms-listener name="helloWorld"
      busidref="quickstartEsbChannel" />
  </listeners>
  <actions>
    <action name="action1" class="org.jboss.soa.esb.actions.SystemPrintln">
      <property name="printfull" value="true"/>
    </action>
    <action name="action2" class="org.jboss.soa.esb.actions.bpel.BPELInvoke">
      <property name="service" value="{http://www.jboss.org/bpel/examples/wsdl}HelloService"/>
      <property name="operation" value="hello" />
      <property name="requestPartName" value="TestPart" />
      <property name="responsePartName" value="TestPart" />
    </action>
    <!-- The next action is for Continuous Integration testing -->
    <action name="testStore" class="org.jboss.soa.esb.actions.TestMessageStore"/>
  </actions>
</service>

Line 16: Here's where we start the definition of the BPELInvoke action.
Line 17: The service in the Riftsaw BPEL process to be invoked.
Line 18: And the operation.
Lines 19 and 20: The request and response WSDL parts.

This diagram illustrates the inter-relationship of the JBossESB bpel_helloworld quickstart and the RiftSaw BPEL process configuration files.

Before we run the quickstart, there's one more thing to look at; the client. In the case of the quickstart, this is the SendEsbMessage.java program. This program is invoked when you execute the "ant sendesb" ant target as defined on lines 11-20 in the quickstart build.xml file:


<project name="Quickstart_esb_bpel_hello_world" default="run" basedir=".">

   <description>
     ${ant.project.name}
     ${line.separator}
   </description>

   <!-- Import the base Ant build script... -->
   <import file="../conf/base-build.xml"/>

   <target name="sendesb" depends="compile"
     description="Will send an esb Message">
     <echo>Runs Test ESB Message Sender</echo>
     <java fork="yes" classname="org.jboss.soa.esb.samples.quickstart.helloworld.test.SendEsbMessage" failonerror="true">
       <arg value="HelloWorldBPELESB"/> <!--  service category -->
       <arg value="SayHello"/>  <!--  service name -->
       <arg value="Hello World via ESB to BPEL"/> <!--  Message text -->
       <classpath refid="exec-classpath"/>
     </java>
   </target>

</project>

The command parameters are passed to SendEsbMessage.java. If we look at line 18 in that program (see below), we'll see that the client sends a message and receives a response. (Remember that with BPEL, all traffic follows a synchronous message exchange pattern.)


 public class SendEsbMessage
 {
   public static void main(String args[]) throws Exception
   {
 //  Setting the ConnectionFactory such that it will use scout
     System.setProperty("javax.xml.registry.ConnectionFactoryClass","org.apache.ws.scout.registry.ConnectionFactoryImpl");

     if (args.length < 3)
     {
       System.err.println("Usage SendEsbMessage <category><name> <text to send>");
       System.exit(1);
     }

     Message esbMessage = MessageFactory.getInstance().getMessage();

     esbMessage.getBody().add(args[2]);

     Message respMessage = new ServiceInvoker(args[0],args[1]).deliverSync(esbMessage, 5000);

     System.out.println("REPLY: "+respMessage.getBody().get());
   }

 }

OK, let's deploy and run the quickstart. Here are the ant commands and the output displayed by the client:


sendesb:
[echo] Runs Test ESB Message Sender
[java] REPLY: Hello World via ESB to BPEL World

BUILD SUCCESSFUL
Total time: 10 seconds

And here's the information written to the server log )I've truncated this a bit...)

22:57:05,591 INFO  [STDOUT] Message structure:
22:57:05,592 INFO  [STDOUT] [ message: [ JBOSS_XML ]
.
.
.
context: {}
body: [ objects: {org.jboss.soa.esb.message.defaultEntry=Hello World via ESB to BPEL} ]
fault: [  ]
attachments: [ Named:{}, Unnamed:[] ]
properties: [ {org.jboss.soa.esb.message.byte.size=3920,
org.jboss.soa.esb.message.time.dod=Tue Nov 10 22:57:05 EST 2009,
javax.jms.message.redelivered=false} ] ]

OK, it's not exactly thrilling, but, if you look closely, you'll see that the client sent this message:

Hello World via ESB to BPEL

And the RiftSaw BPEL process replied with this:

Hello World via ESB to BPEL World

That's right. The hello operation in the RiftSaw BPEL process did its thing and appended "World" to the message!

Closing Thoughts

The fact that from the ESB's perspective, a RiftSaw BPEL process is a web service, makes orchestrating ESB processes a straightforward task. The corollary is also true, in that a JBossESB action can also invoke a RiftSaw BPEL process in the same manner as a web service. It's also possible, however, to invoke a RiftSaw BPEL process with one of the JBossESB's out-of-the-box actions, BPELInvoke. In the next post to this blog, we'll look how exceptions are handled across the RiftSaw-JBossESB integration.

Acknowledgments

As always, I want to thank the RiftSaw community (especially Kurt Stam and Gary Brown), both for creating RiftSaw, writing the user guide on which this blog entry is based, and for their timely review input for this blog post!

From BPEL to the ESB and Back - Introduction to the Riftsaw-JBoss ESB Integration

2009-11-03T08:03:00.000-08:00

One of the great strengths of the JBoss software is in the integrations between projects. In this post, we'll examine the Riftsaw - JBoss ESB integration to connect Riftsaw BPEL processes to ESB services.

Background - JBosssESB

Service Oriented Architecture (SOA) is not a single program or technology. It’s really a matter of software architecture or design. In hardware terms, a “bus” is a physical connector that ties together multiple systems or subsystems. Instead of having a large number of point-to-point connectors between pairs of systems, you connect each system to the bus once. An Enterprise Service Bus (ESB) does the same thing, logically, in software.

Instead of passing electric current or data over the bus to and from the connections (or “endpoints”) on the ESB, the ESB logically sits in the architectural layer above a messaging system. The messaging system allows for asynchronous communications between services over the ESB. In fact, when you are working with an ESB, everything is either a service (which in this context is your application software) or a message being sent between services. It’s important to note that a “service” is not automatically a web service. Other types of applications, using transports such as FTP or JMS, can also be services. Is an ESB the same thing as SOA (Service Oriented Architecture)? Not exactly. An ESB does not provide a Service Oriented Architecture, but it does provide the tools than can be used to build one–especially loose-coupling and asynchronous message passing. SOA is a series of principles, patterns, and best practices.

JBossESB[1] is an open source ESB implementation that supports multiple transports, protocols, a listener-action model for loose coupling of services, content based routing with JBoss Rules (Drools), and BPEL process management with Riftsaw.

The Riftsaw-JBoss ESB Integration

In reviewing the Riftsaw-JBossESB integration, the three topics to consider are:

Orchestrating ESB Services From BPEL in Riftsaw to the ESB
Making Calls From the ESB to the BPEL process definition in Riftsaw
Exception Handling

(As a point of reference, the Riftsaw-JBossESB integration is similar to the jBPM-JBossESB integration[2] in that it covers topics related to these three topics, but there is an important differences. In the Riftsaw-JBossESB integration, communication is synchronous (remember that we are working with web services) and follows the request-response pattern. As a result, the Riftsaw-JBossESB integration is simpler than the corresponding jBPM-JBossESB integration.)

We'll take these topics one at a time. Let's start with: Orchestrating ESB Services From BPEL in Riftsaw to the ESB.

You might think that a feature as powerful as the orchestration of ESB services would be difficult to configure, but actually, it's very straightforward. Remember that from the JBoss ESB's perspective, the BPEL process is a web service. The ESB can receive messages from a Riftsaw BPEL process just as it would from any web service. Let's illustrate this by modifying the Riftsaw BPEL "hello_world" quickstart to orchestrate a service as defined by the JBoss ESB "helloworld" quickstart.

Modifying the Quickstarts

In the BPEL "hello_world" quickstart process definition, we have to modify this file:

File: samples/quickstart/hello_world/bpel/HelloWorld.wsdl


   1    <?xml version="1.0" encoding="utf-8" ?>
   2    <!--
   3      ~ Licensed to the Apache Software Foundation (ASF) under one
   4      ~ or more contributor license agreements.  See the NOTICE file
   5      ~ distributed with this work for additional information
   6      ~ regarding copyright ownership.  The ASF licenses this file
   7      ~ to you under the Apache License, Version 2.0 (the
   8      ~ "License"); you may not use this file except in compliance
   9      ~ with the License.  You may obtain a copy of the License at
  10      ~
  11      ~    http://www.apache.org/licenses/LICENSE-2.0
  12      ~
  13      ~ Unless required by applicable law or agreed to in writing,
  14      ~ software distributed under the License is distributed on an
  15      ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  16      ~ KIND, either express or implied.  See the License for the
  17      ~ specific language governing permissions and limitations
  18      ~ under the License.
  19      -->
  20    <wsdl:definitions
  21        targetNamespace="http://www.jboss.org/bpel/examples/wsdl"
  22        xmlns="http://schemas.xmlsoap.org/wsdl/"
  23        xmlns:tns="http://www.jboss.org/bpel/examples/wsdl"
  24        xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
  25        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  26        xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  27        xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype">
  28     
  29        <wsdl:message name="HelloMessage">
  30            <wsdl:part name="TestPart" type="xsd:string"/>
  31        </wsdl:message>
  32     
  33        <wsdl:portType name="HelloPortType">
  34            <wsdl:operation name="hello">
  35                <wsdl:input message="tns:HelloMessage" name="TestIn"/>
  36                <wsdl:output message="tns:HelloMessage" name="TestOut"/>
  37            </wsdl:operation> 
  38        </wsdl:portType>
  39     
  40         <wsdl:binding name="HelloSoapBinding" type="tns:HelloPortType">
  41            <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
  42            <wsdl:operation name="hello">
  43                <soap:operation soapAction="" style="rpc"/>
  44                <wsdl:input>
  45                    <soap:body
  46                        namespace="http://www.jboss.org/bpel/examples/wsdl"
  47                        use="literal"/>
  48                </wsdl:input>
  49                <wsdl:output>
  50                    <soap:body
  51                        namespace="http://www.jboss.org/bpel/examples/wsdl"
  52                        use="literal"/>
  53                </wsdl:output>
  54            </wsdl:operation>
  55        </wsdl:binding>
  56      <wsdl:service name="HelloService">
  57        <wsdl:port name="HelloPort" binding="tns:HelloSoapBinding">
  58          <soap:address location="http://localhost:8081/bpel/processes/helloWorld"/>
  59        </wsdl:port>
  60      </wsdl:service>
  61 
  62      <plnk:partnerLinkType name="HelloPartnerLinkType">
  63           <plnk:role name="me" portType="tns:HelloPortType"/>
  64           <plnk:role name="you" portType="tns:HelloPortType"/>
  65       </plnk:partnerLinkType>
  66    </wsdl:definitions>

The change to note is on line 58: Since we want the ESB application to define a listener to "listen" for incoming http traffic, we have to change the port for the BPEL process to not conflict with the JBoss AS server itself. We've selected port 8081 as the new port for the BPEL process. Remember, that as far as the ESB is concerned, the BPEL process is a web service.

In the JBoss ESB "helloworld" quickstart, we have to modify these 4 files:

File: jbossesb-4.6/samples/quickstarts/helloworld/jboss-esb.xml


   1    <?xml version = "1.0" encoding = "UTF-8"?>
   2    <jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd" parameterReloadSecs="5">
   3 
   4        <providers>
   5              <jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
   6                  <jms-bus busid="quickstartGwChannel">
   7                      <jms-message-filter
   8                          dest-type="QUEUE"
   9                          dest-name="queue/quickstart_helloworld_Request_gw"
  10                       />
  11                  </jms-bus>
  12                  <jms-bus busid="quickstartEsbChannel">
  13                      <jms-message-filter
  14                          dest-type="QUEUE"
  15                          dest-name="queue/quickstart_helloworld_Request_esb"
  16                      />
  17                  </jms-bus>
  18 
  19                  <jms-bus busid="quickstartEsbReplyChannel">
  20                      <jms-message-filter
  21                          dest-type="QUEUE"
  22                          dest-name="queue/quickstart_helloworld_Request_esb_reply"
  23                      />
  24                  </jms-bus>
  25 
  26 
  27              </jms-provider>
  28 
  29            <jbr-provider name="JBR-Http-1" protocol="http" host="localhost">
  30                <jbr-bus busid="Http-1" port="8081"/>
  31            </jbr-provider>
  32          </providers>
  33       
  34          <services>
  35            <service
  36                category="FirstServiceESB"
  37                name="SimpleListener"
  38                description="Hello World">
  39 
  40             <listeners>
  41                    <jms-listener name="JMS-Gateway"
  42                        busidref="quickstartGwChannel"
  43                        is-gateway="true"
  44                    />
  45                    <jms-listener name="helloWorld"
  46                                  busidref="quickstartEsbChannel"
  47                    />
  48                    <jbr-listener name="Http-Gateway" busidref="Http-1" is-gateway="true"/>
  49 
  50                </listeners>
  51         
  52        <actions mep="RequestResponse">
  53                       <action name="action1"
  54                           class="org.jboss.soa.esb.samples.quickstart.helloworld.MyJMSListenerAction"
  55                           process="displayMessage"
  56                           />   
  57                        <action name="action2" class="org.jboss.soa.esb.actions.SystemPrintln">
  58                          <property name="printfull" value="false"/>
  59                        </action>
  60                        <!-- The next action is for Continuous Integration testing -->
  61                        <action name="testStore" class="org.jboss.soa.esb.actions.TestMessageStore"/>
  62                </actions>
  63            </service>
  64          </services>
  65      
  66    </jbossesb>

The changes are:

Lines 29-31, and 48: Here's where we define the HTTP gateway listener that will watch for the message (request) sent by the BPEL process.
Line 52: This is an important change. In the original ESB helloworld quickstart, the message exchange pattern (mep) was set to "OneWay." In our modified quickstart, we need to have a response sent back to the BPEL process to complete the request/response sequence.
Lines 19-23: What's this all about? For each ESB-unaware gateway channel, the ESB requires a corresponding ESB-aware channel. In this context, "ESB-aware" refers to a channel communicating via messages in the org.jboss.soa.esb.message.Message format, and "ESB-unaware" refers to communicating via messages in a format other than (org.jboss.soa.esb.message.Message). We also have to add this ESB-aware channel to these files:

File: jbossesb-4.6/samples/quickstarts/helloworld/deployment.xml

     1    <jbossesb-deployment>
   2      <depends>jboss.esb.quickstart.destination:service=Queue,name=quickstart_helloworld_Request_esb_reply</depends>
   3      <depends>jboss.esb.quickstart.destination:service=Queue,name=quickstart_helloworld_Request_esb</depends>
   4      <depends>jboss.esb.quickstart.destination:service=Queue,name=quickstart_helloworld_Request_gw</depends>
   5    </jbossesb-deployment>

File: jbossesb-4.6/samples/quickstarts/helloworld/jbm-queue-service.xml

     1    <?xml version="1.0" encoding="UTF-8"?>
   2    <server>
   3 
   4      <mbean code="org.jboss.jms.server.destination.QueueService"
   5        name="jboss.esb.quickstart.destination:service=Queue,name=quickstart_helloworld_Request_esb_reply"
   6        xmbean-dd="xmdesc/Queue-xmbean.xml">
   7            <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
   8            <depends>jboss.messaging:service=PostOffice</depends>
   9      </mbean>
  10 
  11      <mbean code="org.jboss.jms.server.destination.QueueService"
  12        name="jboss.esb.quickstart.destination:service=Queue,name=quickstart_helloworld_Request_esb"
  13        xmbean-dd="xmdesc/Queue-xmbean.xml">
  14        <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
  15        <depends>jboss.messaging:service=PostOffice</depends>
  16      </mbean>
  17      <mbean code="org.jboss.jms.server.destination.QueueService"
  18        name="jboss.esb.quickstart.destination:service=Queue,name=quickstart_helloworld_Request_gw"
  19        xmbean-dd="xmdesc/Queue-xmbean.xml">
  20        <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
  21        <depends>jboss.messaging:service=PostOffice</depends>
  22      </mbean>
  23    </server>

Finally, we have to modify build.xml to reference the changed port number for the web services - only one line is changed:

    33   <arg value="http://localhost:8081/bpel/processes/helloWorld"/>

After we deploy both the quickstarts, we can initiate the ESB service orchestration by executing the "ant sendhello" command for the Riftsaw BPEL hello_world process. The server log shows this output:

22:38:51,690 INFO  [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
22:38:51,700 INFO  [STDOUT] Body: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsdl="http://www.jboss.org/bpel/examples/wsdl">
 <soapenv:Header/>
 <soapenv:Body>
    <wsdl:hello>
       <TestPart>Hello</TestPart>
       <TestPart2>Hello</TestPart2>
    </wsdl:hello>
 </soapenv:Body>
</soapenv:Envelope>
22:38:51,701 INFO  [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
22:38:51,716 INFO  [STDOUT] Message structure:
22:38:51,716 INFO  [STDOUT] [<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsdl="http://www.jboss.org/bpel/examples/wsdl">
 <soapenv:Header/>
 <soapenv:Body>
    <wsdl:hello>
       <TestPart>Hello</TestPart>
       <TestPart2>Hello</TestPart2>
    </wsdl:hello>
 </soapenv:Body>
</soapenv:Envelope>

And the Riftsaw BPEL hello_world process client shows this output:

$ ant sendhello
Buildfile: build.xml

sendhello:
   [echo] Send test message to: Quickstart_bpel_hello_world
   [java] <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsdl="http://www.jboss.org/bpel/examples/wsdl">
   [java]    <soapenv:Header/>
   [java]    <soapenv:Body>
   [java]       <wsdl:hello>
   [java]          <TestPart>Hello</TestPart>
   [java]          <TestPart2>Hello</TestPart2>
   [java]       </wsdl:hello>
   [java]    </soapenv:Body>
   [java] </soapenv:Envelope>
   [java]
   [java]

BUILD SUCCESSFUL
Total time: 2 seconds

Closing Thoughts

The fact that from the ESB's perspective, a Riftsaw BPEL process is a web service, makes orchestrating ESB processes a straightforward task. In the next post to this blog, we look going back the other way and making calls from the JBossESB to a BPEL process definition in Riftsaw.

References

[1] http://www.jboss.org/jbossesb

[2] http://jboss-soa-p.blogspot.com/2009/06/hanging-together-on-soa-platform.html

Acknowledgments

As always, I want to thank the Riftsaw community (especially Kurt Stam and Gary Brown), both for creating Riftsaw (and its documentation and examples) and for their timely review input for this blog post.

An Impatient Start with JBoss Riftsaw - 5 steps in 5 minutes

2009-10-29T05:49:00.000-07:00

I often recall having to spend many hours fighting with complex and error prone processes to install server software and get an 'helloworld' example running. With JBoss, however, it's much simpler. Unzipping a couple of files and maybe running ant generally does the trick.

Which brings us to Riftsaw, JBoss's new open source BPEL 2.0 engine. Riftsaw integrates with JBoss ESB and is optimized for use with the JBoss AS server. Even though it's a new project, it's easy to get going in only a few minutes. The entire set up process is documented in the Getting Started Guide, but if you're impatient, here are the steps. You can install and deploy everything you need in about 5 minutes, Assuming you don't have too slow a network connection. ;-)

You need (3) packages:

A JBoss application server to host Riftsaw,
A JBoss ESB server to support accessing services over the ESB,
and Riftsaw itself

Here are the (5) steps to take: (note - for this example, we're installing into /opt/local)

Step 1 - Install JBoss AS 5

On thing to keep in mind here is that you'll have to use Java 1.6 and install the for JDK 1.6 version of JBoss AS

Download: http://sourceforge.net/projects/jboss/files/JBoss/JBoss-5.1.0.GA/jboss-5.1.0.GA-jdk6.zip/
unzip jboss-5.1.0.GA-jdk6.zip

Step 2 - Install/deploy JBoss ESB 4.6 to AS

Download: http://www.jboss.org/downloading/?projectId=jbossesb&url=/jbossesb/downloads/4.6/binary/jbossesb-4.6.zip
unzip jbossesb-4.6.zip
cd /opt/local/jbossesb-4.6/install
cp deployment.properties-example deployment.properties
edit deployment.properties-example (set "org.jboss.esb.server.home=/opt/local/jboss-5.1.0.GA")
ant deploy

Step 3 - Build/Install/Deploy Riftsaw to AS

cd /opt/local
mkdir riftsaw ; cd riftsaw
svn checkout http://anonsvn.jboss.org/repos/riftsaw/trunk/
mvn clean install -P docs
cp distribution/target/riftsaw-2.0-SNAPSHOT.zip /opt/local
cd /opt/local
unzip riftsaw-2.0-SNAPSHOT.zip
cd /opt/local/riftsaw-2.0-SNAPSHOT/install
edit deployment.properties (set "org.jboss.esb.server.home=/opt/local/jboss-5.1.0.GA" and "org.jboss.esb.home=/opt/local/jbossesb-4.6")
ant deploy

Note: An alternative to building Riftsaw from the trunk source would be to download the latest stable build from: http://www.jboss.org/riftsaw/downloads.html

Step 4 - Start up the AS server

cd /opt/local/jboss-5.1.0.GA/bin
sh ./run.sh

Step 5 - Run a quickstart

This BPEL quickstart sends a message, modifies it, and sends back the modified version.

cd /opt/local/riftsaw-2.0-SNAPSHOT/samples/quickstart/hello_world
ant deploy
ant sendhello
View the process here: http://127.0.0.1:8080/bpel-console/org.jboss.bpm.console.Application/Application.html

OK. It's not really 5 steps, to run the quickstarts that use the ESB, there's one more step:

Step 6 - Run an ESB quickstart

First, deploy Riftsaw ESB samples to the ESB directory.

cd /opt/local/riftsaw-2.0-SNAPSHOT/install
ant deploy-esb-examples

Then, run a quickstart:

cd /opt/local/jbossesb-4.6/samples/quickstarts/conf
cp quickstarts.properties-example quickstarts.properties
edit quickstarts.properties (set org.jboss.esb.server.home=/opt/local/jboss-5.1.0.GA)
cd /opt/local/jbossesb-4.6/samples/quickstarts/bpel_helloworld
ant deploy
ant sendesb (to demonstrate an ESB action invoking a BPEL process)

Well - my 5 minutes are up. What's next? I want to try all the examples, read the documentation and spend a lot more than 5 minutes working with Riftsaw. I also want to examine Riftsaw-ESB integration in greater detail in a subsequent blog post. It's described in the User Guide... ;-)

BPEL Editor for RiftSaw

2009-07-22T13:39:00.001-07:00

As many of you saw in Burr's webinar presentations today, we are planning on leveraging the Eclipse BPEL editor for use with the RiftSaw runtime. Consistent with JBoss practice, this editor will be distributed at part of JBoss Tools. I'd encourage those interested to visit the JBT site and make use of their downloads, forums, mailing lists, JIRA, etc. to participate in the open source community around this part of our BPEL offerings. Doing so will make sure that all involved see any questions or comments.

Webinar: Simple, Open and Affordable BPEL

2009-07-21T19:34:00.000-07:00

As more and more organizations are leveraging BPEL to specify orchestration of Web services, there is a growing need for a simple, open and affordable implementation.

In this session, you learn how Red Hat plans to deliver an enterprise-class, supported, open source BPEL engine as part of the JBoss Enterprise Middleware portfolio. You also learn how to leverage this technology to help your organization fulfill the promise SOA and have an opportunity to interact with the key engineers behind the product.

Date: July 22, 2009
Time: Choose from two live sessions:
- 9am EDT (New York) / 13:00 GMT / 3pm CEST (Paris)
- 2pm EDT (New York) / 18:00 GMT / 8pm CEST (Paris)

Speaker: Burr Sutter

Register Now

http://www.jboss.com/promo/BRMWebinarSeries/

Here is link to the slides.

JBoss BPEL Server

2009-07-21T15:49:00.000-07:00

Project Riftsaw is a WS-BPEL 2.0 engine that is optimized for the JBoss Application Server container. WS-BPEL 2.0 is an XML-based language for defining business processes that orchestrate web services.

Riftsaw supports :

short-lived and long-running process executions
process persistence & recovery
process versioning
JBoss deployment architecture, enabling hot deployment
ant-based deployment
integrated with the JBoss ESB
Eclipse-based designer (Bundled with JBoss Tools 3.1)

Riftsaw is based on Apache Ode and will extend Ode in the following ways:

Tight integration with Eclipse BPEL editor
Support for JBossWS, and therefore the three web service stacks (Native, Apache CXF and Metro)
Enterprise quality management console
Runs in JBoss Cluster

We welcome your input and involvement. Please get started as an end-user by downloading these items, read the getting started guide and provide feedback in the forums. If you are interested in becoming a contributor to this new and exciting project please use the developer forums to contact us.