OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] i021; proposal around option 3


Title: [ws-rx] i021; proposal around option 3

Gil:

 

I like your solution, and in fact I had proposed something very similar in the past (on my 10/13 email ;-) but did not push it for lack of interest:

>...get rid of the RMAssertion container as we know it.

>Replace it with RMSAssertion and RMDAssertion. Each one of these will be container for assertion items that concern

>respectively the behavior of a Source and of a Destination endpoints, relative to a sequence.

 

- your RMInbound could also be named RMDAssertion (in my outline) as it concerns the endpoint in an RMD role.

- your RMOutbound could also be named RMSAssertion (in my outline) as it concerns the endpoint in an RMS role.

 

Yours are more intuitive,  so go for it.

 

A few remarks:

- now that most protocol parameters have been removed, there does not seem to be much left to put in RMOutbound / RMSAssertion.

- the meaning of asserting a policy for outbound (endpoint in RMS role) could be (a) that outbound messages must be handled reliably by WS client (b) that in addition, if any parameters are there they should also be used by client if relevant to client acting as RMD? (I'd prefer instead (a) and that a separate policy concerns the Client acting as RMD, e.g. for AI)

- As I mentioned before, the ultimate best solution here might be to keep a single assertion container and make use of a role attribute if WS-Policy had one, that would qualify an attachment (e.g. as source or as destination) but there is no such thing in Policy.

 

Jacques

 


From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent: Thursday, December 15, 2005 11:19 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] i021; proposal around option 3

 

Issue: http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i021

This proposal addresses the issue by splitting the current <wsrmp:RMAssertion> into two separate assertions:

<wsrmp:RMInbound [wsp:Optional="true"]? ... >
    <wsrmp:AcknowledgementInterval Milliseconds="xs:unsignedLong" ... /> ?
    <wsrmp:MaxMessageNumber Number="xs:unsignedLong" ... /> ?
    ...
</wsrm:RMInbound>

and

<wsrmp:RMOutbound [wsp:Optional="true"]? ...>
    ...
</wsrmp:RMOutbound>

Note that <wsrmp:RMInbound> preserves the configuration parameters currently contained in <wsrmp:RMAssertion>.

To indicate that RM is required for inbound messages only you might use something like the following policy (note: same as current example in WS-RM Policy)

<wsp:Policy wsu:Id="MyPolicy" >
    <wsp:ExactlyOne>
        <wsrmp:RMInbound>
            <wsrmp:AcknowledgementInterval Milliseconds="200" />
        </wsrmp:RMInbound>
    </wsp:ExactlyOne>
</wsp:Policy>

Note this proposal does not change the current specification with regards to supported policy attachment options (Endpoint Policy Subject; wsdl:binding or wsdl:port).

To indicate that RM is required for both inbound and outbound messages you might use something like the following policy:

<wsp:Policy wsu:Id="MyPolicy" >
    <wsp:ExactlyOne>
        <wsrmp:RMInbound>
            <wsrmp:AcknowledgementInterval Milliseconds="200" />
        </wsrmp:RMInbound>
        <wsrmp:RMOutbound />
    </wsp:ExactlyOne>
</wsp:Policy>

Obviously you can use combinations of these assertions and the wsp:Optional attribute to indicate many different policy combinations such as:

    • an endpoint requires RM for inbound messages and supports the optional use of RM for outbound messages
    • an endpoint does not support RM for inbound messages but requires the use of RM for outbound messages
    • etc.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]