Apr 25

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 https://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 – https://blogs.czapski.id.au/wp-content/uploads/2010/04/JC62_HL7_Resilience_Project_Exports_no_Envs.zip

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

Apr 24

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 https://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 “https://blogs.czapski.id.au/wp-content/uploads/2010/04/02_Installing_JavaCAPS_6.2_on_JeOS_appliance_v1.0.0.0.pdf“.

Jan 12

The HL7 v2 standard mandates the use of acknowledgments to ensure message delivery, critical in Healthcare. There are the “Original Mode” acknowledgments and “Enhanced Mode” acknowledgements. Within the enhanced mode acknowledgments there are “Accept Acknowledgements” and “Application Acknowledgements”.

This Note walks through development of two BPEL Module-based solutions that cooperate in generating and processing Enhanced Accept Acknowledgments using HL7 v2.3.1 messages. This discussion should apply to any v2.x, greater then v2.2, where the Enhanced Mode acknowledgments were introduced. In addition, the solutions are used to illustrate receiving HL7 BC ACK generation, when receiving an invalid HL7 message.

The Note, Processing_Explicit_HL7_AcceptAcks_v1.0.0.0.pdf, can be found at https://blogs.czapski.id.au/wp-content/uploads/2010/03/Processing_Explicit_HL7_AcceptAcks_v1.0.0.0.pdf.
The associated GlassFish ESB v2.2 Projects, HL7EA_Projects.zip, can be found at https://blogs.czapski.id.au/wp-content/uploads/2010/03/HL7EA_Projects.zip.

May 08

Just now I had an occasion to work with an integration solution intended to process lots of records. By lots I mean over 1 million smallish records. My customary platform to experiment on is Windows XP. Lots of reasons for that, most of them historical – I have tools I know and like and so on. While trying to work with such a volume of data I noticed a number of “interesting” things, which I thought I should share. These things are related to both the platforms (Windows vs. Linux), the tools and the architectural decisions.

I needed lots off data to test the solution I was contemplating, which involved XML processing, to see how constructing and parsing XML affects solution performance. To make it easier to compare timing differences I though I should use lots of records.

The discoveries are discussed in Right tools for the job.pdf.

Feb 27

This Quick Note discusses a solution to the use case provided by Richard Kuiter.

An input file contains the following records:

H100000000000014099120ASN00507
L1140991200000008261850826185738
L1140991200000008261850826185738
L1140991200000008261850826185738
L1140991200000008261850826185738
L1140991200000008261850826185738
L1140991200000008261850826185738
H100000000000014099126ASN00531
L1140991260000008262690826269662
L1140991260000008262690826269662
L1140991260000008262690826269662
L1140991260000008262690826269662
L1140991260000008262690826269662

It is required that each block of records starting with the H1 (header) record and containing all the following L1 (line) records, be written to a different file.

The solution involves the use of:
1.    Batch Inbound eWay to locate the input file and provide its name and location to a Java Collaboration Definition
2.    Batch Local File eWay to provide an Input Stream to the Batch Record eWay
3.    Batch Record eWay to break up the input stream into records delimited by carriage return+new line
4.    Batch Local File eWay to write each block of records to a file with a distinct name

Brief steps to implement this solution are given in the full Quick Note as QuickNote_001. The collaboration code will work in Java CAPS 5 and 6 Repository.

Feb 23

Securing web services, to be invoked over the Internet, is both essential and difficult. Using appropriate tools and technologies makes it easier to accomplish the task. Developer-dependent solution, where security is embedded directly into consumers and providers, is inflexible and labour-intensive. Gateway-based solutions are more flexible, more dynamic and easier to manage. In this note Java CAPS 6-based web service consumer and provider pair are developed. The solutions are exercised first without, then with the web services security gateway. This enables demonstration of how web services can be secured, how policies can be developed and propagated and how WS-Security-mandated XML markup can be dealt with outside the development shop. The Layer 7 SecureSpan XML Gateway, and its oft forgotten companion, the SecureSpan VPN Client, are used to explore the topic. The reader should be able to acquire enough knowledge to obtain and deploy the SecureSpan XML Gateway, and to use its basic functionality to implement gateway-mediated secure web services solutions.

The full text of this Note is available from: WS-Security_for_Java_CAPS_the_Gateway_Way_1.0.pdf

Feb 14

If we overlook the fact that using web services to transfer large payloads is a very stupid idea, we will be faced with the need to implement the optimisation mechanisms to make transfer of large payloads using web services a little less inefficient from the stand point of the size of the over-the-wire data to be transferred. The standardised, supported mechanism for this is the Message Transmission Optimisation Method (MTOM), http://en.wikipedia.org/wiki/MTOM. Java CAPS Repository-based Web Services don’t offer a convenient mechanism to provide MTOM support.

This note walks through the implementation of a Java CAPS Repository-based, eInsight-based web service consumer and the implementation of the EJB-based Web Service Wrapper Consumer for this service, which provides support for MTOM. The Note discusses how to exercise the wrapper service using the NetBeans web services testing facilities, how to trigger the Java CAPS Repository-based web service invoker and how to observe on-the-wire message exchanges. The invoker implementations discussed in this Note will invoke the web service providers discussed in an earlier Note, “Java CAPS – Exposing MTOM-capable Java CAPS Classic Web Service”, http://blogs.sun.com/javacapsfieldtech/entry/java_caps_exposing_mtom_capable.

The note is available as Invoking_MTOM-WS_using_Java_CAPS_Classic.pdf

