1. WP 1.5 Process Management Process Execution & Reliability
Christoph Langguth
UNIBAS

2. Overview Process in SOA:
„Combination“ of several services into a workflow
Process itself can be called as a service
Process execution should be distributed
i.e. the individual activities are carried out at the node where the invoked service „sits“
Strive to support Processes defined in BPEL+ as well as in native format of existing UMIT/UNIBAS process execution engine Osiris
BPEL+ converted to „native“ format before actual execution
Geneva, March 28, 2006
DILIGENT N°

3. Past & current activities
Deployed existing process execution engine OSIRIS into GT4 container
Works, but several issues especially with required libraries (TBD)
Make different instances use GT4 „transport mechanisms“
= use WS calls for communication instead of own socket-based communication
This is the CSEngine service
Created new DILIGENT-specific components
Most substantial: CSActivity component
Enhanced Osiris to (partially) support BPEL variable assignments
Needed for flexible Xpath assignments
GLiteJobWrapperService implementation
Geneva, March 28, 2006
DILIGENT N°

4. GLiteJobWrapperService
GT4 stateful service
Factory: createResource()
Instance:
setJdl(String jdl)
Could (should?) as well be moved to factory
getStatus()
submit()
getJobOutput()
Usage:
Submit(), keep polling getStatus(), getJobOutput()
OR: submit(), subscribe to status changes, getJobOutput()
Problems:
Notifications within gLite don‘t work – have to periodically poll for status changes
Getting job output doesn‘t work with gLite 1.4 => getJobOutput not tested or implemented
Job output will be a bunch of files – what should the return type be?
Zip and base64-encode as a string?
Use attachments?
Provide both possibilities?
Geneva, March 28, 2006
DILIGENT N°

