[Oslc-Automation] Actions 2.0 - Dialog RDF
Martin P Pain
martinpain at uk.ibm.com
Fri Dec 13 08:41:51 EST 2013
Following on from the discussion about the scenario/interaction pattern of
"delegated UI dialog to execute action later" for resources that don't
exist - that scenario was already covered in "scenario C" at:
http://open-services.net/wiki/automation/Action-dialog-scenarios/
although admittedly it is a complex scenario that the current spec does
not solve (or at least we haven't yet described a way that it solves it).
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
21/11/2013 09:40:01:
> From: Martin P Pain/UK/IBM at IBMGB
> To: John Arwe <johnarwe at us.ibm.com>,
> Cc: oslc-automation at open-services.net
> Date: 21/11/2013 09:40
> Subject: Re: [Oslc-Automation] Actions 2.0 - Dialog RDF
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> 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: [image removed] and within IBM on: [image removed]
>
> [image removed]
>
>
>
>
> 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
> _______________________________________________
> 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/20131213/548f6ba2/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/20131213/548f6ba2/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/20131213/548f6ba2/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/20131213/548f6ba2/attachment.gif>
More information about the Oslc-Automation
mailing list