Re: Counting noses on "is SOAP and/or WSDL intrinsic to the definition of Web service"

Cutler, Roger (RogerCutler) wrote:

>I'm not quite sure exactly how this would work, but it seems to me that
>some approach roughly along these lines might form the basis for
>reasonable consensus.
>  
>
My feeling is that we need to take a step back, look at how we got here 
and where we're going and we might even some day be able to define what 
a Web service is ;-)

An HTTP server is a service as far as the HTTP client is concerned. 
That's as interesting as DNS, DHCP and all the other IP-based protocols 
out there.

An HTTP server may also serve documents. This is what most people equate 
with the Web -- not getting an HTTP response but getting the document 
you asked for, some meaningful response. It is also where HTTP meets the 
Web - the links are not in the protocol but in the documents. HTTP by 
itself is not more Web than DNS, but HTML is Web even if the document is 
delivered using SMTP.

A service the way I understand it does something useful. Before I use it 
I need to know about that. I know what my bank can do for me, I know 
what my lawyer can do for me, and I know what a fast-food restaurant or 
a megaplex would do for me. These are services. Incidentally by 
experience I also know what Amazon and eBay would do for me, but the 
majority of Web sites out there - I have no clue. They may be an HTTP 
service but I don't care much for HTTP responses. They may be Web 
servers but I have no clue what service they perform. I would not call 
them Web services.

A SOA starts with defining what the service does and how to go about 
using it, and does so using some set of technologies. IDL, Java 
interfaces and UML are all good. It also needs some way to encapsulate 
messages so you can use utility services like routing, RM, security, 
CORBA interceptors, etc. BTW this is my definition of what -5 is.

Plain XML over HTTP is a good way to build a lot of services, but it's 
missing the secret ingredient to be an SOA - the SOA doesn't care that 
you can use HTTP to retreive XML data, it cares that you can define, 
publish, discover and otherwise use services.

To make a Web out of an SOA you need two things. You need to be able to 
link all these services together whhich means some lingua franca to 
describe them and send these descriptions around. And since links are 
exchanged you can't predict who would be talking to whom, so you also 
need some lingua franca for encapsulating messages.

The decision to do so using XML and call these languages WSDL and SOAP 
is arbitrary and nothing but a fad. But you can't create a Web without 
some level of standardization and so any SOA architecture that wants to 
be Webby in any sense of the term needs to pick a set of languages, 
hopefully one for each specific task. You can call the result Web 
services or Webbed services or 'services that can be linked in a web' or 
WSA SOA.

So while an HTTP server that sends XML messages is not a service until 
you can determine what it does before using it, a service that returns a 
JPG when you ask it to return a JPG based on its definition is a Web 
service. It would have to attach it to some SOAP message to benefit from 
all the utility services, but if the service was advertised as wedding 
pictures retrieval service and does just that, then it's a service.

Just my 2c

arkin

Received on Monday, 2 June 2003 23:27:23 UTC