[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal to progress beyond 1.01J
Proposal for more accurate WS-Reliability Model: Add a definition for the Respond abstract operation, as proposed by Jacques in 1.01J. Include the response conveyance as a potential part of the Notify operation, as proposed by Jacques. To maintain the design requirement that the RMP does not have to be aware of the WSDL for the payload, make invocation of the Respond operation optional for the Callback and Poll reply patterns. For these patterns, the Receiving RMP could just ignore the Respond invocation if it occurs , since it is totally in control of initiating the response with these two reply patterns. If a response is conveyed by the Respond operation it would be put in the underlying response to the reliable message request, but the Sending RMP would not have to deal with it, since it will get its reply thru a callback or a poll. For the callback and poll pattern the Receiving RMP response initiation would be independent of whether the respond primitive is invoked or not. However, if the response reply pattern is requested, there needs to be an added requirement that the Respond operation is invoked by the Consumer on the Receiving RMP. That would be the trigger for the Receiving RMP to add its soap header block with the reply to the soap response. For Duplicate elimination case, the Receiving RMP should be allowed to return a cached copy of the original Respond contents. This is desirable behaviour. If the Sending RMP had successfully received the first response and conveyed it to the producer, it could ignore the second response, or do other things dependent on the local implementation of the Notify primitive. If the response to the duplicate invocation is not available to the Receving RMP, then it can return an empty soap body with its ack reply for the duplicate. In the typical case, by the time the Sending RMP receives the second ack, it will have already delivered the response to its producer using the Notify operation. The receving RMP in this case can just ignore the ack response to the duplicate invoke, not caring that the body is empty. The only case which would be troublesome is when the original response was lost, say to a transport connection failure. The sending RMP would see the second empty body ack as the response for the original invocation and would deal with it in a manner specific to the implementation of the Notify operation on the sending sysem. This is a minimal fix which meets the needs of the specification, in my opinion. Comments please. Tom Rutt -- ---------------------------------------------------- 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]