« | Home | »

Ten Years of SOAP

By Noah | May 17, 2010

Ten years ago today, at the 9th International Web Conference in Amsterdam, we held a panel discussion to introduce the SOAP networking protocol to the Web community.   Just a week before, the SOAP 1.1 specification had been posted as a W3C Note.   Many legitimate criticisms have been aimed at SOAP in the years since, but it and XML-rpc were big steps toward the creation of simple, data-driven Web applications, and toward the widespread availability of portable, standardized, information integration protocols.  A large number of SOAP implementations were built, almost immediately, for a wide variety of languages, and of course vendors such as BEA, IBM and Microsoft eventually provided very deep SOAP integration with their middleware stacks.

Although I am pleased about the positive impact that SOAP has had, I am also frustrated about how it turned out.  I always hoped we could build a stack that would be portable (we mostly achieved that), and that would scale comfortably from use in the smallest and simplest scriptable Web clients, to reasonably sophisticated enterprise applications.   The hope was for a system that could be used for highly secure, asynchronous, streamed communication between enterprise applications, but that could also be accessed from a single line of Javascript or PERL script to make simple queries or updates to those same applications, and that would integrate smoothly with the Web and with REST.

Unfortunately, SOAP was ultimately positioned at the base of a stack that is far too complex to be appealing to the sorts of communities that now, for good reason, gravitate toward JSON-over-REST.  Whether XML could ever have been a good base for such simple applications is an interesting question, but a serious effort was never really made.  WSDL, WSA, and WS-Security were from the start complex, heavyweight technologies that fit best into systems built using sophisticated tooling.

SOAP and the associated WS-* standards are indeed widely used today in conjunction with systems like Websphere and .Net, and I suppose that’s a good thing as far as it goes.   Conversely, REST is good for many things, but it doesn’t scale to high-end application-to-application communication.  I think we missed a chance to build something far simpler than WS-*, something that would have scaled from very simple to quite robust, and that would have achieved better consistency and integration for more users and more applications.

Nonetheless, SOAP was at least an important step on the way to building simple, data-driven Web applications, and perhaps it’s had some more success than that.  Either way, it’s been 10 years.

Topics: History of computing, Web, Internet, Computing | 3 Comments »

3 Responses to “Ten Years of SOAP”

  1. Mark Baker Says:
    May 18th, 2010 at 1:16 PM

    “REST is good for many things, but it doesn’t scale to high-end application-to-application communication”

    D’em’s fightin’ words! 😎

    Interested to hear why you believe that. I’ve been doing Web-scale m2m integration for several years now, and haven’t run into any big problems with it.

  2. Noah Says:
    May 18th, 2010 at 1:24 PM

    Hey Mark, good to hear from you!

    I guess what I’d say is: REST has lots of advantages and I’m not trying to say otherwise,. There are indeed many scenarios where it’s a good answer.

    There is, I think, lots that REST doesn’t try to do, and some of these things might be important in particular scenarios. To pick a few, not necessarily in priority order:

    * Application, as opposed to transport-level security. Yes, you can layer it on, but there mostly aren’t standards today. Used RESTfully, application/soap+xml is a standard for doing just that.

    * Durable queueing a la JMS, MQSeries/WebSphereMQ, etc.

    * Various sorts of full duplex asynchronous streaming (in many, many cases, it’s not needed, but one can certainly envision process control, telemetry, or perhaps high-end video applications in which it is…though I’ll admit that SOAP is a stretch for doing video for other reasons)

    To pick another example of something REST doesn’t do directly: I don’t think you’d want to build bittorrent out of HTTP. You might well want to layer a REST service on top of Bittorrent, but that’s different. I’m making the point that there are a variety of useful qualities of service that you might want, for which REST itself isn’t the right building block. For some of those, SOAP messages might be.


  3. Mark Baker Says:
    June 1st, 2010 at 2:00 PM

    Hey Noah.

    “There is, I think, lots that REST doesn’t try to do”. I fully agree, but I took your comment that I quoted to suggest that REST couldn’t be extended, i.e. that something about REST *prevented* scaling to large scale m2m.

    Also, your concerns seem to be more with HTTP and other Web technologies than with the REST architectural style itself. For example, message-level security done right is more RESTful than transport level security because it would be completely stateless.

    Anyhow, just wanted to clarify. Thanks.

Submit a comment:

Please press the submit comment button below to submit your comment for posting. All comments are moderated, so your comment will not appear until it has been reviewed. The blog owner reserves the right to decline to post any comment for any reason. Also, by pressing the submit comment button, you confirm your acceptance of the legal agreement below. Please read it before submitting your comment.

Legal agreement: by pressing the submit comment button you grant to Noah Mendelsohn a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute your comment contribution and derivative works thereof. Noah Mendelsohn reserves the right to republish such material in any form, though reasonable efforts will be made to retain the attribution to you. You also confirm that you have not knowingly violated copyright or other applicable laws pertaining to material that you have quoted or reproduced in your comment. (Note: if this agreement is not acceptable, an alternative is for you to post your comment on your own blog or other public Web site, and to post a link to that here. That way, you may retain more complete control of your own material.)