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: • • • • • • •
Nov 27

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

By Michael Czapski Sun 2 Comments »

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

Tagged with: • • • • • • • •
Oct 10

GlassFish ESB, v2.1 – EJB SSL Mutual Auth and JBI WS-Addressing – Exploring Effects of Security Policies, Rev.0.3

By Michael Czapski Sun No Comments »

In this document I explore the effects of selected web services security policies on SOAP message exchange in the GlassFish ESB v2.1.

This is a work-in-progress document, now at rev 0.3.

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

More in CH05_WSSecurityExploration_r0.3.pdf at https://blogs.czapski.id.au/wp-content/uploads/2010/03/CH05_WSSecurityExploration_r0.3.2.pdf

Tagged with: • • • • • • • • • • • •
Sep 18

GlassFish ESB, v2.1 – Exploring Effects of Security Policies, Rev.0.2, More SSL and EJB-based projects

By Michael Czapski Sun No Comments »

In this document I explore the effects of selected web services security policies on SOAP message exchange in the GlassFish ESB v2.1.

This is a work-in-progress document, now at rev 0.2.

To provide early access I intend to release revisions of this document as significant new sections become available.

Revision 0.1: Content
* Assumptions and Notes
* Person Service XML Schema and WSDL Interface
* Common XML Project
* PersonSvc BPEL Module
* PersonCli BPEL Modules
* Person Service – Plain End-to-End
* Person Service – SSL with Server-side Authentication

Revision 0.2:Added 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

More in CH05_WSSecurityExploration_r0.2.3.pdf at https://blogs.czapski.id.au/wp-content/uploads/2010/03/CH05_WSSecurityExploration_r0.2.3.pdf.

Tagged with: • • • • • • • • • •
Sep 16

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

By Michael Czapski Sun No Comments »

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”, https://blogs.czapski.id.au/?p=23.

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 document, “Excessive length of Stay Healthcare IEP Demonstration”, can be found at https://blogs.czapski.id.au/wp-content/uploads/2010/03/Combinned_Intelligent_Event_Processor_Demonstration_v1.0.pdf

The pre-built projects in the “Excessive length of Stay Healthcare IEP Demo Companion Archive” can be found at https://blogs.czapski.id.au/wp-content/uploads/2010/03/Healthcare_Demo_Combined_v1.0.zip

Tagged with: • • • • • • • • • • • • •
Sep 07

GlassFish ESB, v2.1 – Exploring Effects of Security Policies, Rev.0.1, SSL with Server-side Authentication

By Michael Czapski Sun No Comments »

In this document I explore the effects of selected web services security policies on SOAP message exchange in the GlassFish ESB v2.1.

This is a work-in-progress document.

To provide early access I intend to release revisions of this document as significant new sections become available.

Revision 0.1: Content

  • Assumptions and Notes
  • Person Service XML Schema and WSDL Interface
  • Common XML Project
  • PersonSvc BPEL Module
  • PersonCli BPEL Modules
  • Person Service – Plain End-to-End
  • Person Service – SSL with Server-side Authentication

More in CH05_WSSecurityExploration_r0.1.pdf, at https://blogs.czapski.id.au/wp-content/uploads/2010/03/CH05_WSSecurityExploration_r0.1.pdf

Tagged with: • • • • • • • • • •
Sep 04

HL7 Processor Demonstration – GlassFish ESB v2.1

By Michael Czapski Sun 2 Comments »

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”, to be found at https://blogs.czapski.id.au/wp-content/uploads/2010/03/00_HL7_Example_Development_Instructions_Final.pdf.

Updated note is available at https://blogs.czapski.id.au/wp-content/uploads/2010/03/00_HL7_Example_Development_Instructions_Final_1.1.2.pdf

Tagged with: • • • • • • •
Aug 05

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

By Michael Czapski Sun 4 Comments »

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

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