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 Jul 07, 2008

Java CAPS Users Conference - EMEA

The Java CAPS Horizons Summit is returning to Europe with a two-day conference plus post-event hands-on workshops.

The summit agenda is designed for Java CAPS Customers to:

  • Become familiar with the new technology in Java CAPS Release 6
  • Gain insight into migrating to the new platform
  • Get the latest developments and insider tips directly from technology innovators
  • Participate in workshops, technical deep dive and solution sessions
  • Network with your peers and exchange knowledge
  • Become familiar with the components of Java CAPS including: GlassFish Enterprise Server, Access Manager, Sun Java System Message Queue, NetBeans IDE, and MySQL
  • Learn how to participate in the open source communities which will drive Java CAPS going forward.

Another goal of the summit is to provide customers with a chance to interact directly with representatives from the Java CAPS Engineering team. This may be in the form of a common round-table session or as a 1-on-1 session. When registration opens you will have a chance to sign-up for an engineering feedback sessions

The date and location are tentatively set for Oct 6-8 in Munich. Hopefully they will be confirmed in the coming weeks but we wanted to announce as early as possible before people start their summer vacations.

Friday Jun 20, 2008

OpenESB @ JavaDeus

Yesterday was the Austrian Developer Day - JavaDeus. It was a good event with about 450 attendees, not to mention the free beer, dinner, and giant outdoor screen to watch the euro2008 qtr final after the technical sessions had finished. Plenty of Sun technology on show with JavaFX, DTrace, SunSPOTs, Alexis doing his Glassfish spiel, and also one of the MySQL engineers, Kay, doing some sessions.

The OpenESB session went well with a full room of developers and also a couple of JavaCAPS users who were interested in new capabilities. I combined the introductory presentation and demonstration into a single session and also showed off some of the Fuji technology being prototyped for OpenESB v3.

The session before mine was also interesting with a former Sun employee discussing the integration concepts used by Mule2 and SCA (as realised in Tuscany). Combined with the OpenESB session it showed that many of the concepts are analogous (though not equivalent) across all these infrastructures, though the implementations vary in their approach to in-built mediation support, tooling, pluggability, and vendor independence.

The OpenESB tooling really stood out and, though Mule currently has more out of the box mediation capabilities, the Integration Flow Language of Fuji certainly looks like a very flexible alternative. The technology preview shows a lot of promise and IFL generated the most interest amongst people with some experience with integration middleware.

Wednesday Jun 11, 2008

OpenESB at Austrian Developer Day

As Alexis already pointed out, Sun Austria is hosting a Java Developer Day on June 17th 2008. This is a free event with NetBeans, JavaFX, MySQL, OpenSolaris, OpenESB, and of course GlassFish.

I'll be doing a preso/demo of OpenESB. If you are interested in OpenESB or its relationship with JavaCAPS Release 6, come on down.

Thursday May 15, 2008

Differences between Java CAPS 6 and OpenESB

One of the most common questions I get asked is, "Will Sun support OpenESB?" or "Is Java CAPS a supported version of OpenESB?" Developers want to get started now with functionality in Open ESB and feel confident that it will be supported by Sun with a Java CAPS license.

We do already have some JavaCAPS customers who are entering the development phase of their projects with Open ESB in the knowledge that the infrastructure will be a supported part of Java CAPS by the time they go to production. Unfortunately, the answer to the original questions is a little more detailed than simply "yes" or "no". Let me explain...

Java CAPS 6 is, to grossly oversimplify it, Java CAPS 5 + some OpenESB technology. However the first release of Java CAPS 6 will not include all OpenESB components. This is for a couple of reasons:

  • Not all openesb components have been through the necessary QA to make them ready for production yet.
  • Not all openesb components are developed by Sun, so it is impossible for Sun to support them.

When Java CAPS 6 is released, it will consist of some openesb components. For instance:

  • JBI runtime.
  • JavaEE SE

During the rest of 2008, Sun will continue to make other openesb components production ready and make them supported parts of Java CAPS. The exact content and timeline of these "Component Packs" or is still to be released, but you can probably expect them to include:

  • IEP SE
  • JMS BC
  • File BC
  • others.
(note: I'm not in product management so this isn't an official list, just an indication)

Additionally, Sun may enter agreements with the companies who are developing other openesb components and make them "supported" parts of Java CAPS. So it is possible that OpenESB components that are not developed by Sun will also be supported by a Java CAPS license.

To give you an example. I currently have two Java CAPS 6 "customers", even though it has not yet been released.. They have looked at their requirements and see that they need only components which will be available in the initial release of Java CAPS 6 or will most likely be available in Component Packs in 2008. They have started development work now and plan to be in production in 2009. By 2009, all OpenESB components they need will be supported parts of Java CAPS.


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