[Oslc-Automation] Actions 2.0 - Dialog RDF

[John Arwe]

action:request [ a oslc:Dialog ] seems like it would work, and certainly 
re-uses existing concepts & artifacts in what looks like a completely 
sensible way.

Are these scenarios heading to a wiki page?

I'm a *bit* confused when you say that scenarios B and C are "specific to 
the Automation profile".
It is true that the Automation *spec* defines what usage=template means. 
Automation is the only spec I'm aware of that overloaded resource creation 
with additional semantics (flogs self Again for missing that in 2.0 review 
phase), but I'd hope that we're drafting the usage URI in such a way that 
another spec Could re-use it if a similar situation arose.  Being defined 
by the Automation spec alone therefore does not tie templates to the 
Automation profile.

Put another way: if we assume that action:request [ a oslc:Dialog ] is the 
syntax, and the semantic of action:request is "contains instructions for 
executing the Action", then if a particular set of instructions includes 
usage=template do we consider that an error (since usage=template 
conflicts somehow with ... I'm not sure what, but maybe I'm missing 
something) ?  The reason we needed usage=template is that there is a 
semantic "create means create now" carried by creation factories in 
general, but *the knowledge that the dialog was for a creation factory* 
came from following a oslc:creationDialog link in a service provider 
document, a context/semantic that Actions does not have.  I think this is 
the reason Steve suggested calling these "action dialogs", to clearly 
distinguish them (and along the way give us the opportunity to define the 
semantics differently if needed).

We could, for example, create usage URIs like "execute immediately" for 
actions, and require 1:* usage URIs on action dialogs; all URIs on a given 
dialog must be "compatible" in the same sense that Automation uses to 
enable logical subclassing of verdicts/states, and a client must not use a 
dialog unless it understands at least one of those URIs.

That allows profiles (defined in Core, or elsewhere) to define dialogs 
with different semantics without having to worry about (compliant) clients 
getting unexpected results. 

One such profile might be called "deferred execution".  For the moment, 
I'll assume that's defined separately from the Automation profile 
(combining them later if we decide they must be is always easier than 
untangling things after the fact).  What we need for this is actually 2 
dialogs: one to create the template, and one that accepts a template as 
pre-fill (using existing terminology) and executes it immediately (a 
standard creation dialog that accepts pre-fill; we need to think through 
what the interaction pattern (responses) should be).  We *could* define a 
single "execute immediately" interaction pattern that works for both 
cases, I think...strawman off the cuff would be:

200 or 204 = succeeded already; poll the resource being acted upon to find 
current state.
202 = queued for execution (accepted but not yet completed).  HTTP says 
the response payload contains a "monitor" in this case, but not what a 
monitor is - left completely open; we could say that the monitor (if 
you're using our usage URI) SHOULD be an Automation Request, with a 
Location header (allowed by HTTP, but no meaning assigned to that in 
HTTP).  IF the client wants to know when/if the request completes (and its 
ultimate status), THEN the client needs to poll the monitor resource (no 
query, no service provider needed, just GET the Location URI) and use the 
state/verdict properties in the result per Automation 2.0.  The provider 
is required to clean these up w/o any client DELETE request (my strawman - 
not the client's fault that the server queues the request, the client 
wasn't really Trying to create some new resource it would be responsible 
for).

All other status codes exactly as HTTP uses them.
Particular implementations might never return the 202, but clients still 
need to cope with 202.  I would not be averse to giving "202 capable" 
implementations their own usage URI, if the perceived burden on clients is 
too high.  There's an argument to be made that any HTTP client already 
MUST deal with 202 anyway, possibly by treating it as a generic 2xx, thus 
ignoring all the polling/monitor specifics, but I'd bet that no all are 
correctly coded in practice.

Automation 2.1 could require that implementations support both Automation 
Plans as implementations and template dialogs (in which case maybe it is 
just one Automation profile), or it could treat them separately. 
Personally I lean toward flexibility.

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131120/6627c86c/attachment-0003.html>