Problems in Section 5.2

[Tom Rutt <tom@coastin.com>]

Overview of problems needed to be Fixed in Section 5.2

Section 5.2 is called “reliability of WSDL operations”.

We need to clarify what this means.

We agreed a long time ago that we would not require wsdl for all 
implementations of this spec. At least we agreed that WS reliability 
features should be able to be added to existing WSDL descriptions of web 
services without changing the WSDL.

Well, this is what causes the seeming Conendrum. If we really want to 
talk WSDL speak, then we should describe the entire soap body, including 
our reliability header
Elements. If we did this, the use case Doug wants in 2b would be readily 
admitted.

One could take an existing wsdl, and transform it into a WSRM capable 
wsdl by adding the soap header elements as input and output parts of the 
wsdl operation, and wsdl binding them to the soap header. This should be 
clarified/ discussed in this section. When the user is not using the 
wsdl, it causes problems in trying to explain how the spec
Works in a BP 1.0 compliant manner (remember bp 1.0 requires wsdl). We 
have been thining of our header elements only as extension elements 
unaware to the user. Well this is what is causing some of our conceptual 
problems.

We need to discuss the simplifying limitation of the Respond primitive 
only being used to convey the immediate consumer initiated payload (not 
including the wsrm: response element of the soap header) to be conveyed 
in a wsdl operation output message. This will take it out of the one-way 
discussions.


 From Doug’s email:
2) Section 5.2 is completely about the producer / consumer interactions
though some of its text has been applied to the RMP use of an underlying
protocol. The matrix in section 5.2 states that all RM-Reply patterns
may be used with consumer-generated payload(s) or application responses
on the receiving RMP side. However, the callback and poll RM-Reply
patterns provide multiple opportunities to return payload information
(as they are currently described, see (1) above) and the specification
does not describe which option is recommended. Our new Respond
operation (possibly restricted to specific RM-Reply pattern choices)
must be mapped to the underlying protocol at least as far as timing is
concerned. We may also decide to further restrict when the consumer may
invoke the Respond operation.

Doug has hit a nail in a soft spot of our spec. I will explain further 
below.

2a) The sentence “However, an RMP is not requried to disinguish WSDL
operation types.” [please note new spelling errors] was introduced in
a recent edit to section 5.2, enshrining an assumption a few of the TC
had previously made. This assumption contradicts the complete control
an RMP has over the bits on the wire. The consumer may or may not
provide payload information (the consumer interface may be described
using either a request-response or a one-way operation type). Even if
the receiving RMP is only passing the information through, it must be
aware of when to wait for the consumer to invoke the Respond operation.
This sentence should be removed.

I think that if a user really does the complete WSDL to express what is 
going on with
WS-Reliability, the WSDL description of an operation would have an input 
message with a wsrm:request element as one part, and the request payload 
expressed as one or more additional message parts. The SOAP binding for 
this would bind the wsrm:request element to the soap header and the 
request payload parts to the soap body. The wsdl operation output 
message will have one part for the wsrm:response element, and (possibly 
) a response payload to be bound to the soap body of the underlying http 
response.

Now the Respond operation should be limited to the scope of the part of 
the output message which is bound to the soap body.

Note: that the use of the terms” one way wsdl operation” are confusing 
the issue here. The way I have described it above, the user can write 
the wsdl so that an operation without response payload, may carry a 
wsrm:response element in the soap header of the underlying http response.



Please respond with any comments/ suggestions.

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