Packaging reusable services in OpenESB and JavaCAPS 6
By jason on Jul 21, 2008
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.
- The 3 services are all independent of each other and can be undeployed, modified, and redeployed as needed.
- 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.
- 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.
- 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.
- 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.
- 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.