Friday Feb 26, 2010

GlassFish ESB Resilience Options

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 original article, GlassFish ESB Resilience Options, is available at http://blogs.czapski.id.au/2010/03/glassfish-esb-resilience-options

Friday Jan 29, 2010

GFESB v2.x – Using NMProperties in BPEL 2.0 to force the HTTP BC to send the “connection: close” HTTP header

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/2010/01/glassfish-esb-v2-2-field-notes-exercising-load-balanced-highly-available-horizontally-scalable-hl7-v2-processing-solutions, in section called “WS Projects”, pages 35-36 , I discuss how NMProeprties 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.

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

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

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”. In the major writeup, now called “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 original article is available as GlassFish ESB v2.x – Reading and Writing arbitrary SOAP Headers in BPEL 2.0 using NMProperties, at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-x-reading-and-writing-arbitrary-soap-headers-in-bpel-2-0-using-nmproperties

Wednesday Jan 27, 2010

Recording of a dmonstration of the "GlassFish ESB v2.2 Field Notes - Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions"

In the blog entry "GlassFish ESB v2.2 Field Notes - Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions" 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 " through the blog article Recording of a dmonstration of the “GlassFish ESB v2.2 Field Notes – Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions” at http://blogs.czapski.id.au/2010/01/recording-of-a-dmonstration-of-the-glassfish-esb-v2-2-field-notes-exercising-load-balanced-highly-available-horizontally-scalable-hl7-v2-processing-solutions

Monday Jan 25, 2010

GlassFish ESB, v2.x - BPEL SSL Mutual Auth Mk.II and using JBI WS-Addressing for explicit routing - Exploring Effects of Security Policies, Rev.0.4.1

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 original article is avilabe as GlassFish ESB, v2.x – BPEL SSL Mutual Auth Mk.II and using JBI WS-Addressing for explicit routing – Exploring Effects of Security Policies, Rev.0.4.1 at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-x-bpel-ssl-mutual-auth-mk-ii-and-using-jbi-ws-addressing-for-explicit-routing-exploring-effects-of-security-policies-rev-0-4-1

Wednesday Jan 13, 2010

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

The HL7 v2 standard mandates the use of acknowledgments to ensure message delivery, critical in Healthcare. There are the “Original Mode” acknowledgements and “Enhanced Mode” acknowledgements. Within the enhanced mode acknowledgements 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 Acknowledgements using HL7 v2.3.1 messages. This discussion should apply to any v2.x, greater then v2.2, where the Enhanced Mode acknowledgements were introduced. In addition, the solutions are used to illustrate receiving HL7 BC ACK generation, when receiving an invalid HL7 message.

The blog article and the related material are available at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-2-processing-explicit-hl7-v2-accept-acknowledgements

Tuesday Jan 05, 2010

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

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 article is available at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-2-field-notes-exercising-load-balanced-highly-available-horizontally-scalable-hl7-v2-processing-solutions

Monday Jan 04, 2010

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

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 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 orginal article is available as GlassFish ESB v2.2 Field Notes – Installig GlassFish ESB on the Basic JeOS Appliance for LB and HA Testing at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-2-field-notes-installig-glassfish-esb-on-the-basic-jeos-appliance-for-lb-and-ha-testing

Friday Nov 27, 2009

GlassFish ESB v2.1 - Using JavaScript Codelets to Extend BPEL 2.0 Functionality

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.

The original article is available as GlassFish ESB v2.1 – Using JavaScript Codelets to Extend BPEL 2.0 Functionality at http://blogs.czapski.id.au/2009/11/glassfish-esb-v2-1-using-javascript-codelets-to-extend-bpel-2-0-functionality

Thursday Sep 17, 2009

GlassFish ESB v2.1 - Excessive length of Stay Healthcare IEP Demonstration

As a healthcare enterprise looks after patients, information is gathered about various events that take place. Information about notable events, Admissions and Discharges, for example, is recorded in Hospital Information Systems or Patient Administration Systems. These systems typically broadcast event information in a form of HL7 messages for use by other enterprise systems, for example laboratory or diagnostic imaging. A stream of HL7 messages can be intercepted and processed to derive all sorts of interesting information.

