optional messages and indeterminate sequences of messages

Arising from some of Tuesday's discussion:

The cases where

   A sends some number of messages X; then A sends one message Y

   A may or may not send message p; A sends message q

(with the decision as to which to send being decided by conditions
at A), are essentially similar. After n occurences of X, another
X is effectively optional - the difference is just that, if there is an
X, the dance stays at the same point, where as after a p, it moves on 
to require q. But you can treat them both as X{min,max};Y with min=1,
max=* in
the first case, min=0, max=1 in the second.

(recasting "send message" to "interaction" doesn't really change things,
though is important for generality)

As an example, make X "add an item to my open order", and Y "my 
order is complete, please proceed". That's a bit different from the
piecemeal order filling case, where both sides could determine from
the X's that a Y is now due.

It's going to be pretty easy to implement the real receiver (B) in 
reality, so CDL shouldn't require heavy mechanisms. Just recognizable
ones.

There doesn't seem any point in pretending there is some information
available at B which will tell it what is coming next. It's going
to find out when the interaction occurs.

So, perhaps:

<sequence>
...
<workunit repeat="true" guard="something at A">
    <interaction operation="X">
</workunit>
<interaction operation="Y">
...
</sequence>    

To my surprise, I couldn't see a need for <choice>. If this is 
an optional message rather than a sequence, then omit repeat="true".


On projecting to the endpoints, that's easy for A

while (somethingHere() ) {
    channelToB.sendX();
}
channelToB.sendY();

It requires a bit more intelligence at B. The projector has
to recognise that the guard condition is no use to it and
create code than is driven by what comes in.

boolean x_looping = true;
while (x_looping) {
    msg incoming = channelFromA.receive();
    switch (incoming.type) {
    case X: processAsX(incoming);
            break;
    case Y: processAsY(incoming);
            x_looping = false;
            break;
    }
}

My argument against pretending there is something at B that
will let it know what is coming is that it won't help the
projection - it HAS to be determined by an incoming message.
The best you could do would be to force the distinction down into the 
infrastructure messages/headers.
    
An unpleasantness of that is the B projector has to do a lookahead,
and it might be nicer to have a 1:1 relation between the cdl construct
and what is generated. But I'm not sure how that might look, especially
if there are multiple terminating messages (orderComplete, orderAborted,
pleaseHoldAsOpen ...). 



Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd
web: http://www.choreology.com
email: peter.furniss@choreology.com
phone: +44 870 739 0066
mobile: +44 7951 536168

Received on Wednesday, 29 September 2004 11:34:23 UTC