Category Archives: Sun

Migrating Java CAPS 5/6 Assets to Oracle SOA Suite – HL7 JCD to Document Callout Migration

This article leverages discoveries from the 2+ year old article “Migrating Java CAPS 5/6 Assets to Oracle SOA Suite 11g – HL7 JCD to Spring Component Migration”, at http://blogs.czapski.id.au/2010/10/migrating-java-caps-56-assets-to-oracle-soa-suite-11g-hl7-jcd-to-spring-component-migration,  and presents a different method of reusing “HL7 Transformer JCD” code in a SOA or OSB solution. This method uses SOA Suite for healthcare integration, slightly modified Java code for a “HL7 Transformer JCD” and WebLogic JMS. The Java CAPS part of the discussion is substantially the same, except the JCD code is wrapped in a SOA Suite for healthcare integration Callout, rather than being converted to a Spring Component embedded in a SOA Campsite. The “HL7 Adapter” part of the article is different in that SOA Suite for healthcare integration is used instead of the SOA Suite B2B HL7 functionality.
This article is of potential interest to these Sun/SeeBeyond customers who have an investment in moderate and large Java Collaboration Definition-based transformation and mapping rules, and who are looking for ways to reuse as much as possible of the Java code involved, when migrating to the Oracle SOA Suite or the Oracle Service Bus. The example developed in this article comes from the healthcare domain and uses the HL7 OTDs (Object Type Definitions). This is a deliberate choice because all but the most trivial HL7 transformations will involve hundreds of lines of Java code, therefore are a good candidates for migration. The adapter part of the HL7 solution is provided by the SOA Suite for healthcare integration. This makes the method domain-specific.
Discussion in this article addresses a subset of technologies available in the Java CAPS and in the SOA Suite for healthcare integration. Specifically, the Java Collaboration Definitions supported in Java CAPS 5.x and in Java CAPS 6/Repository, and the SOA Suite for healthcare integration (part of the SOA Suite 11g R1 PS5).
There is no discussion pertaining to JBI-based technologies or Java CAPS BPEL-based technologies. There is no discussion about other ways in which Java logic can be deployed as part of an Oracle SOA Suite solution.
The HL7 eWay and JCD based Java CAPS solution will be ported to the Oracle SOA Suite for healthcare integration and Java-based environment. HL7 Adapters will be replaced with the HL7 endpoints provided by the Oracle SOA Suite for healthcare integration infrastructure. What minimal routing is used will be provided by the Mediator component via JMS Queues. Transformation logic will be ported to the Java POJO (Plain Old Java Object) and will be embedded in the endpoint as a document callout.
This article walks through the process of “extracting” JCD source and related archives from Java CAPS, developing a stand-alone Java application which uses the JCD source, encapsulating JCD source in a SOA Suite for healthcare integration callout and finally reproducing Java CAPS HL7 solution functionality in an equivalent SOA Suite for healthcare integration solution.
The complete article is available at http://blogs.czapski.id.au/wp-content/uploads/2013/02/09_HL7JCD2DocumentCalloutMigration_v1.0.1.pdf.

Data files used in this article series are available at:

ADT_A01_output_1.hl7 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A01_output_1.zip – this file contains a single ADT A01 transaction

SOA Suite for healthcare integration Series – HL7 v2 solution using JMS “the Java CAPS way”

This article may be of interest to these who would like to use the “SOA Suite for healthcare integration” HL7 v2 delimited message handling functionality in solutions similarly to how Oracle Java CAPS HL7 eWay-based solutions were built, perhaps as endpoints in a “Service Bus”-based infrastructure, or to these who would like to use the HL7 messaging handing functionality in OSB environments. In essence, for these unfamiliar with the Java CAPS pattern of use, there were the “Inbound HL7 eWay” and the “Outbound HL7 eWay” patterns. An inbound HL7 v2 Adapter (eWay) would receive a HL7 message, perform all (minimal) validation and acknowledgement processing and store the incoming message in a persistent JMS Queue for some downstream component to process the message as necessary. An Outbound HL7 v2 Adapter (eWay) would read a HL7 message from a JMS Queue (where it was deposited by some upstream component) and send it out to the external system, performing any HL7 ACK processing that might have been required.
In the prior articles in this series we used direct integration between the HL7 v2 endpoints and SOA Suite Composites which provided processing logic. While in my articles JMS is used implicitly as an internal mechanism (via B2B_IN_QUEUE and B2B_OUT_QUEUE JMS queues) the SOA Suite composite did not explicitly use JMS adapters.
It is possible to configure SOA Suite for healthcare integration endpoints in such a way that messages the inbound endpoint receives will be deposited in a particular JMS destination (queue or topic other than the B2B_IN_QUEUE) associated with the endpoint, and messages to be sent by an outbound endpoint will originate in a specific JMS destination (queue or topic other than the B2B_OUT_QUEUE). This will allow such endpoints to be used in Oracle Service Bus-based or other ESB-based solutions as services with JMS interfaces.
In this article we will develop and exercise an inbound-to-JMS and JMS-to-outbound HL7 v2 delimited message processing solutions to demonstrate this capability.

