We developed the BIS-Grid engine as a set services to be deployed to a UNICORE 6 installation. These service extensions mainly consists of two service types, Workflow Management Service and Workflow Service , and an arbitrary standard WS-BPEL workflow engine. Thereby, the service extensions are WSRF services. Also, in our case the WS-BPEL engine is the open source workflow engine ActiveBPEL. Together, the service extensions and the arbitrary WS-BPEL engine represent the BIS-Grid workflow engine . The service extensions are deployed as Grid Services within UNICORE 6's service container, the UNICORE/X component. For each workflow deployed with the Workflow Managament Service one Workflow Service will be created using a hot deployment mechanism without restarting UNICORE/X. These services manage and access ActiveBPEL. As a standard WS-BPEL workflow engine, it typically orchestrates stateless \wss and supports only basic security mechanisms, e.g.~username-based and password-based authentication. Therefore, advanced security concepts must be provided by the service extensions in the UNICORE 6 service container.
The Figure presents an overview on the architecture of the BIS-Grid workflow engine. Within UNICORE/X, the BIS-Grid service extensions are placed beside so-called UNICORE Atomic Services which provide basic functionalities to support Grid computing, and beside other \gss that, e.g. may provide access to information systems. One important design decision was to neither extend the WS-BPEL standard nor to modify ActiveBPEL for Grid Service orchestration, although the WS-BPEL 2.0 specification provides an extensibility mechanism that allows to integrate additional functionality without declining the standard. However, the use of proprietary extensions would conclude in a solution that may not be interoperable with future versions of the standard as well as with standard WS-BPEL engines.
Leaving the WS-BPEL standard and the engine untouched ensures sustainability and flexibility, and allows to exchange the WS-BPEL engine by any other WS-BPEL engine. The Figure shows that the ActiveBPEL engine is located behind UNICORE~6. Hence, it can be deployed separately on backend nodes to support load balancing.
Beside these advantages there are issues that have to be addressed when using such a decoupled system architecture. The WS-BPEL code that is necessary to call a Grid Service is more complex than it would be with proprietary language extensions. For example, even if one wants to use a WSRF resource of a Grid Service for one single invocation, one has to explicitly create, use, and destroy it resulting in several WS-BPEL invoke activities. We address this by hiding the complexity of the code from the user as far as possible, especially from the workflow designer. To do so, we propose to extend an existing WS-BPEL editor by introducing new ``Grid Activities'' that encapsulate the WS-BPEL code for Grid Service invocation. Furthermore, there is the need to address some implementation-specific aspects such as a UNICORE 6/WS-BPEL process mapping problem. These aspects have to be addressed in the WS-BPEL code but are not part of the actual (fuctional) workflow. Therefore, we propose to inject these aspects automatically at workflow deployment, thereby concealing them from the workflow designer. In detail, these aspects are described in the BIS-Grid Specification, and in in Deliverable 2.1, which discusses these aspects in form of BPEL patterns (see Deliverables ).