Re: [sca-bpel] Issue 3 - An amended proposal - Correlation Disagreementbetween SCA and BPEL proposal

[Alex Yiu <alex.yiu@oracle.com>]

Hi, Dieter and others,

[a]

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? 

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:

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:

• Whether it is one-size-fit-all protocol situation? or we will adopt multiple protocols
• Whether we want to SCA specific protocol which may not work with non-SCA client
  
• Whether we want to reuse and extend some WS-* protocol. (for example, WS-BusinessActivity, as it has some close to BPEL scope life cycle)
  

All these decisions are complicated enough to create its own sub-TC. :-)

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