-
Notifications
You must be signed in to change notification settings - Fork 10
Automation Specification Notes
Automation 2.1 Last update Feb 2015
Automation predates Actions
- Automation plans are discovered through query and selection dialogs
- Actions provides additional discovery capability in the context of a resource
- Automation plans have a well-known means of execution and can be used to execute actions
- Actions provides other means of execution in addition to, or instead of automation plans through interaction patterns in profiles.
Automation resources define automation plans, request and results for SDLC lifecycle operations.
Automation Plan: a unit of automation available for execution - function definition
- parameterDefinition - plan parameters
- usesExecutionEnvironment - execution environment details, OS, DB, browser, etc.
- futureAction - actions that become available on resources as a result of the execution of this plan
Automation Request: resource representing a request to execute an AutomationPlan - function invocation
- state - current state of the automation request
- desiredState - indicates a future desired state of automation request
- inputParameter - actual parameter values for AutomationPlan parameterDefinitions
- executesAutomationPlan - URI to plan definition
Automation Result: represents the result of executing an automation plan
- state achieved
- desiredState
- contribution - result of this automation
- inputParameter - copy of automation request parameters
- outputParameter - of the automation plan execution
Parameter Instance: represents an input or output of an automation request or result
Dialog - immediate-execution creation dialog, deferred-execution creation dialog
- binding - to an action to execute
Automation defines extensions to the OSLC Actions 2.0 specification. Actions provide a means of advertising actions (or operations) that can be performed on (or in the context of) a specific resource. This relates to Automation in two ways:
- Automation Requests can be used as an interaction pattern by which actions can be executed
- Actions can provide a way to aid management and the lifecycle of automation resources.
The Actions specification reuses Automation resources to define an Automation Request interaction pattern, which can be used to execute actions. Actions also defines a specification profile that implementations can use, which provides interoperability based on providers and consumers both using a common interaction pattern. This specification extends the Actions specification by defining interaction patterns which are useful in the management of automation resources.
Historical note: Actions started off in Change Management as a way to change the state of a ChangeRequest. Because Actions are applicable to other things, the open-services.net working group decided to extract CM actions content out into a separate Actions spec. Actions were also integrated Automation as described above. But Automation ground to a halt and the Automation TC was abandoned. As a result, OSLC Change Management 3.0 depended on Actions that didn’t exist anymore.
- Automation 2.1 was promoted to Finalization 17 Feb, 2015.
- Automation specification development moved to OASIS in the Automation TC
- However the Automation TC lost its chair and failed to meet, and was eventually disbanded
- There are no know implementations of Automation 2.1, but there are a number of client and server implementations of Automation 2.0.
- Automation specification 2.1 was then adopted by oslc-domains TC and was migrated to OASIS ReSpec by Koneksys.
- OSLC Configuration Management Specification 1.0 shapes reference oslc_auto namespace and use about 15 Automation properties, primarily for oslc_config:Activity for providing information on the state of long running activities such as creating a baseline.
- OSLC Configuration Management 1.0 requires an extension to Automation 2.0 for an oslc_auto:progress property. See this email.
- open-services.net Actions 2.0 was promoted to finalization on 17 Feb, 2015, along with Automation 2.1.
- Actions 2.0 was moved to OASIS OSLC Core TC. There has been no further work on this specification, and it is not included in the OSLC Core 3.0 multi-part specification.
- An early version of OSLC Configuration Management 1.0 did utilize actions to define operations on configuration management resources. But this has been removed.
- The OSLC Change Management 3.0 specification did refer to a specific actions profile for describing how to change the state of a ChangeRequest, but this was not included in the Change Management 3.0 Specification, CS02.
- An early version of Actions (maybe 1.0?) is implemented in Rational Team Concert. But there are no known implementations of Actions 2.0.
Proposed recommendation:
- Review Automation 2.1 changes to ensure compatibility with 2.0 implementations
- Add new oslc_auto:progress as needed by Configuration Management
- Leave Actions 2.0 as an OSLC Core 3.0 working draft