Tuesday Nov 10, 2009

Clustering GlassFish ESB - BPEL Failover and Load Balancing

Tom Barrett has created another of his detailed OpenESB tutorials - this time for BPEL HA. It shows how failover of process instances works in a highly available BPEL Engine configuration using a Glassfish Cluster.

For those who would like to follow a screencast, I've recorded the tutorial. The written tutorial was developed with GlassfishESB v2.1 on WinXP. The screencast uses the same version but on OpenSolaris 200906 running in VirtualBox.

Part 1: Establishing a GlassFish Cluster

  • Setting up Glassfish in a cluster and configuring the BPEL engine for persistence and failover

  • Screencast (16mins, swf)

Part 2: Creating the BPEL Test Application

  • Creating a simple bpel process to test failover and deploying it to the cluster

  • Screencast (10mins, swf)

Part 3-4: Establishing the Test Cases and Testing BPEL Failover in the Cluster

  • Using SoapUI to create test suites for the individual process engine instances

  • Running the test suites and monitoring the state of the process instances during process failover and recovery

  • Screencast (10mins, swf)

Part 5: Experiencing Load Balancing to the BPEL SE

  • Configuring the Glassfish Load Balancer plugin with the Sun Web Server to distribute load between the instance of the cluster.

  • This project was not recorded because it is mainly concerns installation and settings in configuration files and is well-covered in the written tutorial.

Sunday Sep 20, 2009

Deploying BPEL Apps to Fuji M8

Deploying apps from GlassfishESB v2.1 to GlassfishESB v3.

There's lots of new functionality being implemented for GlassfishESB v3 as part of the Fuji research project. However a very important consideration is that existing projects that run in the current release (v2.1) will continue to work in the next major release (v3).

This how-to shows how to take a simple BPEL project from GFESBv2.1 and deploy and test it in the latest milestone release of Fuji (M8).

Play Screencast

I had to rush through the screencast very quickly to fit in the 5 minute limit imposed by Jing, so here's a run-down of what is happening

  • Start in the GlassfishESBv2.1 environment
  • I already have a simple service assembly with a HTTP BC and a BPEL SE Service Unit
    • The BPEL SU simply returns "Hello <string>" for whatever string is passed to it
  • Run the unit test to show it working
  • The Fuji runtime does not yet support Application Variables, so I replace the variable with the hardcoded value for the HTTP Port
    • Rebuild the application with the hardcoded value so it can be deployed to the Fuji runtime
  • Stop the GFESBv2.1 server so the Fuji Server can be started and use the same ports.
  • Milestone8 of Fuji requires the latest version of NetBeans, so start up NetBeans 6.7.1
  • The current fuji installer doesn't include BPEL SE, so you'll need to download and install it separately (plus the saxon library it depends on)
  • > curl -O
    > curl -O

  • Start the BPEL SE and HTTP BC components
  • Now install the zip file for our BPEL application Service Assembly.
    • start the application
  • Check the the same URL for the WSDL file to ensure the server is running and the service is available
  • To test the project, I've installed the SOAPUI netbeans plugin.
  • Create a SOAPUI project, point it to the service, and test.
Screencast (again).

Wednesday Mar 25, 2009

Constraints on BPEL correlation: A workaround

In a previous blog entry I discussed limitations of BPEL Correlation when performing asynchronous communication within the JBI container.

Paul Perez has provided a workaround for those situations using a BPEL Bridge

This workaround works because the BPEL engine only enforces the Recoverability Systemic Quality for processes that are labelled as Atomic. If the BPEL Bridge is not atomic then it returns an ACK immediately and the original process can continue executing while waiting for the Callback.

The same thing would work if the JavaEE SE was able to differentiate between transactional and non-transactional EJBs. That is, only enforce the Recoverability Systemic Quality on EJB Service Units that are annotated as transactional. That way non-transactional EJBs would result in the ACK being returned upon receipt of the msg and not upon successful completion. (An RFE has been filed for this change).

Thursday Mar 19, 2009

bpel correlation with an EJB WS

