Aug 25

In my past articles I presented, amongst other things, HL7 v2 messaging solutions using the Oracle SOA Suite 11g R1 B2B HL7 infrastructure. At the beginning of the calendar year 2012 Oracle released a new incarnation if its HL7 messaging capability under the name of the “SOA Suite for healthcare integration”. This capability builds on the SOA Suite B2B HL7, adding design, configurator, monitoring and management user interface capabilities which greatly simplify the task of creating HL7 v2 messaging solutions and enhance management and operational reporting.
The new and changed functionality is significant enough for me to consider writing a series of articles on the topic. The series is intended to walk the reader through the tasks of creating specific HL7 v2 messaging solutions using the SOA Suite for healthcare integration.
At this point in time I expect to produce articles on the following topics, in the order given:

  1. Overview of the Development Environment – this article
  2. A Very Brief Overview of HL7 v2 Messaging
  3. A Very Brief Overview of the SOA Suite for healthcare integration
  4. Creating a Canonical Message Model –
  5. HL7 v2 Inbound to File –
  6. Constructing file name from message content and messaging properties –
  7. HL7 v2 Inbound to HL7 v2 Outbound Pass-through –
  8. Transformation and Routing using XSL and Mediator –
  9. Adding Data Map for pass-through code translation –
  10. Automating Exception Message Handling –
  11. Externalise, “Repair” and Resubmit “broken” messages –
  12. Implementing an A19 Query Processor –
  13. Send, Receive and Translate HL7 messages using B2B Web Services
  14. Other Key Features
  15. HL7 v2 solution using JMS “the Java CAPS way” – (this article was propmpted by correspondence with Steve L)

It will take some time to produce these articles and the list may change.
I am interested in hearing from people about other topics they might like to see covered. I will consider suggestions though I am not promising that I will act upon them.
In the following sections I am briefly elaborating on what I expect each topic to cover, and presenting a solution schematic where a solution will be developed.

The article is availabe as “SOA Suite for healthcare integration Series – Series Overview” at

Mar 06

It is expected that business solutions, whether designed in accordance with the Service Oriented Architecture principles, or designed following any of the other accepted architectural principles, are robust, reliable and available. Robustness, reliability and availability, in this context, means not just that solutions are free of design and implementation defects but are also architected and deployed in such a way that business users can access them when needed, in spite of any failures that may occur.

In an ideal world all applications will always be available for use. In the real world this may not be possible, or may not be possible at a reasonable cost.

The document referenced below discusses resilience options available to the designers of GlassFish ESB solutions and considerations that need to be entered into when designing GlassFish ESB solutions for resilience and high availability.

The document, GlassFishESB_Solution_Resillience_Options_v0.5.pdf, is available at

Jul 17

Java CAPS 6 has the 5.x compatibility infrastructure which allows one to import 5.x projects right into Java CAPS 6, build, deploy and run without changes. One can also develop repository-based projects in Java CAPS 6 – that’s the 5.x-style projects. This is the old way of developing Java CAPS solutions – still good and valid.

If one were to decide to not use the old way there is the JBI infrastructure, which allows development of solutions that use BPEL Service Engine, XSLT Service Engine, IEP Service Engine, Java EE Service Engine, etc., and a variety of Binding Components. The implication is that business logic is implemented in BPEL 2.0, which is used to orchestrate other services and resources, including interaction with external systems through Binding Components. This is the new way of developing Java CAPS solutions – 100% compatible with the Open Source OpenESB project since it uses the OpenESB project-developed container and components.

Someone might ask “so what happened to eGate?”. “eGate” meaning Java Collaboration Definition-like logic components, eWays and the JMS messaging backbone.

While the facility seems underadvertised/downplayed, Java CAPS 6 provides a number of 5.1 eWay-based JCA Adapters and a moderately easy means of developing JCA Message-Driven Beans that can use these adapters to implement JCD-like logic components and, effectively, eGate-like solutions that do not use BPEL or the JBI infrastructure.

