- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Wed, 15 Jun 2005 21:34:24 +0200
- To: "David Hull" <dmh@tibco.com>
- Cc: "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, <public-ws-async-tf@w3.org>
- Message-ID: <2BA6015847F82645A9BB31C7F9D64165106866@uspale20.pal.sap.corp>
See comments inlined.
_____
From: David Hull [mailto:dmh@tibco.com]
Sent: Wednesday, Jun 15, 2005 12:19 PM
To: Yalcinalp, Umit
Cc: Anish Karmarkar; public-ws-async-tf@w3.org
Subject: Re: Proposal for Async Extensions
Yalcinalp, Umit wrote:
Let me understand this better:
- wsaw:ResponseBinding is only applicable when wsaw:UsingAddressing is
engaged, right?
Not necessarily. Anonymous response could be useful in other contexts.
[Yalcinalp, Umit] I am still not clear about this. You mean that with
your proposal you may have an anonymous response with a separate binding
for the response?
- There may be multiple ResponseBinding elements, each defining a
different binding option.
Yes.
- If this element is not present, we assume the actual binding is in
effect for the responses.
If it's not present, then you're left with either anonymous responses,
if the UTB supports it, or nothing, in which case the operation had
better be one-way.
- I would guess this proposal applies to only request-response. I could
not understand why this element would apply to specifically in-only case
per Section 3 of your document. Robust-in is another discussion.
It applies to all three. Where does it appear to say otherwise?
[Yalcinalp, Umit]
IMO, it does not. I don't understand the utility of it for one-way. If
there is a response for a one-way mesage, the response definition is not
going to be in the binding, it may be in some other document, some other
WSDL. We not only have to deal with the response message's binding, but
we need to account for the definition (schema) of the actual response
message. Allowing it for in-only does not make sense to me.
- Does the ResponseBinding element provide the same kind of granularity
that WSDL binding section would provide? This is a WSDL question. If so,
how. If not, why not. Maybe you did not think about this, or I missed
the subleties.
I'm not sure exactly what the question is, here. My concern is that,
for the binding of any particular operation, you can determine what
response channels are available.
[Yalcinalp, Umit] WSDL allows finer granularity to define binding
operations (which does not apply here), but specific binding related
information for message references. I am particularly interested in how
your proposal interacts with Section 2.12. of WSDL 2.0 specification [1]
when we start talking about responses. Currently binding applies to the
whole operation and what needs to be relaxed with your proposal. I was
trying to tease out the specifics in writing with respect to that
section.
Thanks.
--umit
-----Original Message-----
From: public-ws-async-tf-request@w3.org
[mailto:public-ws-async-tf-request@w3.org] On Behalf Of David Hull
Sent: Wednesday, Jun 15, 2005 11:41 AM
To: Anish Karmarkar
Cc: public-ws-async-tf@w3.org
Subject: Re: Proposal for Async Extensions
I left out wsdl:required here because I don't think it's really
applicable. Including a particular <wsaw:ResponseBinding> advertises
that you can send (non-anonymous) responses through that binding. If
you want to say that you only support HTTP for responses, you include
only the one response binding element. If you provide more than one
response binding element, then you're saying you'll accept response
endpoints using any of those bindings. In other words,
there's no sense
in providing more than one response element and singling out one as
wsdl:required, and if there's only one response binding, then
wsdl:required would be redundant.
Does that make sense?
Or (re-reading) did you mean that wsdl:required would mean that
anonymous responses aren't allowed? If so, I would prefer to use some
other marker for that situation. For example, what would this mean:
<wsaw:ResponseBinding
wsdl:required="true">http://www.w3.org/2003/05/soap/bindings/H
TTP/<wsaw:ResponseBinding>
<wsaw:ResponseBinding
wsdl:required="false">http://www.w3.org/@@@@/@@/soap/bindings/
some-other-binding/<wsaw:ResponseBinding>
Anish Karmarkar wrote:
Question:
The example binding in the write-up is:
<binding name="operation name">
<wsaw:UsingAddressing required="true"/>
<wsaw:ResponseBinding>http://www.w3.org/2003/05/soap/bindings/
HTTP/<wsaw:ResponseBinding>
...
</binding>
i.e. wsdl:required="false" for the wsaw:ResponseBinding element.
What happens if wsdl:required="true" attribute is present on
wsaw:ResponseBinding element? I assume that this means that
a separate
HTTP connection MUST be used for the response. Right?
-Anish
--
David Hull wrote:
Attached please find a proposal for extensions for handling
asynchronous behavior. This was an action item of mine from last
Wednesday's call.
I believe the attached proposal has several advantages
over previous
proposals, namely:
* No new SOAP MEPs are needed to handle asynchronous
messaging over
two-way transports.
* Given that messaging over a one-way transport simply
means sending
a message, which any binding must be able to do,
there may be no
need for a "one-way SOAP MEP" at all.
* Little if any change is needed to the existing HTTP
SOAP binding.
* Acknowledgments may be explicitly correlated via
[message id] and
may carry any other needed information.
* There are precise and complete rules for what combinations of
addressing headers are allowed in what circumstances.
* The [response binding] element covers the "Multiple
Connection
HTTP" use case as a special case.
* Other bindings with backchannels are straightforward.
* It includes Tony's Timeline explicitly, addressing
concerns about
when faults may or must be sent on the backchannel.
We may want
to tone down some of the statements made in this
section, but this
can be done without disturbing the rest of the rules.
* It's short. Most of the bulk is illustrative examples. The
normative material runs to a page or two.
--------------------------------------------------------------
----------
Extensions for Asynchronous Message Exchange
1 SOAP Bindings
1.1 Anonymous Response feature
SOAP bindings MAY support the /anonymous response/ feature. Such a
binding MUST provide a means of sending a reply directly to the
sender of a given message, independent of the contents of the SOAP
message itself.
1.1.1 Response Correlation property
Bindings which support the anonymous response feature MAY provide a
means of correlating responses with the message to which they are
responding, independent of the contents of the SOAP
message itself.
In such a case, the value of the /response correlation/
property for
that binding is /true./ Otherwise it is /false/.
1.2 Marker message
An endpoint receiving a SOAP message (other than an anonymous
response) using a binding which supports the anonymous response
feature MUST produce a SOAP response to the sender, as per the SOAP
request-response MEP. If the endpoint does not respond
with a fault
or an application-level response, it MUST indicate that no further
response will be sent on the anonymous response channel,
by sending a
message with an [action] property of
http://www.w3.org/@@@@/@@/addressing/marker. This message MAY also
have any other content, as appropriate.
Bindings MAY provide optimized means of transferring
particular forms
of messages with this [action].
2 WSDL Extensions
2.1 Response Binding element
WSDL binding elements MAY include zero or more [response binding]
child elements. The value of such an element MUST be an
IRI denoting
a SOAP underlying transport binding. This infoset item is
represented as an element with QName |wsaw:ResponseBinding|.
2.2 Using Addressing element
WSDL binding elements MAY include zero or one [using addressing]
child elements. If this element is present, the operation MUST
follow the rules specified in the WS-Addressing Core, SOAP Binding
and WSDL Binding specifications. This infoset item is
represented as
an element with QName |wsaw:UsingAddressing|.
3 Interaction with WS-Addressing
The following uses the WSDL 2.0 names for MEPs, with the
understanding that the same considerations apply in the context of
WSDL 1.1. This section applies only to the in-only, robust in-only
and in-out MEPs.
3.1 Supported Response Bindings
For any given operation, the set of /supported response bindings/
contains all, and exactly all, of the following IRIs:
* The IRI
|http://www.w3.org/@@@@/@@/addressing/anonymous|, if the
transport binding for the operation supports the anonymous
response feature.
* The values of all [response endpoint] children of the binding
element
Unless the operation is in-only, this set MUST NOT be empty.
3.2 Compatibility of endpoints and supported
response bindings
For a given /in /message in a WSDL MEP the set of /response
endpoints/ is
* The empty set in an in-only MEP
* The set {[fault endpoint]} in a robust in-only MEP.
* The set {[fault endpoint], [response endpoint]} in
an in-out MEP.
All response endpoints for a message MUST be compatible
with exactly
one of the supported response binding IRIs for the operation. Note
that this is automatically true for an in-only operation. An
endpoint is compatible with a binding IRI if
* The [address] of the endpoint and the binding IRI are both
|http://www.w3.org/@@@@/@@/addressing/anonymous|
* The binding specified by the binding IRI provides a means of
sending a message to the [address] of the endpoint.
An endpoint receiving a message with incompatibly
specified response
endpoints MUST attempt to fault if an anonymous response channel is
available, as per section 3.3 below.
3.3 Faults and the anonymous response channel
An endpoint supporting the anonymous response channel may encounter
errors at various stages in processing the message.
* If such an error occurs before the [fault endpoint]
property is
found to be valid, or the [fault endpoint] property
is valid and
has the [address]
|http://www.w3.org/@@@@/@@/addressing/anonymous|,
the endpoint
MUST attempt to send an appropriate fault on the anonymous
response channel.
* Otherwise (i.e., the [fault endpoint] is valid and
is not directed
to the anonymous response channel)
o If the error occurs while the responding
endpoint is in the
/receiving/ state (i.e., it has not yet begun to send a
response, and no failure has occurred), the
endpoint MAY
attempt to send a fault on either the
anonymous response
channel, or to the [fault endpoint], but MUST
attempt to
send a fault.
o If the error occurs while the responding
endpoint is in the
/sending, fail/ or /success/ state, the endpoint MUST
attempt to send a fault to the [fault endpoint].
3.4 Message ID
In addition to any requirements placed by the WS-Addressing
specifications, an /in/ message SHOULD contain a [message id]
property if the [address] of at least one response endpoint is not
|http://www.w3.org/@@@@/@@/addressing/anonymous|.
1 Existing bindings
Authors of new underlying transport bindings are encouraged to
specify whether the binding supports the anonymous
response feature,
and if so, the value of the response correlation property and any
optimizations for marker messages. The following supplements the
existing SOAP/HTTP binding by supplying this information for it.
1.1 SOAP/HTTP
The SOAP/HTTP binding supports the anonymous response feature with
response correlation /true./ The anonymous response channel is
simply the normal HTTP response mechanism. An HTTP response with
status code 202 (Accepted) and no SOAP body is equivalent to a SOAP
response with an [action] property of
|http://www.w3.org/@@@@/@@/addressing/marker|, no other headers and
no body.
The practical consequence of this is that a WSDL binding with
|transport="http://schemas.xmlsoap.org/soap/http"
<http://schemas.xmlsoap.org/soap/http> |and| a
<wsaw:UsingAddressing> |element present will follow the rules given
in sections 1-3 above, as illustrated in the non-normative examples
in section 5 below.
2 Non-normative examples
2.1 WSDL Fragments
These examples illustrate three operations: An in-only /Ping/
operation, a robust in-only /RobustPing/ operation, and an in-out/
EchoString/ operation. They are defined abstractly by:
|<operation name="Ping">|
| <input message="s0:PingMessageIn"/>|
|</operation>|
|...|
|<operation name="RobustPing">|
| <input message="s0:RobustPingMessageIn"/>|
|</operation>|
|...|
|<operation name="EchoString"> |
| <input message="s0:EchoStringMessageIn"/> |
| <output message="s0:EchoStringMessageOut"/> |
|</operation>|
|...|
For the purposes of this illustration, they are bound by:
|<binding name="operation name"> |
| <wsaw:UsingAddressing required="true"/>|
|
<wsaw:ResponseBinding>http://www.w3.org/2003/05/soap/bindings/
HTTP/<wsaw:ResponseBinding>|
| ...|
|</binding>|
This binding indicates that the rules specified by
WS-Addressing are
in effect, and that responses may be sent via an HTTP connection
separate from the one carrying the request.
2.2 Sample HTTP wire traces
2.2.1 In-only
HTTP request:
POST /wsaService/service.ashx HTTP/1.1
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://tempuri.org/ServicePortType/Ping</wsa:Action>
</soap:Header>
<soap:Body/> <soap:Body/>
</soap:Envelope>
HTTP response:
HTTP/1.1 202 Accepted
2.2.2 Robust in-only with anonymous [fault endpoint]
HTTP request:
POST /wsaService/service.ashx HTTP/1.1
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://tempuri.org/ServicePortType/RobustPing</wsa:Action>
<wsa:FaultTo>
<wsa:Address>http://www.w3.org/@@@@/@@/addressing/anonymous</w
sa:Address>
</wsa:FaultTo>
</soap:Header>
<soap:Body/> <soap:Body/>
</soap:Envelope>
HTTP response (if no fault occurred):
HTTP/1.1 202 Accepted
HTTP response (if a fault occurred):
HTTP/1.1 500 Internal Server Error
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
...
</soap:Header>
<soap:Body> <soap:Body>...</soap:Body>
<soap:Envelope> <soap:Envelope>
2.2.3 Robust in-only with non-anonymous [fault endpoint]
HTTP request:
POST /wsaService/service.ashx HTTP/1.1
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://tempuri.org/ServicePortType/RobustPing</wsa:Action>
<wsa:FaultTo>
<wsa:Address>http://www.example.org/fault</wsa:Address>
</wsa:FaultTo>
<wsa:MessageId>uid:SomethingUnique</wsa:MessageId>
</soap:Header>
<soap:Body/> <soap:Body/>
</soap:Envelope>
HTTP response (in all cases):
HTTP/1.1 202 Accepted
Outgoing HTTP fault message (if a fault occurred):
POST fault HTTP/1.1
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
<wsa:RelatesTo>uid:SomethingUnique</wsa:RelatesTo>
...
</soap:Header>
<soap:Body> <soap:Body>...</soap:Body>
<soap:Envelope> <soap:Envelope>
HTTP response to outgoing HTTP fault message (if a fault occurred):
HTTP/1.1 202 Accepted
2.2.4 In-out with anonymous [reply endpoint] and [fault
endpoint]
HTTP request:
POST /wsaService/service.ashx HTTP/1.1
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://tempuri.org/ServicePortType/EchoStringReque
st</wsa:Action>
<wsa:ReplyTo>
<wsa:Address>http://www.w3.org/@@@@/@@/addressing/anonymous</w
sa:Address>
</wsa:ReplyTo>
<wsa:MessageId>uid:SomethingUnique</wsa:MessageId>
</soap:Header>
<soap:Body> <soap:Body>EchoMe</soap:Body>
</soap:Envelope>
HTTP response (if no fault occurred):
HTTP/1.1 200 OK
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://tempuri.org/ServicePortType/EchoStringRespo
nse</wsa:Action>
<wsa:RelatesTo>uid:SomethingUnique</wsa:RelatesTo>
</soap:Header>
<soap:Body> <soap:Body>EchoMe</soap:Body>
<soap:Envelope> <soap:Envelope>
HTTP response (if a fault occurred):
HTTP/1.1 500 Internal Server Error
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
...
</soap:Header>
<soap:Body> <soap:Body>...</soap:Body>
<soap:Envelope> <soap:Envelope>
2.2.5 In-out with non-anonymous [reply endpoint] and
anonymous [fault endpoint]
HTTP request:
POST /wsaService/service.ashx HTTP/1.1
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://tempuri.org/ServicePortType/EchoStringReque
st</wsa:Action>
<wsa:ReplyTo>
<wsa:Address> http://www.example.org/reply</wsa:Address>
</wsa:ReplyTo>
<wsa:FaultTo>
<wsa:Address>http://www.w3.org/@@@@/@@/addressing/anonymous</w
sa:Address>
</wsa:FaultTo>
<wsa:MessageId>uid:SomethingUnique</wsa:MessageId>
</soap:Header>
<soap:Body> <soap:Body>EchoMe</soap:Body>
</soap:Envelope>
HTTP response (if no fault occurred):
HTTP/1.1 202 Accepted
Outgoing HTTP reply message (if no fault occurred):
POST /reply HTTP 1.1
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://tempuri.org/ServicePortType/EchoStringRespo
nse</wsa:Action>
<wsa:RelatesTo>uid:SomethingUnique</wsa:RelatesTo>
</soap:Header>
<soap:Body> <soap:Body>EchoMe</soap:Body>
<soap:Envelope> <soap:Envelope>
HTTP response to outgoing reply message (if no fault occurred):
HTTP/1.1 202 Accepted
HTTP response to request message (if a fault occurred):
HTTP/1.1 500 Internal Server Error
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
...
</soap:Header>
<soap:Body> <soap:Body>...</soap:Body>
<soap:Envelope> <soap:Envelope>
2.2.6 In-out with non-anonymous [reply
endpoint] and [fault
endpoint]
HTTP request:
POST /wsaService/service.ashx HTTP/1.1
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://tempuri.org/ServicePortType/EchoStringReque
st</wsa:Action>
<wsa:ReplyTo>
<wsa:Address>http://www.example.org/reply</wsa:Address>
</wsa:ReplyTo>
<wsa:FaultTo>
<wsa:Address> http://www.example.org/fault</wsa:Address>
</wsa:FaultTo>
<wsa:MessageId>uid:SomethingUnique</wsa:MessageId>
</soap:Header>
<soap:Body> <soap:Body>EchoMe</soap:Body>
</soap:Envelope>
HTTP response to request message (in all cases):
HTTP/1.1 202 Accepted
Outgoing HTTP reply message (if no fault occurred):
POST /reply HTTP/1.1
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://tempuri.org/ServicePortType/EchoStringRespo
nse</wsa:Action>
<wsa:RelatesTo>uid:SomethingUnique</wsa:RelatesTo>
</soap:Header>
<soap:Body> <soap:Body>EchoMe</soap:Body>
<soap:Envelope> <soap:Envelope>
HTTP response to outgoing reply message (if no fault occurred):
HTTP/1.1 202 Accepted
Outgoing HTTP fault message (if a fault occurred):
POST /fault HTTP/1.1
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
...
</soap:Header>
<soap:Body> <soap:Body>...</soap:Body>
<soap:Envelope> <soap:Envelope>
HTTP response to outgoing fault message (if a fault occurred):
HTTP/1.1 202 Accepted
2.2.7 In-only, headers needed in marker message
For various reasons, a SOAP marker message response may need to
contain SOAP headers beyond the <wsa:Action> header. In this case,
the response should be a non-optimized SOAP message, as shown here:
HTTP request:
POST /wsaService/service.ashx HTTP/1.1
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://tempuri.org/ServicePortType/Ping</wsa:Action>
</soap:Header>
<soap:Body/> <soap:Body/>
</soap:Envelope>
HTTP response:
HTTP/1.1 200 OK
<soap:Envelope> <soap:Envelope>
<soap:Header> <soap:Header>
<wsa:Action>http://www.w3.org/@@@@/@@/addressing/marker</wsa:action>
<myns:SomeHeader>...</myns:SomeHeader>
</soap:Header>
<soap:Body/> <soap:Body/>
</soap:Envelope>
Received on Wednesday, 15 June 2005 19:34:59 UTC