[Oslc-Automation] first cut at split of auto request from fixed body is live

Mon Mar 24 06:50:43 EDT 2014

"Interaction patterns" section changes:

"using a binding to construct one or more HTTP messages " - currently 
they're all HTTP messages (although the deleagted UI dialog is an indirect 
HTTP message by creating an iframe), but I could see non-HTTP bindings 
being created in future, e.g. to send an MQTT message. On the one hand all 
the ones we have at the moment are HTTP, so we may not need to cater for 
this future possibility in our wording, but on the other hand we might not 
want to restrict the bindings that other specs can define.

I would also not jump straight into the single vs multiple flow problem, 
perhaps something like this:

Consumers invoke actions to achieve a certain goal (desired result) using 
a binding, and that binding's interaction pattern, to know the steps to 
take to invoke that action. Each action can have one or more bindings, as 
alternatives to each other,[1], and each binding can use one or more 
interaction patterns, also as alternatives to each other[2]. Each binding 
gives the specific details that are needed to execute any of its 
interaction patterns for this particular action, for example the HTTP 
message to construct, if using any of the HTTP-based interaction patterns.

Most of the interaction patterns involve the consumer constructing one or 
more HTTP messages. Some interaction patterns always consist of a single 
message, but others permit or require multiple messages to achieve the 
same goal. This distinction becomes critical when a consumer is trying to 
determine whether or not its goal has been achieved, based on message 
responses.
When using interaction patterns that always consist of a single message 
flow, consumers will expect the HTTP status code to equate to the success 
or failure of the goal (executing the action): if a success status code 
(2xx class) is returned (other than "202 accepted"), consumers will 
interpret that to mean that the action ran successfully. Single-message 
interaction pattern definitions SHOULD avoid other interpretations.
When using interaction patterns that sometimes or always consist of 
multiple message flows, in general consumers cannot expect “the” HTTP 
status code to equate to the success or failure of the goal (executing the 
action), because the issue of which message’s status code to use arises. 
Multi-message interaction patterns MUST define how a consumer 
unambiguously determines the status of its goal from the messages.
        [1] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#executing-actions

        [2] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#recognizing-patterns

"Pattern: Automation Request" section changes:

If we're not inheriting from HTTP fixed body any more, what about using a 
Creation Factory resource, rather than an http:Request?
However: (1) we currently have no way of specifying the AutoRequest to use 
as the template
(2) Similar to the problem with extending HTTP requests, we would need to 
make sure this could be distinguished from "single-request creation" 
actions, for exactly the same reasonas as mentioned in your previous 
change.
It's probably simplest to leave it as an http:Request message, as then we 
have the fact that the http:body resource's rdf:type is AutomationRequest 
to distinguish it from any other for of HTTP interaction pattern.

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

From:   John Arwe <johnarwe at us.ibm.com>
To:     oslc-automation at open-services.net, 
Date:   21/03/2014 21:17
Subject:        [Oslc-Automation] first cut at split of auto request from 
fixed   body is live
Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net>

[1]  has the prose on general IP-level mixing rules 
[2]  has updated Auto Req recognition rule + proposal to change it 
both red for now so it's easy to review just the changes 

I have to search for other side effects (I know there's still a lingering 
stmt that an AR binding *could* be recognized as FB IP, but that's the 
point of the proposal at [2]). 

[1] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Interaction-patterns 

[2] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#pattern-autoreq 

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/20140324/2874e6cc/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/20140324/2874e6cc/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/20140324/2874e6cc/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/20140324/2874e6cc/attachment.gif>