Following the previous article on Contraints when using BPEL Correlation with OpenESB, I thought I should provide a little example of how communication with asynch services and correlation can be done from a bpel process. 

This is a simple example I whipped up for a customer workshop.

It starts with some attached predefined XSDs and WSDLs to represent the interfaces:

  • in-out (req-resp) process interface
  • in-only asynch service interface
  • in-only callback interface

  • The process implements the process and callback interfaces.
  • The EJB webservice implements the asynch interface and acts as a client to the callback interface.

The development is quite simple. The only thing that needs special attention is checking the endpoints used for the EJB WS and the callback interface.

  • When the EJB WS is created using "Webservice from WSDL" the tooling modifies the WSDL supplied endpoint URL. So the wsdl used in the bpel project needs to be updated accordingly.
  • The callback WSDL generated by the Open ESB tooling includes an Application Variable to represent the URL port to use. The regular EJB JAX-WS tooling doesn´t understand Application Variables, so the port needs to be set in the WSDL before the client code is generated.
Screencast (approx 15mins)

Tuesday Mar 17, 2009

Constraints on BPEL Correlation in Open ESB

One of the useful features of BPEL as an orchestration language is its built-in support for correlation – the ability to correlate callbacks from asynchronous services with the original invoking process instance. If you´d like an intro to Correlation, the team at Pymma have written a nice tutorial explaining the concepts of BPEL Correlation and how to make use of it in OpenESB.

Correlation works well when BPEL is used as a simple scripting language for basic webservices, but there are things to consider when using it to orchestrate services offered in a JBI-based infrastructure or when combining correlation with webservice standards such as reliable messaging or transactions. This article discusses constraints on BPEL Correlation in the JBI-based infrastructure of OpenESB, GlassfishESB, and JavaCAPS.

The basic Correlation scenario is quite simple:

  1. the process invokes an asynchronous service with an in-only message (i.e., no reply)

  2. the process continues to execute until the service sends a callback response

  3. the process engine receives the response and uses the correlation information to match the response to the original invoking process instance

  4. the process instance receives the callback msg and processes it accordingly

And this is exactly what happens if you implement a bpel process which calls an over-the-wire WS-I Basic Profile compliant webservice using OpenESB.

However, if you include the Asynchronous Service in the same Service Assembly (aka Composite Application) as the BPEL process, then the process fails to continue executing. In fact, the entire process waits endlessly. To understand why this occurs you need to look a bit deeper at what is happening under the covers in the JBI infrastructure.

Here´s how the basic Correlation scenario works again, but this time including more detail about what is happening under the covers. To follow this you should have a basic understanding of JBI concepts. This page and presentation screencast are useful places to start.

  1. the process invokes an asynch service with an in-only message (i.e., no reply)

  • the BPEL Service Engine (SE) wraps the service invocation in a Normalized Message.

  • the Normalized Message (NM) is wrapped in a Message Exchange (ME) object. In this case, it is a “in-only” Message Exchange.

  • the Message Exchange is sent from the BPEL SE to the Normalized Message Router (NMR).

  • the NMR determines that the requested service is offered by the SOAP Binding Component (BC) and routes the NM to that component.

  • the SOAP BC returns an Acknowledgement (ACK) to the NMR

  • the NMR passes the ACK back to the BPEL Engine

  • the BPEL Engine allows the process instance to continue

  1. the process instance continues to execute until the remote service sends a callback response

  • the SOAP BC creates a Normalized Message which is passed back to the BPEL SE with a similar set of steps to those described previously.

  1. the BPEL Engine receives the callback response and uses the correlation information to determine which process instance the response should passed to.

  2. the process instance receives the callback msg and executes accordingly

This more detailed look at what is happening in the JBI infrastructure seems like a lot of overhead but remember that its only Java objects communicating in the same JVM. Performance benchmarks have shown that there is very little overhead for this level of indirection.

So, why does the scenario fail when the Asynch Service is included in the same Composite Application rather than being invoked as a remote webservice? The issue concerns Systemic Qualities which are the non-functional attributes of the JBI Components offered by GlassfishESB.

