In the major writeup called “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, 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.
In the major writeup, now called “CH05_WSSecurityExploration_r0.4.2.pdf”, at https://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.
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 https://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 https://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 https://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 https://blogs.czapski.id.au/?p=27. In the major writeup, now called “CH05_WSSecurityExploration_r0.4.2.pdf”, at https://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 https://blogs.czapski.id.au/wp-content/uploads/2010/03/CH05_WSSecurityExploration_r0.4.2.pdf
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)
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.
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.
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.
Java CAPS Basics Book: http://safari.oreilly.com/9780137146130
Michael’s Java CAPS Field Technical Tips Blog: http://blogs.sun.com/javacapsfieldtech/
Java CAPS Basics Book review: http://www.javaranch.com/bunkhouse/bookSearch.jsp?category=Web Services and SOAP
Java CAPS Basics Book Comment: http://camelcase.blogspot.com/2008/05/first-and-only-java-caps-book-is.html
JavaOne2008 Presentation: Sun Java Composite Application Platform Suite: Implementing Selected EAI Patterns, TS-5301, JavaOne Online Technical Sessions, JavaOne 2008
Java CAPS Basics Book and JavaOne 2008 Presentation Comment: http://radio.javaranch.com/michael/2008/05/11/1210531145299.html
IT Toolbox Member Profile: http://it.toolbox.com/people/mczapski/
Key participation in Health Interoperability Showcase at the International MedInfo 2007 Conference: http://www.hisa.org.au/system/files/u1990/Interop_Showcase_2007_-_Handbook.ppt
St.Vincent’s Hospital Sydney – WebResults Project, Proceedings of AUUG’95 and Asia-Pacific World Wide Web Conference
Healthcare Workshop Presentation: Web Services and Service Oriented Architecture – Getting to There from Here, Where-to from Here? – HL7 “Web Services in Healthcare” Workshop, Tuesday, 28 March 2006 – Sydney
Healthcare Workshop Presentation: Web Services – Providing Healthcare Solutions, Where-to from Here? – HL7 “Web Services in Healthcare” Workshop, Tuesday, 28 March 2006 – Sydney
Strengthening Privacy and Confidentiality Protection for Electronic Health Records, From Proceeding (494) Web Technologies, Applications, and Services – 2005
Secure Messaging and Information Exchange for Health, HIC 2005 and HINZ 2005: Proceedings
A Question of Confidence, not a Question of Trust. Better Data Confidentiality Protection is Necessary, HIC 2004: Proceedings
Old Problem – New Solutions: HealthConnect System Architecture for Information Delivery, HIC 2003 RACGP12CC [combined conference]: Proceedings
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
