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 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

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 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“.

Jan 03

It seems frequently assumed that architecting and deploying Highly Available (HA) solutions requires Application Server and/or Operating System clustering. When it comes to SOA and Integration solutions this is not necessarily a correct assumption. Load Balanced (LB) and Highly Available HA) SOA and Integration solutions may not require that degree of complexity and sophistication. Testing LB and HA solutions requires infrastructure consisting of multiple hosts and the ability to “crash” hosts at will. With virtualization technologies available now it is far easier to use multiple virtual machines then to use physical machines. It is also easier and potentially less destructive to “crash” virtual machines then it is to do so with physical machines.

This note walks through the process of installing a GlassFish ESB v2.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/?p=15.

At the end of the Note we will have a GlassFish ESB VMware Appliance with GlassFish ESB Runtime infrastructure, ready to use for GlassFish ESB Load Balancing and High Availability testing, or any other purpose for which a GalssFish ESB runtime appliance might be appropriate.

The complete note is available as 02_Installing_GlassFishESB_on_JeOS_appliance_v1.0.0.1.pdf at http://blogs.czapski.id.au/wp-content/uploads/2010/03/02_Installing_GlassFishESB_on_JeOS_appliance_v1.0.0.1.pdf

Jan 03

It seems frequently assumed that architecting and deploying Highly Available (HA) solutions requires Application Server and/or Operating System clustering. When it comes to SOA and Integration solutions this is frequently a wrong assumption. Load Balanced (LB) and Highly Available HA) SOA and Integration solutions may not require that degree of complexity and sophistication. Testing  LB and HA solutions requires infrastructure consisting of multiple hosts and the ability to “crash” hosts at will. With virtualization technologies available now it is far easier to use multiple virtual machines then to use physical machines. It is also easier and potentially less destructive to “crash” virtual machines then it is to do so with physical machines.

This note walks through the process of building a Base OpenSolaris-based VMware Virtual Appliance, based on the JeOS Prototype. It will be used as the underlying infrastructure in future Notes discussing building GlassFish ESB, Java MQ, MySQL and other appliances used in LB and HA testing. The major advantage of this infrastructure is that, as well as being fully functional, if is free (as in free beer).

At the end of the Note we will have a basic VMware Appliance, running the minimal, headless OpenSolaris Operating System (based on June 2009 JeOS Prototype), configured to use NAT networking, and ready to use as the basis of GlassFish ESB and other infrastructure. To accomplish this we will download the JeOS Prototype, configure machine name and NAT networking and test network connectivity. We will also discuss the steps required to clone this appliance.

The complete walkthrough is available as 01_Preparing_baisc_JeOS_appliance_v1.0.0.3.pdf at http://blogs.czapski.id.au/wp-content/uploads/2010/03/01_Preparing_baisc_JeOS_appliance_v1.0.0.3.pdf.

preload preload preload