[Oslc-Automation] Automation Template Scenarios

[Martin P Pain]

The Automation Template Scenarios wiki page [1] says the the problem it is 
trying to solve is that "Automation added “execution” as an immediate 
consequence of Automation Request creation".

However, it then later says "the “template” of the automation request [is] 
saved in a resource on the consumer".

To me these sound like two different problems. The suggested solution 
achieves the two scenarios by addressing the first issue, by delaying (or 
preventing) execution once the request has been created on the provider. 
However, if we were to address the second issue - by never saving the 
template request on the provider in the first place - then this would also 
achieve the two scenarios.

Solving the first problem would - as the wiki page states - only relate to 
the Automation domain. However, the second problem might be useful in 
other domains too.

There is a way we could solve the second problem. If we used a 
"templateDialog", as was originally mentioned, and returned the RDF graph 
of the templated resource through the "oslc-response" data [2] passed back 
through postMessage() (window.name might not support strings long enough) 
then the resource would not need to be created on the provider at 
template-creation time at all.

This would allow providers to avoid having to create a resource that only 
needs to be requested once. I do not like the idea of forcing providers to 
create such a short-lived resource, as it adds a burden of maintaining and 
cleaning up short-term persisted data which it might otherwise not need to 
do. Without that requirement, it would be fairly simple to support a 
templateDialog. (And providers who are happy to create such a short-lived 
resource could return the standard "oslc-response" data containing a URL 
anyway.)
I raised a similar concern not long ago about synchronous execution (about 
creating resources that will only be requested a single time), and am glad 
that in that case there is an alternative to creating a short-lived 
resource. I think we should consider if we can provide an alternative 
here, such as the "oslc-response" suggestion above.

Also, if we went ahead with using the creation dialog for template 
creation, I presume the new means of identifying that a dialog supports 
pre-fill would also be used to say whether or not we support template 
creation? Otherwise a client that wants template creation might use the 
pre-fill on the creation dialog with the appropriate "don't execute" 
status set, running the risk that the status will be ignored by the 
provider and the request executed anyway! (That would be in the case where 
the provider supports pre-fill but not template creation.) Using a 
templateDialog would avoid that need.

While if we were to add the new "don't execute yet" state that would allow 
for the "scheduling/approval smarts" to be either on the client or the 
server, these scenarios are already achievable if the smarts are on the 
provider end. It's up to the provider implementation when a request gets 
executed anyway, so whether or not it has an additional "waiting" state, 
or a separate property indicating what it's waiting for, or nothing at 
all, it can still wait until the trigger or approval before executing it. 
(If the execution happens by workers/agents, then the provider-worker 
relationship is currently provider-implementation-specific anyway, so it 
can still define its own way to delay execution).
My point is that using the creation dialog & a new state for template 
creation shouldn't be done solely because it allows for the "smarts" to be 
on either the provider or consumer - although we do need to consider both. 
(I know this wasn't directly the motivation for it - I'm just addressing 
one possible argument.)

It's possible that there's room for both a templateDialog and a new 
"waiting"/"don't execute yet" state. This would allow the consumer to 
create a template and save it itself (not on the provider); or to create a 
resource in "don't execute yet" state on the provider and then change that 
state when it's ready (both of these put the consumer in control); or for 
the provider to expose the scheduling settings in the creation dialog and 
control the "don't execute yet" state on its own (this is where the 
provider's in control - and is possible in v2, but might be better 
communicated to consumers by a new state).

Do you think there would be any benefit to a templateDialog for these 
reasons, or would it be extra complexity for too little gain? (Is there 
anything new here, or have we already addressed these issues?)

Thanks,
Martin


[1] 
http://open-services.net/wiki/automation/Automation-Template-Scenarios/
[2] 
http://open-services.net/bin/view/Main/OslcCoreSpecification#The_UI_Provider_s_responsibiliti

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/20130712/6ad7995d/attachment-0003.html>