Packaging reusable services in OpenESB and JavaCAPS 6

When you need to create reusable services in OpenESB or the JBI components provided in JavaCAPS 6 you are constrained by the packaging and deployment model defined in the JBI standard. This entry will look at the different alternatives and their consequences.

The JBI standard refers to individual services as Service Units (SU) and requires that one or more SUs must be packaged together as a Service Assembly (SA) for deployment. A deployable application would then consist of one or more SAs. You can think of it was being analogous to JAR files and EAR files in JavaEE. These SAs are atomic deployment units to a JBI-compliant runtime such as OpenESB or JavaCAPS 6.

For instance, this Hello World SA example consists of two SUs, one for the BPEL process and one for the SOAP binding component:

Let's look at an example using processes and sub-processes by stretching the Hello World example beyond where it should go. Although I'm talking about BPEL SUs, the principles are the same for packaging and deploying reusable SUs defined for any Service Engine.

Say we have a business process, bpHelloWorldMulti which takes two strings in its input msg, the name of the person to say 'hello' to and the language to use when saying 'hello'. If 'language' = "EN" it says "Hello "; if 'languague' is set to "NO" it says "Hei " (norwegian).

Now we have two other processes, bpHelloWorldEN and bpHelloWorldNO. Which expose services to say hello in English and Norwegian respectively. They implement themselves by simply calling the subprocess bpHelloWorldMulti with the language element set to 'EN' or 'NO'

How should these be packaged and deployed in SAs? There are 3 alternatives.

The first alternative is to package the reusable service, bpHelloWorldMulti, with a binding such as a SOAP binding, into a SA and deploy it. bpHelloWorldEN and bpHelloWorldNO are also packaged in their own respective SAs and deployed. The two main processes can then call sub process as if it was a remote service.

  • Advantages:
    • The 3 services are all independent of each other and can be undeployed, modified, and redeployed as needed.
  • Disadvantages:
    • Communication between two services must occur through binding components - over the wire - which is inefficient when all services are hosted on the same node.
    • Some dependency checking needs to be done to ensure that bpHelloWorldMulti is deployed before either of the two calling services are executed. This wont be checked at deploy-time by the runtime environment and will result in a runtime exception if the bpHelloWorldMulti is not deployed when one of the services attempts to invoke it.

The second alternative is to package bpHelloWorldMulti in both of the two SAs which hold bpHelloWorldEN and bpHelloWorldNO. That is, there is a copy of bpHelloWorldMulti in each of the two SAs.

  • Advantages
    • Communication can occur more efficiently by not requiring over-the-wire communication through binding components
    • Developer dependency checking is not a problem because bpHelloWorldMulti is deployed and undeployed with each its calling services.
  • Disadvantages
    • Service Units deployed to the same JBI component require unique xml schema QNames. The two versions of bpHelloWorldMulti in each SA would need to have different namespaces so there are no name clashes during deployment.
    • Maintenance nightmare.

The third alternative is similar to the first - the three services are each deployed in their own SA. However, in this case we register bpHelloWorldMulti as an External Service Unit in the Service Assembly of the two calling Service Assemblies. In this scenario, when we deploy the SAs for bpHelloWorldEN and bpHelloWorldNO , they will be able to communicate through the NMR (i.e., not over the wire) with bpHelloWorldMulti. This is the best alternative in most reuse scenarios.

  • Advantages:
    • Communication can occur more efficiently by not requiring binding components
    • The three Service Units are all independent of each other and can be undeployed, modified, and redeployed as needed.
  • Disadvantages:
    • Some checking needs to be done to ensure that bpHelloWorldMulti is deployed before the two calling services are invoked. This wont be checked at deploy-time by the runtime environment and will result in a runtime exception. Similarly, if the bpHelloWorldMulti is undeployed or the interface is changed, a run-time exception will result.

There is also a fourth alternative, where bpHelloWorldMulti is packaged in the same SA as bpHelloWorldEN, and bpHelloWorldNO refers to it as an External Service Unit. That will have similar disadvantages for bpHelloWorldNO as the third alternative.


This simply doesn't work for me. Well your example would probably work but I have a chain of EJBs and that doesn’t work. I have a simple Echo bean that I try to call in various ways:
1. Call as WS (no JBI) works fine.
2. Call via a proxy EJB as WS (use Web Service Client, still no JBI) works fine.
3. Call via CASA, direct or wrapped by BPEL, similar to your examples, also works fine.
4. But when I try to call the proxy EJB via CASA and BPEL I get "JBIMR0044: Unable to locate activated endpoint for service connection".

I try to put everything in the same CASA as JBI Modules, I try to add WSDL ports (force "over the wire"), I try to put the Echo bean in an External Module and so on. Often I’m unable to connect the wrapper to the service and see the message "Cannot connect two shadows of the same endpoint. The connection is not really needed". What I’m doing is really a fine example of cargo cult programming! Unfortunately I’m running out of variations on how to call the service and none of them is working!

Posted by Roger P on November 02, 2009 at 09:06 AM CET #


Its hard for me to see exactly what you are trying to do. Can you post to users@openesb list and include a pic of CASA for #4?


Posted by Jason on November 03, 2009 at 12:16 AM CET #

Post a Comment:
Comments are closed for this entry.



« June 2016