Re: [oslc-automation] Returning an AutoResult from an AutoRequest creation (was: Proposal: Link header in responses to AutomationRequest creation)

[Steve K Speicher <sspeiche@us.ibm.com>]

> From: Martin P Pain <martinpain@uk.ibm.com>
> To: Tim Friessinger <TFRIESS@de.ibm.com>
> Cc: oslc-automation@lists.oasis-open.org
> Date: 12/09/2014 02:54 AM
> Subject: [oslc-automation] Returning an AutoResult
from an AutoRequest 
> creation (was: Proposal: Link header in responses to AutomationRequest
creation)
> Sent by: <oslc-automation@lists.oasis-open.org>
> 
> See replies inline below
> 
> 
> Tim Friessinger <TFRIESS@de.ibm.com> wrote on 03/12/2014 16:34:46:
> > when I read the Auto V2 spec some time ago, I thought the idea
is, that an
> > OSLC Automation Service Provider can return an Auto Result as
response to
> > the Automation Request POST action by a client.
> > With that returned Auto Result comes of course the URI of this
Auto Result
> > (rdf:about), so the client knows how he can refresh/ update this
Auto
> > Result without the need for doing a query.
> > I think this wasn't mentioned explicitly in the spec, but it
was at least
> > how I thought it makes sense. ;-)
> 
> The resource that is returned by either a POST to a creation factory,
or 
> from a creation dialog, can have both rdf:type oslc:AutomationRequest
and 
> oslc:AutomationResult (i.e. it can be multi-typed), but I do not believe
> that it can be solely a Result. Although it probably doesn't say that
explicitly... 
> If the provider decides to create a single resource that is a multi-types
> Request/Result, it probably ought to keep it that way throughout the
> lifetime of that resource. For many implementations I expect this
would be 
> fine, but not for some. 
> 
> > So basically it's the same idea as the Link option, proposed
by Samuel, but
> > maybe a little bit more "OSLC style":
> > In Auto V3 one could specify that a POST action for an Automation
Request
> > returns at least an Auto Result stub, so even if execution is
delayed, the
> > client has at least the URI where to fetch the Auto Result again,
> > to see if meanwhile something happend.
> 
> I believe (although Steve might be able to give more information on
this) 
> that it was an explicit decision in v2 to allow providers to not create
the 
> Result when the Request was created. For example, they may have the
Result 
> created by their "agents"/"workers", rather than
by their central server. Or
> the Result may even be hosted on a separate server (although I'm not
aware 
> of any best practice guidance suggesting how to make sure the clients
can 
> find them, so that might be problematic). 
> 
No, I believe in v2 is was desired for "syncronous"
scenarios or automation providers that didn't provide persistence, ie did
keep track of requests and follow on results.

Specifically it says:
"When
a provider creates an automation request, it can also include an automation
result, which might or might not yet be finished at the point in time when
the provider responds to the create request."

See: http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.0/#Asynchronous-and-Synchronous-Automation-Execution

> Unless we want to remove this sort of flexibility, I think we will
always 
> need the clients to be able to deal with both cases: where the server
> provides the Result (or its URL) at the time of Request creation,
and the 
> case where the Result is not created until later. 
> 
> So I believe that means the clients, to be fully 'interoperable',
would need
> to be able to: 
> - find the Result for a given Request using whatever query facility
is 
> available in OSLC 3 
> - find the Link header on the Request's representation (whether a
response 
> from the POST creation , or from a GET on its URL) which points to
the Result 
> - detect if the Request object is multi-typed with oslc:AutomationResult
as well. 
> 
> And for v2 compatibility (if the server chooses to be compatible):
> - be able to find the Result for a given Request using a v2 oslc:queryCapability.
> 

It could also be possible that a simple single triple
could be returned with the HTTP POST response for the creation request:

<auto-result> oslc_auto:producedByAutomationRequest
<auto-request>.

This is just 1 statement from the result that is needed
for Sam's case.  I know the resource definition for Auto Result has
a number of other required properties.  Though the header seems simpler
than this but not by much, esp if the client already would be looking for
the result in the response.

- Steve

> 
> 
> 
> 
> > 
> > ----- Forwarded by Martin P Pain/UK/IBM on 02/12/2014 10:09 -----
> > 
> > From:        Samuel Padgett <spadgett@us.ibm.com>
> > To:        oslc-automation-comment@lists.oasis-open.org
> > Date:        20/10/2014 18:23
> > Subject:        [oslc-automation-comment]
Proposal: Link header in
> > responses to AutomationRequest creation
> > Sent by:        <oslc-automation-comment@lists.oasis-open.org>
> > 
> > 
> > 
> > Currently, as I understand it, Automation clients must query
to find the
> > AutomationResult for an AutomationRequest they created. Something
like
> > 
> > oslc.where=oslc_auto:producedByAutomationRequest=<request-uri>
> > 
> > This requires at least two requests, one POST for the AutomationRequest
and
> > one GET to find the AutomationResult. It also forces servers
to support
> > OSLC query. As someone who has written several OSLC providers,
I can say
> > query is a lot of work to implement and difficult to get right.
> > 
> > I propose we add an optional Link response header [1] in responses
to OSLC
> > AutomationRequest creation. This is an optimization to remove
the query
> > step. For example,
> > HTTP/1.1 201 Created
> > Content-Length: 0
> > Link: <http://example.com/auto/result/82>;
rel="
> > http://open-services.net/ns/auto#produces";
anchor="
> > http://example.com/auto/request/82"
> > Location: http://example.com/auto/request/82
> > 
> > 
> > 
> > Here a client can discover the AutomationResult just by looking
at the Link
> > headers on the POST response.
> > 
> > We could relax the MUST requirement for queries if a provider
supports the
> > Link header. Providers that don't immediately create an AutomationResult
> > for an AutomationRequest could leave off the Link header and
continue to
> > use query.
> > 
> > Link is used in several places in LDP 1.0 [2], and we've used
it in OSLC
> > 3.0 resource preview drafts [3].
> > 
> > [1] http://www.ietf.org/rfc/rfc5988.txt
> > [2] http://www.w3.org/TR/ldp/
> > [3]
> > https://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/
> > specs/resource-preview.html?rev=42&sc=1#linkHeader
> > 
> > --
> > Samuel Padgett | IBM Rational | spadgett@us.ibm.com
> > Eclipse Lyo: Enabling tool integration with OSLC
> > 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
> > 
> > [attachment "pic04575.gif" deleted by Martin P Pain/UK/IBM]
> 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