Architecture
SpecificationThe work of OMII-BPEL is to focus on the latest BPEL specification and technology. OMII-BPEL now supports the latest WS-BPEL 2.0 specification. Both BPEL Designer and ActiveBPEL engine are compliant to this specification. The full document can be found from the following link. Overview
OMII-BPEL bundles and binds up two major open source BPEL tools, BPEL Designer and ActiveBPEL engine, to make sure they work seamlessly with each other and within OMII stack, together with other OMII-supported services.
Conceptually, BPEL Designer is implemented as a vendor-neutral BPEL editor that ports vanilla BPEL documents that can run on any BPEL engines. In addition to the basic requirements that one would normally expect from a GUI editor, like user-friendly interface, rich editing, or even pre-deployment (and inline) validation, debugging in simulation, BPEL Designer makes it possible to integrate with any BPEL engines through providing an extensive runtime framework that BPEL engine can integrate with. Depending on the engine's implementation, this normally also means the editor should also takes care of producing whatever extra to the BPEL document, that the engine will need in deployment time. In the case for ActiveBPEL, it is some resource information that are needed from the user to the engine before executing a BPEL process, for example, where the service that is invoked by the process is, where to look up the XSD schema for those types used in the WSDL, and so on. BPEL Designer does all these automatically.
BPEL is all about service orchestration. A BPEL process is a center of control that coordinates web resources, or, in a Grid computing environment, the Grid resources. It is only when these resources can be arranged properly that the usage of these Grid resources can be maximized; it is when the e-scientists can really take advantage of the existing computing resources. Following the paradigm of service-oriented computing, effectively all services can be orchestrated as being modeled in BPEL and executed by BPEL engines. BPEL is such specification designed to enable modeling of both an autonomous unit of logic internally, as well as the interaction between these units externally. In a picture of large, BPEL intrinsically foster service reuse and hierarchical composition.
Use cases
A typical use case that involves BPEL (both the BPEL script and BPEL runtime) and another OMII managed service, GridSAM, is as this: use BPEL Designer to design a BPEL process that interacts with GridSAM's job submission service port and job monitoring service port; produce the deployment archive by BPEL Designer at the end of the modeling; deploy the process onto ActiveBPEL, which is hosted in OMII Server container; from the BPEL Designer construct the request message that triggers the BPEL process; once got started, ActiveBPEL submits a pre-defined job in JSDL to GridSAM; GridSAM translates the JSDL script to whatever works for the underneath resource manager and sends the job to the underlying Grid computers; ActiveBPEL polls the job status through GridSAM's monitoring interface until the job is completed eventually.
Yet another use case is when Grimoires can be used through BPEL Designer's UDDI browser to inquire and publish services from and to the repository. An service description, more specifically, WSDL document can be retrieved from Grimoires and imported directly to BPEL Designer, where the WSDL will be referenced for defining service interaction with the BPEL process. And then at the end of successfully deploying the BPEL process, the process manifests itself as a Web Service with a WSDL document, which then can be published to Grimoires. It's likely in some cases, this new service can be reused in a even larger process, acting just like a normal web service.