The complete article is available at http://blogs.czapski.id.au/wp-content/uploads/2013/02/SOASuiteHCI_ch15_Inbound_HL7v2Delimited_The_JavaCAPS_Way_v0.1.0.pdf.

Data files used in this article series are available at:

ADT_A01_broken_1.hl7 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A01_broken_1.zip – this file contains a single ADT A01 transaction, in which the EVN segment’s name is rbroken, making the message invalid. This message is used in the article “SOA Suite for healthcare integration Series – Exception Handling – Processing Endpoint Errors” for testing exception handling
ADT_A01_output_1.hl7 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A01_output_1.zip – this file contains a single ADT A01 transaction
ADT_A03_output_1.hl7 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A03_output_1.zip – this file contains a single ADT A03 transaction
ADT_A01_output_5099.hl7 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A01_output_5099.zip – this file 5099 ADT A01 transactions, separated by \r\r\n, or Carriage Return, Carriage Return and New Line
QRY_A19.hl7 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/QRY_A19.zip – this file contains a sample A19 query message

Migrating Java CAPS 5/6 Assets to Oracle SOA Suite 11g – HL7 JCD to Spring Component Migration

This article is of potential interest to these Sun/SeeBeyond customers who have an investment in moderate and large Java Collaboration Definition-based transformation and mapping rules, and who are looking for ways to reuse as much as possible of the Java code involved, when migrating to the Oracle SOA Suite. The example developed in this article comes from the healthcare domain and uses the HL7 OTDs (Object Type Definitions). This is a deliberate choice because all but the most trivial HL7 transformations will involve hundreds of lines of Java code, therefore are a good candidates for migrating to the SOA Suite Spring Component as means of preserving the code and the effort invested in developing it. This does not make the method domain-specific. On the contrary, the method is applicable to all other domains where JCDs with significant transformation and mapping rules content are used.

Discussion in this article addresses a subset of technologies available in the Java CAPS and in the SOA Suite. Specifically, the Java Collaboration Definitions supported in Java CAPS 5.x and in Java CAPS 6/Repository, and the Spring Component supported in the SOA Suite 11g R1 PS2. Both use the Java programming language and related runtime environment to implement processing logic.  There is no discussion pertaining to JBI-based technologies or Java CAPS BPEL-based technologies. There is no discussion about other ways in which Java logic can be deployed as part of a Oracle SOA Suite solution.

The HL7 eWay and JCD based Java CAPS solution will be ported to the Oracle SOA Suite 11g B2B and Mediator-based environment. HL7 Adapters will be replaced with the Oracle “Healthcare Adapters”, provided by the SOA Suite B2B HL7 support infrastructure. Routing will be provided by the Mediator component and transformation logic will be ported to the Spring Component.

This article walks through the process of “extracting” JCD source and related archives from Java CAPS, developing a stand-alone Java application which uses the JCD source, encapsulating JCD source in a Spring component and finally reproducing Java CAPS HL7 solution functionality in an equivalent SOA Suite solution.

The complete article is available at http://blogs.czapski.id.au/wp-content/uploads/2010/10/08_HL7JCD2SpringComponentMigration_v1.3.pdf

Exercising a Resilient Java CAPS 6 HL7 v2 Repository Solution

From time to time prospective clients ask for a proof that Java CAPS will not loose HL7 messages in the event of machine or network failure.

