Since Sun Microsystems started the Java Business Integration specification work, and subsequently started releasing the OpenESB platform and components around 2006, until Sun was acquired by Oracle around 2010, I published a number of blog articles dealing with different aspects of the JBI-based technologies embedded in the OpenESB, GlassFish ESB and Java CAPS/JBI. I lost interest in the topic when Sun acquisition was completed and it became clear to me that the JBI specification will not be supported by Oracle other as part of the legacy Java CAPS/JBI and the GlassFish ESB products. Around the same time there was a fair bit of activity around the OpenESB community aimed at working out whether and how OpenESB can be picked up by the community, perhaps development branch forked so it can be controlled by the community, etc.. Since I did not expect that effort to lead anywhere I stopped following these discussions and eventually OpenESB mailing lists to which I was subscribed disappeared to be replaced by others to which I did not subscribe.
I never went back to my original blog articles to see if they are still implementable and whether the software used in them is still available. Needless to say some articles can no longer be implemented as written and the links to the OpenESB / GlassFish ESB distributions which I provided in my articles no longer lead anywhere useful.
Recently I had an occasion to look at some of the articles and it occurred to me that perhaps they can be updated if OpenESB is available somewhere, so people can still try them. I did put a fair bit of effort into the articles and it is such a waste to have the solutions unimplementable. I went looking for OpenESB distributions to see if they are available, what state they are in, and whether anyone cares. It turned out that LogiCoy (http://www.logicoy.com/) maintains and develops OpenESB, at least one distribution of which is publically available, and I know some of the people at LogiCoy who are working on this platform. I understand from them that a new release, v2.3 (of which a Beta version is available at the community site – http://www.open-esb.net/) will be officially released sometime this month. Once the release is available I will come back to this article to provide the link to it and perhaps to the installation documentation.
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.
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.
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.
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.
In the blog entry “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 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 http://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]
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.
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.
When working on the HA solutions discussed in my HA blog entry I realized that it will be difficult to work out whether messages are delivered in order, as was required, and whether any are missing. I got over the issue by ensuring that my test data was prepared in such a way that messages in each test file had increasing, contiguous sequence numbers embedded in the message. For HL7 v2, which is the messaging standard with which I dealt, I used MSH-10, Message Control ID field. I wrote processed messages and acknowledgments to files whose names embedded MSH-10 Message Control Id, with the sequence number, so breaks in sequence and out of order messages could be readily detected.
With multiple message files containing between 1 and 50,000 messages, adding a sequence number to each message by hand was clearly out of the question.
I put the GlassFish ESB to use. I constructed a file-to-file BPEL module project to read each test file and to prepend a sequence number to each message’s MSH-10 field. The only snag was how to get a sequence number that would start at 0 and increase by 1 for each message, such that each BPEL process instance would get the next sequence, and that messages would be written to the output file in order.
This note discusses how I went about accomplishing the task.