RE: WSA constraints

Anne Thomas Manes wrote on Monday, September 23, 2002 11:58 PM:
> The Web has many similarities to an SOA, but as I said, it's 
> oriented for
> human consumption rather than machine consumption. An SOA 
> requires that a
> service be defined by a contract. The Web has no such 
> constraint. (HTTP GET
> tells an application how to get a resource, but not how to 
> use it once it
> has it.)

So by implication, something like CORBA or EJB, which we would all agree are designed to support application consumption rather than human consumption, *do* tell a caller how to use a service? In that case, Anne, please tell us the semantics of the following CORBA IDL interface and operation:

  interface MyInterface { string my_operation(in string s1, in string s2); };

At least with a GET, I know I'm going to get a representation of the resource. Without uniform interfaces, however, you know *nothing*. The my_operation method above could be anything -- you can't possibly know the semantics, and you have absolutely no way of finding out without knowing the implementation details of the service.

SOAa are quite simple. They consist of services that make themselves available to clients through some form of registry, and clients that use the registry to first find information about a desired service and then use that information to interact with the service itself. That's it. As simple and intuitive as this may seem to many of us, it's unfortunately a foreign concept to many others, who instead think about the application from the client-side perspective and thus treat services as just extensions of specific client applications. Non-SOA thinking has resulted in many spaghetti-like point-to-point applications with "services" that are so application specific that they cannot be used by any other apps.

Is the Web a SOA? Absolutely. The fact that humans are driving the client side doesn't even enter the equation.

--steve

Received on Tuesday, 24 September 2002 01:22:43 UTC