In this Note a heterogeneous, non-clustered collection of hosts will be used to implement and exercise Java CAPS 6/Repository HL7 v2 based solutions. The environment consists of two independent “machines”, which are not a part of an Operating System Cluster. Each “machine” hosts a GlassFish Application Server, which is the Java CAPS 6 runtime. Application Servers are independent of one another and are not clustered. This is to demonstrate that HL7 processing components, and solutions based on these components and other standard components in the Java CAPS infrastructure, can be designed and implemented in such a way that message loss in the event of typical failure and disruption scenarios is avoided.

This note discusses an exercise involving an example healthcare environment processing HL7 v2 messages. Discussion includes customization of a generic Java CAPS 6.2 VMware Virtual Appliance for a specific HL7 exercise and deploying ready-made Java CAPS 6/Repository-based solutions. The exercise for HL7 eWay and HL7 Inbound and Outbound projects, processing HL7 v2.3.1 messages, will be conducted and discussed.

The reader will be convinced that a resilient Java CAPS solution can be configured and that it will process messages in the face of typical failure and disruption scenarios without message loss or duplication.

Note that this article is not introductory in nature. It assumes that the reader has a fairly good working knowledge of the Java CAPS 5 or Java CAPS 6/Repository product and a good working knowledge of related areas, such as HL7 messaging, virtualisation and suchlike. These matters are not explained in this article.

The note is available as 03_Conducting_JavaCAPS_6_HL7_Resilience_Exercise_v1.0.0.0.pdf at http://blogs.czapski.id.au/wp-content/uploads/2010/04/03_Conducting_JavaCAPS_6_HL7_Resilience_Exercise_v1.0.0.0.pdf

Kiran Busi pointed out o me that the project export links in the PDF documehnt are broken. Here they are, correct this time. It is less trouble to post them here then to modify the PDF and re-post that.

JC62_HL7_Resilience_Project_Exports_no_Envs – http://blogs.czapski.id.au/wp-content/uploads/2010/04/JC62_HL7_Resilience_Project_Exports_no_Envs.zip

JC62_HL7_Resilience_Project_Exports_with_Envs – http://blogs.czapski.id.au/wp-content/uploads/2010/04/JC62_HL7_Resilience_Project_Exports_with_Envs.zip

Installing Java CAPS 6.2 Runtime on the Basic JeOS Appliance for HL7 Resilience Testing

From time to time prospective clients ask for a proof that Java CAPS will not loose HL7 messages in the event of machine or network failure.

This note walks through the process of installing a Java CAPS 6.2 runtime on the Base OpenSolaris-based VMware Virtual Appliance, discussed in the Blog Entry “GlassFish ESB v2.x Field Notes – Preparing Basic JeOS Appliance for GlassFish ESB LB and HA Testing” at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-x-field-notes-preparing-basic-jeos-appliance-for-glassfish-esb-lb-and-ha-testing.

At the end of the Note we will have a Java CAPS 6.2 VMware Appliance with Java CAPS 6.2 Runtime infrastructure, ready to use for reliability testing, or any other purpose for which a Java CAPS 6.2 runtime appliance might be appropriate.

The Note is available at “http://blogs.czapski.id.au/wp-content/uploads/2010/04/02_Installing_JavaCAPS_6.2_on_JeOS_appliance_v1.0.0.0.pdf“.

Java One 2008 and Java CAPS Book Pictures – a trip back in time :-)

As I was going through the past entries, fixing links and uploading articles, to make sure that past posts in the new blog are working, I came across articles related to my trip for the Java One 2008 and the “launch” of the Java CAPS book. Since it is not likely that I will be getting another book in a great hurry I thought I will post some of the picures I took with my crummy phone camera 🙂

Michael Czapski with a copy oof the Java CAPS Book in the Java One 2008 bookstore

Brendan Marry, one of the co-authors, with the Java CAPS Book, in front of a shelf with a bunch of Java CAPS books

Java One 2008 feeding place - sone of the over 15 thousand people queuing to get lunch

Java One 2008 - plenary session venue

Brendan Mary with Myrna Rivera (right) in the Prentice Hall boot on teh Java One 2008 Exhibition floor. Myrna, who worked for SUn Publishing at the time, helped us a great deal in getting the book published - thanks Myrna 🙂

Java One 2008 - a walking, talking Duke mascot

Frank Kieviet (not that one could tell) delivering his part of our Java One session on implementing EAI patterns with OpenESB

