[Oslc-Automation] Advertising actions on the Result from the Plan

[Martin P Pain]

Comments inline in red
Your comments prefixed with ">" (for those viewing in text-only mode)




From:   John Arwe <johnarwe at us.ibm.com>
To:     oslc-automation at open-services.net, 
Date:   16/10/2013 22:54
Subject:        [Oslc-Automation] Advertising actions on the Result from 
the Plan
Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net>



> Looking at 
http://open-services.net/wiki/automation/Exposing-arbitrary-actions-on-RDF-resources/#Advertising-actions-on-the-Result-from-the-Plan 
, some comments. 

> Without the parameterised plan: 

> - there's not enough here for a client to know it is capable of knowing 
> how to invoke the future Action. Automation would have to add that 
> requirement; i.e. that the action on the result MUST at least support 
> the Automation Plan implementation type, using the current terms. If we 
> do so, not much practical difference between these two options that I 
> can see. 

The automation wiki page says "If a provider is providing Actions for 
consumption by Automation consumers.... It MUST include one AutomationPlan 
implementation of each action." - so we already have that requirement.
Having said that, replying on the spec for this information is subject to 
the same problems as if the actions spec said "it's always POST" rather 
than encoding that in the data - namely, lack of extensibility.


> - the Result might offer multiple Actions, with duplicate rdf:type sets, 

> some supporting the Automation Plan implementation type and others not 
> supporting it. I'm allowing, for example, that the Plan and Result are 
> owned by different providers, which is a case I remember at least one 
> implementation saying they had; the Result provider could offer a stop 
> action (that the Plan provider somehow knows about - how, I don't care) 
> and a second stop action implemented by a third provider. This seems 
> like a stretch, but if the Result provider allows updates (put/patch) 
> that add actions, there you are. We don't have to solve that, but if 
> there's an option that clearly does/not it would be useful to keep in 
> mind. 

If those duplicate actions are semantically equivalent, they should be 
multiple requests on a single action. Then as long as one of those 
Requests uses the AutoPlan impl type, we're fine - the 
minimal-implementation consumers just identify and use the AutoPlan one. 
The PUT/PATCH to add actions is interesting - using the spec as-is they 
would have to identify if any of the existing actions are semantically 
equivalent, which would be difficult. But if they're adding an action onto 
an AutoResult, then they ought to be subject to the Automation profile of 
Actions anyway, which would require an AutoPlan implementation of the 
Action.
> With the parameterised plan: 

> - the "orchestration composition time" problem I think is that the 
> requestURI value is unknown on the Plan. Reusing core:Action with 
> requestURI 0:1 (or 0:0) seems right to solve that. 

I don't understand what you mean. It sounds like you're talking about 
"without the parameterised plan". Are you saying we don't need to allow 
for a parameterised plan? I'm happy to leave it out of the spec, as long 
as we think we have a reasonable chance of adding it in later if someone 
comes up with the need later (which feels very unlikely at this point).
If you're saying that we don't know the requestURI for the parameterised 
plan, my intention of allowing parameterised actionOnResult plans is to 
allow clients with provider-specific knowledge to insert the context for 
the action as an AutoRequest parameter value. In other words, instead of 
giving the context-specific requestURI and AutoPlan URI that will be in 
the Result's Action, we provide a contextless requestURI and AutoPlan URI, 
with the context provided by the parameter. The provider-specific 
knowledge is required to know how to find the value of that "context" 
parameter, and which parameter it should be the value of.
As I said, I'm happy to leave this out of the spec, especially due to this 
provider-specific knowledge being required.

There is a separate case for when the action has required parameters other 
than the context... that's a whole other problem. That's not the problem I 
was trying to address here.

> - dcterms:identifier is only going to be useful if both Plan-Action and 
> Result-Action are somehow known to come from the same Provider, which 
> Automation does not guarantee (tolerable) but also does not give the 
> client any iron-clad always-available way to know (less attractive - I 
> don't think we Require oslc:serviceProvider links).

Does the same dcterms:identifier value explicitly mean different things 
from different providers? As the provider of the Result really should know 
about the Plan, it can perhaps pull those identifiers from the Plan 
provider. This would likely need provider-specific logic to know which 
identifier to use, but if the Plan provider is advertising actionOnResult 
in this case then it would have to have Result-provider specific knowledge 
to know that the actions will be available anyway. So as long as it 
doesn't contradict dcterms' definition of dcterms:identifier to say that 
they can be used to match actions even across providers (ONLY between a 
Result and its Plan when they are on different providers), I don't believe 
there's a problem here. They would check the identifier between the Plan 
and the Result, and not have to know if they are on the same provider or 
not.

> It really wants to 
> be a URI, but it seems likely that (ala requestURI) the correct URI (to 
> the Result-Action of interest, which is inherently scoped to 1 request) 
> cannot be reliably known from the Plan (which is scoped to 0:n Results). 

> In cases where the resource context is supplied outside the request URI 
> (e.g. in a fixed body), I can see a URI working. 

My feeling on this is that we have a URI - it's the value(s) of rdf:type. 
So one option would be to say that separate actions on the AutoResult MUST 
have distinct value sets for rdf:type (possibly only applying this 
requirement in the case of the action being advertised through 
actionOnResult). If the provider has two actions that map to 
core:StopAction, then they must define their own type for each of them (in 
addition to Action and StopAction) to differentiate them. In other words, 
they give this action a URL that applies to both its parameterised and 
non-parameterised forms, and include that in the rdf:type values.

...


> "without" + adding the MUST support AP implementation type seems like 
> the minimum that Could work, so I'm tempted to start there and say any 
> improvements in robustness/reliability are implementation extensions. 
> Which is vaguely unsatisfying. 

Do either of my comments about dcterms:identifier or rdf:type above help 
give robustness/reliability to this case?

> I wonder out loud: if the Result-Actions (as in the "with" option, fully
> fleshed out with the final requestURI) were linked via actionOnResult 
from
> the Request, would that satisfy the scenario? ....

No, as even the Request is not created when the orchestration Plan is 
authored. And as the orchestration Plan may be executed multiple times 
(possible even concurrently in different environments managed by the same 
provider) there may be multiple Requests existing over time, so even 
fixing the "don't execute on Request creation" 'problem' wouldn't make 
this work.

...

> Net: I do see how some particular implementations could accomplish this. 

> I do not see how it can be done using Automation alone by *all* the 
> implementations I remember us discussing in the past as being either 
> permissible or real. Simply too many degrees of freedom in the general 
> case. 

Does anything I've said change that?

Best Regards, John

Voice US 845-435-9470  BluePages 
Tivoli OSLC Lead - Show me the Scenario 
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131017/e24250d7/attachment-0003.html>