Re: Definition of Choreography

Mathews, Walden wrote:
>>I would go further: implementation and interface are just two different 
>>things and years of experience indicates that keeping them separate is 
>>better. That separation is a _major_ reason for the whole web services 
>>program. That will hold true for 1.0, 1.1, 2.0 and 10.0. IMO, the W3C 
>>should be focused on interface.
> 
> 
> There seems to be some confusion about what is interface and what is not,
> though. 

That's certainly true!

> ... Programming languages and design tools focus on the syntax of
> interface, but ignore other important interface qualities.  If slip my
> car into reverse, the syntax of that interface can be expressed in terms
> of shift lever motion.  There's another important aspect of the interface
> between me and my car: the fact that if I tramp on the gas next, the car
> is going to bolt *backwards*.  Because I put it in that state.

You choose to express it in terms of a state machine: "in that state". I 
choose not to, because it complicates and adds nothing.

There are two levels I'd like to explore:

First, is the car's state associated with my "conversation" with the 
car? Not really. I can put the emergency brake on, get out, switch seats 
with my wife can get in and she has in her head the precondition: "If 
the gear is 'reverse' then putting my foot on the gas will make me move 
backwards." "If the gear is 'drive' then putting my foot on the gas will 
make me move backwards." (let's put aside safety issues about switching 
drivers while the car is in gear)

So the state is not tied to the driver/automobile conversation: all 
relevant state is exposed always in addressable resources. That's simply 
good interface design, whether for humans or web services. It loosens 
the binding between participants and allows the concept of 
"conversation" to go away.

There are also conditions relating to the emergency brake. When you 
model them as a state machine you get a minor explosion of states. I 
would rather tell a new driver: "don't hit the accelerator with the 
emergency brake on." It is uselessly complicating for me to build a 
state machine describing all of the possibilities of reverse+emergency 
break, drive+emergency brake, reverse w/out emergency brake, drive w/out 
emergency brake, etc.

Second, let's move beyond cars with gears and stuff. When you have an 
idealized interface to a car (like the ones in video games and fuel cell 
vehicles) you use a joystick instead. In other words, you transform a 
stateful interface into a stateless one. There are all kinds of good UI 
reasons to do that but there is also an important reliability reason. 
You can never "forget" what state you are in and hit the gas thinking it 
means something other than it does. Now think about web services 
"forgetting" can happen either through a missed message (this is the 
Internet after all) or a client failure. So transforming a stateful 
interface into a stateless one improves reliability in that environment too.

  * http://evworld.com/databases/printit.cfm?storyid=297

Similarly, if I get out of the car, and my wife gets in, with a 
stateless joystick interface, she never needs to think: "what did he do 
just before I got in?" It is simply not relevant. Once again I've 
loosened the binding. Not only does my wife not need to ask me what I 
did before I got in, she doesn't even have to _look_ because what I did 
is not relevant to her.

These are the two levels of loose binding service providers should work 
on achieving. Total statelessness if possible. Explicitly addressable 
state otherwise.

> Sorry if I'm stating the obvious, but it seems folks are saying that
> anything that can't be seen on the command line or in the method
> signatures must be "implementation".

Programming language people have gone very far down the path of trying 
to specify behavioural outcomes as "interface" and have typically backed 
off. In the end, your interface becomes as complicated as your 
implementation (really a recoding of it) and keeping them in sync 
becomes a problem.

  Paul Prescod

Received on Monday, 21 October 2002 14:12:12 UTC