RE: Resource definition

>  
>  
> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net] 
> Sent: Saturday, February 22, 2003 8:20 PM
> To: Francis McCabe; Mark Baker
> Cc: Burdett, David; www-ws-arch@w3.org
> 

> This raises an important point. In most applications I have 
> experienced and most I can conceive of, clients understand 
> the problem domain in terms of the state of domain objects.  
> They don't want to toggle the switch, they want the light on. 
>  They don't care what starting state it was in.  This is too 
> prevalent to dismiss.
> 
> Things which are operation-centric and state-agnostic tend to 
> be games, not businesses. 

It seems to me that for the vast majority of applications of Web services
that I'm aware of TODAY, the "service" is some operation to be invoked that
does something out in the real world -- transfer money, make plane
reservations, integrate operations using an SAP system in one division with
a Baan system in another division, and so on. Ultimately, these result in
real things happening: I get on a plane, I get money from the ATM, my
Amazon.com order arrives by FedEx, and so on.

I would not begin to dispute that one COULD model all these things as
transfers of information rather than invocations of operations, but the fact
remains that most of those boarding passes are printed, cash dispensed, and
books are shipped under the control of bazillions of lines of procedural
code that is NOT going to be re-written because it is no longer fashionable.
And ultimately, something happens in the real world because switches are
toggled, doors opened, trucks loaded, bills dispensed, etc.  Note all the
verbs!

The more reasonable approach seems to me that *some* services involve
primarily the transfer of information around the Web, and they are good
candiates for a RESTful design, and *other* services involve the invocation
of an action, and they are good candidates for an SOA design.

Received on Saturday, 22 February 2003 20:49:15 UTC