- From: Asir Vedamuthu <asirv@webmethods.com>
- Date: Mon, 7 Feb 2005 11:47:28 -0800
- To: "'Liu, Kevin'" <kevin.liu@sap.com>, Asir Vedamuthu <asirv@webmethods.com>, public-ws-async-tf@w3.org, www-ws-desc@w3.org
- Message-ID: <5B10E50E14A4594EB1B5566B69AD9407068E6A20@maileast>
Kevin,
Thank you for answering my question.
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 2:12 PM
To: Asir Vedamuthu; public-ws-async-tf@w3.org; www-ws-desc@w3.org
Subject: RE: Initial thoughts on WSDL2.0 LC101 - do we need message level
binding properties?
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 <mailto: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 <mailto: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
<mailto: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
<http://www.w3.org/@@@@/@@/wsdl/soap> "
wsoap:protocol= "
http://www.w3.org/@@@@/@@/soap12/bindings/HTTP
<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
<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 <mailto: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
<http://example.com/mybinding1> "/>
myExt:mep="http://example.com/mymeps/http-in-smtp-out
<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
<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
<http://www.w3.org/@@@@/@@/wsdl/soap> "
protocol= " http://www.w3.org/@@@@/@@/soap12/bindings/HTTP
<http://www.w3.org/@@@@/@@/soap12/bindings/HTTP> " .../>
<output messageLabel="out"
type= " http://www.w3.org/@@@@/@@/wsdl/soap
<http://www.w3.org/@@@@/@@/wsdl/soap> "
protocol= " http://www.w3.org/@@@@/@@/soap12/bindings/SMTP
<http://www.w3.org/@@@@/@@/soap12/bindings/SMTP> " .../>
...
</operation>
<operation ref="logReport" ... >
<output messageLabel="out"
type= " http://www.w3.org/@@@@/@@/wsdl/http
<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.html>
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:48:40 UTC