Discussion on Issue i006

[Tom Rutt <tom@coastin.com>]

This email is intended to start discussion on the ws-rx issue i006

I006 - Source based delivery QoS policy assertion
http://lists.oasis-open.org/archives/ws-rx/200506/msg00055.html

Here is a more precise statement about the real issue at the core of i006

"How does the RM Destination know which level of Delivery assurance to 
associate with a received message?"

We can't just discard this question as only relevant to the 
implementation space, especially if the assumptions below are valid:

- I expect an RM Destination to handle concurrently several sequences 
associated with different delivery assurances (DA) (driven by different 
WS operation requirements, e.g. InOrder or not, but also by SLA 
requirements, given the cost / overhead of RM)
- Even if we assume that some DA is statically assigned to an endpoint, 
a layered implementation (see discussion below) of the RM destination 
component should not have to peak inside the message body or other 
headers to figure the DA. RM Header data such as Sequence ID should be 
sufficient.
- Assuming all messages within a sequence as associated with the same 
delivery assurance (DA) (assumed in WS-RM Policy), it is not clear how 
the RM Destination associates a new sequence ID with a DA, when 
answering a SequenceCreation request from the Source.


The following discussion items make a more detailed case for the above 
assumptions.

----------------------- (Example Use Case) -------------------
Example:
Lets assume there is some predetermined agreement of type 1) between an 
application sender and an application receiver.

Using the folowing example abstract interface definition:
Interface (Broker){
Operation Buy(in AccountNo, in StockName, in NumberOfShares):
Operation Sell(in AccountNo, in StockName, in NumberOfShares);
Operation UpdateInfo(in AccountNo, in CustomerAddress, in CustomerPhoneNo);
Operation query (in AccountNo, out SequenceOf {StockName, NumberOfShares}
}

Assume the agreements between application destination and application 
source include the following:
• The Buy and Sell operations need to be protected for guaranteed 
delivery, duplicate elim, and ordered delivery.
• The UpdateInfo operation only needs to be protected for guaranteed 
delivery (it is idempotent).
• The Query operation needs no reliability Qos.

Since it is more costly in resources to support ordered delivery (e.g., 
received messages must be held before delivery while waiting for receipt 
of prior message), there would be benefit in allowing three concurrent 
communication "sessions" between the same two sending and receiving 
endpoints:
• One which does not use ws reliable messaging
• One which uses a ws-reliable messaging sequence which supports ordered 
delivery, duplicate elimination, and Guaranteed delivery QOS
• One which uses a ws-reliable messaging sequence which supports only 
guaranteed delivery.

For this use case, the rm source should be able to request creation of 
two Reliability message sequences, one with all qos enabled, the other 
with only Guaranteed delivery enabled.

------ Additional Motivation regarding Layered implementation ---------

It might be worthwhile to explore and explain what layered 
implementation of RM means. Specifically,

(1) an RM layer that is implemented as an SOAP message handler 
(jax-rpc/Axis style) which is concerned only with dealing with WSRM SOAP 
headers. It is not necessarily aware of the higher level logic or the 
application requirements. Its job is to process the WSRM soap headers 
(on the receiving side), remove those headers and delivery the message 
to the application when all the delivery assurance semantics have been 
met. And add WSRM headers on the sending side to the SOAP payload and 
pass it down to the next header handler in the chain (perhaps a WSS 
handler).

(2) an RM layer that is implemented as a SOAP intermediary and serves 
multiple applications. The intermediary is not necessarily aware of the 
application logic or the semantics but needs to ensure that the RM 
delivery assurance semantics have been met. This is similar to the WSS 
intermediaries whose sole job is to encrypt/decrypt, and sign/verify 
messages.

The important thing to note is that when implemented in layers, on the 
receiving side, the WSRM layer processes (and removes) the WSRM headers 
and hands the message to the layer above (application). When the 
application receives the message it is not aware of things like sequence 
number to implement the delivery assurances. In such a case, the RM 
destination (i.e. the WSRM layer) has to implement the delivery 
assurances. This requires that the RM destination be aware of the 
delivery assurances for every sequence that it processes (possibly for 
multiple operations, multiple ports, multiple applications -- as it is 
implemented as a different layer or as an intermediary).

One can think of ways for the application to communicate what its 
requirements are in a implementation specific way to the RM destination
-- and that should not be prevented. But there is a case to be made that 
this is such a fundamental requirement which affects interop and 
application semantics that providing native support for this in the 
protocol is a low-hanging fruit and can be done by adding a minimal
(one) protocol element to the protocol. I.e. the cost/benefit ratio is 
very low.

Second issue to mention is that: in the argument against this, there 
seems to be an assumption that the sender is the client and the receiver 
is the service. This is not always true. Consider a out-only MEP of WSDL 
2.0 (or the notification transmission primitive of WSDL 1.1), the sender 
is the service and receiver is the client. In this case, the sender may 
in fact want to communicate to the receiver the QoS for the sequence and 
the application semantics may very well depend on the client 
implementing the right QoS. This is true for the 'response' part of a 
request-response MEP as well. This certainly can be implemented using 
some out of band policy negotiations (for which, a standard does not 
exist), but again, this is a big problem for interoperability which can 
be solved with very minimal increase in the protocol complexity.

Third issue is: what happens if the services advertises multiple QoS in 
its WSDL/Policy? I.e., it says that for Gold members it guarantees 
delivery but for Platinum members it guarantees ordered-delivery. OR it 
could say: I support 2 levels of QoS for which there is different 
pricing, I'll charge you based on which one you use -- please select 
one. Having the RM sender assert the QoS in the sequence creation 
message solves this problem.
[This is also an answer to the question of why would two clients request 
different QoS for the same operation]

Fourth issue is: WSRM is independent of WSDL or policy. In fact the 
sender and receiver may not be using WSDL at all. This was asserted in 
the WS-Addressing group (as a rational to create a new construct called 
EndpointReference instead of reusing a WSDL construct). In such a case, 
how does the RM destination figure out which QoS to implement before 
delivering messages to the Application receiver.



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