- From: Assaf Arkin <arkin@intalio.com>
- Date: Mon, 30 Jun 2003 14:34:44 -0700
- To: jdart@tibco.com
- CC: Steve <steve@enigmatec.net>, "Monica J. Martin" <monica.martin@sun.com>, Burdett David <david.burdett@commerceone.com>, Nickolas Kavantzas <nickolas.kavantzas@oracle.com>, Jean-Jacques Dubray <jjd@eigner.com>, "'Yaron Y. Goland'" <ygoland@bea.com>, "'WS Chor Public'" <public-ws-chor@w3.org>
Jon Dart wrote: > > 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. +1 You can model reliable messaging down to the level of individual messages, and you can do it in many ways, e.g. send a message enough times with a good chance it will eventually reach its destination. So that's one option a good language would let you use, and in some cases it may actually be more efficient to bypass RM/coordination and just craft an appropriate choreography. But for cases where you do -- always or sometimes -- rely on RM/coordination, I agree with Jon that we're better off treating it as a black box. arkin > > 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. >> >> >> > > -- "Those who can, do; those who can't, make screenshots" ---------------------------------------------------------------------- Assaf Arkin arkin@intalio.com Intalio Inc. www.intalio.com The Business Process Management Company (650) 577 4700 This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, dissemination of this communication is prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately.
Received on Monday, 30 June 2003 17:36:17 UTC