1. Design Thoughts for JDSL 2.0
Version 0.2

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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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