Title: Message
Jim,
It looks like the
decision made in the 122 resolution has not been applied to the draft yet.
(Editors please confirm).
Regarding the
statement you quote below, it seems it should at least be substantially
reworked, if not eliminated. If we are giving advice about when to use one
construct (receive/reply) vs. the other (receive/invoke), I doubt that the issue
of whether "the customer request can be processed in a reasonable amount of
time" is relevant here. The issue seems to relate to the case where, for
example, an HTTP binding for the WSDL Request/Response MEP would suffer a
timeout condition if the receive and reply are too far apart in time. But that
would not be the case if other so-called asynchronous bindings were
used.
Ugo
-----Original Message-----
From: Jim Clune
[mailto:]
Sent: Monday, December 13, 2004 2:26
PM
To: Ugo Corda;
Subject: Re:
[wsbpel] Assumptions about WSDL 1.1 MEPs
Thanks, Ugo. I failed to review the issues list
thoroughly. I'm afraid I'm still not clear on the resolution to Issue 122. The
resolution indicates that changes will be made removing references to
"synchronous" and "asynchronous" relating to reply, but the "In spec" section
is marked as "No change". Does this mean that the change has not been made yet
or that no change is required? In particular, is the paragraph
quoted below slated for removal, or has it intentionally been left in the
spec?
Jim Clune
Parasoft
Corporation email:
101 E.
Huntington Ave. voice: (626)
256-3680
Monrovia, CA.
91016 fax :
(626) 256-6884
----- Original Message -----
From:
Ugo
Corda
To: Jim Clune ;
Sent: Monday, December 13, 2004 1:31
PM
Subject: RE: [wsbpel] Assumptions about
WSDL 1.1 MEPs
Jim,
This was
discussed in Issue 118 and Issue 122, and resolved in Issue
122.
Ugo
-----Original Message-----
From: Jim Clune
[mailto:]
Sent: Monday, December 13, 2004 12:59
PM
To:
Subject:
[wsbpel] Assumptions about WSDL 1.1 MEPs
I am wondering if the current BPEL draft is
making an incorrect assumption about WSDL 1.1 MEPs. The assumption
that the spec seems to make is that a WSDL operation with
Request/Response MEP will necessarily have the request and response in the
same network connection, regardless of the binding. My questions
are:
1. Is the spec making this assumption? (I
think it is.)
2. Is this assumption correct? (I think it is
not.)
My reading this assumption in to the spec
comes largely from Section 6.5. The current draft contains the
following paragraph, where I interpret "synchronous" to mean "in the same
network connection":
The example makes the implicit assumption
that the customer request can be processed in a reasonable amount of time,
justifying the requirement that the invoker wait for a synchronous
response (because this service is offered as a request-response
operation). When that assumption does not hold, the interaction with the
customer is better modeled as a pair of asynchronous message exchanges. In
that case, the "sendPurchaseOrder" operation is a one-way operation and
the asynchronous response is sent by invoking a second one-way operation
on a customer "callback" interface. In addition to changing the signature
of "sendPurchaseOrder" and defining a new portType to represent the
customer callback interface, two modifications need to be made in the
preceding example to support an asynchronous response to the customer.
First, the partner link type "purchasingLT" that represents the
process-customer connection needs to include a second role ("customer")
listing the customer callback portType. Second, the <reply> activity
in the process needs to be replaced by an <invoke> on the customer
callback operation.
I don't think you can correctly infer whether
or not a request/response pair will be on a single network connection
based solely on an abstract WSDL. If I'm
either misreading the spec or misunderstanding WSDL, could someone clarify this for me? If not, I'll submit
this as an issue to be resolved. Thanks.
Jim Clune
Parasoft
Corporation email:
101 E.
Huntington Ave. voice: (626)
256-3680
Monrovia, CA.
91016
fax : (626) 256-6884
