Title: RE: [wsrm] Problems in Section 5.2
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:]
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.
