In the blog entry “GlassFish ESB v2.2 Field Notes – Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions”, at https://blogs.czapski.id.au/?p=13, I present the GlassFish ESB v2.2-based load balanced, highly available, horizontally scalable solution for HL7 v2.x delimited messaging, using both the HL7 Binding Components, Web Services and JMS in request/reply mode. The one and a half hour recording of me discussing and demonstrating this solution is available as a Flash Movie (SWF), “GFESB_LB_HA_Demo_Session SWF ” at https://blogs.czapski.id.au/wp-content/uploads/2010/03/GFESB_LB_HA_Demo_Session_SWF.swf (62.7Mb download)
Jan 24
In this document I explore the effects of selected web services security policies on SOAP message exchange in the GlassFish ESB v2.x.
This is a work-in-progress document, now at rev 0.4.1.
To provide early access I intend to release revisions of this document as significant new sections become available.
Rev 0.1: Content
• Assumptions and Notes
• Person Service XML Schema and WSDL Interface
• Common XML Project
• PersonSvc BPEL Module
• PersonCli BPEL Module
• JBI-based Person Service – Plain End-to-End
• JBI-based Person Service – SSL with Server-side Authentication
Rev 0.2: Additional Content
• JBI-based Person Service – SSL with Mutual Authentication (broken)
• EJB-based Person Service – No security
• EJB-based Person Service – SSL with Server-side Authentication
Rev 0.3: Additional Content
• EJB-based Person Service – SSL with Mutual Authentication
• JBI-based Person Service – Exploring WS-Addressing
Rev 0.4: Additional and Changed Content
• Modified sections 5.8 and 5.9 (SSL Server side and mutual authentication)
• Using WS-Addressing for Explicit Dynamic Routing
• Pre-requisite Cryptographic Objects [TBC]
• Upgrading Metro to version 1.5 [TBC]
• Username Token Profile 1.0 (2004) Policy [TBC]
More in CH05_WSSecurityExploration_r0.4.1.pdf at https://blogs.czapski.id.au/wp-content/uploads/2010/03/CH05_WSSecurityExploration_r0.4.1.pdf
The archive, CH05_WSSecurityExploration_r0.4.1.zip, containing all projects developed so far is to be found at https://blogs.czapski.id.au/wp-content/uploads/2010/03/CH05_WSSecurityExploration_r0.4.1.zip.
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.
Jan 09
GlassFish ESB v2.2 was released in late December/early January 2010. This release brings a number of design-time improvements in handling HL7 v2 messages. Some of these have been on my and other people’s wish lists for years.
HL7 v2 structure nodes use full names, rather then acronyms like MSH.1.
In BPEL, mapping can be performed at message, segment, component, subcomponent and field level.
These improvements are noteworthy enough to warrant a note, GFESBv22_HL7_Handling_Improvements.pdf, at https://blogs.czapski.id.au/wp-content/uploads/2010/03/GFESBv22_HL7_Handling_Improvements.pdf.
Jan 05
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. Frequently, protocol, binding component, JBI and architectural application design properties can be exploited to design highly available solutions. 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.
In this Note a heterogeneous, non-clustered collection of hosts will be used to implement and exercise three load balanced, highly available GlassFish ESB-based solutions. The environment consists of a number of independent “machines”, which are not a part of an Operating System Cluster. Each “machine” hosts a GlassFish Application Server. Application Servers are independent of one another and are not clustered. This is to demonstrate that load balanced, highly available, horizontally scalable solutions, based on the GlassFish ESB software alone, can be designed and implemented.
The specific class of solutions to which this discussion applies is the class of solutions which:
1. are exposed as request/reply services
a. HL7 messaging with explicit Application Acknowledgment
or
b. Request/Reply Web Services
or
c. JMS in Request/Reply mode
2. implement business logic as short lived processes
3. are
a. atomic
or
b. are idempotent
or
c. tolerant of duplicate messages
Classes of solutions with characteristics different from these named above require different approaches to high availability and horizontal scalability, and are not discussed here.
In this Note only high availability and scalability of receiver solutions is addressed. This aspect is the focus because a failure to process a message by a receiver may result in message loss –generally a bad thing.
Paradoxical as it may sound; senders are special cases of receivers. Just as a receiver is triggered by arrival of a message so too is a sender. Making sure that the sender trigger message does not get lost is much the same as making sure the message a receiver receives does not get lost. This means that the same considerations apply to senders and to receivers.
This note discusses an exercise involving an example load balanced, highly available, horizontally scalable healthcare environment, processing HL7 v2 messages. Discussion includes customization of generic GlassFish ESB v2.2 VMware Virtual Appliances for a specific Load Balancing and High Availability exercise and deploying ready-made GlassFish ESB solutions. The exercise for HL7 BC-based, Web Service-based and JMS-based highly available, load balanced, and horizontally scalable receivers, processing HL7 v2.3.1 messages, will be conducted and discussed.
At the end of the Note we will have three GlassFish ESB VMware Appliances with GlassFish ESB v2.2 Runtime infrastructure, ready to use for further GlassFish ESB Load Balancing and High Availability exercises.
The reader will be convinced, one hopes, that for the applicable class of GlassFish ESB-based solutions, load balancing and dynamic failover without message loss work. For that class of solutions this provides for high availability and horizontal scalability without resorting to Application Server or Operating System clustering.
The complete Note is available as 03_Conducting_HL7_LB_and_HA_Exercise_v1.0.0.1.pdf at https://blogs.czapski.id.au/wp-content/uploads/2010/03/03_Conducting_HL7_LB_and_HA_Exercise_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 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 https://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 https://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 https://blogs.czapski.id.au/wp-content/uploads/2010/03/01_Preparing_baisc_JeOS_appliance_v1.0.0.3.pdf.
Nov 28
In some specific circumstances, for example when testing high availability and failover scenarios, it may be desirable to make a BPEL process wait for a random amount of time, not exceeding some maximum duration, before continuing.
This Note describes the JavaScript Codelet which, given a maximum duration in Milliseconds, will return a random time up to that maximum duration, as an ISO8601 Duration Literal, suitable for use in the BPEL Wait activity. An example process that uses this Codelet is also developed and discussed.
This Note relies on the material presented in the Blog Entry “GlassFish ESB v2.1 – Using JavaScript Codelets to Extend BPEL 2.0 Functionality”, at https://blogs.czapski.id.au/?p=17.
The document is to be found at https://blogs.czapski.id.au/wp-content/uploads/2010/03/BPEL_WaitRandomDuration_v1.0.1.pdf.
The example project is to be found at https://blogs.czapski.id.au/wp-content/uploads/2010/03/ISO8601DurWait.zip
Nov 27
The BPEL SE, featured in the GlassFish ESB, the OpenESB and the Java CAPS 6, has the ability to execute JavaScript (ECMAScript) code inline. Why would one do that, you may ask. The answer is: because BPEL, great as it is with XML all over the place and all, can not do everything, and invoking Web Services and POJOs from BPEL for small and simple code adds too much overhead.
Take a date conversion, for example. It takes about 4 lines of Java code to perform date conversion. Doing this in BPEL is too horrible to contemplate. Doing this in JavaScript is not too bad, given availability of ready-made JavaScript scripts that do the job. The issue is that one cannot invoke Java from BPEL without resorting to a web service or a POJO. Invoking JavaScript, on the other hand, does not require either. Furthermore, JavaScript, in the Netscape days, acquired the ability to embed Java using technology known as LiveConnect.
In this Note we will explore the BPEL SE capability to execute JavaScript code inline. In passing we will also explored the ability of JavaScript to execute Java statements, and through these means to extend BPEL 2.0 with arbitrarily sophisticated functionality, without having to resort to invoking web services or POJOs.
We will introduce 2 Rules which must be followed, and 1 Rule which should be followed, for successful BPEL and JavaScript integration. We will develop two complete examples of embedded JavaScript code that provides reasonably useful functionality not natively available through BPEL. While the two examples will be fairly trivial it will be clear that more sophisticated functionality can be added following the method introduced in this Note.
Writeup, BPEL_JavaScript_Java_GetProperty_v1.0.2.pdf, can be found at https://blogs.czapski.id.au/wp-content/uploads/2010/03/BPEL_JavaScript_Java_GetProperty_v1.0.2.pdf
Projects, developed in the writeup, in the archive BPEL_JavaScript_Java_GetProperty_v1.0.2_code_bis.zip, are to be found at https://blogs.czapski.id.au/wp-content/uploads/2010/03/BPEL_JavaScript_Java_GetProperty_v1.0.2_code_bis.zip
