CS Engine Service. The CSEngine is the core service used for the orchestration of the distributed execution of a compound service. It is responsible for starting a process and executing process activities, and for routing the process execution to the next node. The CSEngine is based on a distributed process execution engine called OSIRIS. The functionality exposed by the service is in part implemented inside an internal library, the OSIRIS library. The library is meant for internal use by the CSEngine only and it’s not described here in detail. XXXXXX supports a custom graph based process description model, which can be partially mapped on the BPEL process description language. The main constructs of the model are the following activities: • SOAPCall - this activity provides the functionality to send a given SOAP message to a web service defined by its endpoint and optionally its SOAP action (as defined in the WSDL for the operation). It corresponds more or less to the BPEL “invoke” activity. It takes as input arguments the EPR of the service to be invoked, the operation to be executed, the message to be passed to the service operation, a flag indicating alternative calling mechanisms, the number and list of additional headers to be passed in the SOAP call and returns the response message resulting from the service invocation; • Assignment –this activity, which corresponds to the BPEL “assign” activity, provides the functionality to assign any number of process variables (or parts thereof) or expressions to other variables or parts thereof. It takes as input parameter the list of source of assignment and returns the list of results of the requested assignments; • Wait – this activity, which corresponds to the BPEL “wait” activity, provides the functionality to wait for a specified amount of time, i.e. to pause process execution. Both types of parameters that are mentioned in the BPEL specification are supported, and exactly one of “For” or “Until” must be given. It takes as input parameters the specification of the time to wait. • Empty – this activity corresponds to the BPEL “empty” activity. The semantics are those of a no-op, i.e. the activity does nothing and has no effect. • Switch – this activity corresponds to the BPEL “switch” activity. i.e. its semantics are those of a conditional branch. • While – this activity corresponds to the BPEL “while” activity, i.e. its semantics are those of a loop with an exit condition. OSIRIS process definitions are only allowed in the ...
