Re: Choreography and Components (was: Re: Is Systems Software Research Irrelevant?)

[Daniel Weinreb <address@hidden>]

Paul Prescod wrote:

>Daniel Weinreb wrote:
>
>>...
>>Real component architectures, in the sense of an architecture that 
>>lets two programs interoperate even if the programs were written 
>>by disparate people in disparate places under very different 
>>adminstrative environments, require *more*, not *less*, declarative 
>>semantics. CORBA and > RMI are just a start; at least they give names 
>>to operations and specify input and output types. The whole 
>>WSDL/UDDI/SOAP path is a somewhat improved version of the
>>same.  
>>
>
>I'm curious: improved how?
>
Oh, I don't have anything very valuable to say about this. For some 
purposes XML is nicer
than IIOP because people can read it.  The UDDI stuff has some value, 
maybe.  I guess there
might be something in the OMG/CORBA suite that does all the same things, 
and I wouldn't
really know...

>
>Let me posit a theory I've been thinking about for a while. 
>
>"Choreography" is not a notion that we usually use in the local case. If
>it was, you would not have to explain it to the list. The reason
>choreography is not usually necessary in the local case is because we
>instinctively move the "steps to accomplish something" into the data. If
>there are a hundred steps to solve a problem, then this can be
>represented in an object oriented language as an object, which you call
>a method on to get another object, which you ... a hundred times. You
>don't have to tell the person the order in which to call because it is
>*impossible to get the order wrong*. You don't have the object necessary
>to call step 99 until after you've called step 98.
>
>As a simple example, consider two different designs for file IO:
>
>open("/somedirectory/somefile")
>data = read("/somedirectory/somefile")
>
>You could execute those steps in the wrong order. But consider what
>programming languages really do:
>
>file = open("/somedirectory/somefile")
>data = file.read()
>
>You *cannot* execute those steps in the wrong order so there is no need
>to define a choreography for this API. In a language with sufficiently
>deterministic garbage collection, you could even do away with the
>"close" method (which reintroduces a sort of method ordering issue). 
>
>But even if we do not do away with the "close" method,
>we do not have to view this as a choreography problem (and generally do
>not do so). Rather we say: "when the object is in the closed state, the
>read method cannot be called." This is no different than saying: "When a
>stack is empty, it may not be popped."
>
It's true that you can describe things in terms of state variables 
instead of describing them
in terms of flow of control.  But sometimes flow of control is nicer -- 
easier to understand,
easier to "prove" (convince yourself) correct.

It's like the difference between programming with threads versus 
entirely event-driven
(e.g. interrupt-driven) software.  The former uses PC and stack state 
where the latter
retains no PC nor stack state and has to encode everything as data 
state.  You can\
always do it, but the former is often more convenient and clear.

And in practice, we usually *don't* say "when the object is in the 
closed state, the
read method cannot be called".  We usually leave that out, even though 
we shouldn't.
Look at real documentation of libraries of Java or Perl code.  You 
usually just don't see
that stuff; it's all tacit  Very few interfaces really
in practice do have this kind of commenting.  Especially when the state 
information
becomes more complicated than just "open/closed", when it becomes so 
complicated
that PC state is a lot prettier than data state.

>
>
> * The two participants can be as stateful or stateless as they like (as
>long as the shared state is available somewhere). For instance, the Web
>uses this model and this allows browsers to be stateless. Not all
>browsers are stateless, but you can accomplish meaningful, multi-step
>tasks on the Web with browsers that are. Obviously less trusting
>participants will want to be more stateful if only to log interactions.
>
Yeah, event-driven is "stateless" (in the sense that the state is 
encoded as data rather
than running threads/processes), and that kind of statelessness has 
benefits, but looking
at the big picture there are pros and cons to both approaches.

>
>
> * Eliminating the need to *negotiate* the choreography simplfies the
>integration process. Of course you still have to make the assertions
>about proper actions given particular properties of the shared state but
>I claim that you need to do this *anyways*. That's standard business
>rules. You can only do X if the Y amount is greater than 0 etc. DAML
>seems like an excellent starting point for a declarative language for
>these assertions.  
>
But the point I'm making is that the two are interchangble; they're duals.

--Dan