Re: [ws-rx] [i021]: a proposal

[Tom Rutt <tom@coastin.com>]

Jacques Durand wrote:

> Proposal for i021:
>
> Instead of the finer-granularity attachment of policies (e.g. at 
> message level) option, would propose the other option that is more in 
> line with the intuitive scoping of policies, which are generally 
> understood as applying to messages sent to the endpoint (and not sent by).
>
> After Line 187 in Oct 6^th WS-RM Policy doc:
>
> "As seen above, elements of an RM Policy assertion may concern the 
> behavior of either an RM Source (e.g. 
> wsrm:BaseRetransmissionInterval), or of an RM Destination (e.g. 
> wsrm:AcknowledgementInterval). When attached to a service endpoint, 
> although the endpoint may alternatively act as a Source and a 
> Destination for operations that use both input and output messages, an 
> RM Policy assertion will by default only apply to this endpoint in its 
> Destination role. By default, any client to this endpoint must comply 
> with the RM Policy assertion elements that concern the Source role."
>
> That would be the minimal update needed to remove ambiguity.
>
I agree with the minimal update proposed above.

I do not agree with the concrete proposal below. Such detailed policy 
attachment should be left as out of scope for this version of the 
protocol and the policy attachment specs.

I provide some rationale at the end why it is pragmatic to default to 
supporting only input message reliabilty:

> Other side of the issue 021: how do we attach a policy to a service 
> endpoint that governs output messages - say, a service endpoint is 
> requiring its clients to use RM protocol and send back Acks with some 
> AcknowledgementInterval T (possibly different from the policy 
> assertions that govern the input messages)?
>
> Proposal is to add an attribute to wsrmp:RMAssertion element: @scope.
>
> - If @scope="in" (default) then the assertion applies to input 
> messages only (service endpoint acting as RM Destination)
>
> - If @scope="out" then the assertion applies to output messages only 
> (service endpoint acting in RM Source role).
>
> - if @scope="inout" then the assertion applies to both input and 
> output messages.
>
> I'll draft the formal proposal for that schema update after getting 
> some feedback on the idea.
>
> -Jacques
>

Here is why the default should be only supporting reliability on the 
input message of a wsdl operation.


Background Discussion around Issue 021:

There are four typical event sequence cases supported by the current 
ws-RM spec for WSDL operations, which provide WS-RM Delivery Assurances 
only for the input message. These are shown as cases a) thru d) below.

These four example cases show normal sequences of events associated with 
typical usage of the WS-RM spec (wsdl one way vs request/response 
operatons, and asynch call back vs Anonymous AckTo). Case b) is shown 
because it is interesting, even though it does not comply with WS-I BP 
1.1 (wsdl oneway operations bound to soap/http must not have a soap 
envelope in the Http response).

Case a) One-way WSDL operation, using asynch AckTo
1. SA invokes send(message:string) primitive on RMS
2. RMS assigns RequestNumber and buffers message for possible retransmission
3. RMS invokes receiveSoapRqst on RMD (with SequenceHdr and message body)
4. RMD invokes deliver(message:string) primitive on RA
5. RMD returns empty receiveSoapResp to sending RMS
6. RMD invokes receiveSoapRqst on AckTo RMS (with AckHdr)
7. AckTo RMS returns empty receiveSoapResp to RMD
8. AckTo RMS frees message buffer for acknowledged RequestNumber(s)

Case b) One-way WSDL request, using anonymous AckTo case (Non WS-I 
Compliant):
1. SA invokes send(message:string) primitive on RMS
2. RMS assigns RequestNumber and buffers message for possible 
retransmission
3. RMS invokes receiveSoapRqst on RMD (with SequenceHdr and message body)
4. RMD invokes deliver(message:string) primitive on RA
5. RMD returns receiveSoapResp to RMS (with AckHdr and empty body)
6. RMS frees message buffer for acknowledged RequestNumber(s)

Case c) Request/Response WSDL operation, using anonymous AckTo:
1. SA invokes sendRqst(message:string) primitive on RMS
2. RMS assigns RequestNumber and buffers message for possible 
retransmission
3. RMS invokes receiveSoapRqst on RMD (with SequenceHdr and message body)
4. RMD invokes deliverRqst(message:string) primitive on RA
5. RA invokes sendResp(message:string) primitive on RMD
6. RMD returns receiveSoapResp (with AckHdr and message body) to RMS
7. RMS invokes deliverResp(message:string) primitive on SA
8. RMS frees message buffer for acknowledged RequestNumber(s)

Case d) Request/Response WSDL operation, using asynch AckTo:
1. SA invokes sendRqst(message:string) primitive on RMS
2. RMS assigns RequestNumber and buffers message for possible 
retransmission
3. RMS invokes receiveSoapRqst on RMD (with SequenceHdr and message body)
4. RMD invokes deliverRqst(message:string) primitive on RA
5. RA invokes sendResp(message:string) primitive on RMD
6. RMD returns receiveSoapResp to sending RMS (with message body)
7. RMD invokes receiveSoapRqst on ActTo RMS (with AckHdr)
8. AckTo RMS returns receiveSoapResp to RMD (empty)
9. AckTo RMS frees message buffer for acknowledged RequestNumber(s)

Cases a) and b) are for WSDL one-way operation types.

Note: an application request/response “dialogue” can be defined in WSDL 
as two separate one way operations, one for each direction. If each side 
of the dialogue is willing to take on both roles (RMD and RMS), a two 
way reliable exchange can be constructed by setting up separate rm 
sequences in each direction between the two applications.

Cases c) and d), for WSDL request/response operations, do not support 
reliability for the response message. Providing reliability for a wsdl 
synchronous Response requires additional implementation mechanisms, such as:
• buffering response messages by the RMD;
• RMD including a sequenceHdr in the response Body, and;
• asynchronous acknowledgement carried on a callback soap Request.

Supporting the expression of reliability policy for the output message 
of a wsdl request/response operation would require attaching rm policy 
at the message-subject level. Such fine grained policy attachments can 
be left as extension points to the specification..

As a default, when rm policy assertions are attached to a WSDL 
description only at endpoint subject level, the implied semantics for 
all operations served by that endpoint can be interpreted as:
• each of those operations require reliable delivery only for their 
input messages.
• client relevant policy types (such as retransmission interval) apply 
to the RMS invoking on that Endpoint,
• server relevant policy types (such as DA levels and Ack interval) 
apply to the RMD at the service Endpoint.


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133