B2J Architecture

Author: Antony Miguel, Last Updated 15th March 2006

Overview

  • In order to understand B2J's current architecture it is necessary to understand where B2J came from (briefly!). B2J originated as the TPTP (Test and Performance Tools Platform) Choreography component. The TPTP Choreography component was intended to couple various aspects of TPTP to allow them to work together and to provide an efficient distributed runtime for TPTP which would naturally have access to the coupled services.

    See this diagram for a quick overview of how the Choreography component was to fit into TPTP.

    To this end the TPTP Choreography component provided an efficient BPEL 2.0 execution framework capable of distributing a single BPEL process across multiple physical hosts.

    At the beginning of 2006 the TPTP Choreography component underwent a change of focus and was moved to a more suitable home in STP (SOA Tools Platform), where it could be more easily exploited by other projects.

    The component was made a Subproject of STP and renamed B2J (BPEL to Java) to reflect it's new focus. The original Choreography component was designed to convert BPEL into Java which could then be executed in the context of a replacable engine framework. The Choreography component then provided two implementations of the engine framework; a JVM-local engine for running BPEL in-process and a multi-process distributed engine able to run a single BPEL process efficiently across many machines. The combination of these two implementations were to meet the requirements of TPTP.

    In the move to the STP project, the BPEL to Java translation and the replacability of the engine has become key. The focus of the newly named B2J Subproject is to expose the BPEL to Java translation as a framework and allow other vendors to use this in their own BPEL environments. As reference implementations, B2J also provides the original engines.

Architectural Overview

    B2J consists of two main parts. The first takes arbitrary BPEL and generates Java source files which implement the BPEL by using the B2J engine APIs. These files are then compiled into Java class files using a replacable Java compiler (e.g. JDT if running in Eclipse or javac if running in any old standard JVM).

    The second part comprises the B2J engine framework implementation which runs the compiled class files.

    As shown in the diagram above the first step in executing the specified BPEL program is for the choreography component to translate it to Java source code. This Java source code assumes the existence of a B2J engine Runner interface. This Runner interface provides the translated Java source code with facilities to send and receive messages on specified conversation IDs, create and access shared memory constructs such as shared variables or maps, and to create and access synchronisation constructs like semaphores, mutexes and barriers. The translated Java source code uses these APIs to implement the necessary BPEL programming constructs.

    This abstraction allows the engine to replaceable with either a simple implementation (e.g. the B2J local engine) or a complex distributed implementation (e.g. the B2J distributed engine)

    The translated Java source code is then compiled into Java classes using a replaceable Java compiler. This set of compiled classes is referred as the engine Program (there is also a Program class which serves as a container and classloader for these compiled classes).

    When the program is ready, an engine implementation is instantiated to run the program. The EngineFactory class is used by the B2J Launch Configuration to instantiate an engine implementation and the program is passed through to the implementation and launched via the standard Client API interfaces.

    The engine implementation takes the program classes and launches the specified Runners to execute the program. It passes in a reference to itself as an implementation of the Runner interfaces so that the executing runners have access to the necessary distributed constructs.

B2J Distributed Engine Implementation

    The B2J distributed engine implementation is capable of running a single BPEL process across multiple machines. The threads created in each BPEL flow are distributed across a specified set of physical hosts according to a deployment algorithm or deployment service invocations made from within the BPEL.

    This engine uses a star topology where the a Coordinator host coordinates all distributed transactions between a number of Worker hosts. The Coordinator is a single point of synchronisation for all distributed transactions and so manages synchronisation and shared memory across the runners in all the Workers.

    The Coordinator machine can be on the same machine as a Worker machine but where there are a large number of Runners or a number of Runners that are draining resources due to operations they are performing it is likely that hosting the Coordinator machine on a separate machine will yield better performance.

    For more information on the B2J distributed engine, take a look at the distributed engine architecture document here.

Local Engine Implementation

    A second B2J engine framework implementation provides a purely local implementation and serves as a good basic example implementation of the B2J engine interfaces.

    The local engine does not distribute the BPEL process in any way (although it does still support multithreading and parallel BPEL activities). This implementation has certain benefits over the distributed engine implementation such as a greatly reduced startup time and increased performance in certain conditions (e.g. message passing, where the local engine does not need to pass messages across a network).