Tom Rutt wrote:
If a web
service was going to clarify its use of WS-Reliability, it might also
want to have a second input part on the operation for the wsdl:request
element. This could be bound to the soap header in the soap http
binding.
This case and the case you mentioned in the previous mail (about
adding a output part and bind it
to a wsrm:response soap header) are perfectly valid if an User
desires to do so and neither our spec.
prohibits this case nor it can do it as it is an User's choice.
We did ponder on this many times before and decided that the spec.
won't mandate it and at the
same time doesn't explicitly prohibit it. If an User wants to do it,
he should be able to do it.
The case you mentioned in your previous mail, where in, an output
message with one part bound
to a SOAP Header to use the Response RM Reply pattern is also valid
but then again it becomes a
request-response operation w.r.t. WSDL because of the presence of the
output message definition
and hence was able to use the Response pattern.
I don't know how any one can use the Response RM_Reply pattern for a
one-way WSDL operation
which is what the NO cell represents in the table in section 5.2. I
think this is valid and I don't
think we should change it to Yes.
This
detailed use of WSDL shoulld not be disalllowed, and it can get thru
the BP 1.0 restrictions
Tom Rutt
Tom Rutt wrote:
Let me clarify:
Assume a WSDL description for a port type has an operation definition
with an input message with one part, and an output message which has
just just one part specified as a wsrm:response element. If the soap
/http post binding binds the input message part to the soap body, and
the output message part to the soap header, this is no longer a WSDL
one way operation. This explicit WSDL defintion would get thru the
criterea of the BP 1.0.
Tom Rutt
Tom Rutt wrote:
I just realized why we have this seeming
conendrum.
If we were really expressing what we are doing with the response reply
pattern, we would
have an extra return message part for our response element, and we
would soap bind it to the soap header.
Thus, strictly speaking, the way we are using soap for the response
reply pattern, would not be wsdl
one way, even the consumer' view of the wsdl is no return part for the
message.
JUST THE FACT that the rmp is acting above the soap processor means we
should have special wsdl
for our interactions, which would include the wsrm:response element as
a return message part of the operation,
bound to a soap header in the return.
Tom Rutt
Sunil Kunisetty wrote:
Tom Rutt wrote:
From the minutes of 6/14 meeting, My
comments new to this email start
with <ter> tag
"
2b) The one-way consumer interface and Response RM-Reply pattern
is the
most direct combination to reliably deliver one-way messages
from a
producer "hidden" behind a firewall. The matrix in section 5.2
should
not disallow this combination. While synchronous polling at
least
works, it always requires an additional round trip.
<ter> one of Sunil's objections to the above proposal is based
on the
BP 1.0 restriction.
I Quote from BP 1.0a of WS-I
"
5.6.10 One-Way Operations
There are differing interpretations of how HTTP is to be used when
performing one-way operations.
R2714 For one-way operations, an INSTANCE MUST NOT return a HTTP
response that contains a SOAP envelope. Specifically, the HTTP response
entity-body must be empty.
R2750 A CONSUMER MUST ignore a SOAP response carried in a response from
a one-way operation.
R2727 For one-way operations, a CONSUMER MUST NOT interpret a
successful
HTTP response status code (i.e., 2xx) to mean the message is valid or
that the receiver would process it.
One-way operations do not produce SOAP responses. Therefore, the
Profile
prohibits sending a SOAP envelope in response to a one-way operation.
This means that transmission of one-way operations can not result in
processing level responses or errors. For example, a "500 Internal
Server Error" HTTP response that includes a SOAP message containing a
SOAP Fault element can not be returned.
The HTTP response to a one-way operation indicates the success or
failure of the transmission of the message. Based on the semantics of
the different response status codes supported by the HTTP protocol, the
Profile specifies that "200" and "202" are the preferred status codes
that the sender should expect, signifying that the one-way message was
received. A successful transmission does not indicate that the SOAP
processing layer and the application logic has had a chance to validate
the message or have committed to processing it.
Despite the fact that the HTTP 1.1 assigns different meanings to
response status codes "200" and "202", in the context of the Profile
they should be considered equivalent by the initiator of the request.
The Profile accepts both status codes because some SOAP implementations
have little control over the HTTP protocol implementation and cannot
control which of these response status codes is sent.
"
<ter> the requirements seem tied to HTTP transport binding for
SOAP,
rather than to SOAP in general. However the first two sentences of
explanatory text is written regarding Soap in general.
"
The BP requirement may be tied to Http, but as I mentioned umpteen no.
of times
on the call and as_ always you keep interrupting me without listening
completely,_ I was
saying that the abstract part of the WSDL one-way operation prohibits
a response.
Infact, let me re-quote a snippet from what you quoted:
" *One-way operations do not produce SOAP responses. *Therefore,
the Profile
prohibits sending a SOAP envelope in response to a one-way
operation.
This means that transmission of one-way operations can not result
in
processing level responses or errors."
Let me also cut-and-paste the snippet from the WSDL 1.1 spec.
regarding the
one-way operation:
/2.4.1 One-way Operation/
/The grammar for a one-way operation is:/
/<wsdl:definitions .... > <wsdl:portType .... > */
/ <wsdl:operation name="nmtoken">/
/ <wsdl:input name="nmtoken"?
message="qname"/>/
/ </wsdl:operation>/
/ </wsdl:portType >/
/</wsdl:definitions>/
/The input element specifies the abstract message format for
the one-way operation./
Note that there is no output or fault definition for a one-way
message.
What BP did is re-inforcing what is said in WSDL 1.1 spec. and
clarified what to do in Http case
as the latter is request-response transport.
What I'm still not clear on Doug's issue 2(b) is how to employ a
Response RM-Reply pattern
for a one-way WSDL operation.
I fully understand and agree that usage of word MEP in section 5.2 is
misleading and corrected.
I also agree that one-way consumer interface MAY be mapped to a R-R
binding/operation and
thus CAN be used with a Response RM_Reply pattern.
But, section 5.2 is NOT about Consumer interfaces, rather WSDL 1.1
operation types.
With that context, I don't see anything wrong with that table.
I don't see how the combination of one-way consumer interface and
Response RM-Reply pattern
is the most used one. To me this is the least used one as most likely
a one-way consumer interface
will be mapped to a one-way WSDL operation and hence a one-way
binding. I'd assume Callback
pattern to be the most commonly used pattern in that scenario.
-Sunil
