Re: Choreography State Definition (was: RE: More requirement

I tried getting to the bottom of the remarks about RM below by going 
back through my email. Alas I cannot see the original email that raised 
this. Perhaps it was a private communication ;-(

Whilst it is true that pi-c assumes that RM is in place I do believe 
that you can still model external observable behaviour without RM and 
using pi-c principles to guide you. An absence of a communication (a 
handshake) can be modeled as an implicit interaction both sides of the 
original interaction. This provides a way to model timeouts which can 
be used to handle issues about non-receipt of interactions or partial 
interactions.

At the end of  the day all visible behaviour be it explicit interaction 
or implicit interaction (timeouts, exceptions etc) can be said to be an 
interaction. Thus we can model the external observable behaviour in 
most of these cases as a choice in pi from the perspective of one 
party. For example any process P that is in a state to receive a 
specific communication on channel "a" of type "x" can be re-written as:

	P = ax.P' 	
			- P receives x on channel x and continues as P' to do something

	P = ax.P' + t<timeout>.P'' + e<exception>.P'''
			- as above unless a timeout occurs in which case it continues to do 
P'' or P''' if an exception is detected.

	One can even use restriction so that the last two terms are not 
propagated outside of the scope of P.

So I think it doesn't mean that because RM is normally required we 
cannot derive benefit from a pi-c approach.

Comments ....

Cheers

Steve T


On Monday, June 30, 2003, at 04:05  pm, Monica J. Martin wrote:

>
>>
>> Burdett: Thanks for the explanation - it makes complete sense. The 
>> essence of the idea id I understand it correctly is that Pi-c 
>> *relies* on the reliable delivery of messages which translates, as 
>> you describe, into the requirement that Pi-c would *have* to be used 
>> with a Reliable Messaging (RM) protocol. If RM is not used, then you 
>> have to introduce some way of compensating when the inevitable 
>> problems occur.
>>  However even if you do use a RM protocol, the RM protocol can still 
>> fail and leave the two roles in an inconsistent state where one side 
>> thinks the message was delivered and therefore is continuing while 
>> the other does not and is therefore halted. I won't go into the 
>> reasons why here since it has been discussed on various RM working 
>> groups before. Bottom line you "can't" completely guarantee that both 
>> sides know that a message has been delivered AND that therefore the 
>> one side won't start while the other is halted.
>
> mm1: However, this does not negate the value of using reliable 
> messaging because the key is to lower risk and increase 
> confidence/certainty in the results, correct?
>
>>  So I think the key question we have to answer is:
>> 1. Do we want to restrict our choreography definition language to be 
>> used *only* in conjunction with RM, so that we can support Pi-c, or
>> 2. Do we want remove that restriction and let each side to carry on 
>> processing independently and therefore not use Pi-c
>>
> mm1: I believe we may have to consider an approach that allows for 
> both.  And, we have to weigh whether (1) or (2) is given priority. I 
> would suggest we discuss this on tomorrow's call as it impacts many 
> assumptions, and we need to prioritize which will be the 'norm' in the 
> marketplace.  I believe the thrust for reliable messaging is clear, 
> but do realize you have to provide the lesser (if you consider RM the 
> greater) case to enable legacy migration and real-world business 
> constraints in some circumstances.
>
>> *My* answer would be to go for the second option as:
>> 1. RM is never 100% guaranteed and therefore
>> 2. You have to allow for the specification of the exception handling 
>> that occurs when processes get out sync anyway
>> 3. Forcing processes to wait while the RM protocol takes place could 
>> result in extended execution times. For example if you are using SMTP 
>> to deliver the messages.
>> 4. Carrying out process in parallel sometimes and handling 
>> inconsistencies when they occur is a natural way of doing many 
>> different types of processing.
>>
> mm1: See comment above. Reliable messaging could be an option.  This 
> depends on our focus.
>
>
> This email is confidential and may be protected by legal privilege. If 
> you are not the intended recipient,  please do not copy or disclose 
> its content but  delete the email and contact the sender immediately. 
> Whilst we run antivirus software on all internet emails we are not 
> liable for any loss or damage. The recipient is advised to run their 
> own antivirus software.
>

This email is confidential and may be protected by legal privilege. If you are not the intended recipient,  please do not copy or disclose its content but  delete the email and contact the sender immediately. Whilst we run antivirus software on all internet emails we are not liable for any loss or damage. The recipient is advised to run their own antivirus software.

Received on Monday, 30 June 2003 16:03:44 UTC