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

>
> 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.

Received on Monday, 30 June 2003 10:55:15 UTC