OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-bpel] NEW ISSUE: Title: Correlation disagreement betweenSCA and BPEL



Hi DK,

Thanks for chiming in this discussion.

Among cases of "zero/one/multiple matching process instance(s)":

For multiple message process instances, I guess that it is covered by bpel:conflictReceive fault already. I believe a conflictReceive fault will happen EITHER at the time of IMA (inbound message activity, e.g. <receive>) got executed/enabled OR at the time arrival of a message that matches multiple IMAs. (The latter case was actually suggested by you in a later stage of spec discussion, if my memory is correct.)

I guess only the "zero" case is unspecified in BPEL 2.0 spec, which I term it as "dead letter message" case or undelivered message case.

I am not against talking about the possibility of "dead letter message" case in SCA-BPEL. Just our hands may be still somewhat tied here. My concerns (summarized here again) are:
  • The proposed behavior to deal with "dead letter message" should be identical whether SCA conversation is used or not. Because, we can have "dead letter message" situation even without SCA conversation.
  • We need to define a way to detect this "dead letter message" situation. Considering the racing condition between message and a (future) matched IMA, timeout-based mechanism is the only generic way to detect the "dead letter" (that I can think of so far).
  • Without referring to a specific conversation mechansim (e.g. WS-Addr, WS-Coordination, WS-BusinessActivity), it may be difficult to define an across-the-board mechanism:
    • to notify the sender of the dead letter
    • or to allow the sender to specific the timeout condition that a message is considered a dead letter (if we choose to use timeout based detection method)
  • And, we don't want to fault the BPEL process itself indiscriminately. Because, the correlation in the BPEL process instance may be right and the sender may be the one that makes mistake in the message. It should be up to the BPEL process designer to decide this.

Thanks!


Regards,
Alex Yiu



Dieter Koenig1 wrote:
OF2263AD53.35070588-ONC1257363.00511C26-C1257363.0051FD2B@de.ibm.com" type="cite">
Hi Alex, I agree with your interpretation of WS-BPEL 2.0. IMO, for both
correlation means, we need to consider the cases of zero/one/multiple
matching process instance(s), the case where the two sets are not
identical, and the case where a resolved process instance does not expect
the message (note however that it may do so at a later point in time). Many
cases (like the obvious case of an undelivered message) are out of scope of
WS-BPEL 2.0, but we might want to describe the expected behavior in
SCA-BPEL.

Kind Regards
DK



                                                                           
             Alex Yiu                                                      
             <alex.yiu@oracle.                                             
             com>                                                       To 
                                       Najeeb Andrabi <nandrabi@tibco.com> 
             27.09.2007 04:40                                           cc 
                                       sca-bpel@lists.oasis-open.org,      
                                       Danny van der Rijn                  
                                       <dannyv@tibco.com>,                 
                                       ALEX.YIU@oracle.com                 
                                                                   Subject 
                                       Re: [sca-bpel] NEW ISSUE: Title:    
                                       Correlation disagreement between    
                                       SCA and BPEL                        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Hi, Najeeb,
(explicitly cc'ing Danny as well)


I think your email explanation fits my guess on what you are worrying
about. Here is my understanding on how WS-BPEL 2.0 spec (not SCA-BPEL spec)
deals with this situation.
      First let me re-elaborate the situation with my own wordings to make
      sure we are on the same page:
            SCA infrastructure dispatchs a message to a BPEL process by
            some sort of machine-generated ID (similar to GUID)
            However, there is a mismatch between the correlation set used
            and the message content (say OrderNumber is somehow screwed up)
      In this case, the message will NOT be passed to the BPEL process
      instance through BPEL infrastructure. (I think that is what WS-BPEL
      2.0 spec says.)
      This is a situation where a message is successfully received
      successfully by the BPEL infrastructure from the lower layer
      communication infrastructure BUT there is no matching inbound message
      activity (e.g. receive). Let me call this "dead letter message
      situation".
      The very same situation can occur even without any SCA conversation
      mechanism. That is,  just a plain old correlation mistake somewhere
      in the message or process. The difference is the SCA conversation ID
      serves an extra ID (think correlation redundancy) that allows the
      detection of the correlation problem earlier.
      Unfortuatnately, WS-BPEL 2.0 spec does not specific semantics to deal
      with "dead letter message situation".  (My first attempt to deal this
      situation was actually in BPEL F2F Apr 2004.) And, SCA conversation
      mechanism is one of the "engine-managed correlation" examples (using
      BPEL TC discussion term, used in issue list but not in the spec). I
      think if we want to deal with this "dead letter" situation. We should
      have a solution generic to all BPEL's "dead letter" scenario, even
      without using SCA conversation mechanism. Hence, I am wondering
      whether SCA-* spec (including SCA-BPEL) is the right place to handle
      this situation.
      Last time, when I read about SCA conversation mechanism in SCA
      Assembly spec, it is somewhat binding independent. (It may involve
      WS-Addr, WS-Coordination, WS-BusinessActivity or SCA vendor specific
      mechanism). It may be difficult to define how to notify the client in
      an async fashion about the correlation mismatch situation, if we
      cannot specify some binding/protocol details. Say, if the caller and
      callee are both using WS-BusinessActivity, this correlation mismatch
      will not want to shift the coordination context to the "faulted"
      state.
      NOTE: bpel:correlationViolation is NEVER used to send back a fault to
      the client of the BPEL process. It is used ONLY in correlation set
      initiation lifecycle error so far in WS-BPEL 2.0.


Thanks for reading this long email. :-)



