RE: What are web services good for? (WAS: RE: Two new features o f the Web)

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> Sent: Tuesday, August 21, 2001 10:11 AM
> To: Dave Winer; xml-dev@lists.xml.org
> Subject: What are web services good for? (WAS: RE: Two new features of
> th e Web)
> 
> 
> What are web services good for?  What are they not good for?
 

> I have this sense that some consider web services another 
> technology in  search of a problem to solve.  

I'm glad you posted this question ... I was about to do the same thing.
Irrespective of the details of SOAP, UDDI/WSDL/whatever, .NET ... why has
this become the "next big thing?"  As previous discussions have indicated,
"web services" are not all that much different from what people can do with
the Web today (OK, Web services are for machines, not people ...) and we've
been able to do remote procedure calls on Unix for decades, over COM/CORBA
for years ... what's the big deal?  Why do I see assertions such as "There's
little argument that XML Web services are the future of computing"
http://www.aspnews.com/trends/article/0,2350,9921_868321,00.html every time
I look at the trade press?

I have somewhat mixed feelings ...

Positive Answers:

"XML and HTTP makes cross-platform RPC feasible at long last": DCOM is
proprietary, CORBA too complex, SOAP (or XML-RPC, don't want to get into
that war) hits the sweet spot by offering just enough power to be useful
while leveraging the HTTP infrastructure and all the XML tools/knowledge out
there.

"SOAP is a more rational way to let others access your site than documenting
your URL voodoo": 

"We need Web Services to make wireless devices truly useful": There's no way
to have "fat client" or even conventional web-page applications run on a PDA
or cellphone or "smart car", nor is there enough bandwidth to dump entire
phonebooks/maps/documents on demand; the only way to work within the given
constraints is to do most of the work on the server and have a "thin"
application call for discrete chunks of pre-processed information on demand.


"It's better to call services than query for data in a distributed,
heterogeneous environment": I think it boils down to the database management
principle of "data independence" and the OO principle of "encapsulation" --
the best architectures expose the fewest details about the actual data
representation, and encourage data exchange via simple accessor methods
rather than transfer of data structures.  Again, XML helps find the sweet
spot because you can access a significant amount of information via a single
accessor call (all the more necessary in a high-latency, unreliable
environment like the internet or wireless internet) and pass it around in a
simple, universally-understood, somewhat self-describing format.  In
principle you could probably this with SQL and use relations as the
universally understood format ... but I can much more easily imagine sending
a SOAP message to an airline asking if I can have a seat on a particular
flight than I can imagine them letting me do a SQL query and update!  

Cynical Rantings:

"I need money, Honey": getting consumers and enterprises addicted to
subscription-based web services will provide a faster-growing and more
predictable source of revenue for the Big Guys.

"The bandwagon effect": Everybody else jumped on the Web Services bandwagon,
so we'd better ... we'll worry about where it is going after we get settled
on board. 

"It's the Next Big Thing because it's the Next Big Thing": Working out the
details of how the 2500 pages of W3C specs can actually work in the real
world is BOR-ing; it's more fun to fantasize and prototype than to debug and
solidify.