This Note discusses and illustrates the implementation of a mixed Java CAPS 5.x-like integration solution that retrieves a file from the local file system using JCA Adapters and passes its content to a BPEL 2.0 process executing in the JBI container. This requirement I have seen and heard of being implemented in 5.x many times by many customers.

Most of the material in the first 16 pages of this Note is the same as in Note 2.

The JCA Message-Driven Bean, the piece of JCD-like Java logic, will be triggered by a Batch Inbound Adapter (what one would have called the Batch Inbound eWay in 5.1), will read the content of the file using the Batch Local File Adapter (eWay) and will send the payload as a string to a BPEL 2.0 Business Process, which will be triggered by this message and will execute in the JBI container. The batch Inbound Adapter will be configured to use a regular expression to match the name of the file. Once it finds the file it will rename the file by prepending the GUID to the name and will pass the new name, the original name and the directory path to the Java code. This is exactly what the 5.1 Batch Inbound does. The JCA MDB will use the new name, the original name and the directory path to dynamically configure the Batch Local File Adapter to retrieve the file content and rename the file (post transfer) to the original name with some string appended to indicate that the file was processed. This, too, is exactly what one would do in a 5.1 JCD in the same circumstance. Once the payload is available the JCA MDB will use the OneWay WSDL interface and the JBI NMR to send it, as a String, to a BPEL 2.0 process. Both the JCA MDB and the BPEL process will be a part of the same JBI Composite Application and will communicate with one another using the Normalized Message Router (NMR).

The entire Note is available in 03JCA-BInboundThroughBLFToBPEL2.0.pdf

Jun 21

The attached document explores the ability of Java CAPS 6/JBI and OpenESB to expose and execute Java-based logic as a JBI service. It walks through the process of creation, deployment and execution of a simple File-to-File integration solution that reads an XML record from a text file, invokes java logic that operates on that record then writes the XML response record into a file.


There are errors in pictures on pages 12 and 13. The WSDL name in the pictures does not correspond to the name in the text. This error is corrected in revision 1.1 of the document, 04File2FielJavaEE_1.1.pdf. Thanks to Juraj Kazda for spotting the issue.

Mar 07

It has been a long road but the Java CAPS Book, on which my colleagues and I have been working for a while, is about to make it into the world. The publisher made it available on line through the Safari Books Online – Rough Cuts.

Anyone with a subscription can get their hands on the material right now. Anyone without a subscription can get a trial subscription from Safari Books Online.

The URL is:

The printed version is expected early May 2008.



A correction – Sebastian’s name is spelt incorrectly – it is actually Sebastian Krueger – we are working on getting the spelling corrected.

Thanks Christian for picking up the acronym error.

Tagged with:
Nov 07

By default Java CAPS uses the Java Message Service infrastructure as its underlying messaging layer. Occasionally there is a requirement or a temptation to develop synchronous service, for example invoked as web services or as HTTP Request/Response services, that invoke some back-end component over JMS. In request/response scenarios the response must be delivered by the component which received the request, a JCD or a BP. If the request is passed to the nback-end infrastructure through a JMS Queue or Topic there arises an issue of getting the response back to the same instance of the JCD or a BP that sent the original request. The attached extract, JMS RequestReply, from an early draft of the “Java CAPS Basics – Implementing Common EAI Patterns“, discusses and illustrates how the JMS RequestReply() method of the JMS OTD can be used to implement this kind of functionality.

Oct 22

After almost 2 years the Java CAPS Book I authored with Sebastian Krueger, Brendan Marry, Saurabh Sahai, Peter Vaneris and Andrew Walker, seems like finally seeing the light of day. The tentative print date for the book, “Java CAPS Basics – Implementing Common EAI Patterns”, Part I, is advertised as set at February 2008 at the pre-order page at

Here are the Table of Contents and the Preface

Tagged with:
preload preload preload