Regards,
Alex Yiu



Najeeb Andrabi wrote:

      Hi Alex,
                  Sorry could not get back to you earlier. I have done a
      quick write up of the correlation disagreement issue.
      Thanks,
       Najeeb



      Correlation Disagreement between SCA and BPEL


      SCA defines conversational interfaces at binding level and not at an
      application level. This approach can result in ambiguous behavior as
      the two correlation mechanisms are mutually exclusive. To illustrate
      this, let use consider a long running Loan Approval SCA composite
      application that is implemented using BPEL component

      (Embedded image moved to file: pic26675.gif)

      The client make two asynchronous web services (submit request and
      check response) calls using SOAP over HTTP.  These two web service
      calls take part in SCA container based conversation. The SCA
      container correlates based on a correlation id that it generates as a
      response for the submit request web service call.

      . The interface used by the Loan Approval process is defined below:

                  <portType name =”LoanService”
      sca:requires=”conversational”>
                       <operation name = “submitRequest”>
                                         <input message =
      “tns:submitRequestRequest”/>
                                         <output message = “tns:
      submitRequestResponse”/>
                        </operation>
                        <operation name = “checkResponse”
      sca:endsConversation=”true”>
                                         <input message =
      “tns:checkResponseRequest”/>
                                         <output message =
      “tns:checkResponseResponse”/>
                        </operation>
                  </portType>


        This works fine if the correlation is not defined at the BPEL
      process level.

           Now, if the BPEL process correlates as well based on LoanRequest
      correlation set that uses orderNumber and orderDate properties; there
      is a possibility for ambiguous behavior as the SCA container could
      correlate correctly while the BPEL container fails to correlate
      correctly and sends a correlation violation exception back to the
      client.

      <correlationSet name=”LoanRequest” properties=”orderNumber
      orderdate”/>

      <process>
               <sequence>
              <sequence>
                <Receive name="Submit Request Receive"
                       partnerLink="submitRequestPL"
                        operation="submitRequest"
                       portType="LoanService"
                        variable="submitRequestVariable"
      createInstance="yes">
                  <correlations>
                    <correlation set="LoanRequest" initiate="yes"
      pattern="in"/>
                  </correlations>
                </Receive>
                <Reply name="Submit Request Reply"
                       partnerLink="submitRequestPL"
                        operation="submitRequest"
                       portType="LoanService"
                        variable="submitResponseVariable"/>
              </sequence>
              <sequence>
                <Receive name="Check Response Receive "
                       partnerLink="checkResponsePL"
                        operation="checkResponse"
                       portType="LoanService"
                        variable="checkResponseRequestVariable"
                        createInstance="no">
                    <correlations>
                       <correlation set="LoanRequest"/>
                    </correlations>
                <Reply name=" Check Response Reply"
                       partnerLink="checkResponsePL"
                        operation="checkResponse"
                       portType="LoanService"
                        variable="checkResponseResponseVariable"/>
              </sequence>
          </sequence>
      </process>



      From: Alex Yiu [mailto:alex.yiu@oracle.com]
      Sent: Wednesday, September 26, 2007 11:30 AM
      To: Najeeb Andrabi
      Cc: sca-bpel@lists.oasis-open.org; ALEX.YIU@oracle.com
      Subject: Re: [sca-bpel] NEW ISSUE: Title: Correlation disagreement
      between SCA and BPEL


      Hi Najeeb,

      Could you elaborate your concern with a more concrete example?
      Particularly to elaborate what you mean by "BPEL correlation fails"?

      Thanks!

      Regards,
      Alex Yiu



      Najeeb Andrabi wrote:
      TARGET: SCA C+I WS-BPEL spec, General

      DESCRIPTION: SCA conversation mechanism primarily deals with
      correlations at the transport/messaging level not at an
      application/component level. Currently, there is no mechanism to
      handle a case where SCA runtime correlates correctly but BPEL
      correlation fails.

      PROPOSAL: none





  






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]