[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Discussion on Issue i006
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]