WSDL can describe bindings of operations to many different
protocols, but most bindings are to SOAP.
SOAP can be transported across many different protocols, but
most SOAP messages are transported over HTTP.
Individual SOAP messages may have many different headers, but
most don't have any.
Each of the above statements is arguable, but one thing that is
undeniable is that a large number of people have
found "simple XML over HTTP" to be a sweet spot.
The end result is that people who use a SOAP Toolkit can't
access the eBay API.
I can hear Tim
Ewald now "but Soap Envelope and Soap Body are but a small
price to pay for future extensibility". That's nice, but
toolkits that insist on inserting these elements don't help those
who want to access eBay today.
Now, Imagine a SOAP 1.3 specification which is identical to SOAP
1.2 with exactly two changes:
If you ever want to send a message with zero headers, then you
are required to omit the soap:Envelope and soap:Header
In such a world, people who use SOAP 1.3 enabled toolkits would
be able to construct messages to be sent to eBay. If they are
so inclined, they could write schemas for such messages (in the
schema language of their choice). They could even wrap this
schema in WSDL, and share it amongst themselves.
All of a sudden, a class of developers would find eBay to be
"Web Service enabled". Without requiring any coordination or
changes with eBay.
Now, we are in a position to have a different set of
Now we (almost) get eBay. What
These requests require HTTP GET.
WS-Transfer's description of Get is the following:
There are no body blocks defined for a Get
Above, I talked about omitting soap:Envelope and soap:Body
elements when no headers are present, but what should one do if
there are no body elements? How about using HTTP GET in such
In fact, for compatibility with WS-Transfer, we could also
require the use HTTP GET if there is a single soap:Header which
contains a wsa:Action of GET.
All of a sudden, a class of developers would find Bloglines to
be "Web Service enabled". Without requiring any coordination
or changes with eBay.
Again, we find ourselves to be in a position to have a different
set of discussions.
One of the details I glossed over in the
eBay discussions above is that the eBay API
also defines some HTTP Headers. HTTP headers are simple
collections of token and string values. Modeling this as a
SOAP Header is a piece of cake. In fact, there
already is one.
There are other details, like status codes, that need to be
worked out, but the overall approach is to consider an
instead of the traditional inside-out approach that web services
has traditionally taken.
There are a couple of other issues. Automatically omitting
Envelopes will prevent interop with existing SOAP servers.
For this reason, it might make sense to consider this as a WS-HTTP
instead of a rev to SOAP itself.
Also, while adding any
mustUnderstand will cause existing eBay to crap out, adding any
optional headers will cause problems too. Getting this solved
will require a change to eBay, albeit a small one. There
isn't much that can be done to solve this, but allowing soap
requests to go out without any envelopes allows progress to be made
today, allowing advocacy for soap headers to take place in
Sam Ruby's approach to bridging SOAP and raw XML over HTTP
I've never been too big on SOAP. It's nice that there are lots of toolkit implementations out there, but for most of my projects, it just seems like overkill. Many developers joke about the acronym being an oxymoron, because SOAP can quickly lose its......
Sam talks about WS-HTTP, and where we could be with Web services and HTTP. Thanks for the mention of WS-Get Sam! I'm stoked that some folks were talking about this at sells-con. I shoulda been there... Sam mentions the use......
A thought or two on Sam Ruby's latest entry: I can hear Tim Ewald now "but Soap Envelope and Soap Body are but a small price to pay for future extensibility". That's nice, but toolkits that insist on inserting......
This makes too much sense, it could never happen. Adapt a standard to real world examples? Learn from actual usage patterns to determine what the standard should contain? C'mon Sam, this is too reasonable!
SOAP and REST Do Not Have to be Mutually Exclusive
From WS-HTTP talking about SOAP vs. REST style interfaces: WSDL can describe bindings of operations to many different protocols, but most bindings are to SOAP.SOAP can be transported across many different protocols, but most SOAP messages are transported over HTTP.Individual......
All this just because the layering got totally screwed up by the broken requirement of protocol independence? Egads. Time to check back with those first principles, me thinks. The SOAP response MEP, though not without problems, at least gets the...
(You can actually view the WSDL without logging in.)
The real problem for me isn't that we (or Web services in general) don't support SOAP, it's that the WSDL we generated using Axis only works on .NET and Java. Trying to get PHP or Perl to parse this WSDL it a bitch and a half. If you could throw some IBM resouces into fixing open source SOAP toolkits, (or someone else could arrange a similar effort), I would be a lot more interested in your SOAP story.
Right now, I have to jump through all sorts of hoops, including patching PEAR::SOAP, and that seems to defeat the purpose of SOAP.
WS-REST continued: do we need an HTTP Transfer SOAP binding and simplified WSDL?
The Web services and HTTP world are still way separate. Without getting into the politics, I wonder what it would take to get to a mixed world: where SOAP clients can “see” Web resources, and Web clients can “see” SOAP......
(I started writing this as a comment in Harry’s blog in conversation to this , and soon realized that it would be better off living here; plus it took on a life of its own as they are wont to do - and at the very least I have more room to type here...