Design Thoughts for JDSL 2.0 Version 0.2

JSDL and WS-BPEL WS-BPEL for managing choreography of multiple jobs Complex controls constructs : switch, for, while, etc. integration with other types of activities/services Web service, human tasks, etc. Complex variable support/manipulation and expressions (XPath) Long running transaction support: compensation Event and exception management Supports for usage profiles Two possible approaches for representing flows of Jobs BPEL document JSDL document includes/references BPEL document WS-BPEL is designed or Web Service choreography A WS-BPEL process implements a WS A process is instantiated on WS message receive and completes on WS message reply Dependency on WSDL Built in constructs for WS invocation, correlation, partner roles, etc. Support of asynchronous activities provided through WS callback and correlation IBM Confidential

JSDL and WS-BPEL Extension to WS-BPEL for supporting Job choreography Support Job activity that specify JSDL submission Support parallel control constructs ForEach Extensions to JSDL for integration with BPEL Integration with WS-BPEL variable management support Variable references can be used in Job Definition entity elements and attributes IBM Confidential

WS-BPEL document - sample <process name=“Job-Flow"………> <flow> <links> <link name=“job1-to-job2”/> </links> <job name=“job1” > <sources> <source linkName=" job1-to-job2 " /> </sources> Job submission document </job> <job name=“job2” ................ > <targets> <target linkName=" job1-to-job2 " /> </targets> </flow> </process> IBM Confidential

JSDL with WS-BPEL document - sample <JobDefinition> <Application> <flow> <links> <link name=“job1-to-job2”/> </links> <job name=“job1” > <sources> <source linkName=" job1-to-job2 " /> </sources> Job submission document </job> <job name=“job2” ................ > <targets> <target linkName=" job1-to-job2 " /> </targets> </flow> </JobDefinition> IBM Confidential

Job Definition Reuse Clearly separate 2 types of entities: Job definition entity Can be reused across multiple Job submissions Defines: What “program” has to be executed Requirements for the program execution Required scheduling parameters Submission entity Parameters specific to a single submission instance It can embed a Job definition entity or refer to an external one Variable support IBM Confidential

Actors Developer Submitter Administrator Operator Builds the “programs” that can be executed Submitter Requests the “programs” execution and manage their lifecycle Administrator Manages the scheduling environment Defines policies for governing “programs” execution Operator Monitors and controls the job execution IBM Confidential

Main Use Cases Developer Submitter Administrator Operator Creates Job Definitions Submitter Submits jobs for execution using Job Definitions Specifies the Job Definition inline Specifies reference to a Job Definition document Manages the lifecycle of the submitted jobs Monitors status Get output Terminate Etc. Administrator Manages resources Manages infrastructure Defines scheduling policies Operator Manages all submitted jobs IBM Confidential

Resource Requirements Resource requirement specification based on resource model No implicit assumption about specific resource types and attributes Matching on relationships between resources Specification of Resource preferences and Optimization criteria Specification of Job Affinity IBM Confidential