The solution developed in this walkthrough deals with Excessive Length of Stay. Length of stay is defined as the period between patient’s admission to and discharge from the hospital. Statistical average expected length of stay is typically available for different kinds of patients presenting with different kinds of conditions. A significant variation from the average length of stay for specific patients may indicate complications, treatment errors, infections and other kinds of issues that the hospital needs to investigate. Notification of such incidents may help the hospital in addressing these issues and prevent future occurrences.

In this solution the Intelligent Event Processor is used to calculate the continuously updated average length of stay over a period of time and use it to compare against each event’s length of stay. It passes, to the downstream component, all events where the length of stay exceeds the average by 1 ½ times and ignores all others.

In the initial iteration, the solution reads a stream of discharge messages, containing admission date, discharge date, length of stay, and a bunch of other fields from a file and passes them to the IEP process. The IEP process keeps the window on the last 10 seconds worth of records and continuously calculates the average length of stay over all records in that window. As records are added to and removed from the window the average is recalculated. As each record is seen its length of stay is compared to the average length of stay of all records in the window at the time. If the length of stay in the current record is less then or equal to 1 ½ times the average at the same time the record is discarded. If the average is greater the record is ejected to the output and ultimately written to a file of exception records.

In a subsequent iteration the solution is modified to accept messages from a JMS Queue. This modification allows the solution to use the stream of discharge messages produced by the HL7 Processor solution, discussed in “HL7 Processor Demonstration - GlassFish ESB v2.1”.

In a further modification the solution is configured to send notification messages to another JMS Queue. Notification messages are processed by a different solution and sent to an email recipient.

The article and referenced materials are available at http://blogs.czapski.id.au/2009/09/glassfish-esb-v2-1-excessive-length-of-stay-healthcare-iep-demonstration

Friday Sep 04, 2009

HL7 Processor Demonstration - GlassFish ESB v2.1

This Note walks the reader through development of a GlassFish ESB v2.1based solution that addresses a Healthcare-related business problem. The Note elaborates on the healthcare background necessary to get a notion of what is being done and why, and provides detailed steps required to implement and exercise the solution to the business problem.

We will use the HL7 Binding Component, the File Binding Component, the JMS Binding Component, the SOAP/HTTP Binding Component, the BPEL 2.0 Service Engine, the JavaEE Service Engine, the HL7 Encoder and EJB-based Web Services in a JBI-based solution. 

This note is an update, for GlassFish ESB v2.1, of the original note  "HL7 Processor Demonstration - Java CAPS 6/JBI and OpenESB".

Updated note is available at http://blogs.czapski.id.au/2009/09/hl7-processor-demonstration-glassfish-esb-v2-1

Thursday Aug 06, 2009

GlassFish ESB v2.1, OpenESB - Configuring HTTP BC for Plain WS-Security 1.0 Username Token Support

This document discusses how the SOAP/HTTP Binding Component can be configured, in a service provider and in a service consumer, to use WS-Security 1.0 (2004) Username Token Profile support. WS-Security 1.0 (2004) provided support for the Username Token, which could be sent over the wire in the clear. This was insecure but Sun JAX-RPC libraries allowed this, since the standard allowed this. Through Project Metro release 1.4 it was impossibly to formulate a WS-Security policy that decorated a SOAP message with the Username Token headers, without requiring to also encrypt parts of the message. This prevented solutions built on top Metro 1.4, or earlier, from supporting cleartext Username Token. Metro 1.5 relaxed this requirement. The WS-Security policy configured using the GlassFish ESB NetBeans WS-Security wizard will be modified to require and provide a Plain text Username Token.

The document is here: 02_Configuring_HTTP_BC_for_WS-Security_UsernameToken.pdf

The companion archive containing all projects is here: WSSecPolicies_PersonUsernamePlain.zip

Thursday Jul 30, 2009

Java CAPS 5 / 6, OpenESB, GlassFish ESB - Handling SOAP Headers in BPEL

