RE: MultipleHTTPConnectionEnabled extension for SOAP 1.1 and 1.2 + WSDL extension

Hello Alice,

 

Welcome to the world down the rabbit-hole.  You might be thinking to
yourself, "and what is the use of a book without conversations"  I'm the
Queen of Hearts, and I'd like to welcome to the maze world of meps and
bindings.  This is an abstract world where we build abstractions upon
abstractions, and debate the simplicity of our descriptions of
abstractions.  Humpty-Dumpty will be our guide.  He uses words, and the
abstractions or concepts they represent, mean what he means exactly when
he says them, no more no less.  We will see if we can make meps and
bindings mean one out of so many different things.  Though we have to be
careful of the meps, they're the proudest -- schemas you can do anything
with, but not meps.

 

Back to our abstraction reality...

 

Hi Umit,

 

This binding seems incomplete.  It appears to only specify the behaviour
of a single sending and receiving soap node, and says that a 200 or
4/5xx is returned.  As it stands, this is effectively what I proposed in
the SOAP one-way binding.  There is some wording about opening a
separate connection (ie 4.1.1.2), but you don't specify the extra node
and state machine.  That is the bulk of the work if you want 2 http
connections.  If I send a "ReplyTo" address, the connection is opened to
some other node.  Now part of the abstraction fun begins in what to call
it, and by "it" I mean the "other node" that we all know what I mean.
There is a "SOAP Response" message that is flowing between the "SOAP
Responder and ?"   Is it a SOAP Response Responder?  Remember that the
"SOAP Response Responder" (or whatever) will have a similar state
transition diagram to the "SOAP Responder"

 

FWIW, this is one of the joys of the use of 2 one-way meps and a one-way
binding is that new node names and stds don't have to be created.  

 

You are also missing perhaps the fundamental biggest questions in the
state transition diagrams: when can the responder open the 2nd http
connection and when can it respond on the first?  This applies to Faults
and to Responses.  The words of 4.1.2.2 are critical.  The implication
of the words as written are that a SOAP responder must wait until it has
completely received the message before sending the acknowledgement AND
opening the 2nd HTTP connection.  I don't think that is nearly the
intent of the async tf.  For example, we've talked about sending Faults
over the original connection if the WS-A FaultTo header isn't
understood, and this is precluded by the current words. 

 

FWIW * 2, this is one of the joys of the use of 2 one-way meps and a
one-way binding is that the split between the responding over the first
connection vs responding over a 2nd connection is completely left out of
scope.

 

Some other questions:

 

- umm.. "This binding extension of SOAP to HTTP is intended to make
appropriate use of HTTP as an application protocol." but then you drop
support for HTTP GET.  From a "use GET and HTTP as a transfer protocol"
perspective, this binding is worse than the SOAP HTTP binding.  

- 4.1.1.2 Receiving state says that the status line can be 2xx, yet
earlier you said 200.  

- 4.1.1.2 lists 3xx.  You only mention 200 and 4/5xx earlier, did you
mean to keep this?  

- 4.1.1.2 says "Start making an abstraction of the response message
available in http://www.w3.org/2003/05/soap/mep/InboundMessage ." do you
mean "OutboundMessage"?

- 4.1.2.1 Seems like you are wanting to remove GET

- 4.1.2.2 indeed, what is the mime type of the empty response?

 

Cheers,

Dave

 

  _____  

From: public-ws-async-tf-request@w3.org
[mailto:public-ws-async-tf-request@w3.org] On Behalf Of Yalcinalp, Umit
Sent: Wednesday, May 25, 2005 12:54 AM
To: public-ws-async-tf@w3.org
Subject: MultipleHTTPConnectionEnabled extension for SOAP 1.1 and 1.2 +
WSDL extension

 

Folks, 

Please find proposals for both SOAP 1.1 and SOAP 1.2 extensions for HTTP
binding. It is a zip file that contains SOAP extensions for both
transports, WSDL extension and some diagrams.  Since some mail systems
reject this, the file extension is .uzip. David, I humbly stole your
excellent diagrams/sample messages for this proposal. :-) 

SOAP 1.1/HTTP extension is a joint proposal from Oracle/SAP. 

SOAP 1.2 extension is something that I have crafted rather hurriedly
this week, therefore it did not get much review. Apologies in advance
for the gross omissions/mistakes that are made for SOAP 1.2 extension. I
just wanted to get this on the table for discussion/agreement so that we
can have something solid to discuss. I would appreciate the help of SOAP
1.2 folks for formulating a better writeup/fixing bugs. 

The only Transmission primitive/MEP that is being affected by the
proposed extension is request-response or in-out. Therefore the others
are omitted. SAP believes that we still need to define a SOAP in only
MEP for SOAP 1.2 which is independent of this proposal. 

The proposal covers only SOAP xx/HTTP bindings and how the behaviour is
modeled to accommodate multiple HTTP connections, hence the name. We
chose a rather long name just to be clear about the semantics. This
extension is only about HTTP, not any other transport so it has a rather
narrow, but necessary scope that is covered by WSDL and WS-Addressing. 

We thought that there are three different use cases that need to be
addressed by indicating the extension we specify in WSDL in conjunction
with WS-Addressing:  

Scenerio 0: WS-Addressing is in use, but MultipleHTTPConnectionEnabled
extension is not specified in WSDL. The SOAP/HTTP binding is assumed to
be syncronous as we know to exist today. Separate HTTP connections are
not used. 

Scenerio 1: MultipleHTTPConnectionEnabled extension is specified and
used with wsdl:required = "true". This means that the separate HTTP
connections must be used, replyTo specifies the address for the second
connection. If the client is not capable of using this extension, the
semantic of wsdl:required = "true" applies. The client in this case can
not communicate with the service. 

Scenerio 2: MultipleHTTPConnectionEnabled extension is specified and
used with wsdl:required = "false". The client can communicate with the
service regardless of whether it understands the
MultipleHTTPConnectionEnabled extension or not. If the 

client does not use this extension (or does not understand it -- it is 
not relevant which) then separate HTTP connections are NOT used. If it
does use this extension  (and of course understands it) then separate
HTTP connections are used. 

The bottom line is that service will support both. 

I did not recraft the semantics for WSDL extension as the usage and the
intent for SOAP 1.1 and SOAP 1.2 is similar in the second proposal. 

Personally, whether we call this an extension versus a new SOAP binding
or the appropriate namespace for the extension (how to name the beast)
is a secondary problem. I would prefer that we don't concantrate on
this, but rather the semantics of what we propose in order to move on to
describe a new SOAP input MEP as the next step. 

SAP wants to make concrete progress in the async task force and hence we
think that detailed proposals are the only way to proceed.
Corrections/counter proposals/friendly amendements are most welcome. 

Thanks. 

--umit 

<<MultipleHTTPConnectionEnabledProposal.uzip>>