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

As a practical matter, we can't rely on WS-RM* because the existing 
specs are only drafts.

There is also another point. Reliable messaging is a "native" feature of 
some transports, such as JMS. If such a transport is part of the Web 
services stack then you will get certain guarantees about message 
delivery; however, you won't necessarily get a visible alteration in the 
message flow (JMS sends acknowledgements, but they're consumed by the 
messaging layer: they are not considered messages of the same class as 
the data payload delivered to a recipient).

In other words, the fact that RM may involve extra messages (e.g. 
acknowledgement) visible at the application layer is not inherent to RM 
per se, but is an artifact of implementing RM over an unreliable 
transport such as HTTP.

The implication is that you have to treat reliable messaging as a "black 
box" at the choreography layer. I.e., if it exists, its supporting 
messages are not part of the message exchange captured at the 
choreography layer. It is a QOS, nothing more.

There is some implication that you may have to handle timeouts in the 
absense of RM.

--Jon

Steve wrote:
> 
> 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:35:08 UTC