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] strawman proposal for delivery assurance in policyfor RM


Let’s just say I’m proposing a more direct mechanism.

When building the execution pipeline from a WS-Policy file it is easier to map a single assertion to

some execution module rather than reason over two assertions.

All the best, Ashok


From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: Wednesday, January 03, 2007 1:51 PM
To: Ashok Malhotra; Durand, Jacques R.; Christopher B Ferris; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] strawman proposal for delivery assurance in policy for RM

 

Are you suggesting a shortcut for:

 

<wsp:All> <wsrmp:AtLeastOnceDelivery/><wsrmp:AtMostOnceDelivery/></wsp:All>

 

--umit

 

 


From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
Sent: Wednesday, Jan 03, 2007 1:45 PM
To: Durand, Jacques R.; Christopher B Ferris; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] strawman proposal for delivery assurance in policy for RM

Jacques:

In addition to

AtLeastOnceDelivery --  implies 1 to N copies delivered

AtMostOnceDelivery – implies 0 or 1 copies delivered

 

Don’t we also need

 

ExactlyOnceDelivery – implies exactly one copy of message delivered

 

All the best, Ashok


From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: Wednesday, January 03, 2007 1:09 PM
To: Christopher B Ferris; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] strawman proposal for delivery assurance in policy for RM

 

Sorry for being late on this - Chris proposal below (Dec 7) appears OK to me, at least for DAs expressed within the scope of policy assertions. Here is some proposed defs for the minimal set of DAs being considered:

AtLeastOnceDelivery: When sending a message under this DA, one of the two following outcomes shall occur: either (1) the RMD has received the message and successfully delivered it to the AD, or (2) either the AS or the AD is made aware of a delivery failure.

(note: under which conditions the AS vs. the AD is notified, is left to futher tuning - also the meaning of delivery failure notification is left to implementations)

AtMostOnceDelivery: When sent under this DA, a message shall not be delivered more than once by the RMD to the AD. Message duplicates are identified by their Sequence ID and Sequence number.

(note: should we tolerate duplicate delivery provided a failure notification is done? I would prefer not, I think the spec provides the means for an implementation to NEVER deliver duplicates)

InOrder:  When sent under this DA, messages from the same sequence shall be delivered by the RMD in the same order they have been submitted to an RMS.

(note: the above def of InOrder allows for gaps in the delivery - different flavors of what kind of ordered delivery is tolerated can be defined on top of that)

Jacques

 

 

 


From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, December 07, 2006 1:35 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] strawman proposal for delivery assurance in policy for RM


Previous to the LC draft of the WS-Policy 1.5 - Framework spec, there was no means by which
you could include an assertion that had no client impact and/or on-the-wire manifestation. All assertions
had to be both understood and would manifest themselves in the interactions between the two
parties.

However, in the LC draft, the WS-Policy WG introduced a new attribute: wsp:Ignorable, of type boolean,
that could be added to an assertion to indicate that at the policy consumer's discretion, that assertion
could be omitted from consideration in the intersetcion algorithm. Thus, a service provider that
wanted to advertise a QoS capability of the service, sich as a delivery assurance, that in fact placed
no requirements on the part of the client, such that the client could choose to ignore it if it didn't
understand that assertion. Effectively, it is a means for the service prvider to advertise in its policy
"here is an assertion, but you don't need to do anything about it, or even understand it and you can
still interoperate with me".

One of the concerns that we had previously with regards to delivery assurances (DA) was that regardless
of what DA was, or was not inforce, the protocol was exactly the same in all cases. Thus, prior to the
changes introduced in the WS-Policy LC draft, there was really no means of defining a policy assertion
that could advertise a DA and also provide a means by which the client could choose whether it
wanted to consider it in the intersection.

Given that WS-Policy now has this new feature, and given the concerns that have been raised by
FIX and others, perhaps we might consider addition of policy assertions that reflected the semantics
of the DAs we previously had in the input specification, with a strong recommendation that service
providers leverage the wsp:Ignorable='true' attribute to allow for a client to omit the assertion from
consideration in the intersection algorithm.

e.g.

<wsrmp:ExactlyOnceDelivery wsrmp:InOrder='true|false' wsp:Ignorable='true'/>
<wsrmp:AtMostOnceDelivery wsrmp:InOrder='true|false' wsp:Ignorable='true'/>
<wsrmp:AtLeastOnceDelivery wsrmp:InOrder='true|false' wsp:Ignorable='true'/>

This approach would give the client (RMS) the choice as to whether to engage with the service
as it could use the policy intersection mode of 'strict' to ensure that it only interacted with
a service provider that supported RM and offered the DA it required. Alternatively, a client
that didn't care what the DA was at the service provider could use the lax mode of intersection
to omit the assertion from the intersection algorithm.

Considerations:
- only ONE DA could be advertised per service endpoint, as there is nothing in the message
that would indicate which was in play since the protocol operates the same in all cases. There is nothing
in WS-Policy that can enforce such a constraint (that an assertion be exclusive of others in any
alternatives in the policy statement). We would need to have a constraint like:

        A Policy statement MUST NOT contain more than one of the DA assertions in its collective
        alternatives. A Policy statement MAY include the same DA assertion in more than one alternative.

- Should probably provide guidance on use of the wsp:Ignorable attribute (e.g. SHOULD be used
unless the service is being deployed with knowledge that all consumers of the service will
both understand that assertion and be willing to include it in the policy intersection)

Thoughts?

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295



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