Systemic Qualities provide for a number of capabilities which allow GlassfishESB to guarantee different Quality of Service delivery types. E.g., once-and-only-once, at-most-once, and at-least-once. For instance, the Recoverability Quality guarantees that Service Engines can recover from a failure without loss of message. To achieve this when two Service Engines are communicating, the provider Service Engine (e.g., the JavaEE SE providing the Asynch Service) will not send the ACK message to the consuming Service Engine (e.g., the BPEL SE) until the EJB has completed processing. That way, if a system failure occurs during the execution of the Asynch Service, it could be reprocessed without violating the one-and-only-once delivery type.

The consequence of this behaviour, i.e., not sending the ACK until the EJB completes, is that the Business Process does not continue executing. The BPEL SE must wait until the ACK is received from the JavaEE SE. Similarly, when the callback msg is sent, the JavaEE SE must wait to receive the ACK from the BPEL SE. The system then goes into an endless wait-state. The Asynch Service tries send the Callback msg to the process, but the JavaEE SE will never receive the ACK that its callback msg has been received by the BPEL SE because the BPEL SE is still waiting for the ACK for the original request.

This situation occurs for any correlation scenario where the Asynch Service´s container (i.e., the Service Engine in which it executes) provides an ACK to the BPEL SE _after_ the Asynch Service satisfies the request (ie., completes) rather than on receipt of the request. In the original scenario, i.e., when the BPEL process invokes an external webservice, the ACK is sent back from the SOAP BC to the BPEL engine on receipt of the service invocation. However, if the SOAP BC was configured to use a standard that required a different Quality of Service, e.g., WS-ReliableMessaging, then the SOAP BC would only send the ACK after receiving an ACK from the remote service. Similarly, if the BPEL process was configured to utilise transactions (i.e., atomic process) then the ACK would not be received upon initial receipt.

This constraint on BPEL Correlation in Glassfish ESB is not as serious a limitation as it may seem. The use of asynchronous communication is usually used in the implementation of long-running business processes where the importance of these Quality of Service features have a different weighting in your analysis of alternative solutions when compared to fast-running processes. Moreover, other design approaches to implement “correlation” can be achieved without relying on the OOTB functionality of the BPEL Engine.

The support for OOTB Correlation is one reason why BPEL can be sometimes be a useful technology for service orchestration. But blindly relying on technology features is never a substitute for good design.

Tuesday Jul 22, 2008

Communicating through the JBI Bridge from BPEL to a JCD

One of the features of JavaCAPS 6 is the ability to communicate between the new JBI-based applications and the Repository-based projects of the JavaCAPS 5.x technology. This allows reuse of existing projects and the ability to make use of the 5.x architecture while it continues to provide functionality that is not yet available in the new technology.

This example shows how to communicate from the JBI-compliant BPEL 2.0 engine of OpenESB and JavaCAPS to a repository-based JCD. Though the principle is the same for communicating from any JBI-compliant composite application to a JCD.

The starting point for this example is the OpenESB introduction tutorial. This example also assumes that you are familiar with the JBI-based technology of OpenESB and the repository-based projects of JavaCAPS. If you are not yet familiar with the JBI-based technology, you should definitely start with the aforementioned tutorial.

The first step in the tutorial creates a simple BPEL process, which is exposed using a SOAP Binding Component Service Unit, and then deployed in a Composite Application (a Service Assembly in JBI speak).

The second step shows how to invoke an EJB Service from that BPEL process. But what if you wanted to implement that functionality in a JCD? You might do this for 2 reasons:

  1. You already have the functionality implemented in a JCD and you want to reuse it
  2. That step may consist of considerable mapping logic and it will be easier to implement it using the graphical mapper of JCD collaborations rather than writing the java manually.

The following movie shows how to:

  1. create a JCD using XSD OTDs
  2. build it in a repository-based project
  3. include that project as a Service Unit in a JBI Service Assembly (Composite Application)
  4. test the process and jcd

Demo movie

 (This item is also located on the Grok JavaCAPS wiki)




« July 2016