Loading ...
Sorry, an error occurred while loading the content.

5221Re: xml protocols and transport bindings

Expand Messages
  • allenjswa
    Feb 1, 2002
    • 0 Attachment
      > > I have also seen people successfully bind SOAP to SMTP, again not
      > > 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?

      I think you miss the point -- people *do* interoperate using SOAP
      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 the

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

      No 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 employers
      > happened to have installed. Optimistically, SOAP is two years away

      I don't get your point -- have you ever tried to write a POP3/IMAP
      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!)
      > Pessimistically it will take much, much longer because of all of

      You *do* seem very pessimistic. The thing I find strange, though,
      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 other
      > transports...and in different message patterns....

      Yes, but hopefully we will do it one step at a time, rather than
      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.
    • Show all 20 messages in this topic