[Oslc-Automation] Actions 2.0 - Dialog RDF
Martin P Pain
martinpain at uk.ibm.com
Thu Nov 21 04:40:01 EST 2013
Responses inline.
Kind regards,
Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
Open Services for Lifecycle Collaboration - Automation WG joint chair
E-mail: martinpain at uk.ibm.com
Find me on: and within IBM on:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on
20/11/2013 14:13:01:
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net,
> Date: 20/11/2013 14:13
> Subject: Re: [Oslc-Automation] Actions 2.0 - Dialog RDF
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> 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?
They are now here:
http://open-services.net/wiki/automation/Action-dialog-scenarios/, linked
to from the teardpown and Auto actions pages.
> 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) ?
It conflicts with the interaction pattern that says "submitting this
dialog executes the action". However, I'm not necessarily saying that this
is an error. Perhaps it's better that we rely on the oslc:usage value(s)
on the dialog to define the interaction pattern (in which case we need one
for "action dialog") so then the template dialog usage can define the
template-based interaction pattern. Right now I quite like the idea of
that (as long we we're not implying things by a value _not_ being present,
as we've ended up doing with creation dialogs).
...
>
> 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.
Sounds good.
> 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).
There are two forms (at least) of deferred execution: one where the user
is present at the "later" time, and one where they are not. For the
latter, having a separate dialog would not work - you need a creation
factory (or some other defined interaction/request).
In my previous email I said "I think any "execute later" scenarios are
substantially different - they need to pick a particular implementation
(e.g. AutoPlans, ResourceShape) by which it will be executed at the later
time". One of those implementations for the "later" interaction/request
could be a dialog, for the cases where a user is present (which is what
you have described briefly in your previous paragraph).
However, for cases where there is no user present at the later time (such
as in the virtual service concrete/example scenario for teardown) that
later interaction needs a defined interaction pattern. For flexibility, I
would suggest leaving that interaction pattern open in the same way as the
initial Action's interaction pattern is.
In other words, the "execute later" (with dialog) steps would flow
something like this:
1) Display the "execute later" dialog (e.g. AutoRequest template dialog)
2) Use the return value of the dialog to retrieve/generate the request
body for the appropriate "later" interaction pattern is for (e.g. request
and store the AutoRequest template)
3) At the later time, follow the steps of the appropriate "later"
interaction pattern (e.g. submit the AutoRequest template to the creation
factory that is pointed to from the http:requestURI of the Action).
This allows us the same flexibility for execution later as we have for
execution now, but with a way to use dialogs to generate the request body.
But the whole interaction pattern is incomplete without a defined "later"
interaction pattern. This is why I said "they need to pick a particular
implementation (e.g. AutoPlans, ResourceShape) by which it will be
executed at the later time" and "(B) and (C) are specific to Automation
profile" (as the way I wrote them they are using the automation
interaction pattern at the "later" stage).
So we either:
1) leave the whole of the "execute later" dialog-based interaction pattern
to individual implementation type definitions,
or
2) we define a generic framework which generic clients can use to execute
any interaction pattern, on to which implementation type definitions can
add specifics. (But this would probably constrain those implementation
types/interaction patterns too much).
This is the main point I want to discuss at this point. Does my
description of it make sense?
> 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).
...
> There's an argument to be made that
> any HTTP client already MUST deal with 202 anyway
For now my only comment here is to remember that this return data is the
result of a delegated dialog, not an HTTP request. While we could use the
http RDF vocab to encode this information in JSON-LD (and that might not
be a bad idea) we don't already have an HTTP response context here - we
would be adding it anew.
> 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
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
Original message in full:
"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on
20/11/2013 14:13:01:
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net,
> Date: 20/11/2013 14:13
> Subject: Re: [Oslc-Automation] Actions 2.0 - Dialog RDF
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> 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
> _______________________________________________
> 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/20131121/62e05a0c/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131121/62e05a0c/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131121/62e05a0c/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131121/62e05a0c/attachment.gif>
More information about the Oslc-Automation
mailing list