Tagged with:
Feb 12

If we overlook the fact that using web services to transfer large payloads is a very stupid idea, we will be faced with the need to implement the optimisation mechanisms to make transfer of large payloads using web services a little less inefficient from the stand point of the size of the over-the-wire data to be transferred.

The standardised, supported mechanism for this is the Message Transmission Optimisation Method (MTOM), http://en.wikipedia.org/wiki/MTOM. Java CAPS Repository-based Web Services don’t offer a convenient mechanism to provide MTOM support.

This note walks through the implementation of a Java CAPS Repository-based, eInsight-based web service and the implementation of the EJB-based Web Service Wrapper for this service, which provides support for MTOM. The Note discusses how to exercise the services using the NetBeans web services testing facilities and how to observe on-the-wire message exchanges.

The note is available as Exposing_MTOM-capable_Java_CAPS_Classic_Web_Service.pdf

Tagged with:
Jan 23

I have been making references  to Tom Barrett’s tutorials in my blog entries, screencasts, and writeups, but without providing the links to them. Now, courtesy of Tom, I am able to do so. See below for the link and the description of Tom’s tutorials.

++++
The three tutorial documents from CEC 2008 are posted at:
http://wikis.sun.com/display/OpenESBTutor/Tom+Barrett%27s+Open+ESB+and+Mural+Tutorials

See the following section:

Sun Customer Engineering Conference (CEC) – Three Tutorials
The following three tutorials were developed for customer-facing systems engineers at Sun and at Sun partners. They were delivered at CEC 2008 held in Las Vegas in November, 2008. The goal of these three tutorials is to document the steps necessary to create, from scratch, three demonstrations that were delivered in Java CAPS/GlassFish ESB/Open ESB-related sessions at CEC 2008.

1. Exploring GlassFish ESB (V 1.1) – 90 pages – November 6, 2008 This tutorial is based upon an Internet store front scenario where customers purchase items and purchase orders (POs) are generated and forwarded to the “backend” Purchaser. The Purchaser, in turn, collaborates with the Supplier which coordinates shipping and generates a delivery notices (DNs). DNs are returned to the Purchaser and the Purchaser matches up DNs with POs before forwarding instructions to Finance for further processing.

Specific technical topics include:

Custom encoder to marshal XML to delimited records and unmarshal delimited records to XML
BPEL: looping, predicates and correlation
Service Engines: BPEL
Binding Components: HTTP, File, JMS

2. Exploring Sun ESB Suite: Open ESB Technology (V 1.1) – 51 pages – November 18, 2008
This tutorial explores a health care scenario that analyzes HL7 ADT (Admission Discharge Transfer) records to identity patient length of stays that have exceeded an average threshold set by management.  The Intelligent Event Processor (IEP) computes a moving average and identifies ADT records that note an exceptional patient length of stay.  IEP generates an alert for each excessive length of stay detected.

Specific technical topics include:

Intelligent Event Processor (IEP) (Time-Based Window, Relation Aggregator, Correlator / Filter)
BPEL orchestration
File BC for ADT record input
BPEL process invokes IEP via HTTP binding component
IEP uses File BC for output
Service Engines: BPEL, IEP
Binding Components: HTTP, File

3. Exploring Sun MDM Suite: Open ESB and Mural Technology (V 1.0) – 111 pages – November 6, 2008
This tutorial explores a health care scenario where multiple patient master databases exist containing duplicate and inconsistent patient information. A patient master index is defined and a patient application is generated that stores its master index in MySQL, provides a web-based interface to maintain index records, surfaces web services that can be called by other applications to do programmatic access to the index records and supports a JMS topic to broadcast master index changes to other hospital applications.

Specific technical topics include:

Defining patient data model
Establishing MySQL tables
BPEL process feeding index via web service call
BPEL process “listening” on JMS topic for index updates
Using Master Index Data Manager web app
Service Engines: BPEL
Binding Components: File, JMS

Errata:  If you have trouble with this version of the tutorial, please see these errata notes.  Thanks to all who have provided feedback. I’ll address these issues/comments in the next version of the tutorial.

— Tom Barrett

Jan 08

The Note “HL7 Processor Demonstration – Java CAPS 6/JBI and OpenESB” walks the reader through development of a Java CAPS 6/JBI-based / OpenESB-based solution that addresses a Healthcare-related business problem. The Note elaborates on the healthcare background necessary to get a notion of what is being done and why, and provides detailed steps required to implement and exercise the solution.

I recorded a screencast of a session during which I discuss the business side of the Note, then discuss, implement, deploy and exercise all components of the solution documented in the Note.

The screencast is here: HL7Processor_Exercise_Screencast.avi. The associated archive, 00_HL7Processor_example_screencast_companion.zip, contains code fragments and other bits and pieces which are used, or referred to, in the screencast. Of some interest are the Note itself, in documents/00_HL7_Example_Development_Instructions_Final.pdf, and the brief example implementation instructions, in documents/00_HL7_ExampleBrief.pdf. I followed the brief instructions while I was building the projects when recording the screencast.

The screencast, which is over 320 Mb in size and takes 2 hours and 50 minutes to play, may require a TechSmith Compression Codec on your machine to allow your player to play the media. You can get one from the TechSmith site: http://www.techsmith.com/download/codecs.asp. Information on the codec can also be found here: http://www.movavi.com/codec/TSCC.html. If you prefer, and you are on Windows, you can get the CamPlay.exe from here: CamPlay.zip and use it instead.

Tagged with:
preload preload preload