i021 semantics

[Paul Fremantle <paul@wso2.com>]

Last week I pushed hard that we should define the semantic of RM policy independently of wsp semantics.

Here is my attempt. This text is NOT intended to be added to the spec. 

First thought. One can either define a complete endpoint to support reliability or individual 
messages.

Second thought. You can define the reliability to be optional or not. The word optional in this 
semantic definition is NOT inherited from wsp:optional. Instead it is 
defined in the text below.

There are therefore some options listed below. 

A) Attachment is endpoint and NON-Optional.
All messages requests and responses must be delivered reliably. Client 
must implement RMS. If there are any two-way messages then client must 
implement RMD.


B) Attachment is endpoint and Optional
Messages may be delivered reliably. The endpoint will respond to 
CreateSequenceMessages (all things being equal).
In the case where there is no offer, the endpoint may choose to send a 
CS message to the client. If there is a fault in response to the CS, it 
should deliver the responses unreliably.

[I see this being used in the case where the intention is to support 
reliable request and response, but can fall back to unreliable]

C) Attachment is message level and optional, on an input message.
The client may choose to send a CreateSequence to the endpoint, and may 
choose to send those messages marked reliable in the context of a 
sequence. The client may also choose to send messages NOT marked as 
reliable in the context of the sequence. The endpoint should not fault 
these for being reliably delivered. In other words, the client may, on 
seeing that some messages have the policy attached, choose to send all 
messages to this endpoint reliably. The endpoint may also choose to 
try to send responses reliably, but should not fault if the CS fails. 
(In other words B is in effect here.)

D) Attachment is message level and optional on an output message.
The endpoint may choose to send a CS to the client. If there is a fault 
in response to the CS, it should deliver responses unreliably. The 
endpoint may implement an RMS, and the client may implement an RMD but 
if neither of these is true, communication will still occur. 
The client may also choose to send messages reliably, but should not fault if
the endpoint fails to start a sequence. (In other words B is in effect here as well.)


E) Attachment is message level and NON-optional on an input message.
The client must implement an RMS and must deliver the messages marked as
reliable as part of a sequence, and the service endpoint will fault 
otherwise. The client may choose to deliver all other messages for the 
same service and endpoint reliably. The endpoint should not fault these 
for being delivered as part of a sequence. The endpoint may attempt to 
deliver responses reliably but should not fault if the CS fails. 
(In other words B is in effect here).


F) Attachment is message level and NON-optional on an output message.
The client MUST implement an RMD, and the endpoint must deliver all the 
marked messages in the context of a sequence. The endpoint
may choose to send *all* responses to the client reliably. The client must
not fault because non-marked messages are delivered reliably. The client 
may also attempt to deliver any request messages in the context of a sequence. 
In other words B is in effect here.

The summary of this (non-normative!) is that if any messages are marked as reliable (either optional or non-optional) 
there is the option of treating the whole endpoint as reliable (optionally). The reason this is important is because 
it means that clients or service providers that cannot handle the complexity of message-level attachment have the choice of 
treating the whole endpoint (or all input/output messages) as reliable.

Having worked through this, I also have a suggestion on how to capture this in policy. 

I am sending it in another note.

Paul

-- 

Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://feeds.feedburner.com/bloglines/pzf
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com