Mar 08

OpenESB v2.3 Series – OpenESB is Alive and Well and Living in …

By Czapski Michael OpenESB v2.3 Articles No Comments »

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.

In the spirit of “Jacques Brel is Alive and Well and Living in Paris” (http://en.wikipedia.org/wiki/Jacques_Brel_is_Alive_and_Well_and_Living_in_Paris) I decided to have a look at my JBI articles and release updated versions using the OpenESB distribution released to the community by LogiCoy’s. This will happen as time and motivation permit.

In this article I am listing articles which I may get around to updating to work with LogiCoy’s version of OpenESB, and their status (Not started, Updated, Never to be worked on again). This blog entry is available at https://blogs.czapski.id.au/wp-content/uploads/2013/03/OpenESBIsALiveAndWellAndLivingIn…_v0.1.0.pdf.

 

Tagged with: • • • • • • • • • • • • • • • •
Mar 06

GlassFish ESB Resilience Options

By Czapski Michael Sun No Comments »

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.

The document, GlassFishESB_Solution_Resillience_Options_v0.5.pdf, is available at https://blogs.czapski.id.au/wp-content/uploads/2010/03/GlassFishESB_Solution_Resillience_Options_v0.5.pdf

Tagged with: • • • • • • • •
Jan 29

GlassFish ESB v2.x – Reading and Writing arbitrary SOAP Headers in BPEL 2.0 using NMProperties

By Michael Czapski Sun 3 Comments »

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

Tagged with: • • • • • • • • • •
Jan 12

GlassFish ESB v2.2 – Processing Explicit HL7 v2 Accept Acknowledgements

By Michael Czapski Sun No Comments »

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.

Tagged with: • • • • • • • • • • •
Jan 09

GlassFish ESB v2.2 Notes – HL7 v2 Handling – Notable improvements in BPEL Mapper

By Michael Czapski Sun No Comments »

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.

Tagged with: • • • • • • •
Jan 08

GlassFish ESB v2.2 Field Notes – Ephemeral, JVM-global, POJO-based Sequence Number Generator for BPEL

By Michael Czapski Sun No Comments »

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.

The complete note, GFESBv22_EphemeralSequenceGenerator_v1.0.0.0.pdf, is to be found at: https://blogs.czapski.id.au/wp-content/uploads/2010/03/GFESBv22_EphemeralSequenceGenerator_v1.0.0.0.pdf

Tagged with: • • • • • • • • •
Jan 05

GlassFish ESB v2.2 Field Notes – Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions

By Michael Czapski Sun 4 Comments »

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

Tagged with: • • • • • • • • • • • • • • • •
Jan 03

GlassFish ESB v2.2 Field Notes – Installig GlassFish ESB on the Basic JeOS Appliance for LB and HA Testing

By Michael Czapski Sun No Comments »

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

Tagged with: • • • • • • • •
Jan 03

GlassFish ESB v2.x Field Notes – Preparing Basic JeOS Appliance for GlassFish ESB LB and HA Testing

By Michael Czapski Sun 2 Comments »

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.

Tagged with: • • • • • •
Nov 28

GlassFish ESB v2.1 Field Notes – JavaScript Codelets to Make BPEL Process Wait for a Random Duration Up to a Maximum number of Milliseconds

By Michael Czapski Sun No Comments »

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

Tagged with: • • • • • • •
Previous Entries
preload preload preload