Every now and then there arises a need to carry out-of-band information alongside the business payload but without disturbing or modifying it. Message Envelope Pattern is the Enterprise Integration Pattern label that is typically applied to solutions that address this issue. How the issue is addressed in practice varies depending on the technology in use. For JMS, for example, JMS Message Properties could be used to carry out-of-band information while the payload would be carried as the JMS payload. Web Services, typically using SOAP over HTTP, can address this requirement through the SOAP Header Extension Mechanism, whereby custom headers can be added to the SOAP Header while the payload is carried in the SOAP Body.

This document discusses construction of a WSDL that supports custom SOAP Header element and BPEL processes that are used to set and get custom header values in JBI and in eInsight. This mechanism is known to work in Java CAPS 5.x, Java CAPS 6 Classic and OpenESB / GlassFish ESB.

It is assumed that the reader is sufficiently familiar with the GlassFish ESB / OpenESB BPEL Service Engine and the SOAP/HTTP Binding Component, and / or Java CAPS Classic eInsight Business Process Manager and eDesigner IDE to be able to build projects without a step-by-step pictorial document.

The document is available here: 01_Handling_SOAP_Headers_in_BPEL_.pdf
The companion archive, containing WSDLs and projects, is available here: 01_Handling_SOAP_Headers_in_BPEL.zip

Sunday Jun 21, 2009

Making Web Space Server And Web Services Play Nicely In A Single Instance Of The Glassfish Application Server

It is likely that, at some point or another, a SOA-based solution will require a graphical user interface. In a typical 4 layer SOA stack SOA 1, the Presentation Layer, is delivered as a series of Web Applications, by preferences through a Portal-based solution. Sun Web Space Server 10 is a Free and Open Source Portal solution that can be readily integrated into a SOA infrastructure, for example one based on the GlassFish ESB v2.1 – the Free and Open Source ESB. How Web Space Server can be added to the GlassFosh ESB v2.1 infrastructure is discussed in the blog entry “Adding Sun WebSpace Server 10 Portal Server functionality to the GlassFish ESB v2.1 Installation”, at http://blogs.sun.com/javacapsfieldtech/entry/adding_sun_webspace_server_10. Web Space Server takes over the web container, in a manner of speaking, causing all web references to be redirected through to the portal infrastructure. This makes it impossible to interact with web services deployed to the instance of GlassFish. Web Services and Web Space Server do not play nicely together when installed in the manner discussed in the Blog.

This document provides instructions which will allow Web Services and Web Space Server to play nicely in the same instance of GlassFish by changing the servlet context which the Web Space Server manages from / to a different one. This will allow all other servlet contexts to be treated qas though the Web Space Server was not installed and will allow the two sets of functionality to coexist.

The credit for this solution goes to users@webspace.dev.java.net, in particular Srikanth Konjarla, Deepak Gothe and Allan Foster.

 Here is the document, MakingWebSpaceServerAndWebServicesPlayNicely.pdf.

Saturday Mar 14, 2009

Use Subversion with GlassFishESB, OpenESB or Java CAPS 6 for version control

Java CAPS 5.x came with its own, built-in version control system, which many people liked and many despised. Java CAPS 6 Repository still has that version control system. Unlike the repository-based components standard NetBeans components, EJBs, and the JBI-based components, developed through the OpenESB Project and supported, for a fee, in the GlassFishESB product, must use an external version control system, if they are to be placed under version control.

This note discusses how a Subversion VCS can be installed on a Windows platform and used to provide version control for non-Repository components in Java CAPS 6 product and for projects in the GlassFishESB product and OpenESB project.

Clearly, non-Windows platforms can be similarly configured to support Subversion.

This Note, http://mediacast.sun.com/users/Michael.Czapski-Sun/media/Subversion_with_OpenESB_GlassFishESB_or_JavaCAPS6/details, is a step-by-step guide to getting Subversion installed and configured to work with NetBeans 6.1. It is not a tutorial on version control.

About

In this Blog I post abstracts of articles / writeups / notes on various aspects of Java CAPS and SOA Suite including solutions, discussions and screencasts. The links to the referenced material are included in the bodies of the abstracts.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today