5. CSEngineService Stateless service for the time being
executeProcess(String param)
Takes an Osiris-style message containing the process name and arguments
Will be replaced by startCS(#any) corresponding to the WSDL interface of the respective process
Needs „polymorphic“ calls according to the respective input/output of the process
Can be achieved by manipulating the incoming message using an Axis Handler (simple prototype seems to work)
saveProcessDefinition(String xml)
Takes process definition in Osiris format for storing internally
Will be superseded by CSResourceMgr to store in DIS
receiveOsirisMessage()
Used internally for the communication between different CSEngine nodes
Geneva, March 28, 2006
DILIGENT N°

6. CSActivity
Is the library (Osiris component) responsible for carrying out execution steps
Two types of activities for now:
Assignment:
Corresponds to BPEL <assign> activity
Allows the assignment between process variables or parts thereof (using XPath)
Implemented for variables, also implemented bpws:getVariableData(var,part,query)
Part is actually ignored for now (GT4 supports only one part!)
Geneva, March 28, 2006
DILIGENT N°

7. CSActivity SOAPCall (BPEL: <invoke>) – needs three parameters:
SOAPAction (to know which operation to invoke)
Message to send („raw“ SOAP)
EPR – three possibilities:
(plain URL)
WSRF EndpointReferenceType
This INCLUDES stateful resource identifiers!
DILIGENT service ID (not implemented yet)
Actual EPR will be dynamically selected
Returns: the raw SOAP response message
Relatively close to BPEL style, but:
Does not need WSDL at runtime to resolve PortTypes (but needs SOAPAction)
Geneva, March 28, 2006
DILIGENT N°

8. Very simple example
Invoke createResource() on
Assign getVariableData('result','dummy','/createResourceResponse/EndpointReference') to epr
Invoke setValue() on epr
Invoke getValue() on epr
Geneva, March 28, 2006
DILIGENT N°

9. Problems encountered
Integrating/adapting existing engine to DILIGENT is harder than expected
It uses its own datatypes, message types, repositories, replication mechanisms
It doesn‘t know about XML or XML namespaces
Getting BPEL-style assignments (XPath!) to work wasn‘t evident
„Breaking up“ the internal message paths and logic used, and modifying it to use the DILIGENT infrastructure (i.e. the CL functionality) is still under investigation
Geneva, March 28, 2006
DILIGENT N°

10. OSIRIS in a nutshell
All communication is message-based using a proprietary message format
Messages contain a target component identifier and the payload
All messages on each node always go through a core component (Horus)
Horus uses pipelines of Handlers to modify/dispatch the messages
Load balancing is done in such a handler
Management of joins (after forks in process) as well
(Replicated) repositories used for maintaining all information
Which components exist in the system (and where)
Which are the known processes and activities
Geneva, March 28, 2006
DILIGENT N°

11. Subscription repository
Contains among others the list of components available in the Osiris „network“ (central DB, local replicated cache on nodes)
Used to find possible candidate nodes for the execution
Corresponds =~ to the DeploymentCache functionality
Problem 1: don‘t want to maintain an additional layer of replication („besides“ DILIGENT)
Problem 2: it just knows about Osiris components (CSActivity available on each DHN); but for matchmaking & routing, we need the Target EPR (either concrete URL or logical Diligent name)
Problem 3: can‘t just leave it out as all the rest of Osiris depends on it…
Problem 4: each node needs to know SubRep address for bootstrapping
Solution attempt: each node runs its own SubRep (w/ info about local components only); routing has to be implemented from scratch
Geneva, March 28, 2006
DILIGENT N°

12. Process description repository
Contains process descriptions as well as „execution steps“
Execution steps (=activity) also include dependencies
But again, only in terms of Osiris components, no info suitable for Diligent matchmaking
Information that DeploymentCache would need
Is used extensively by the underlying logic for executing a process (activity)
Again, has to be kept locally (at least its interface)
But retrieve actual information from the DIS (and keep them in sync)
Geneva, March 28, 2006
DILIGENT N°

13. Join Repository/Load Repository
JoinRep: Used for the management of Process Joins
„Process instance abc, step 23 meets at node xyz“
Should be relatively simple to modify to use DILIGENT persistent notification mechanisms
LoadRep:
Again needed for matchmaking („which is the best of the known nodes“)
Will be completely left out, replaced by POS
Geneva, March 28, 2006
DILIGENT N°

14. MsgProcessRequestHandler
Messages in Osiris
1. Step x pre: CSActivity on A
2. fetch def. of
step x
12. CSActivity via Horus on B
MsgProcessRequestHandler
MsgPubSubHandler
MsgRoutingHandler
MsgSendHandler
[other handlers]
6. Step x post
CSActivity A
SubRep
JoinRep
LoadRep
ProcDescRep
7. fetch step
x+1 comp.
3. CSActivity:A
8. CSActivity:ANY
4. CSActivity on A
Horus on A
9. Where are
CSActivity?
10. select best
11. get/set
Join node
5. Actual execution
Geneva, March 28, 2006
DILIGENT N°

15. Components
CSEngine as central GT4 component and CSActivity for invocation
Implemented and running
DeploymentCache
Needs (detailed!) info from (extended) ProcDescRep
Offers =~ functionality of SubRep
LoadRep =~ POS (matchmaking)
CSResourceMgr (register/unregister resources)
„between“ the ProcDescRep and DIS
Store/load process definitions
At least „one-way-synch“ w/ProcDescRep needed
ServiceQueryBridge
Exact functionality also depends largely on modified ProcDescRep (find relevant processes, successor nodes)
Geneva, March 28, 2006
DILIGENT N°

16. Summary Have a „standalone“ running system
Which runs within GT4 container
Extended to handle complex XML types, namespaces, BPEL Xpath assignments, WSRF EPRs…
focused on „being able to run this“
GLiteJobWrapper
Difficulties
Conflicting jars/Classloader etc.
Sort out interferences and overlap Osiris/GT4/DILIGENT
dictate the detailed design more than expected
Dependencies from CL
Especially heavy use of notifications
Geneva, March 28, 2006
DILIGENT N°