Standards » Architecture Area » PGI WG

Following today's PGI session at OGF33, rename 'Submitted' as 'Pending' and 'Delegated' as 'Processing'.

v12: 2 Use Cases :
- CreateActivity performs minimal validation, quickly returns Jobids (but NO Stage-in information) and goes to 'Submitted:Incoming',
- CreateValidatedActivity performs complete validation, may return Stage-in information, and goes directly to 'Submitted:Validated', at the expense of response time.
Take into account that the Execution Service may be unable to provide one or both :
- Notifications,
- Output Sandboxes.
(PNG drawing of the Big Diagram with Comments)

v12: 2 Use Cases :
- CreateActivity performs minimal validation, quickly returns Jobids (but NO Stage-in information) and goes to 'Submitted:Incoming',
- CreateValidatedActivity performs complete validation, may return Stage-in information, and goes directly to 'Submitted:Validated', at the expense of response time.
Take into account that the Execution Service may be unable to provide one or both :
- Notifications,
- Output Sandboxes.
(PNG drawing of the Big Diagram)

v12: 2 Use Cases :
- CreateActivity performs minimal validation, quickly returns Jobids (but NO Stage-in information) and goes to 'Submitted:Incoming',
- CreateValidatedActivity performs complete validation, may return Stage-in information, and goes directly to 'Submitted:Validated', at the expense of response time.
Take into account that the Execution Service may be unable to provide one or both :
- Notifications,
- Output Sandboxes.
(PNG drawing of the Medium Diagram)

v12: 2 Use Cases :
- CreateActivity performs minimal validation, quickly returns Jobids (but NO Stage-in information) and goes to 'Submitted:Incoming',
- CreateValidatedActivity performs complete validation, may return Stage-in info rmation, and goes directly to 'Submitted:Validated', at the expense of response time.
Take into account that the Execution Service may be unable to provide one or both : - Notifications,
- Output Sandboxes.
(PNG drawing of the Small Diagram)

v12: 2 Use Cases :
- CreateActivity performs minimal validation, quickly returns Jobids (but NO Stage-in information) and goes to 'Submitted:Incoming',
- CreateValidatedActivity performs complete validation, may return Stage-in info rmation, and goes directly to 'Submitted:Validated', at the expense of response time.
Take into account that the Execution Service may be unable to provide one or both : - Notifications,
- Output Sandboxes.
(XMI file readable by any UML tool)

v12: 2 Use Cases :
- CreateActivity performs minimal validation, quickly returns Jobids (but NO Stage-in information) and goes to 'Submitted:Incoming',
- CreateValidatedActivity performs complete validation, may return Stage-in info rmation, and goes directly to 'Submitted:Validated', at the expense of response time.
Take into account that the Execution Service may be unable to provide one or both : - Notifications,
- Output Sandboxes.
(ZARGO file created by ArgoUML)

v11 : Exclude internal states. Second level Job states are also mandatory. Inside the 'Submitted' state : The Execution Service may already allocate resources - Rename 'Waiting' substate as 'Validated' - Add 'Hold' substate. (PNG drawing of the Big Diagram with Comments)

v11 : Exclude internal states. Second level Job states are also mandatory. Inside the 'Submitted' state : The Execution Service may already allocate resources - Rename 'Waiting' substate as 'Validated' - Add 'Hold' substate. (PNG drawing of the Big Diagram)

v11 : Exclude internal states. Second level Job states are also mandatory. Inside the 'Submitted' state : The Execution Service may already allocate resources - Rename 'Waiting' substate as 'Validated' - Add 'Hold' substate. (PNG drawing of the Medium Diagram)

v11 : Exclude internal states. Second level Job states are also mandatory. Inside the 'Submitted' state : The Execution Service may already allocate resources - Rename 'Waiting' substate as 'Validated' - Add 'Hold' substate. (PNG drawing of the Small Diagram)

v11 : Exclude internal states. Second level Job states are also mandatory. Inside the 'Submitted' state : The Execution Service may already allocate resources - Rename 'Waiting' substate as 'Validated' - Add 'Hold' substate. (XMI file readable by any UML tool)

v11 : Exclude internal states. Second level Job states are also mandatory. Inside the 'Submitted' state : The Execution Service may already allocate resources - Rename 'Waiting' substate as 'Validated' - Add 'Hold' substate. (ZARGO file created by ArgoUML)

v10 : Vector operations on Single Jobs do NOT imply Collection Jobs (which are out of scope). Any implementation of the PGI Execution Service MUST implement all first level Job states, exactly as described in this document. It MAY implement substates. If these substates correspond to substates described in this document, then these substates MUST be implemented exactly as described in this document. (PNG drawing of the Big Diagram with Comments)

v10 : Vector operations on Single Jobs do NOT imply Collection Jobs (which are out of scope). Any implementation of the PGI Execution Service MUST implement all first level Job states, exactly as described in this document. It MAY implement substates. If these substates correspond to substates described in this document, then these substates MUST be implemented exactly as described in this document. (PNG drawing of the Big Diagram)

v10 : Vector operations on Single Jobs do NOT imply Collection Jobs (which are out of scope). Any implementation of the PGI Execution Service MUST implement all first level Job states, exactly as described in this document. It MAY implement substates. If these substates correspond to substates described in this document, then these substates MUST be implemented exactly as described in this document. (PNG drawing of the Medium Diagram)

v10 : Vector operations on Single Jobs do NOT imply Collection Jobs (which are out of scope). Any implementation of the PGI Execution Service MUST implement all first level Job states, exactly as described in this document. It MAY implement substates. If these substates correspond to substates described in this document, then these substates MUST be implemented exactly as described in this document. (PNG drawing of the Small Diagram)

v10 : Vector operations on Single Jobs do NOT imply Collection Jobs (which are out of scope). Any implementation of the PGI Execution Service MUST implement all first level Job states, exactly as described in this document. It MAY implement substates. If these substates correspond to substates described in this document, then these substates MUST be implemented exactly as described in this document. (XMI file readable by any UML tool)

- Vector operations on Single Jobs do NOT imply Collection Jobs (which are out of scope).
- Any implementation of the PGI Execution Service MUST implement all first level Job states, exactly as described in this document. It MAY implement substates. If these substates correspond to substates described in this document, then these substates MUST be implemented exactly as described in this document.
(ZARGO file created by ArgoUML)

v9 : Write down that 'Cancellation' and 'Failure' can happen in any substate - Mention Time-out inside 'Delegated:Hold' (PNG drawing of the Big Diagram with Comments)

v9 : Write down that 'Cancellation' and 'Failure' can happen in any substate - Mention Time-out inside 'Delegated:Hold' (PNG drawing of the Big Diagram)

v9 : Write down that 'Cancellation' and 'Failure' can happen in any substate - Mention Time-out inside 'Delegated:Hold' (PNG drawing of the Medium Diagram)

v9 : Write down that 'Cancellation' and 'Failure' can happen in any substate - Mention Time-out inside 'Delegated:Hold' (PNG drawing of the Small Diagram)

v9 : Write down that 'Cancellation' and 'Failure' can happen in any substate - Mention Time-out inside 'Delegated:Hold' (XMI file readable by any UML tool)

v9 : Write down that 'Cancellation' and 'Failure' can happen in any substate - Mention Time-out inside 'Delegated:Hold' (ZARGO file created by ArgoUML)