RE: Consequences of SOAP GET to Web Services?

> Eric,
> 
> On Sun, Jun 16, 2002 at 11:54:23AM -0400, Eric Newcomer wrote:
> > I don't see Web services succeeding by following either the 
> strict "align
> > with the Web" or "align with existing distributed computing 
> technologies"
> > but rather by finding a happy marriage, or a happy medium.  
> To me that's the
> > main challenge, and by going too much in one direction or 
> the other we can
> > just as easily fail.
> 
> Well, I agree strongly that the members of the WG have to take this
> journey for themselves, and I'm not intending to short circuit that
> trip.  But just as strongly, I believe that what they will find when
> they do this is that strictly aligning with the Web will do what they
> want.
> 
> Respectfully, I'd ask that you withhold judgement on which approach is
> best until it's clear what "align with the Web" means.

Whenever a new encapsulation/integration technology like Web Services comes along, a number of people start jumping through hoops trying to map their favorite underlying technology directly up through to the new level. They always end up failing because they failed to learn up front what many others before them learned the hard way on previous technologies. The lesson they're missing is that generally, neither the semantics nor the abstractions of the lower layers map cleanly through to the upper layers. Such mapping works trivially for trivial problems, but it becomes hopelessly complicated when you try to generalize it and automate it. (I wish I had a dime for everyone who's ever asked me how to automatically turn their C++ or Java objects into CORBA objects or EJBs, a quarter for the number of empty promises I've heard from those who say that they've come up with a way to automatically solve such problems, and a dollar for everyone I now hear making the same claims in the Web Services arena.) See [1] fora detailed description of some of the problems and issues in this space. A message from Mike Champion [2] laments the fact that this "middleware bridging" problem is so "labor intensive, fragile, and expensive," and expresses the hope that SOAP can help. Perhaps it can help, but it can't eliminate the problem. One simply cannot get away from the need for human beings to address and resolve mismatches of semantics and abstractions.

There are numerous websites in operation today that offer their services through the HTTP application protocol "interface" while implementing those services in a fully encapsulated manner in the back end via J2EE, CORBA, Microsoft technologies, scripting languages, databases, mainframes, etc. This obviously works, and works well, despite the fact that there's an obvious impedance mismatch between the HTTP way of doing things and the back-end ways of doing things. Arguments that state that Web Services architecture must resemble the architectures of these back-end technologies in order to be able to integrate with them are fully refuted by the existence and operation of the Web itself.

Eric's point about finding a middle ground is true. However, one does not find a middle ground by putting all the technologies involved into a bag and drawing them at random. In today's websites, some technologies are good only for the web side, whereas others are good only for the back end. One way to interpret Mark Baker's position is that the only thing that we know for certain that works on the web side of the Web Services equation is the Web itself, and so we should be looking there for the answers. The abstractions and semantics associated with the various back end technologies we know and love are known to work well only in the back end, not on the web. Simply assuming that they'll work on the web side of the equation is a huge assumption, and IMO a poor one at that. You are much more likely to reach a practical middle ground if you start out from a known working position.

--steve

[1] Vinoski, Steve. "Web Services Interaction Models, Part 1: Current Practice," IEEE
Internet Computing, May/June 2002, 6(3), pp. 89-91. <http://computer.org/internet/ic2002/w3toc.htm>.
[2] <http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0383.html>

Received on Monday, 17 June 2002 16:30:01 UTC