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: Long-Running Request-Response Operations

Hi Danny, I cannot see where WSDL semantics would be changed. WSDL
request-response operations do not make assumptions about any binding
specifics, and in particular, about their response time and sync/async
transport layers.

BPEL processes have always been able to implement a WSDL r-r operation in
way that may cause the response to be delivered significantly later.

SCA clients attempting to synchronously invoke such operations will fail
when the implementation returns control e.g. a month later. An alternative
SCA approach must be made available for clients interacting with such

The point of the issue is that clients invoking such operations first need
to be made aware about their long-running nature. With that, it can be
decided that the usage of e.g. sync SOAP/HTTP bindings is not meaningful
and other async means must be used to invoke the operation.

Kind Regards

  From:       Danny van der Rijn <dannyv@tibco.com>                                                            
  To:         Dieter Koenig1/Germany/IBM@IBMDE                                                                 
  Cc:         sca-bpel@lists.oasis-open.org                                                                    
  Date:       26.10.2007 20:50                                                                                 
  Subject:    Re: [sca-bpel] NEW ISSUE: Long-Running Request-Response Operations                               

      At this point in time, such long-running implementations of
      request-response operations are NOT SUPPORTED by SCA.

I'm not sure I understand this statement.  Why is it not supported?

It seems to me (without fully understanding your proposal, I admit), that
changing the semantics of a WSDL operation in the SCA-BPEL spec is out of


Dieter Koenig1 wrote:

      TARGET: SCA Client and Implementation Model Specification for WS-BPEL
      note that a resolution will likely affect other SCA specifications.

      DESCRIPTION: Consider a WS-BPEL 2.0 process that implements a service
      containing a WSDL request-response operation, using an inbound
      activity (<receive> or <pick>/<onMessage> or
      <eventHandlers>/<onEvent>) and
      a corresponding <reply> activity referencing this operation.
      assume that there are long-running activities between the inbound
      activity and the <reply>.

      At this point in time, such long-running implementations of
      request-response operations are NOT SUPPORTED by SCA. As a result,
      the very
      first SCA-BPEL goal ("... use any valid WS-BPEL process definition as
      implementation of a component within SCA") is NOT MET.

      Many concrete WS-BPEL scenarios involving such long-running
      request-response behavior EXIST TODAY - long interrupts may be caused
      timer-driven activities and service invocations bound to asynchronous
      protocols or involving user interactions. Many of these long-running
      processes expose request-response operations as this is a more
      modeling style, for example, when the business logic is structured in
      hierarchies of parent and sub-processes. SCA must support using such
      processes as implementations of SCA components.

      As an example, without loss of generality, consider the following
      simple <sequence> containing a <wait> activity delaying the response
      by 14
      days (of course, real-world processes would do useful work here
      instead of
      calling the <wait> activity :-).

          <receive ... operation="rrOperation" .../>
          <reply ... operation="rrOperation" .../>

      The SCA implementation as well as a caller of this operation should
      be made
      aware of the long-running behavior. Note that inspecting the process
      implementation is not sufficient as the long-running nature of
      may not be visible in the process model. Regardless of the structure
      of the
      SCA assembly (component/service directly/transitively wired
      composites), an SCA implementation would want to execute calls to
      operation using some asynchronous means internally.

      PROPOSAL: ********** To Be Discussed **********

      A "longRunning" intent is introduced (policy-related details tbd.),
      indicates the long-running behavior of an operation:
        <operation name="rrOperation" ... requires="sca:longRunning"/>

      Its runtime semantics are defined by the following naming convention
      - a
      request-response operation (with the "longRunning" intent):

        <wsdl:operation name="rrOperation" ...>
          <wsdl:input ... message="x:inputMessage"/>
          <wsdl:output ... message="x:outputMessage"/>
          <wsdl:fault name="fault1" message="x:fault1Message"/>
          <wsdl:fault name="fault2" message="x:fault2Message"/>

      is executed AS IF it was specified as a one-way operation (delivering

        <wsdl:operation name="rrOperationRequest" ...>
          <wsdl:input ... message="x:inputMessage"/>

      AND a set of one-way callback operations (delivering the response or

        <wsdl:operation name="rrOperationResponse" ...>
          <wsdl:input ... message="x:outputMessage"/>
        <wsdl:operation name="rrOperationFault1" ...>
          <wsdl:input message="x:fault1Message"/>
        <wsdl:operation name="rrOperationFault2" ...>
          <wsdl:input message="x:fault2Message"/>

      This naming convention enables an SCA implementation to execute a
      long-running request-response operation in exactly the same way as
      corresponding one-way operations defined in a bidirectional

      All existing SCA means (Java APIs etc.) for bidirectional interfaces
      can be
      reused and no new APIs are required.

      The following rules apply to SCA services and references:
        (1) Attach a "longRunning" intent to a request-response operation
      in a
      component's service if and only if its implementation exposes the
      long-running behavior described above.
        (2) Attach a "longRunning" intent to a request-response operation
      in a
      component's reference if and only if its invocation exposes the
      long-running behavior described above.
        (3) Interfaces of references and services are considered compatible
      (eligible for wiring) if both sides match w.r.t. the "longRunning"
      on their contained operations.

      Kind Regards

      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

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