- From: Walden Mathews <waldenm@optonline.net>
- Date: Sat, 22 Feb 2003 21:55:46 -0500
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
You're making two points here, both wrong. (1) In order to get to desirable end states, we have to specify the action to be taken. No, we are better off specifying just the end state (goal) and letting the evolving system apply the best action according to modern technology. Today, that might mean "print a ticket"; tomorrow it might not. In both cases, "Mike on plane" is the result. In the second case, evolution is obviously easier, since you have not built dependencies on the part that is going away. This WAS my point. I hope it's clearer now. (2) Software somehow, by itself, makes parcels appear on your doorstep. Actually, software stops somewhere a little short of that phenomenon. However, what the software does do is to set the state of control documents which motivate the physical change. (Please read "documents" liberally, so as in include, say, some set of registers or ports which when collectively achieve some particular state, will dispense cash.) NOTE: your analysis below about applications NOT being re-written is bass-ackwards. A state-descriptive interface in no way interferes with an existing implementation, while at the same time it paves the way for the inevitable... As evidence of the above, I offer the ILX Entitlement web service, a state-descriptive, networked front end to a legacy system in which not a line of SQL stored procedure was touched. Walden ----- Original Message ----- From: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com> To: <www-ws-arch@w3.org> Sent: Saturday, February 22, 2003 8:48 PM Subject: 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 21:56:06 UTC