[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bpel] Issue 3 - An amended proposal - Correlation Disagreementbetween SCA and BPEL proposal
Hi, Mike and Dieter,
Thanks for the follow up discussion emails.
It looks like there are 3 cases listed on the table in the previous emails sent by Mike and Dieter.
(a) Process instance does not exist. e.g. the UUID-like "conversation-id" does not match any active process instance.
(b) Process instance exists (e.g. the "conversation-id" matches with an active process instance). However, there will NEVER be any potential matching IMA (e.g. the message is targetting operation "cancelPO" and the process has no IMA that match the operation at all. Or there is only potentially IMA and it is already enabled with a wrong CS value).
(c) A potential matching receive may be enabled in future, but not enabled in a "timely fashion".
If I read Michael's email correctly, his two cases are (a)+(b) together as one case and (c) as the other case. On the other hand, Dieter's two cases are (a) and (b).
IMHO, (a) and (b) are definitely close enough to be treated together, as both of them do not involve "timely fashion" concept.
Few additional points to consider:
On the topic: "who specifies timeout and what timeout value"
I am not proposing we should define a detailed timeout mechanism in SCA-* spec, because it may depend on the actual underlying protocol. If a protocol with a business-conversation timeout mechanism exists, my gut feeling is that the sender should specify the value. The actual time out will vary depending on the nature of business conversation.
Dieter Koenig1 wrote:
OFFA8B14EB.D662BCD9-ONC1257395.0057E583-C1257395.0059C21E@de.ibm.com" type="cite">Mike, my preference goes into a similar direction. (1) Indicating that no existing process instance can be correlated with a request - note that this may not always be because of a faulty correlation set; it may also happen if a branch of the process navigates to an <exit> activity such that a <receive> on another branch is effectively cancelled - this would not be a problem caused by the client. (2) Indicating that an existing process instance that has been correlated with a request can never consume the request - of course only if this situation can really be detected - I agree that any good timeout value can be wrong in another scenario. Kind Regards DK From: "Michael Rowley" <email@example.com> To: "Alex Yiu" <firstname.lastname@example.org> Cc: Dieter Koenig1/Germany/IBM@IBMDE, "Mike Edwards" <email@example.com>, "Najeeb Andrabi" <firstname.lastname@example.org>, <email@example.com> Date: 16.11.2007 16:22 Subject: RE: [sca-bpel] Issue 3 - An amended proposal - Correlation Disagreement between SCA and BPEL proposal My first inclination would be to have two different faults. One fault that says we know, logically, that you have sent a faulty correlation set. A different fault would be used to report that your seemingly valid correlation set hasn’t been matched by some designated timeout period (although I’m not sure which side should define that timeout). If others feel strongly that these two error conditions should be combined into one fault, I would be OK with that, but my preference would be to keep them separate. I’m also not sure that I would bother standardizing on the timeout fault, since it may be appropriate for it to be different for different bindings. Essentially, this is an argument to keep it as “never”. Michael From: Alex Yiu [mailto:firstname.lastname@example.org] Sent: Wednesday, November 14, 2007 4:21 PM To: Michael Rowley Cc: Dieter Koenig1; Mike Edwards; Najeeb Andrabi; email@example.com; ALEX.YIU@oracle.com Subject: Re: [sca-bpel] Issue 3 - An amended proposal - Correlation Disagreement between SCA and BPEL proposal Hi Michael, I understand your concern. Wording versions: Version 1: "will never be matched" Version 2: "will not be matched" Version 3: "can not be matched" I think the current version 3 has the least interpretation space for the engine to queue up messages, because it loses the time dimension semantic. Differences on whether to use the term "never": Consider the case that: (one of the bullet in the proposed non-normative text) · matching IMAs blocked by other activities within a sequence Say, a matching IMA is blocked by another preceding receive. Or, a matching IMA is blocked by an ill-defined preceding loop. If we pick the term "never" in version 1, then using this standard fault to notify the message sender won't be covered by the if-condition. Because, the engine cannot logically conclude the external message for the blocking receive will never arrive or the engine cannot logically conclude the ill-defined loop will never finish. My intention here is: the engine may notify the sender of this error condition, if a matching IMA cannot be found in a timely manner. E.g. if a section of a process typically takes only few minutes or hours, after days or weeks of waiting for the blocking receive / loop, and, if the engine decides to notify the sender of this error condition by this new fault, it should be covered by the spec. So, I prefer wordings of version 2 or a new version wording (modified based on version 3): Version 4: "can not be matched ... in a timely manner" Of course, the exact details of "timely manner" will depend on the underlying protocol (transport and coordination) and etc. For example, if: · the operation is request-response · HTTP is the transport protocol (say the HTTP timeout is: 360 seconds) · an IMA cannot be matched within the transport timeout period · but a potential matching IMA is pending but not activated yet. If we use the term "never", then this new standard fault does seem to be applied and the existing transport level time out fault will be applied instead. If we use wordings of version 2 or version 4, then this standard fault can be applied and covered by the spec. Further thoughts and comments? Thanks! Regards, Alex Yiu Michael Rowley wrote: The reason I had included the word "never" was precisely for this reason. I didn't want it to read that there is no IMA active right now. I wanted to say that the system determined that there never would be one. There certainly are times when that can occur, such as when you are using a combination of engine-managed correlation and explicit correlation sets. If we don't say "never", then I'm not sure how we would word this to allow for queuing up messages until an IMA becomes active. Michael -----Original Message----- From: Dieter Koenig1 [mailto:firstname.lastname@example.org] Sent: Tuesday, November 06, 2007 4:31 AM To: Mike Edwards Cc: email@example.com; Najeeb Andrabi; firstname.lastname@example.org Subject: Re: [sca-bpel] Issue 3 - An amended proposal - Correlation Disagreement between SCA and BPEL proposal Alex, Mike E, Mike R, Najeeb, I assume we agree that we want to allow a BPEL implementation to store a message if it can be consumed by a process instance at a later point in time. Do we want to make this explicit in the normative language? (Of course, it cannot be decided in many cases, and additional considerations apply - e.g., it makes a lot of sense for one-way messages and it makes less sense for request-response operations called via synchronous bindings [<- btw, this is another scenario for issue BPEL-12]). For those cases where we finally decide to return an "sca:DeadLetterMessageError" fault to the sender, I have additional questions: - in case of request-response operations, would this fault manifest itself as an SCA ServiceRuntimeException? - in case of one-way operations, will SCA (the assembly spec?) define the coordination protocol messages? Kind Regards DK From: Mike Edwards <email@example.com> To: firstname.lastname@example.org Cc: Najeeb Andrabi <email@example.com>, firstname.lastname@example.org Date: 06.11.2007 09:46 Subject: Re: [sca-bpel] Issue 3 - An amended proposal - Correlation Disagreement between SCA and BPEL proposal Alex, I agree with your point about "never", but I don't like your additional words in parentheses at all. The extra qualifiication just complicates things needlessly - let us leave it to the SCA & BPEL infrastructure to work out whether matching can be done. I changed "will" to "can" as well, to get rid of this flavour of "future-ness" in the wording which is not appropriate, since this statement is about a state and what to do when this state is detected. How about: "If the SCA or BPEL infrastructure is able to determine that a message, that has been sent to an endpoint address of a business process, can not be matched with a corresponding inbound message activity (i.e. receive, onMessage or onEvent), then:" Yours, Mike. Strategist - Emerging Technologies, SCA & SDO. Co Chair OASIS SCA Assembly TC. IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain. Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431 Email: email@example.com Alex Yiu <alex.yiu@oracle. com> To Michael Rowley <firstname.lastname@example.org> 05/11/2007 19:23 cc Najeeb Andrabi <email@example.com>, firstname.lastname@example.org, ALEX.YIU@oracle.com Subject Re: [sca-bpel] Issue 3 - An amended proposal - Correlation Disagreement between SCA and BPEL proposal Hi, Michael, Thanks for the quick feedback. I agree with you that the "if" condition in the normative text can be tightened up. I like your changes in general. I am wondering whether the word "never" may be a bit too strong. I am thinking to use the word with a weaker tone with extra qualification description. How about: "If the SCA or BPEL infrastructure is able to determine that a message, that has been sent to an endpoint address of a business process, will not be matched with a corresponding inbound message activity (i.e. receive, onMessage or onEvent) (possibly based on a message protocol or some infrastructure heuristic), then:" If the extra qualification description "(possibly based on a message protocol or some infrastructure heuristic)" opens new cans of worms, I am comfortable to drop it. Thanks! Regards, Alex Yiu Michael Rowley wrote: Alex, Thanks for the background material. I also the proposed normative text, except for the reference to "a dead letter message", without having a definition for that in our spec. I also thought that "message receiver" might be too vague. Perhaps the first sentence, which you had as: "If the SCA and BPEL infrastructure of the message receiver is able to detect a dead letter message:" could instead read: "If the SCA or BPEL infrastructure is able to determine that a message that has been sent to an endpoint address of a business process will never match a corresponding inbound message activity (i.e. receive, onMessage or onEvent), then: Michael From: Alex Yiu [mailto:email@example.com] Sent: Thursday, November 01, 2007 12:34 PM To: Najeeb Andrabi Cc: firstname.lastname@example.org; ALEX.YIU@oracle.com Subject: Re: [sca-bpel] Issue 3 - An amended proposal - Correlation Disagreement between SCA and BPEL proposal Hi all, Here is an amended proposal for this Issue 3. I believe the spirit of the proposal is the same. But, wordings and details are different. This amended proposal avoids/addresses a few issues that the original proposal has: * "bpel:correlationViolation" is for BPEL's CorrelationSet lifecycle violation - not CS mismatch. I am not sure we want to overload it. All existing "bpel:*" fault thrown are for internally consumption only. Not directly visible through BPEL partnerLink. * There is no formal notion of "wrapping" in WS fault. * We need to address the difference in one-way or request-response MEP. * The flow chart has "wait until all the IMA in all existing processes have been activated". That seems to be not so feasible / well-fit. The proposal has two parts: background (non-normative) text and normative text. If the background text is too long for some audience, I am happy to trim and para-phrase it. I send this longer version for the benefit for the TC discussion. About the normative text, I hope it is short yet concise. One thing to highlight is: it may be infeasible to specify a universal dead letter detection algorithm, which has real values to users. Hence, I am using SHOULD and MAY here, instead of MUST. ------------------------------------ [background text begins here ...] When an inbound message comes into the SCA and BPEL infrastructure, such a message is normally consumed by a matching inbound message activity (IMA)(e.g. a <receive> activity). However, due to process model error or runtime message data error, there is no matching IMA at all or a matching IMA is not enabled within the expected time limit of the (system/business level) protocol between the message sender and receiver. This kind of messages, which do not have a matching IMA, are termed as "dead message messages" Examples of process model error are: * matching IMAs are skipped by faults * matching IMAs blocked by other activities within a sequence or an impossible-to-fulfill control link transition condition. * IMAs cannot receive message due to incorrect usage of message correlation mechanism, including BPEL correlation set and SCA conversational interface Examples of runtime message data error are similar to above, as the above error are not inside the process definition itself but caused by incorrect data values. There might not be a universal way to determine a message is truly a "dead letter message" without any additional protocol between message senders and receivers. Consider the following example, an message is dispatched to a BPEL process instance by SCA conversational mechanism. At the moment when the message is matched with the BPEL process instance, there might be no <receive> activity enabled for the matching partnerLink and operation at all, or there is a <receive> activity enabled for the matching partnerLink and operation but with a mismatched correlation set. Some users might think this is certainly a dead letter message situation. However, a matching IMA may be enabled minutes, hours, or days later, as the matching IMA might be blocked in the process model. On the other hand, there might be some cases that the BPEL infrastructure can determine there will never be a matching IMA enable in future. And, some advanced features in BPEL infrastructure (e.g. process instance repair or process definition repair) might make the detection of "dead letter message" cases more difficult. However, with some additional system-level protocol coordination between the message sender and receiver, it might make detection easier. ------------------------------------ ------------------------------------ [normative text begins here ...] If the SCA and BPEL infrastructure of the message receiver is able to detect a dead letter message: * If the message is sent through a request-response operation, "sca:DeadLetterMessageError" fault SHOULD be thrown to the message sender * If the message is sent through a one-way operation and additional system-level protocol is used between the message sender and receiver, the dead letter message error situation MAY be notified to the message sender, according to the protocol used. ------------------------------------ Looking forward to further comments and fine-tuning. Thanks! Regards, Alex Yiu Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]