- From: Liu, Kevin <kevin.liu@sap.com>
- Date: Mon, 7 Feb 2005 20:10:47 +0100
- To: "Asir Vedamuthu" <asirv@webmethods.com>, <public-ws-async-tf@w3.org>, <www-ws-desc@w3.org>
- Message-ID: <99CA63DD941EDC4EBA897048D9B0061D0B1C1619@uspalx20a.pal.sap.corp>
Hi Asir,
Very good question. I didn't go to the service level since it also
depends on which direction the group wants to go for changing the
binding constructs, if at all.
IF (I say IF since personally I don't have a strong preference) we take
the route of option 2, 3, or 4, we will also need to change the endpoint
constructs. I haven't thought it through, but on top of my mind,
service/endpoint@binding needs to be changed to point to a binding
operation (which may not be an easy thing given operations are not
named).
Best Regards,
Kevin
-----Original Message-----
From: public-ws-async-tf-request@w3.org
[mailto:public-ws-async-tf-request@w3.org]
Sent: Monday, Feb 07, 2005 06:24 AM
To: Liu, Kevin; public-ws-async-tf@w3.org; w3c-ws-desc@w3.org
Cc: Anish Karmarkar
Subject: RE: Initial thoughts on WSDL2.0 LC101 - do we need message
level binding properties?
Kevin,
I have one clarification question, how do options 2, 3 and 4 impact
Service and Endpoint abstraction and XML representations?
Regards,
Asir S Vedamuthu
asirv at webmethods dot com
<http://www.webmethods.com/> http://www.webmethods.com/
-----Original Message-----
From: public-ws-async-tf-request@w3.org
[mailto:public-ws-async-tf-request@w3.org] On Behalf Of Liu, Kevin
Sent: Monday, February 07, 2005 4:42 AM
To: public-ws-async-tf@w3.org; w3c-ws-desc@w3.org
Cc: Anish Karmarkar
Subject: Initial thoughts on WSDL2.0 LC101 - do we need message level
binding properties?
I took an Action Item in the last Async TF call to summarize the options
of changing WSDL2.0 binding to accommodate async and one way bindings in
the context of WSD LC101 (see [0]). This should fulfill my AI.
For those whose email client can not display bold fonts and color, a
word version is attached for your easier reading.
Caveats:
1. Here are my initial thoughts about a few ways the group may consider
to address LC 101. The alternatives listed here are more intended as
food of thought, are not meant to be exclusive.
2. In this message, I only focus on wsdl2.0 core. Changes to soap and
http binding extensions is pending on the conclusion of the discussion
around DavidO's proposals for SOAP MEPs (see [3]) and Greg's slides (see
[4]), for example, for soap binding extension, we MAY need to push
binding <mailto:operation@mep> operation@mep to message/fault reference
level for some bindings . If we can agree on the general direction on
changes to wsdl2.0 core, hopefully it will be easier to scope the
binding extension discussion.
3. For those who are already familiar with Greg's slides [4] which use
WSDL1.1 examples, note the binding level syntax change from wsdl1.1 to
wsdl2.0. In particular,
- wsdl11:binding@type reference the portype whereas wsdl20:binding@type
identifies the binding type in use, such as soap11 binding, http
binding, etc.
- wsdl11 soap:binding@transport == wsdl20:
<mailto:binding@wsoap:protocol> binding@wsoap:protocol
A USE CASE
--------------------
Let's start with an example - a (simplified) ExpenseReport service.
The service has two operations: submitExpense, and logExpense
The submitExpense operation takes an XML document as input which
contains all the expense data. Depending on the total amount of the
expense, the service's response will vary. If the amount is under $100,
the service approves the expense automatically, sends a confirmation
message and reimburses the user's bank account. If the amount is more
than $100, the service will forward the request to a manager for review
and notify the user some times later when the decision to approve or
decline has been made.
The logExpense operation simply sends a one way message to a logging
service every time an expense is approved.
The interface can be easily described using the WSDL 20 in-out mep
(irrelevant constructs ignored):
<description ...>
<types>
<xs:schema ...>
<xs:element name="expenseRequest" >
<xs:complexType ...> ... </xs:complexType>
</xs:element>
<xs:element name = "expenseResponse">
<xs:complexType>
<xs:choice>
<xs:element ref = "tns:ApprovalConfirmation"/>
<!-- an immediate approval message for
amount under $100 -->
<xs:element ref = "tns:ManagerDecision"/>
<!-- manager decision is required for amount
above $100 -->
<xs:choice>
</xs:complexType>
</xs:element>
...
</xs:schema>
<xs:element name="expenseLog" >
<xs:complexType ...> ... </xs:complexType>
</xs:element>
</types>
<interface name = "expenseReport" >
<operation name="submitExpense"
pattern="http://www.w3.org/2004/03/WSDL/in-out" >
<input messageLabel="In"
element="tns:expenseRequest" />
<output messageLabel="Out"
element="tns:expenseResponse" />
</operation>
<operation name="logExpense"
pattern="http://www.w3.org/2004/03/WSDL/out" >
<output messageLabel="Out"
element="tns:expenseLog" />
</operation>
...
</interface>
</description>
For discussion purposes, let's say the expense request will always be
SOAP over HTTP. The response message will be carried in a SOAP envelop
over HTTP when the amount is under $100 and the request is immediately
approved. Otherwise, the response will be sent over SMTP at a later
time. The log message will always be sent out via HTTP POST.
Note that in this example, the MEPs of the two operations use different
binding types and different transport protocols, which makes sense
because the two operations are targeting different clients. See [1] for
DavidB's post on the "Meaning of a WSDL document" which clarifies that a
WSDL is not only for one particular client, but all potential clients of
a service. Also note the input and output messages of the
submitExpense operation use different binding types and protocols based
on its business requirements.
IMPACTS ON WSDL2.0 CORE
---------------------------------------------------
This use case posts a few challenges to the current WSDL2.0 design. Per
status quo, the binding type and protocol can only be defined in the
binding level. Without defining proprietary extensions, the following
is probably the best one can do:
<binding name="expenseReportBinding"
interface="tns:expenseReport"
type="what would be the value here?"
wsoap:protocol="since the two operations both use http as the
underlying protocol (well, partially for the first operation), should
wsoap:protocol be used at all at this level?">
<operation ref="tns:submitExpense"
wsoap:???="since the two messages of this operation may use
different binding type and protocol, anything can be reused from soap
binding or a totally new binding has to be defined ?"/>
<operation ref="tns:logExpense"
http:???="how to indicate the binding type for this operation is
http post"/>
</binding>
The key questions we need to answer are - Should WSDL2.0 allow the
expense report use case? if so, how the binding can be defined in
WSDL2.0 per the above requirements? In particular, what values should be
provided at the binding level for the REQUIRED properties binding@type ?
how to specify that the two operations using different binding? how to
specify that the two messages of an operation use different protocols?
The WSDL2.0 spec (part 1 and part 3) does not have a clear answer for
these questions at all.
Below is a few ways (not meant to be inclusive, other options are
possible) we may consider.
Since the problem is caused by the two or more operations of a single
interface use different bindings, we can either fix it in the binding
level, or in the interface level.
Option 1: change interface specification so that an interface can only
contain operations that use same binding type
In the interface level, if we clearly limit that an interface can only
contain operations that use same binding type, the conflicting
binding@type problem goes away. In the expenseReport case, two
interfaces must be defined, one for submitting expense report, one for
logging expense, then at binding level we don't have to worry about
conflicting values for @type. Such limitation of interface may be more
reasonable than it appears to be - if we think about in reality how many
interface will contain operations that use different binding types, I
would say it's definitely in the 20 side of 80/20 case.
if we add the above limitation, the definition of the expense report
service may look like:
<description ... >
...
<interface name = "expenseReport" >
<operation name="submitExpense"
pattern="http://www.w3.org/2004/03/WSDL/in-out" >
<input messageLabel="In"
element="tns:expenseRequest" />
<output messageLabel="Out"
element="tns:expenseResponse" />
</operation>
</interface>
<interface name = "expenseLog" ...>
<operation name="logExpense"
pattern="http://www.w3.org/2004/03/WSDL/out" >
<output messageLabel="Out"
element="tns:expenseLog" />
</operation>
...
</interface>
<binding name="expenseReportBinding" interface="expenseReport"
type= " http://www.w3.org/@@@@/@@/wsdl/soap"
wsoap:protocol= "
http://www.w3.org/@@@@/@@/soap12/bindings/HTTP" .../>
<operation ref="submitReport" wsoap:mep ="a new special soap mep and
binding needs to be defined for the http-in-smtp-out situation"... >
...
</operation>
</binding>
<binding name="expenseLogBinding" interface="expenseLog"
type= " http://www.w3.org/@@@@/@@/wsdl/http " .../>
<operation ref="logReport" http:method = "POST" ... >
...
</operation>
</binding>
...
</description>
However, this approach has a few downsides:
- it does come with a cost of blurring the abstraction layers of wsdl -
abstract interfaces have to be designed based on binding requirements.
In the case of the expenseReport service, the interface has to be
re-designed to define meaningful bindings.
- it requires additional soap mep/binding to be defined
Option 2: Change binding specification to allow defining bindings for a
subset of operations of an interface.
In the binding level, one may suggest that two bindings can be defined
for the expenseReport interface, one for submitExpense, one for
logExpense. then the binding@type problem can also be solved.
However, per part 1 section 2.9.1, "A Binding component which defines
bindings for an Interface component MUST define bindings for all the
operations of that Interface component. The bindings may occur via
defaulting rules which allow one to specify default bindings for all
operations (see, for example [WSDL 2.0
<http://www.w3.org/TR/2004/WD-wsdl20-20040803/#WSDL-PART3> Bindings]) or
by directly listing each Operation component of the Interface component
and defining bindings for them. Thus, it is an error for a Binding
component to not define bindings for all the Operation components of the
Interface component for which the Binding component purportedly defines
bindings for.", so defining multiple bindings for different operation of
a single interface is disallowed unless we relax this constraint in
section 2.9.1.
Option 3: Go back to the wsdl1.1 way and leave binding type
specification to binding extensions
Change <binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
>
to <binding name="xs:NCName" interface="xs:QName"? >
This solution doesn't require the limitation on interface design as in
option 1, nor requires changing mapping rules between interface and
binding as in option 2. It works just as wsdl1.1 which gives the most
flexibility to binding specifications. for example, creative use of soap
binding extension constructs as shown in Greg's slide 12 becomes
possible if we change the wsdl20 soap binding extensions appropriately.
However, this approach still requires proprietary bindings to be defined
since not too much of the current soap and http binding extensions can
be really re-used for the expense report use case.
Assuming some third party bindings are defined to accommodate the
special situations of the expenseReport service, the binding definition
may look like
<binding name="expenseReportBinding"
interface="tns:expenseReport">
<operation ref="tns:submitExpense" ...
myExt:type="http://example.com/mybinding1"/>
myExt:mep="http://example.com/mymeps/http-in-smtp-out"/>
<operation ref="tns:logExpense" ...
whttp:type=" http://www.w3.org/
<http://www.w3.org/@@@@/@@/wsdl/http> @@@@/@@/wsdl/http " >
! ! myExt:mep="http://example.com/mymeps/http-out"/>
</binding>
*Note WSDL2.0 does NOT provide any guidance about how binding level meps
should be defined, so the interoperability of such extensions are highly
questionable*
Option 4: Enhance the wsdl binding component model and add @protocol
and @type properties to message/fault reference level
we can also add some construct to indicate asynchrony. The binding
syntax can look like:
<binding name="xs:NCName" interface="xs:QName"?
typeDefault="xs:anyURI"?
protocolDefault="xs:anyURI"?
... >
<documentation />?
<fault ref="xs:QName" ...>
<documentation />?
</fault>*
<operation ref="xs:QName" ..>
<documentation />?
<input messageLabel="xs:NCName"?
type="xs:anyURI"?
protocol="xs:anyURI"?
...>
<documentation />?
<feature ... />*
<property ... />*
</input>*
<output messageLabel="xs:NCName"?
type="xs:anyURI"?
protocol="xs:anyURI"?
whttp:shareConnection="xs:boolean"??
...>
<!-- the optional @shareConnection can be used to indicate
asynchrony. I don't claim to be an http expert, so will rely on real
experts to validate this idea. If it's something practical, we need to
clearly specify this property's validity. It is only valid when http is
used for the operation, and it's only valid for non initial message in
wsdl meps that contains multiple messages, for example, the out message
in a wsdl in-out mep. In addition, we need to clearly specify what to do
with the http response message and when shareConnection is set to
false.-->
<documentation />?
<feature ... />*
<property ... />*
</output>*
<infault
type="xs:anyURI"?
protocol="xs:anyURI"?
...>
<documentation />?
<feature ... />*
<property ... />*
</infault>*
<outfault
type="xs:anyURI"?
protocol="xs:anyURI"?
...>
<documentation />?
<feature ... />*
<property ... />*
</outfault>*
<feature ... />*
<property ... />*
</operation>*
<feature ... />*
<property ... />*
</binding>
The good thing about this approach is that wsdl core provides a very
powerful expression power for binding types and protocols used by each
message, and so it dramatically reduces the needs for defining
proprietary binding meps . For example, the expenseReport use case can
be easily supported by WSDL2.0 without having to heavily rely on
proprietary binding extensions:
<binding name="exenpseReportBinding" interface="expenseReport" ...>
<operation ref="submitReport" ... >
<input messageLabel="in"
type= " http://www.w3.org/@@@@/@@/wsdl/soap"
protocol= "
http://www.w3.org/@@@@/@@/soap12/bindings/HTTP" .../>
<output messageLabel="out"
type= " http://www.w3.org/@@@@/@@/wsdl/soap"
protocol= "
http://www.w3.org/@@@@/@@/soap12/bindings/SMTP" .../>
...
</operation>
<operation ref="logReport" ... >
<output messageLabel="out"
type= " http://www.w3.org/@@@@/@@/wsdl/http "
protocol= " <http://www.w3.org/@@@@/@@/wsdl/http>
http://www.w3.org/@@@@/@@/wsdl/http" .../>
...
</operation>
</binding>
IMPACTS on WSDL2.0 pre-defined binding extensions (SOAP and HTTP)
------------------------------------------------------------------------
-------------------
Depends on which option we want to go, the impacts on soap and http
bindings are different. For example, answers may be different for
questions about how asynchrony and one-way should be defined, whether
message level @mep property is necessary, etc.
Thoughts?
[0] <http://lists.w3.org/Archives/Public/www-ws-desc/2004Dec/0021.html>
http://lists.w3.org/Archives/Public/www-ws-desc/2004Dec/0021.html
[1] <http://lists.w3.org/Archives/Public/www-ws-desc/2004Dec/0024.html>
http://lists.w3.org/Archives/Public/www-ws-desc/2004Dec/0024.html
[2] <http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Binding_details>
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Binding_details
[3] <http://www.w3.org/2002/ws/addr/5/MEPsBindingsAddresses.ppt>
http://www.w3.org/2002/ws/addr/5/MEPsBindingsAddresses.ppt
[4]
<http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jan/0004.htm
l>
http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jan/0004.html
[5]
<http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#soap-binding>
http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#soap-binding
Best Regards,
Kevin
Received on Monday, 7 February 2005 19:11:30 UTC