Here's a quick overview to deploy Ode on a JBI container (e.g. ServiceMix)

1) Checkout the trunk from the Apache Ode project

svn co http://svn.apache.org/repos/asf/incubator/ode/trunk/ ode

2) Compile Ode modules:

cd ode
mvn install

3) Install on JBI container

For example, with ServiceMix you can simply use file-system deployment:

(from jbi directory)
cp target/ode-jbi-2.0-SNAPSHOT-installer.zip SERVICEMIX_DIR/install

4) Deploying Processes

1. Place your .BPEL, deploy.xml, .WSDL and .XSD files in SU.ZIP (for ServiceUnit)
2. Place the SU.ZIP in a service assembly
3. Copy the SA.ZIP into SERVICEMIX_DIR/deploy directory

Examples

Some JBI examples are available under jbi-examples/src/examples:

• HelloWorld2
• PingPong
• Async2

To compile the examples, you must define the ODE_HOME environment variable:

# On Linux/Unix
export ODE_HOME=/path/to/ode/distribution

# On Windows
set ODE_HOME=C:\Path\To\Ode\Distribution

and run Ant in the example's directory:

cd jbi-examples/src/examples/PingPong
ant

This will create a JBI service assembly in the "build" subdirectory. With ServiceMix you can simply copy it to the file-system hot deployment directory:

(from PingPong directory)
cp build/PingPing-Assembly.zip SERVICEMIX_DIR/deploy

Finally, you can test the example by typing:

(from PingPong directory)
ant test

JBI Endpoints

Ode now relies strictly on abstract web service definitions (i.e., without binding/service/port definitions), meaning that you only need abstract WSDLs when compiling processes. Since JBI uses normalized messages (in theory, at least), there no need to define bindings for the BPEL service engine.

The following is an example of bindings to JBI internal service endpoints using the deployment descriptor (e.g. deploy.xml):

<?xml version="1.0" encoding="UTF-8"?>
<deploy xmlns="http://ode.fivesight.com/schemas/2006/06/27/dd"
        xmlns:pns="urn:/HelloWorld2.bpel"
        xmlns:sns="urn:/HelloWorld2.wsdl" >

        <process name="pns:HelloWorld2">
                <active>true</active>
                <provide partnerLink="helloPartnerLink">
                        <service name="sns:HelloService" port="HelloPort"/>
                </provide>
        </process>
</deploy>

The above description binds the provided helloPartnerLink to the service sns:HelloService and port HelloPort on the JBI bus.

One may use JBI binding components to make services externally available and therefore providing concrete bindings to those binding components. An example of exposing process services via SOAP/HTTP can be found in the PingPong ping-http service unit.

Database

The generated installer will use an internally-managed embedded Derby database. No configuration is required. To use an external database one needs to modify pxe-jbi.properties found in the component installer zip.

Compatibility Caveat

Many binding components are not very good about delivering messages in the correct format for WSDL11 services.

Known Issues with ServiceMix 3.0

ServiceMix' so-called lightweight components make it difficult to properly expose process services since they do not fully implement the JBI contract and do not allow the process engine to enquire about its external endpoints.

The servicemix-http binding component does not normalize messages

Outstanding Issues

• SM-581 Use WSDL of servicemix-http endpoint if none is supplied by the target ServiceEndpoint [FIXED in trunk but not yet released. Will be in ServiceMix 3.0.1]

• SM-557 WSDL 1.1 message normalization for the servicemix-http component [PENDING REVIEW]

Fixed Issues

• SM-490 Inconsistent property names for JbiConstants.PROTOCOL_TYPE and JbiConstants.PROTOCOL_HEADERS [FIXED in ServiceMix 3.0]

• SM-488 SoapHelper Improvement: Resolve WSDL operation name based on message content [FIXED in ServiceMix 3.0]