Monday Jul 21, 2008

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.

Monday May 05, 2008

Overview of OpenESB Sceencast

I've created a new screencast which provides an overview presentation of OpenESB, including how JBI works, and how OpenESB relates to JavaCAPS.

Having run OpenESB workshops with companies for almost 18 months now, I realise that it is easy to misunderstand the how a JBI-compliant infrastructure operates and also what information is needed by developers to design and build solutions.

JBI is a standard for infrastructure developers and the inner-workings really are not always relevant for developers building applications with a JBI compliant infrastructure. However, app developers should have an understanding of the basic concepts to understand what is happening. Many developers also like to know what is happening "under the covers" so that they fully understand how issues like performance, security, and transactions are handled by the infrastructure. Hopefully this presentation provides that information.

The presentation walks through an example, actually the tutorial problem which was detailed in the last entry, and explains how service interaction occurs and the role of the normalised message router from the developer's perspective.

Friday Jan 25, 2008

Introduction to OpenESB tutorial

I've created a set of screencasts showing how to build a simple composite application using OpenESB. The goal is to build something simple which shows multiple Service Engines and Binding Components to reinforce the concepts of Java Business Integration. The Demo Project is an over simplified Loan Application Process (there is an unwritten rule that all vendor demos must use a banking applications :). The composite application consists of the following parts:
  • the process orchestration is implemented in BPEL
  • the process should be exposed to Applicants as a WS-I Basic Profile compliant webservice
  • the process invokes a JavaEE EJB to performing the processing of the loan application
  • after processing, the process invokes a ReportMail Service which is running remotely and can only be communicated with through JMS
  • finally, the capability to invoke the Loan Application Process through the file systems (e.g., incoming ftp msg) in addition to a webservice endpoint is added.



« July 2016