5221Re: xml protocols and transport bindings
- Feb 1, 2002
> > I have also seen people successfully bind SOAP to SMTP, again notI think you miss the point -- people *do* interoperate using SOAP
> > specified and not guaranteed to interoperate with anyone else who
> > makes up SMTP bindings, but it works just fine for what it's used
> > for.
> What's the use of standards that don't inteoperate?
over SMTP, *today*. So you say, "what's the use of standards
without interop"? And I am just saying, "it is possible to interop
without standards, and people are doing it". Of course it is better
to have a standard, and eventually that will happen. But don't
say "it will never work" or "the standard is broke" when the fact is
that there is no standard for that particular task, and people
happen to be accomplishing the task just fine.
> point-to-point interops. SOAP has massive interop problems and theThis sounds to me like "the sky is falling". I don't see
these "massive interop problems" that you talk about.
> reason you use a standard is to avoid those! Despite all of theNo doubt, but you yourself said that there are no standards for
binding to SMTP or MSMQ/MQSeries.
> pointing any email client at whatever POP server my employersI don't get your point -- have you ever tried to write a POP3/IMAP
> happened to have installed. Optimistically, SOAP is two years away
or NNTP client? You may be surprised to know that you can't just
follow the RFC and end up with a client that talks to most servers.
The fact that Eudora, Outlook Express, and etc. talk to most of the
servers out there is not a function of the client and server vendors
operating in a "black box" and ending up with interop. That is of
course the idea, but it's not exactly the way things turned out, so
unless you actually claim to be writing to those protocols from any
language rather than just consuming a library where someone already
did the work for you, I would say you are talking about something
totally different. Getting a client library to talk to a broad
range of POP3 or NNTP servers requires interop testing with all of
the major servers, period.
> level of interop on HTTP. (after all the spec isn't even done yet!)You *do* seem very pessimistic. The thing I find strange, though,
> Pessimistically it will take much, much longer because of all of
is that you seem to be arguing "it'll never work" about things that
are already working.
> optional features. And then we have to talk about using it on otherYes, but hopefully we will do it one step at a time, rather than
> transports...and in different message patterns....
expect one spec to cover every layer of the puzzle. SOAP is good
for what it does, and the HTTP bindings are good for what they are
designed for. I am sure we will see other uses evolve, especially
since one of the benefits of XML is to not be bound to a synchronous
RPC mechanism. But the fact that such bindings have not been
formalized strikes me as a *good* thing. Do you really think the
industry has enough experience with asynchronous XML-based web
services to be standardizing the "best way"? I would think that the
goal at this point would be to see what sorts of design patterns are
emerging, encourage experimentation, research implications of
various approaches, etc. If SOAP claimed to offer an out-of-box
architecture for XML-based asynchronous web services, I would be
quite skeptical. But to say that SOAP is an ideal message
serialization format for these services is not so far-fetched.
There are already many "experimental" async XML-based web service
frameworks that use SOAP quite happily.
There are many things that a system has to decide when basing
interop on async messaging. Things like long-running transaction ID
format, dialogue contracts, message flow, etc. SOAP is directly
concerned with very little of this -- the rest is done somewhere
else, using standards that are less stable (if even proposed) at
this point. Even at this layer, things like the biztalk and
rosettanet interop events show that the various frameworks *can*
interop, using SOAP as a lower layer. But admittedly getting broad
interop here is going to lag behind the interop that can be expected
in SOAP or XML-RPC.
- << Previous post in topic Next post in topic >>