RE: XML Protocol: Proposals to address SOAPAction header

>> This is so simple.
I am trying to make it simpler.

>> 1. HTTP is a good way to do SOAP.
BEEP is a better way of doing SOAP. In a few years time I am sure someone
will come up with an amazing XYZ protocol which is even better again. We
want SOAP to work really well on all of them.

>> 2. If there's no header to go by, a router has to read the payload.
What about the URI? People are using SOAPAction for lots of different
reasons, as already discussed on this list.

>> 3. In a normal HTTP server much of the traffic is not SOAP.
With BEEP, we are sure that only SOAP messages will flow on a channel that
uses the SOAP profile. The transport connection is divided into logical
channels, and what flows along each channel is defined in a profile of
supported messages. If a channel using SOAP detects non-SOAP messages, it is
an error. Multiple channels can be running concurrently, some using SOAP and
others using different profiles, all on the same TCP connection (or whatever
pluggable transport service that is in use).

>> 4. In the real world, which I hope is what we're talking about, you
>> can't run the payload of a request through an XML parser. It's a
>> waste of CPU cycles.
In the real world, over the next ten years, SOAP will be flowing over very
many different application protocols, and it is an imperative that XMLP
works well on everything - especially at the seams, where different
application protocols meet.  Therefore it is really important to distinguish
what should be in XMLP itself (the SOAP envelope, etc.) and what is part of
a binding to a specific application protocol (HTTP headers go in the HTTP
binding). This group should be working on separate specs for XMLP itself and
one each for the different bindings, e.g. to HTTP.

>> 5. So we built systems up from SOAPAction.
The SOAP 1.1 spec says you can use SOAPAction, so there is nothing wrong
with your **SOAP 1.1** implementation supporting it. The SOAP 1.1 spec does
not say very much about SOAP over other application protocols. If you start
using multiple application protocols together, you are going to hit a
problem if you expect one binding to carry information specific to another
binding through it.
XMLP should clearly resolve problem.

>> 6. Don't break us.
XMLP/SOAP will probably be slightly different to SOAP 1.1 - and I imagine an
XSLT script or something similar will be provided to do a translation.

Received on Tuesday, 12 June 2001 04:28:14 UTC