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>>