Prentice Hall booth at Java One 2008 exhibition floor, featuring the Java CAPS book, amongst others 🙂

GlassFish ESB Resilience Options

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 http://blogs.czapski.id.au/wp-content/uploads/2010/03/GlassFishESB_Solution_Resillience_Options_v0.5.pdf

GFESB v2.x – Using NMProperties in BPEL 2.0 to force the HTTP BC to send the “connection: close” HTTP header

In the major writeup called “GlassFish ESB v2.2 Field Notes – Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions”, at http://blogs.czapski.id.au/?p=13, in section called “WS Projects”, pages 35-36 , I discuss how NMProperties in BPEL 2.0 can be used to force the HTTP BC to send the “connection: close” HTTP header, instead of the “connection: keep-alive” HTTP header, which it sends by default. Normally this does not matter but if a load balancer is to be used as a proxy, and a round robin load balancing is desired, the “connection: keep-alive” gets in the way. Rather then closing a connection after each HTTP request/response, as HTTP protocol was designed to do, “connection: keep-alive” HTTP header indicates to the server that connection is not to be closed in anticipation of another request coming form the same source “shortly”. Since the HTTP BC does not seem to have a place where this header can be removed or changed to “connection: close”, NMProperties in BPEL have to be used to force connection closure and enable correct load balancing behavior.

GFESB v2.x – Using WS-Addressing in BPEL 2.0 to implement the “Routing Ticket” EIP Pattern

In the major writeup, now called “CH05_WSSecurityExploration_r0.4.2.pdf”, at http://blogs.czapski.id.au/wp-content/uploads/2010/03/CH05_WSSecurityExploration_r0.4.2.pdf, in section 5.14.3, “Using WS-Addressing for Explicit Routing”, I discuss how WS-Addressing can be used to implement a variant of the “Routing Ticket” EIP Pattern. A one-way web service consumer sends a request to a request/reply web service, indicating, using WS-Addressing, the address of a one-way web service to which to send the response.

GlassFish ESB v2.x – Reading and Writing arbitrary SOAP Headers in BPEL 2.0 using NMProperties

As I develop bigger prices of work, which have writeups associated with them, I inevitably have to solve small problems that crop up. The problems I solve I typically get written about in the corresponding writeup but may be missed by these who might need these kinds of solutions but who don’t have an interest in the major piece. For example, when writing about the HL7 HA solution, “GlassFish ESB v2.2 Field Notes – Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions”, at http://blogs.czapski.id.au/?p=13, I had to work what host the instance of the business process was using and how to make the process instance wait for a random amount of time. I did separate writeups on these as “GlassFish ESB v2.1 – Using JavaScript Codelets to Extend BPEL 2.0 Functionality”, at http://blogs.czapski.id.au/?p=17, and “GlassFish ESB v2.1 Field Notes – JavaScript Codelets to Make BPEL Process Wait for a Random Duration Up to a Maximum number of Milliseconds”, at http://blogs.czapski.id.au/?p=16.

Here I call reader’s attention to the problem of reading values of SOAP Headers in a BPEL 2.0 process. I discussed one method in “Java CAPS 5 / 6, OpenESB, GlassFish ESB – Handling SOAP Headers in BPEL”, at http://blogs.czapski.id.au/?p=27. In the major writeup, now called “CH05_WSSecurityExploration_r0.4.2.pdf”, at http://blogs.czapski.id.au/wp-content/uploads/2010/03/CH05_WSSecurityExploration_r0.4.2.pdf, I am discussing, in passing, in Section 5.14.2, “Interacting with WS-Addressing Headers in BPEL”, a method that uses Normalized Message Properties (NMProperties) in BPEL 2.0, to access SOAP headers. While this piece discusses how to access WS-Addressing SOAP headers it is equally applicable to other SOAP headers. Similarly, in section 5.14.3, “Using WS-Addressing for Explicit Routing”, I discuss how arbitrary SOAP headers can be added and populated using NMProperties in BPEL 2.0. So if you need to manipulate SOAP header in BPEL 2.0, have a look a these sections.

The writeup, CH05_WSSecurityExploration_r0.4.2.pdf, is available at http://blogs.czapski.id.au/wp-content/uploads/2010/03/CH05_WSSecurityExploration_r0.4.2.pdf