sca-bpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Issue 5: Long-Running Request-Response Operations
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS BPEL" <sca-bpel@lists.oasis-open.org>, "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Wed, 7 Nov 2007 10:37:59 +0000
Anish,
(I am copying this email to Assembly
as well as BPEL - I think there is an Assembly issue lurking here that
applies cross-language)
You are correct in saying that the behaviour
sought is like that implied by the NonAnonymousResponses assertion.
Another way of putting things, more
in SCA terms, is that these sorts of operations actually imply a Callback
style of interface.
This is important, since it means, for
example, that the initial request operation by the client will complete
without a response from
the service provider (as you say, there
is an HTTP response but NOT a WSDL response). The response from the
service
operation arrives later as a separate
connection. This is *precisely* the idea behind callbacks and its
asynchonous nature
is then "obvious" to the client,
since there is a requirement to provide the callback interface to get the
WSDL response message.
OK, so far.
Client Implementation
The first implication for me is on the
client programming API. What is described in WSDL terms as a Request/Response
operation
is regularly mapped (using Java as the
example) to a client API like:
SomeResponseMessageType response someOperation( SomeRequestMessageType
request ) throws OperationException1, OperationException2
....but in the case of "long running"
operations must be mapped to something more like:
a) void
someOperation( SomeRequestMessageType request )
and
b) void
someOperationResponse( SomeResponseMessageType response ) throws OperationException1,
OperationException2
...where the client calls a reference
with an interface including a) but where the client must provide an interface
including b)
There is also the need for a correlation
between the original call to a) and the callback on b). This might
be achieved through
an ID being generated by the system
when a) is called (would need to be returned on the call), which can then
be gathered from
the context when the callback is called.
Or it could be done in the now "approved" asynchronous
fashion for Java, by returning
a Future<type x> object from a)
- and which would then implement the interface b) and get called when the
response message
arrives back at the client.
Service Implementation
The second implication for me is on
the service implementation. The service implementation must know
to "release" the protocol
stack which made the original service
invocation, ideally rapidly after the original request arrives. There
is then the need for the
protocol stack to make a completely
new connection when dealing with the response message.
Now, this could be done via the Binding
code - with the simple call-and-return style preserved for the service
implementation.
However, this may or may not be a sensible
way of doing things. The alternative is that the service implementation
takes the
original request, gets a callback reference
stores it and returns rapidly, long before the operation is actually complete
- the
callback reference is then used whenever
the operation does complete asynchronously. The latter approach would
use
the split interface style of a) and
b) above.
WSDL and Interface handling
One way of approaching this then is
to affect the interpretation of the WSDL:
a) Let's assume that the WSDL operation
is request/response
b) Let's assume that the WSDL operation
is marked "long running" (some annotation to this effect)
c) WSDL2LanguageX tools would have modified
behaviour when encountering this annotation and would generate
the "dual interface" mapping
implied above. Clearly this does not apply to BPEL, which uses WSDL
"native".
d) Clients and Providers in some native
language would use the "dual interface" form and construct their
code
appropriately, in callback style.
e) If WSDL is used directly, then its
interpretation by runtime and binding code will be consistent with the
interpretation
give here.
f) The WSDL annotation COULD be viewed
as a Policy intent - it is just that its implications go a bit further
than selecting
an appropriate policyset for the
binding, since it affects the form of the client and provider code. This
intent might
imply the WS-Policy assertion that Anish
picks out, in the case of Web services. In the case of JMS and messaging
subsystems, things might be different
(and simpler).
Conclusion
I hope that this helps in the debate
- it is an interesting problem and a common case once we deal with long-running
business processes.
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
Anish Karmarkar <Anish.Karmarkar@oracle.com>
01/11/2007 06:29
|
To
| Dieter Koenig1 <dieterkoenig@de.ibm.com>
|
cc
| Danny van der Rijn <dannyv@tibco.com>,
sca-bpel@lists.oasis-open.org
|
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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]