Re: Resource definition

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