There are currently two ways that a BPEL process can be deployed to the RiftSaw BPEL server:

1. Packaging the artifacts and directly deploying them to the JBossAS deploy folder
2. Using the Eclipse based deployment mechanism

This article will describe the first approach. More information on the second approach can be found here.

Defining a Deployment Descriptor

The RiftSaw BPEL Server is based on the Apache ODE BPEL engine and therefore uses the deployment descriptor associated with this project. More information on the structure of the deployment descriptor can be found here.

An example of the deployment descriptor, taken from the $RiftSaw/samples/esb/webservice_esb_bpel/bpel folder in the distribution, is:

<deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03" xmlns:ABI_OrderManager="http://org.jboss.esb/quickstarts/bpel/ABI_OrderManager" xmlns:ABI_Shipping="http://org.jboss.esb/quickstarts/bpel/ABI_Shipping" xmlns:Customer="http://www.jboss.org/samples/bpel/Customer" xmlns:Customer.wsdl="http://www.jboss.org/samples/bpel/Customer.wsdl" xmlns:OrderProcess.bpel="http://www.jboss.org/samples/bpel/OrderProcess.bpel" xmlns:Retailer.wsdl="http://www.jboss.org/samples/bpel/Retailer.wsdl">
  <process name="OrderProcess.bpel:OrderProcess">
    <process-events generate="all"/>
    <provide partnerLink="Customer">
      <service name="Retailer.wsdl:RetailerService" port="RetailerPort"/>
    </provide>
    <provide partnerLink="OrderManager">
      <service name="ABI_OrderManager:RetailerCallbackService" port="RetailerCallbackSoap"/>
    </provide>
    <invoke partnerLink="Customer">
      <service name="Customer.wsdl:CustomerService" port="CustomerSoap"/>
    </invoke>
    <invoke partnerLink="OrderManager">
      <service name="ABI_OrderManager:OrderManagerPortTypeService" port="OrderManagerPortTypePort"/>
    </invoke>
    <invoke partnerLink="Shipper">
      <service name="ABI_Shipping:ShippingPortTypeService" port="ShippingPortTypePort"/>
    </invoke>
  </process>
  <process name="Customer:Customer">
    <process-events generate="all"/>
    <provide partnerLink="PurchasingPLT">
      <service name="Customer.wsdl:CustomerService" port="CustomerSoap"/>
    </provide>
  </process>
</deploy>

The deploy element contains one or more process elements, one per BPEL process being included in the bundle being deployed (note: it is not necessary for all BPEL processes that interact to be defined in the same deployment descriptor - they can be deployed separately). The name attribute defines the qualified name of the BPEL process being deployed.

Under the process element, there is an optional process-events element. This is used to configure what management events should be generated when executing the particular process. The important details are represented by the provide and invoke sub-elements.

The provide sub-elements define the WSDL interfaces that the BPEL process implements. It provides the configuration details for the associated partner link and WSDL service/port.

The optional invoke sub-elements define the WSDL interfaces that the BPEL process will invoke. It also provides the configuration details for the relevant partner link and WSDL service/port.

The filename for the deployment descriptor should be bpel-deploy.xml. NOTE: In the ODE project, they use the filename deploy.xml, but when used in a JEE environment, this is too generic - so RiftSaw prefixes this filename with 'bpel-'.

Packaging up the BPEL Artifacts

The BPEL processes (.bpel files) should be placed in the same folder as the deployment descriptor. However other artifacts can be placed in sub-folders, and referenced based on their relative location.

For example, the $RiftSaw/samples/esb/webservice_esb_bpel/bpel folder contains the BPEL and deployment descriptor for this sample, but the WSDL, XSD and XSL artifacts are placed in separate sub-folders.

The BPEL process references the WSDL based on a relative path, such as:

     <bpel:import importType="http://schemas.xmlsoap.org/wsdl/" location="wsdl/Retailer.wsdl"
               namespace="http://www.jboss.org/samples/bpel/Retailer.wsdl"/>

Similarly the WSDL references the XSD based on a relative path:

     <import namespace="http://www.jboss.org/samples/bpel/CustomerOrder.xsd" 

          schemaLocation="../schema/CustomerOrder.xsd" />

The reference to the XSL transformation is slightly different, the XSL stylesheet is loaded at runtime using the classloader, and therefore needs to be referenced relative to the root folder of the distribution. So for the BPEL activity,

     <bpel:assign name="AssignDataForSalesOrder" validate="yes">

          <bpel:copy>

               <bpel:from expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0">
                    bpel:doXslTransform('xsl/SalesOrder.xsl', $SubmitOrderRequest.Document )
               </bpel:from>

               <bpel:to part="parameters" variable="SalesOrderRequest"/>

          </bpel:copy>

     </bpel:assign>

the XSL stylesheet is located in the subfolder xsl contained beneath the root folder of the distribution.

Although the artifacts can be placed in subfolders, as shown in this example, they can also be placed in the same folder as the deployment descriptor and BPEL processes.

Once the artifacts have been assembled into the appropriate folder structure, then the next step is to package them up into a jar.

NOTE: It is important that the deployment descriptior and BPEL processes be at the root of the jar.

Once the jar has been built, it simply needs to be placed in the deploy folder of the JBossAS environment.