Re: Pi-Calculus Model question.

Ricky Ho wrote:

> Assaf, thanks.  More 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.
>>>>
>>> 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.
>
>
> Are you effectively saying there is a "Dispatch process" which do the 
> following ?
>
> Process Dispatch
>   Receive msg from channel1
>   switch
>     case conditionX
>       Send msg to channel2
>     default
>       Send msg to channel3

As far as pi-calculus is concerned - yes there is such a dispatch 
process. From the perspective of the model the message is dispatched to 
either one of these processes, so the model would treat it like a 
dispatcher. And if you look at possible implementations, e.g. using a 
queue with multiple competing listeners, this is effectively what happens.

As far as the language is concerned we may opt to use higher level 
constructs that are based on that model, but more directly express the 
fact that two processes are competing for the same message. We'll need 
some support from WSDL, e.g. an output only operation may be required in 
this case.

> Of course, to answer my earlier broadcast question, there can be a 
> "Broadcast process" which do the following
>
> Process Broadcast
>   Receive msg from channel1
>   Send msg to channel2
>   Send msg to channel3
>
> Also, I think now is a good now to extend the example to demonstrate 
> some mobility concept.
> Lets say the seller want to tell the shipper (in this case, lets only 
> have one shipper) what the buyer's channel so that the shipper can 
> send an "arrival notice message".  Can you extend the example to show 
> that ? 


process sellerSideOfThings
  receive msg(x,y,z) from channel1
  < got the order (x), the credit card number (y), the buyer's channel (z) >
  . . .
  send msg(w,z) to channel2
  < just sent some shipper the package weight (w) and the buyer's 
channel (z) >
  . . .

process shipperSideOfThings
  receive msg(w,z) from channel2
  < received the package weight (w) and the buyer's channel (z) >
  . . .
  send msg(t) to channel z
  < sending the buyer (z) the expected delivery date (t) >
  . . .

process buyerSideOfThings
   new myChannel
   < this is where is all starts, BTW >
   send msg(x,y,myChannel) to channel1
   < just sent some shipper the information including my channel >
   . . .
   receive  msg(t) from myChannel
   < just received expected delivery date (t) from my channel >
   . . .

arkin

Received on Friday, 18 April 2003 01:48:17 UTC