1 / 7

Design Thoughts for JDSL 2.0

Design Thoughts for JDSL 2.0. Version 0.2. Actors related to Job Submission. Developer Builds the “programs” that can be executed Is typically a human Submitter Requests the “programs” execution and manage their lifecycle Is typically a program, it could a be human Administrator

kalona
Download Presentation

Design Thoughts for JDSL 2.0

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design Thoughts for JDSL 2.0 Version 0.2

  2. Actors related to Job Submission • Developer • Builds the “programs” that can be executed • Is typically a human • Submitter • Requests the “programs” execution and manage their lifecycle • Is typically a program, it could a be human • Administrator • Manages the scheduling environment • Defines policies for governing “programs” execution • Is typically a human • Operator • Monitors and controls the job execution • Is typically a human

  3. Main Use Cases related to Job Submission • Developer • Creates Job Definitions • Submitter • Submits jobs for execution using Job Definitions • Either specify the Job Definition inline • Or 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

  4. Reuse of Job Definition • Job submission involves 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 • Support for parameters and variables • Variable expressions

  5. Security • Use WS-* standards for specifying security information • WS-Security for Job Execution credential • Job Execution Credential should be specified in the main JSDL sections • Dependencies with other JSDL resource constructs (i.e. home filesystem) • Support for credential mapping • Support for applying policies based on credentials (i.e. authorization)

  6. Resource requirement • Specification based on resource meta-model • No implicit assumption about specific resource types and attributes • Express requirement on resource characteristics and relationships between resources • Express allocation of resources • Express resource preferences • Express optimization criteria

  7. Job Choreography • Complex Job choreography is outside of the JSDL scope of Simple multi-step support • Focused on the execution of multiple steps using the same set of resources • Support for simple sequential flow or parallel type of flow • For more complex flows, integration with WS-BPEL will allow for inter-job choreography • Enable to integrate with WS-BPEL for manage the choreography of multiple jobs • Evaluate extension to WS-BPEL required for Job choreography scenarios • Support Job activity that specify JSDL submission artifact • Integration of JSDL with WS-BPEL variable management support • Variable references can be used in Job Definition entity elements and attributes

More Related