- From: Joshua Allen <joshuaa@microsoft.com>
- Date: Tue, 26 Mar 2002 09:41:07 -0800
- To: "Mark Baker" <distobj@acm.org>, "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
- Cc: "Tim Bray" <tbray@textuality.com>, <www-tag@w3.org>
> But the issue is *common practice* and *expectations* on the part of > developers. The vast majority of them, when sitting down to code with > I don't believe one can successfully evaluate the chances of success of > a particular technology without considering how people are using it. > That's why I don't personally expect SOAP to see much success. But that This is exactly opposite my experience. Before there ever was a SOAP, I spent much of my time visiting literally hundreds of customers who provide online services and evaluating their architectures. At that time, XML-RPC *was* around, but not a single customer I visited had heard of it (at least the ones I asked). However, a significant percentage of these customers were *already* using XML over HTTP as an RPC mechanism (I can think of at least 20 who were in *production*). The most common use case by far was for these companies to use this synchronous RPC over XML+HTTP as a way to aggregate services and interface with partners. I have also seen it used for intra-enterprise EAI. At that time, direct XML/RPC to end-user machines was unseen (by me), but I have seen it used now with the advent of SOAP. At that time, everyone rolled their own implementations, and there was little chance that the various implementations would have interoperated without lots of manual work. But people still saw benefit in it. In fact, other than people rolling their own state-management/object-persistence layers, this RPC via XML was probably the most common thing I saw people developing from scratch. So it is hard for me to believe that people won't be doing synchronous RPC over HTTP with XML. There are tons of places that are *still* doing this with layers that they wrote before they knew there was a standard. And many more have already deployed in production on SOAP 1.0. In my opinion, SOAP was already *way* behind the curve in addressing a "common practice", and the point of SOAP was to try to bring some better openness and RESTfulness to something that has already become a rampant situation. People are doing this with or without a standard, and to ignore this scenario is to ignore one of the most common scenarios out there that people are doing.
Received on Tuesday, 26 March 2002 12:41:24 UTC