Re: [wsrm] Problems in Section 5.2

[Tom Rutt <tom@coastin.com>]

WSDL allows a soap binding to bind message parts to the soap header.

If by doing this, a producer can use the request reply pattern even 
though they have no consumer originated
response payload, then they should be able to.

This does not mean that they are required to explicity expose ws 
reliability elements as message parts,
but they should be allowed to.



Tom Rutt

Jacques Durand wrote:

> Tom:
>
> I'll try to address some of these points by Monday,
> but so far I believe that WSDL descriptions should not be concerned 
> with RM headers...
>
> See inline,
>
> Jacques
>
> -----Original Message-----
> From: Tom Rutt [mailto:tom@coastin.com]
> Sent: Thursday, June 17, 2004 1:04 PM
> To: wsrm
> Subject: [wsrm] Problems in Section 5.2
>
>
> 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.
>
> <JD> If you mean by "describe", some typing in WSDL,
> I believe we should not need that. Shouldn't the SOAP model precisely 
> render
> these headers transparent to the service description?
>
> 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.
>
> <JD> I think we can describe what are the right combinations
> of (SOAP binding, underlying MEPs, reply patterns) that are *required* by
> BP compliance (not necesarily *sufficient*) When and if WSDL is used, it
> would have to follow additional requirements that are more 
> service-dependent
>
>
> 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.
>
> <JD> Before bringing in additional restrictions, I think a clearer
> mapping of (1) how the WSDL op types map to RMP operations, (2) how these
> RMP operations (and their usage patterns) map to underlying protocol,
> would help clarify the discussion. This was not so critical before we 
> introduced
> the Respond/Notify channel, but now is.
> I'll draft something on that.
>
> 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.
>

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