This content is historical; the last update prior to adding this red text was 10 Jan 2014.
The content was rolled into Core Actions 2.0.
Actions
This page is proposing an Automation profile of Core’s Actions - a way of exposing arbitrary actions on RDF resources - that requires Automation as an implementation profile for interoperability of a single client across multiple servers.
Contents
TODO
See also: Early discussion: Exposing arbitrary actions on RDF resources: discussion
Scenarios
Description
Automation Scenarios:
Automation’s requirements on Actions are described on the (Actions 2.0 Scenarios)[http://open-services.net/wiki/core/Actions-2.0-Scenarios/) page.
Operations that can be exposed by Actions include (but are not limited to) the following:
- Deleting a resource (teardown), via
oslc:StopAction
This moves to Automation 2.1 spec once it’s mature enough.
Automation providers MUST support the Create an Automation Request specification profile.
Resources
Either say that Automation places no additional constraints on Core Actions, or enumerate those constraints here.
Application to Automation teardown scenarios
- AutomationResult MAY contain a link to an action resource (via the
oslc:action property) to a resource that is of both types oslc:Action and oslc:StopAction to represent the teardown of a deployed resource. If it does so then:
- That action MUST contain a binding that uses the “Automation request” interaction pattern
- That binding MUST link to a template Automation Request, and a creation factory
oslc:creation URI, such that if the request template representation is POSTed to the creation URI, an Automation Request is created that represents a request for the deployed resource to be torn down. The identity of the resource to be torn down MUST be encoded in the AutoPlan, AutoRequest or creation URI (as opposed to the AutoRequest parameters), so the consumer would not have to provide any parameter values.
- The provider MAY include other bindings of the action - such as an empty-body POST - for compatibility with other consumers. Note: however this is unlikely to be worthwhile as these other consumers are unlikely to be looking at an AutoResult resource.
Example:
@base <http://example.com/>.
<results/1>
a oslc_auto:AutomationResult ;
oslc_auto:state oslc_auto:complete ;
oslc_auto:verdict oslc_auto:passed ;
oslc_auto:reportsOnAutomationPlan <plans/1> ;
dcterms:identifier "result-1" ;
oslc:action [
a oslc:Action, oslc:StopAction ;
dcterms:description "Tear down the deployment";
dcterms:title "Tear down";
oslc:binding[
a http:Request ;
http:httpVersion "1.1";
http:requestURI <requests/creationFactory/create> ;
http:mthd http-methods:POST ;
http:body <plans/1.teardown/request-template?resourceId=result-1>;
# Server hides resource ID within (opaque to client) URI
];
];
.
Advertising actions on the Result from the Plan
This sectino does not reflect the latest work on Core Actions
Scenario/use case:
- A user is setting up an automated process which will include the deployment and teardown of an environment.
- While present at the UI, they wish to configure the client that will be executing the automated process to perform the “teardown” action on the deployed environment at the end of the process.
- However, while creating the process the environment is not deployed (it will not be deployed until the process is run) so there is no AutomationResult on which to see that the “teardown” plan is available, so the automation system cannot provide it as an option to the user.
- Instead, it needs to see from the Plan what actions will be available on the Result, so it can give the user those options to execute in the automated process once the deployment has happened.
Requirements:
- By inspecting the Plan, the consumer can see what actions (by type and name) will be available on the Result.
- Optionally, the provider can expose a parameterised AutomationPlan, where either the AutomationResult (or one of its contributions) can be passed in as a parameter - but which value is provided as which parameter is provider-specific.
This is one possible approach, reusing the action:Action type. The downside of this is that it looks like it’s executable on the Plan, when it is not. The benefit is reusing the same terms as the action on the result.
Without the parameterised plan:
@base <http://example.com/>.
<plans/1>
a oslc_auto:AutomationPlan ;
dcterms:title "Deploy";
oslc_auto:actionOnResult [
a action:Action, new:StopAction ;
dcterms:description "Tear down the deployment";
dcterms:title "Tear down";
];
.
With the parameterised plan:
@base <http://example.com/>.
<plans/1>
a oslc_auto:AutomationPlan ;
dcterms:title "Deploy";
oslc_auto:actionOnResult [
a action:Action, new:StopAction ;
dcterms:description "Tear down the deployment";
dcterms:title "Tear down";
action:request [
a http:Request ;
http:requestURI <requests/creationFactory> ;
http:mthd http-methods:POST ;
action:requestBodyParameters <plans/1.teardown>;
# This points to a Plan that has a required parameter
];
];
.
This is either limited to one action of each type (so, if a user selects an action based on the information in the Plan, the consumer implementation can find the real one in the result by finding the result’s action with exactly the same rdf:type values), or we require a dcterms:identifier value which is used to link them.
Another possible approach would be to have a parameter called oslc_auto:resultShape which points to a Resource Shape that describes the result, and this can contain a description of the actions that will be there (maybe… I’m not convinced about things like “title”). This would require consumers who want to know about these actions to understand Resource Shapes, but it’s an optional extension anyway.
