Thoughts on Web Services

These are some excerpts to a response to questions posed by Clay 
Shirky as part of a research report he is doing for O'Reilly on 
Web Services.

...

>   Web Services are an attempt to do for computing what the Web itself
>   did for publishing: to create a simple, loosely coupled method for
>   two arbitrary applications to communicate with one another.

The key is loosely coupled. One of the big wins for the Web is 
that it is "Minimally Constraining". While folks like me like to 
go around and to do the Right Thing, at the end of the day the 
Web puts very few constraints on what you use it for. A lot of 
its power stems from this fact, and folks doing Web Services are 
right to keep this in mind.

>   Web Services are an attempt to define XML interfaces for
>   applications and business processes that can be exposed over the
>   internet.

I'm not sure that XML is a key part of this definition. 
Obviously XML is going to be a very popular way to do this, but 
I think the key is machine-processable, or structured data, 
rather than specifically XML.

>   Web Services are applications that have SOAP interfaces accessible
>   via http.

No!

> In your view, how prevalent will this consensus stack become? Are
> there any layers at which alternative technologies will be able to
> co-exist better than others? Are there any layers where there will
> need to be a single industry-wide standard? Are there any layers still
> missing?

The stack that I prefer is missing:

Decentralized Discovery
RDF Schemas / Web Ontology / DAML-S
RDF
HTTP

The stack we have now is too close to lock-in for my tastes. 
It's too difficult to translate between SOAP interfaces, WSDL 
seems to focus too much on structure than on content, and UDDI 
sounds like a central point of control and failure. The RDF 
solution seems to be the most minimally constraining, as well as 
the one that seems best for preventing lock-in. Unfortunately, 
it's clearly not the most popular.

It is my fervent hope that we can build this system without 
lock-in and choke-point control.

An important layer, which I haven't seen tackled yet is "Trust". 
In a world with thousands of Web Services providing data, 
machines will need to know who they can trust. I think trust 
metrics are an important part of this.

Systems will also need logic. Right now business logic exists in 
code, on the systems that run the Web services, but in the 
future portions of it will be made public, and will be part of 
the Web like any other kind of data. One example of this is 
XSLT. Web services and clients will be able to use this logic to 
deduce new things that they couldn't derive from a simple RPC 
question and response.

With all these deductions a mechanism of Proof will be needed to 
verify they are true and to demonstrate this to other systems.

As you can see, there is fertile space to grow in both alternate 
stacks, more layers to throw on the stack, and best of all, 
interesting applications to take use of the technology.

One example of the layering of these pieces is in Tim Berners-
Lee's diagram of the Semantic Web, of which I think Web Services 
is a facet:

http://www.w3.org/Talks/2001/07/30-swws/slide21-0.html

> Will these two models clash or complement one another?

I think the models will complement each other with a series of 
tools to convert and work between them.

> Is RPC a good idea which has just been waiting for the appropriate
> technological incarnation, or will the difficulties which have stymied
> its general adoption remain true for Web Services as well?

For one thing, CORBA was not minimally constraining. It's the 
same thing people said about the Web and hypertext -- once we 
pulled out the link consistency requirement and introduced the 
404, things took off. You can't insist that there is only One 
True Way to do things. Bringing RPC to the Web allows these 
things to happen -- it distributes and decentralizes the 
technology. We're pulling off the constraints and letting the 
good ideas fly. It may not work, but I'm optimistic that we'll 
at least get somewhere interesting.

(c.f. http://www.w3.org/Architecture/1998/12/oop-min.html)

> For anyone thinking about the development of Web Services in the
> middle term -- 12 to 36 months -- what are the critical issues? What
> are the strengths and weaknesses of Web Services that will matter the
> most? What opportunities will Web Services be able to take advantage
> of in the coming years? What challenges will it face to its spread?

Here's my recommendation: Set your data free, take advantage of 
the data from others, build tools that use the stuff in 
interesting ways, and hang on for the ride.

> And, perhaps most important of all, what do you know about Web
> Services that the rest of the world hasn't caught on to yet?

Web Services is just one part of the big pie-in-the-sky dream of 
the Semantic Web.

I hope some of this is useful, feel free to ask for clarification.

Received on Wednesday, 15 August 2001 17:27:19 UTC