[Oslc-Automation] OSLC Actions: URI to identify interaction patterns. Plus "templates" replacing "with RDF body" pattern
Martin P Pain
martinpain at uk.ibm.com
Wed Jan 15 11:48:51 EST 2014
> From: John Arwe <johnarwe at us.ibm.com>
> I wonder if Availability scenarios would motivate the "raw" creation
> factory binding.
We'll be discussing two more Availability scenarios at the meeting this
week, so we'll see what we think after that. I'm happy to go either way.
> You have changed (in the odt strawman) Auto Request from an IP to a
> request body type. But Automation requires a client to understand a
> larger pattern of requests (and the Automation vocabulary) - the
> meaning of 200 is *different* for a CM-style POST (action completed
> successfully) than an Automation-style POST (action completed, look
> at oslc_auto:verdict for success/failure).
I can't see anywhere that defines what a 200 response means from an
AutoRequest creation factory. Core doesn't seem to define status codes for
Creation Factories, and neither does Automation. And in any case, I'd
expect a "201 Created", which only means "request created" and does not
mean "request executed" therefore does not mean "action completed".
However, I agree that with the fact that the plain HTTP request, if the
response is any 2xx code (other than 202), means the action has completed.
However, the AutomationRequest one does not.
But on the other hand, consumers that only support the generic "HTTP with
template body (aka with RDf body)" can still kick the action off by
treating it as a standard HTTP POST, however they do not know whether it
has completed and (more importantly) they do not know that they do not
know.
(And I don't want to start adding an "oslc:expectedResponseCode" predicate
to let them know what status codes mean success.)
(It also comes to mind that, if AutoRequests are valid "monitor" resources
for 202 responses, then the result of a POST to an AutoRequest creation
factory could validly be either 201 (for the creation of the AutoRequest)
or 202 (for the creation of the AutoResult/the execution of the result).
If we required them to return 202, that could bridge this gap, but
wouldn't fit nicely with Auto 2.0.)
> I don't think you can
> avoid making that a separate IP (at least I cannot see how).
Unless we can solve the "how do generic consumers know that the action has
not yet completed" problem, then that is sounding correct.
It's very important that they don't think it's completed when it hasn't.
However, the other question is: do they always need to know when it has
completed? (Or is it enough that they will are aware that they don't know
when it will complete?)
If they don't always need to know, then I still think it would be good to
let consumers that only understand HTTP-request-with-template (and not the
Automation semantics) kick off the action, but they really need to be
aware that they don't know when it will complete.
If they do always need to know when it completes, then there's no point in
the Automation IP extending any other one.
> > (1) having a single URI to identify each interaction pattern
> > (which means only having a single HTTP request pattern,
> > identifying the different ways of building content separately)
>
> With my client hat on, I don't see what this saves me. I don't
> think it hurts me either, FWIW. Either factoring should work.
>
> I think in terms of implementation effort.
> ...
> Having one IP URI that covers several of those cases is functionally
> no different than saying "look for X and then Y". I have to do that
> in the end either way.
It makes the rule for identifying the IP:
(1) easier to understand
(2) easier to implement.
However, it does mean that the question "can I execute this binding" is
now no longer just "do I understand this IP" but also "do I understand
this request body type"? however, if both of those are still simple
"single URI" checks, I still think this separation is simpler to
understand. But I might be wrong.
>
> There are a couple of degrees of freedom involved, in branches:
> - body or not (branch: if body, how to construct it)
> - single request or not (more generally: which request pattern do I
> need to understand? single, Automation, ...)
> With my RESTy-spec hat on, I react in ways like "an OSLC creation
> factory isn't a HTTP request? really?" Yes, I can get past those,
> it's another forest/trees problem. I won't be the only one asking
> though, as you go through multiple reviews - assuming anyone reads them.
> With my OSLC-spec hat on, I see places in this that would make Core-
> Actions depend normatively on Automation (a domain spec)
Ok, we can move into Core any of those dependencies that need to remain.
> > (2) re-using the idea of "templates" from automation for the "with
> > RDF body" case, to avoid solving the same problems (e.g.
> > content-type) twice.
>
> Conceptually, Automation's templates may be defined with some extra
> restrictions, but the general idea sure is obviously valid once you
> adjust the level of abstraction to the context. If the other emails
> have led "you" to buy the "template is a role a resource can play"
> language, I'd certainly go there over keeping template as some kind
> of "thing-ness". How vs what.
I can accept that.
It still troubles me a little that you can GET and receive an AutoRequest,
but it doesn't behave like other AutoRequests. (I can be ok with that if I
think of them as part of 2 data sets or collections - one of the ones that
are queued for execution, and one that is not.)
> > (3) Also, it brings the "creation factory" interaction pattern
> > into Core, but John has now suggested we only define the
>
> as written it seems like it could
> be used either for immediate execution or something else (like
> Automation requests). Given that those are entirely different
> interaction patterns, I have a little bit harder time seeing the
> value *if* it is considered fully specified as-is.
Right now, it's only intended to have value as a dialog's "immediate
execution IP". (Which doesn't need a resource shape, but could easily have
an oslc:resourceType). To have value on its own it would either need a
resource shape (or at least a type) or a template.
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
14/01/2014 18:24:28:
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net,
> Date: 14/01/2014 18:24
> Subject: Re: [Oslc-Automation] OSLC Actions: URI to identify
> interaction patterns. Plus "templates" replacing "with RDF body" pattern
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> wrt the draft
>
> I wonder if Availability scenarios would motivate the "raw" creation
> factory binding. Maybe Juergen/Tim can weigh in. I think they Can
> use Automation for what they've discussed, but maybe a raw CF would
> be cleaner for some pieces (e.g. if some of their interactions are
> just always synch, and we think that is likely true for "all"
> reasonable implementations).
>
> You have changed (in the odt strawman) Auto Request from an IP to a
> request body type. But Automation requires a client to understand a
> larger pattern of requests (and the Automation vocabulary) - the
> meaning of 200 is *different* for a CM-style POST (action completed
> successfully) than an Automation-style POST (action completed, look
> at oslc_auto:verdict for success/failure). I don't think you can
> avoid making that a separate IP (at least I cannot see how).
>
>
> > (1) having a single URI to identify each interaction pattern
> > (which means only having a single HTTP request pattern,
> > identifying the different ways of building content separately)
>
> With my client hat on, I don't see what this saves me. I don't
> think it hurts me either, FWIW. Either factoring should work.
>
> I think in terms of implementation effort. Moving from dead-simple
> (relatively speaking) to maybe-harder-than-I-want-now is:
> 1: a single naked HTTP request - no request body, no special headers
> to fuss with, blocking request.
> 2: #1 plus a fixed request body ... something I never crack open, I
> just bitwise-copy from the binding. so the delta is I have to fish
> out the content type header :-( from the binding
> 3: #2 plus I crack open (parse) the body, but I never modify it,
> just serialize it (maybe with a different media type than the
> binding had) ... may drag Accept header-style info, unless we say
> introspect at run time which is fine.
> 4: #2 or #3 in a multi-request pattern, like Automation requests
> where I have to create something, then monitor/poll until it reaches
> &some-final-state
> 5: #2 or #4 where I modify the body, or construct it from scratch
>
> Having one IP URI that covers several of those cases is functionally
> no different than saying "look for X and then Y". I have to do that
> in the end either way.
> It's like saying "you have rdfs:Resource, why do you need any other
> types?" Because rdfs:Resource is not always the granularity that a
> client/app is interested in. It's fine for some purposes, not others.
>
> There are a couple of degrees of freedom involved, in branches:
> - body or not (branch: if body, how to construct it)
> - single request or not (more generally: which request pattern do I
> need to understand? single, Automation, ...)
> With my RESTy-spec hat on, I react in ways like "an OSLC creation
> factory isn't a HTTP request? really?" Yes, I can get past those,
> it's another forest/trees problem. I won't be the only one asking
> though, as you go through multiple reviews - assuming anyone reads them.
> With my OSLC-spec hat on, I see places in this that would make Core-
> Actions depend normatively on Automation (a domain spec), and Core
> has said it wants to keep all dependencies ON core FROM domains, not
> the reverse, less we end up in Dependency Hell. I'm talking about
> cases like "Request body type: Resource template" line 476 ...
> whatever's needed should be in Core. I'm not worried about cases
> where Core is just listing and pointing at IPs/profiles known to
> exist elsewhere (it's not a normative dependency), like line 552.
> > (2) re-using the idea of "templates" from automation for the "with
> > RDF body" case, to avoid solving the same problems (e.g.
> > content-type) twice.
>
> Conceptually, Automation's templates may be defined with some extra
> restrictions, but the general idea sure is obviously valid once you
> adjust the level of abstraction to the context. If the other emails
> have led "you" to buy the "template is a role a resource can play"
> language, I'd certainly go there over keeping template as some kind
> of "thing-ness". How vs what.
>
>
> > (3) Also, it brings the "creation factory" interaction pattern
> > into Core, but John has now suggested we only define the
>
> If defining it in Core makes it easier for Automation to define it's
> version via layering, that could be cause to do it (I think emails
> earlier today may have helped to clarify that). Aside from giving
> it a Interaction Pattern name, I don't think it adds any new
requirements.
>
> Maybe it should, though. Maybe *if* you want to use a CF as an
> action binding, *then* it Must advertise resource shape(s) it
> accepts. We are allowed to add requirements for action bindings
> beyond those Core-2 defines for service providers. Such an action
> binding Might still be incomplete/abstract: since it doesn't tell a
> client what type(s) are created, as written it seems like it could
> be used either for immediate execution or something else (like
> Automation requests). Given that those are entirely different
> interaction patterns, I have a little bit harder time seeing the
> value *if* it is considered fully specified as-is.
>
>
> 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/20140115/40ec53cb/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/20140115/40ec53cb/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/20140115/40ec53cb/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/20140115/40ec53cb/attachment.gif>
More information about the Oslc-Automation
mailing list