Re: Pi-Calculus Model question.

Ricky Ho wrote:

> Assaf, thanks again !  More questions embedded ...
>
>
>>> Lets introduce two more roles, "Airplane Shipper" and "Truck 
>>> Shipper", each has its own process flow.
>>>
>>> There are two cases here.
>>>
>>> 1) Queue scenario
>>> The seller send a "shipment request" to a channel.  Can both 
>>> Shippers listening on this same channel but only one of them will 
>>> successfully receive it ?  Lets say the seller doesn't care and both 
>>> shippers are competing to get the shipment request.
>>
>>
>> This is a different issue. In this case the channel is the queue and 
>> you can have multiple consumers for the queue without changing the 
>> semantics of the channel. In this particular case I assume that the 
>> shipper is the process you communicate with. Whether it ends up being 
>> the airline shipper implementation or the truck shipper 
>> implementation is immaterial, you view both implementations as being 
>> equivalent and so you in fact have only one "process" listening to 
>> that channel.
>>
>> This does require some level of abstraction, e.g. as David suggested 
>> by defining message families. So the interaction is based on some 
>> abstract specification that is equivalent for both implementations 
>> allowing for one process to be defined, but there's enough 
>> flexibility to use different messages depending on whether you end up 
>> talking to an airline implementation of a truck implementation of the 
>> shipper process.
>
>
> In this example, lets say the "Airplane Shipper" has a completely 
> different flow from the "Truck Shipper" to handle the shipment.  In 
> other words, it cannot be abstract out to a common process.  The 
> seller needs to be aware of which one has got the shipment request and 
> deal with the shipper differently.  Now, can both Shippers listening 
> on this same channel but only one of them will successfully receive it ?

Yes. But now you'll need them to reply to find out which one you're 
talking to and adapt accordingly. Still the same model:

receive:shipperChannel.(send:airlineResponse.... + send.truckResponse)

So the P + Q composition still works to allow one common process to 
listen but then branch into two separate flows depending on who is 
listening.

>>> 2) Broadcast scenario
>>> The seller send a "shipment request" to a channel.  Can both 
>>> Shippers listening on this same channel and both receive it ?
>>
>>
>> Yes. The broadcast scenario is based on message duplication. Both 
>> shippers listen on different channels specific to their processes, 
>> which may even be different processes (e.g. one doing the shipment 
>> and one tracking a shipment request or auditing the business 
>> commitment). The message is actually sent to both channels, but 
>> technically you will simplify it by using a broadcast medium and so 
>> in the language you can express that with a single send operation.
>
>
> Are you saying that there are some forwarding mechanism between 
> different channel.  So that senderA sends a messageX to channel1 will 
> cause receiverB receive messageX from channel2 as well as receiverC 
> receive messageX from channel3.  In other words, channel can form some 
> forwarding relationship among themselves ?

Channels are more abstract mechanism to model deterministic behavior of 
communication. Broadcast is a mechanism that allows the message to be 
duplicated and received by multiple consumers. The two are orthogonal. 
So discussing channel as a concept is one thing, and then discussing the 
technicality of using broadcast is another thing, but they don't conflict.

>> How about:
>>
>> receive:response(one).recieve:response(two).doSomething(one,two).0
>
>
> But I don't want to force that response(one) has to occur before 
> response(two).  Lets say each of them can happen at any time.

Again, this is an issue of whether you deal with the formalism that 
proves correctness or try to use some language to model it. If you're 
talking about the formalism the formalism is only concenred with the 
fact that the process is correct. When you receive two messages in order 
you don't care in what order they were sent. They may be sent in any 
order, and you may decide to receive them in one particular order. So 
the formalism is sufficient.

If you're talking about the language you would want to express the fact 
that order is not important, for example, because it influences what 
transport mechanism you are using. Using a MOM will ensure order, but 
you may use synchronous protocol in which case enforcing an order on 
receive may be a problem. But that's an issue the language has to 
address, and languages like BPEL/BPML/WSCI address that. So does 
join-calculus which proposes that construct.

But it can be reduced to pi-calculus and in pi-calculus you do not care 
about the technical details but only proving correctness and that 
definition is correct. It yields well to bi-simulation. In other words:

send:x | send:Y | receive:Y.receiver:X

will reduce to 0.

arkin

> Basically, I want to see how pi-calculus represent the "fork/join" in 
> UML activity diagram.

Fork: by sending a message to some process that starts (spawns) that 
process while allowing the sending process to proceed.

Join: by receiving a message from that process when it ends (join) so 
your process blocks until the sending process completes.

arkin


>
>
> Rgds, Ricky

Received on Tuesday, 15 April 2003 03:34:12 UTC