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 Anish, it sounds like a step in the same direction, although I do not
yet fully understand all the consequences of specifying
wsam:NonAnonymousResponses - I can imagine what the interaction may look
like when the operation implemented by the BPEL process is exposed as a
service with a Web service binding.

Now what would it look like if two BPEL processes are directly wired within
the same composite?
   (1) How do I let the calling component's runtime know that the operation
is long-running?
   (2) How should that operation be invoked in a non-blocking way (here
from a calling process' runtime)?

(Embedded image moved to file: pic13375.jpg)


Kind Regards
DK



|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Anish Karmarkar <Anish.Karmarkar@oracle.com>                                                                                                      |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dieter Koenig1/Germany/IBM@IBMDE                                                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Danny van der Rijn <dannyv@tibco.com>, sca-bpel@lists.oasis-open.org                                                                              |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |01.11.2007 07:30                                                                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [sca-bpel] NEW ISSUE: Long-Running Request-Response Operations                                                                                |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Dieter,

Does the WS-Addressing WS-Policy assertion wsam:NonAnonymousResponses
[1] help here?

That assertion says that the effective ReplyTo and FaultTo EPRs must be
non-anonymous. I.e., reply is sent over a separate connection. That
means in the HTTP case, the HTTP response (not the WSDL response) to the
request is sent right away (relatively) and the WSDL response is sent in
a separate HTTP connection asynchronously to the non-anon ReplyTo.

-Anish
--

[1]
http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/#wspolicynonanonresponses


Dieter Koenig1 wrote:
> 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
> operations.
>
> 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.
>
> HTH
> Kind Regards
> DK
>
>
>
>

>   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
> scope.
>
> Danny
>
> 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
>       message
>       activity (<receive> or <pick>/<onMessage> or
>       <eventHandlers>/<onEvent>) and
>       a corresponding <reply> activity referencing this operation.
>       Furthermore,
>       assume that there are long-running activities between the inbound
>       message
>       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
>       the
>       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
>       by
>       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
>       convenient
>       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
>       very
>       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 :-).
>
>         <sequence>
>           <receive ... operation="rrOperation" .../>
>           <wait><for>'P14D'</for></wait>
>           <reply ... operation="rrOperation" .../>
>         </sequence>
>
>       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
>       activities
>       may not be visible in the process model. Regardless of the
structure
>       of the
>       SCA assembly (component/service directly/transitively wired
>       within/across
>       composites), an SCA implementation would want to execute calls to
>       this
>       operation using some asynchronous means internally.
>
>
>
>       PROPOSAL: ********** To Be Discussed **********
>
>       A "longRunning" intent is introduced (policy-related details tbd.),
>       which
>       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"/>
>           ...
>         </wsdl:operation>
>
>       is executed AS IF it was specified as a one-way operation
(delivering
>       the
>       request):
>
>         <wsdl:operation name="rrOperationRequest" ...>
>           <wsdl:input ... message="x:inputMessage"/>
>         </wsdl:operation>
>
>       AND a set of one-way callback operations (delivering the response
or
>       fault):
>
>         <wsdl:operation name="rrOperationResponse" ...>
>           <wsdl:input ... message="x:outputMessage"/>
>         </wsdl:operation>
>         <wsdl:operation name="rrOperationFault1" ...>
>           <wsdl:input message="x:fault1Message"/>
>         </wsdl:operation>
>         <wsdl:operation name="rrOperationFault2" ...>
>           <wsdl:input message="x:fault2Message"/>
>         </wsdl:operation>
>         ...
>
>       This naming convention enables an SCA implementation to execute a
>       long-running request-response operation in exactly the same way as
>       the
>       corresponding one-way operations defined in a bidirectional
>       interface.
>
>       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"
>       intent
>       on their contained operations.
>
>
>
>       Kind Regards
>       DK
>
>
>
---------------------------------------------------------------------
>       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
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
>

---------------------------------------------------------------------
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

pic13375.jpg



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