[Oslc-Automation] Changes I have made to Actions specs based on Actions issues list
Martin P Pain
martinpain at uk.ibm.com
Mon Mar 17 09:07:58 EDT 2014
My only response is:
> The fundamental problem though is that (in the Auto Request asynch
> case) the failure may not be known until *after* the create response
> has been sent.
I don't see this particular aspect as a problem, as long as the "created"
response is defined to mean neither success nor failure (which I believe
is stated in Appendix A of the Actions spec). This means the async style
won't be incompatible with FB (i.e. it won't look like success when it's a
failure), but it will be lacking information that could otherwise be
available when it's a synchronous creation.
That doesn't change the result of those last two emails, but does raise
the question of whether we should change the interpretation of 201 in
Appendix A, or override it in the FB pattern section, to mean that the
Action was successful and resulted in creating a resource. (And add to the
AR pattern a clarification that 201 means the AR has been created, not
that the action has completed. In other words, from the point of view of
executing the Action, can be treated as a 202.) As if we don't allow 201
to mean success, I don't think removing the inheritance solves the problem
- a synchronous create returning 201 for success still doesn't tell the
consumer that it has completed successfully.
(The next question that comes out of the decision to split these two
patterns, is whether the binding should be a Request or a Plan. Part of
the purpose of making it a Request was to enable the compatibility with
FB. However, I think there is still value in it being a Request, as then
multiple Actions can link to Requests each with a different parameter
value for the same Plan.)
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/03/2014 12:35:36:
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net,
> Date: 14/03/2014 12:36
> Subject: Re: [Oslc-Automation] Changes I have made to Actions specs
> based on Actions issues list
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> > appropriate in 2.1 ... saying that if it returns a verdict other
> than "passed" (or perhaps "warning") that it returns a 5xx or 4xx
> status code? (I believe they all permit a response body).
>
> The Automation-level "problem" with doing that is that the synch
> execution style is something that the provider is permitted to
> select on a request by request basis. Some providers are simpler
> today, but that's the general case. What you're suggesting is
> certainly allowed: when the provider knows "early enough", here's an
> additional case it can optimize.
>
> The fundamental problem though is that (in the Auto Request asynch
> case) the failure may not be known until *after* the create response
> has been sent. So the AR IP could inherit from the FB IP *only* if
> the request is always synch-style; since not all AR flows are synch
> style, the AR IP (which encompasses both synch and asynch styles)
> cannot inherit from FB in the general case. We could spec it such
> that *when the provider guarantees that the AR-synch style will
> always be used* that the provider can expose a binding recognized as
> FB whose body happens to be a AR, and otherwise it Must Not do so.
> That's tugging at my "overly complex" meter, but if "hidden" inside
> the Automation spec where the synch/asynch dichotomy is already
> exposed it's probably ok.
>
> > WebDAV's 424 "Method Failure" [1] [2] might be appropriate.
> > (This would mean that those implementations that use 2.0
> synchronous execution would not be compliant to 2.1 - so this might
> be more appropriate for 3.0 than 2.1).
>
> "Method failure" is a string I only see in the MSFT doc; all the
> normative references like RFC4918 say "Failed Dependency". Reading
> the RFC's section on 424 and PROPFIND, it wouldn't be my first (or
> fourteenth) choice.
>
> > Or do you think it would be more appropriate to split the FB and
> AR interaction patterns?
>
> I convinced myself above (...*only* if...) that they must be split;
> they're just incompatible (wrt how the client detects failures) in
> the asynch execution style.
>
> > Any individual provider would still be free, I believe, to use a
> 4xx/5xx return code in the synchronous AR case, as in the paragraph
> above, and so use an AR as a fixed body, but it would have to
> explicitly make it recognizable as both, rather than the spec doing so.
>
> Agree
>
> > I guess we can always suggest it, or even make it a best practice,
> to support FB when using AR (which should work fine with
> asynchronous execution, and the change above can make it work with
> synchronous execution).
>
> So far, n-1 of the 5ish implementations I have using or planning to
> use Automation are in the "my requests are 'always' long-running,
> I'll always use the asynch style, and keep things consistent for
> clients" camp. The other is, so far I think, the polar opposite
> (always synch; I just don't know how long that will actually fly for
> them). Offering multiple bindings, one FB and one AR, is something
> I see only when we have multiple products able to manage a single
> resource (which they each represent independently, and then we have
> to link together later in 'third party' code)... the "link them
> together" code might well merge actions if the types are compatible.
> Maybe other cases will emerge over time, but I don't see *any*
> current implementations saying that it's a best practice to offer both.
>
> > The only question for that approach is what is the recognition rule
for AR?
>
> Just remove the oslc:ContentFromRepresentation resource , so it
> works like resource shape?
> oslc:binding [
> a http:Request
> http:body [
> a oslc-automation:AutomationRequest
> ...
> ]
> ]
>
>
> > I feel like we should go with splitting the patterns,
>
> agree
>
> > and documenting in what cases you can use them together
>
> I'm closer to 'on the fence' about this. If it's "true but not
> commonly used" consequence of the spec, I'd be tempted to relegate
> it to a companion document. We considered doing that for synch/
> asynch "styles" in 2.0 but ran out of energy.
>
> > (I probably can't make a convincing enough argument for making it
> a best practice - we can discuss whether any profile should require
> both from providers),
>
> my views above.
>
> > then propose for 3.0 that synchronous execution returns a non-2xx
> code for failure.
>
> This seems like an option (consequence of the current spec), so I
> wonder if it belongs in a companion document.... perhaps along with
> the whole synch execution style.
>
>
> 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/20140317/9fce610f/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/20140317/9fce610f/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/20140317/9fce610f/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/20140317/9fce610f/attachment.gif>
More information about the Oslc-Automation
mailing list