[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, Dieter and others, [a] Yes, I agree that it is perfectly OK (actually typical) for a BPEL implementation to store a not-consumed-yet message. It is already implied by the non-normative text listed in the proposal, which I prefer adding parts of it into the spec text to provide readers more context: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? There might not be a universal way to determine a message is truly a "dead letter message" ... However, a matching IMA may be enabled minutes, hours, or days later, as the matching IMA might be blocked in the process model. At the same time, I am not sure we want to give ourselves more headache by providing NORMATIVE text on defining how BPEL's message persistence store should behave. I would prefer adding more text to the existing non-normative text to denote Dieter's intended clarification. [b] - 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? For request-response operation: Whether this fault be manifested as SCA ServiceRuntimeException ... that is a very good question. Since ServiceRuntimeException is a Java Exception, I think SCA-Java spec may be at a better position to give us a blanket directional statement on whether sca:* WSDL fault is manifested as ServiceRuntimeException Java Exception If people agree with that, I guess some cross-TC people will open a new issue in SCA-Java TC. For one-way operation: A normative effort on defining the coordination message seem to be a non-trivial effort. First, we need to decide the following issues:
Hence, I prefer not initiating an effort to define a protocol normatively (at least for now), which is in sync with the preference of Mike Edwards of removing my wordings in parentheses. Thanks. Regards, Alex Yiu Dieter Koenig1 wrote: OF69E40D21.AFB83FE2-ONC125738B.0031DE91-C125738B.00344B43@de.ibm.com" type="cite">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 <mike_edwards@uk.ibm.com> To: sca-bpel@lists.oasis-open.org Cc: Najeeb Andrabi <nandrabi@tibco.com>, alex.yiu@oracle.com 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: mike_edwards@uk.ibm.com |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]