The most well-known open source BPEL engine is Apache ODE. Nevertheless, there are several other engines available that also deserve some attention. One of them I recently started using is bpel-g. This engine is based on the final release of the former ActiveBPEL engine by Active Endpoints. This engine was quite well-known at its time (and used in quite some scientific papers), but the direct support by Active Endpoints for the open source version seems to have discontinued (although I could not find an announcement confirming this). I assume the engine has made it into their BPM suite, but again, this is just guesswork. Today, the engine is still under active development, but with a new name, bpel-g. One of its recent new features is integration with Apache Camel. Bpel-g still falls somewhat short on tutorials which is why I am writing this post.
The engine is quite light-weight and you can run it on tomcat. Here, I provide a simple example for installing the engine and deploying a simple BPEL process, an echo process that replies an int value. I assume that you are familiar with the basics of BPEL and WSDL.
To install the engine on tomcat, you need to get two things:
bpel-g.war goes in tomcats webapps directory, located at
$TOMCAT_HOME/webapps and that’s it. You can start tomcat (the startup script is located in
$TOMCAT_HOME/bin) and the engine gets installed and is ready for use. It creates a directory named
$TOMCAT_HOME where the deployment artifacts ought to go, but first you need to build such an artifact.
BUILDING DEPLOYMENT ARCHIVE AND DEPLOYING A PROCESS
Basically, you need a BPEL process, a WSDL definition serving as interface for the process, and a deployment descriptor. All the files described here are available in a github repository. If you package the files in the repository as a zip archive, you can directly deploy this archive on bpel-g. Here is the interface for the echo process defined in the WSDL file (named EchoInterface.wsdl):
<?xml version="1.0" encoding="UTF-8"?> <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:plink="http://docs.oasis-open.org/wsbpel/2.0/plnktype" xmlns:vprop="http://docs.oasis-open.org/wsbpel/2.0/varprop" xmlns:tns="http://dsg.wiai.uniba.de/wsdl/echointerface" name="EchoInterface" targetNamespace="http://dsg.wiai.uniba.de/wsdl/echointerface"> <plink:partnerLinkType name="EchoInterfacePartnerLinkType"> <plink:role name="echoInterfaceRole" portType="tns:EchoInterfacePortType"/> </plink:partnerLinkType> <types> <xsd:schema targetNamespace="http://dsg.wiai.uniba.de/wsdl/echointerface"> <xsd:element name="echoRequest" type="xsd:int"/> <xsd:element name="echoResponse" type="xsd:int"/> </xsd:schema> </types> <message name="echoRequestMessage"> <part name="inputPart" element="tns:echoRequest"/> </message> <message name="echoResponseMessage"> <part name="outputPart" element="tns:echoResponse"/> </message> <portType name="EchoInterfacePortType"> <operation name="echo"> <input name="echoInput" message="tns:echoRequestMessage"/> <output name="echoOutput" message="tns:echoResponseMessage"/> </operation> </portType> <binding name="EchoInterfacePortTypeBinding" type="tns:EchoInterfacePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="echo"> <soap:operation/> <input name="echoInput"> <soap:body use="literal"/> </input> <output name="echoOutput"> <soap:body use="literal"/> </output> </operation> </binding> </definitions>
Its structure is pretty simple: A
partnerLinkType which we need for the BPEL process. Further, type and message definitions for two messages that consist of a single message part, being an int value. A
portType definition with a single synchronous operation and a simple document/literal style binding for this operation. You might notice that there is no service and endpoint address definition in this WSDL. From what I have experienced so far, bpel-g is a little bit special here. You can put service definitions in the WSDL and the package will deploy, but the definitions are ignored. For bpel-g, endpoint information needs to go into the deployment descriptor and more on that later.
Now, here comes a BPEL process that provides an implementation for this interface (named Echo.bpel):
<?xml version="1.0" encoding="UTF-8"?> <process name="Echo" targetNamespace="http://dsg.wiai.uniba.de/bpel/echo" xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" xmlns:ec="http://dsg.wiai.uniba.de/wsdl/echointerface"> <import namespace="http://dsg.wiai.uniba.de/wsdl/echointerface" location="EchoInterface.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"/> <partnerLinks> <partnerLink name="MyRoleLink" partnerLinkType="ec:EchoInterfacePartnerLinkType" myRole="echoInterfaceRole"/> </partnerLinks> <variables> <variable name="ReplyData" messageType="ec:echoResponseMessage"/> <variable name="InitData" messageType="ec:echoRequestMessage"/> </variables> <sequence> <receive name="InitialReceive" createInstance="yes" partnerLink="MyRoleLink" operation="echo" portType="ec:EchoInterfacePortType" variable="InitData"/> <assign name="AssignReplyData"> <copy> <from variable="InitData" part="inputPart"/> <to variable="ReplyData" part="outputPart"/> </copy> </assign> <reply name="ReplyToInitialReceive" partnerLink="MyRoleLink" operation="echo" portType="ec:EchoInterfacePortType" variable="ReplyData"/> </sequence> </process>
The process imports the WSDL file and defines a
partnerLink set to
myRole referencing the
partnerLinkType from the WSDL file. Furthermore, it defines two variables of the
messageTypes from in the WSDL and starts the process with a
receive activity that references the appropriate variable and the
operation defined in the WSDL
assign activity copies the input value to the second variable and this variable is used in the final
reply activity that replies to the synchronous invocation and ends the process.
There is only one more file required, the deployment descriptor (named deploy.xml):
<?xml version="1.0" encoding="UTF-8"?> <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03" xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"> <process xmlns:tns="http://dsg.wiai.uniba.de/bpel/echo" name="tns:Echo"> <provide xmlns:tns="http://dsg.wiai.uniba.de/wsdl/echointerface" partnerLink="MyRoleLink"> <service name="tns:EchoInterfaceService" port="EchoInterfacePort"/> </provide> </process> </deploy>
The structure of this descriptor is actually identical to the structure of the deployment descriptors used by Apache ODE. From version 5.2 on, bpel-g supports the ODE structure. Basically, for every process to be deployed, the services provided and invoked need to be listed here. As said before: If you want to set endpoint addresses, this information needs to go here, in the form of a WS-Addressing
EndpointReference. If you do not set it explicitly, a default address is set for your service, in my case this is
http://localhost:9080/bpel-g/services/EchoInterfaceService. As a side note: The BPEL process at hand does not invoke a service, but if so, an
EndpointReference for that service needs to be put into the deployment descriptor as well.
Now, all you need to do is to build a zip archive of these files (named echo.zip) and put it into bpel-g’s working directory, located at
$TOMCAT_HOME/bpr for hot deployment. Eventually (pretty quickly, from what I have seen), the bpel-g deployment scanner will find the new archive, unpack it into
$TOMCAT_HOME/bpr/work and thus deploy the process. You can fire up your browser at
localhost:8080/bpel-g/ for the bpel-g management pages, where you can see the process deployed and ready for invocation.
INVOKING THE DEPLOYED PROCESS
You can now send SOAP messages to the address
http://localhost:8080/bpel-g/services/EchoInterfaceService using the tool of your choice. Mine is soapUI. A sample SOAP request looks like this:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ech="http://dsg.wiai.uniba.de/wsdl/echointerface"> <soapenv:Header/> <soapenv:Body> <ech:echoRequest>1</ech:echoRequest> </soapenv:Body> </soapenv:Envelope>
And the response I got is this:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <ns1:echoResponse xmlns:aetgt="http://dsg.wiai.uniba.de/wsdl/echointerface" xmlns:ns1="http://dsg.wiai.uniba.de/wsdl/echointerface">1</ns1:echoResponse> </soapenv:Body> </soapenv:Envelope>
The engine is pretty simple to install and use, especially if you compare it to certain commercial products. I suggest you give it a try!
– Fixed broken link to Tomcat download
– Added link to github repository
– Removed installtion of H2 which is already included in bpel-g