- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Wed, 9 Feb 2005 14:15:00 -0800
- To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, "Liu, Kevin" <kevin.liu@sap.com>, <www-ws-desc@w3.org>
- Cc: <public-ws-async-tf@w3.org>
- Message-ID: <7DA77BF2392448449D094BCEF67569A5067A87EC@RED-MSG-30.redmond.corp.microsoft.com>
Ah, ok. This part led me astray:
<xs:element ref = "tns:ManagerDecision"/>
<!-- manager decision is required for amount
above $100 -->
In fact, the response (whether immediate or delayed) is intended to
always be a form of approval confirmation, and the request for a manager
decision is not part of this operation. Renaming ManagerDecision to
ApprovalConfirmationByManager or just having a single
ApprovalConfirmation structure would have kept me from false inferences.
________________________________
From: public-ws-async-tf-request@w3.org
[mailto:public-ws-async-tf-request@w3.org] On Behalf Of Yalcinalp, Umit
Sent: Wednesday, February 09, 2005 11:59 AM
To: Jonathan Marsh; Liu, Kevin; www-ws-desc@w3.org
Cc: public-ws-async-tf@w3.org
Subject: RE: Initial thoughts on WSDL2.0 LC101 - do we need message
level binding properties?
Jonathan,
The user is ALWAYS notified. I guess it may not be clear, but the
manager's notification is only internal to the application which causes
the user's response to be anync.
HTH,
--umit
________________________________
From: public-ws-async-tf-request@w3.org
[mailto:public-ws-async-tf-request@w3.org]
Sent: Wednesday, Feb 09, 2005 11:54 AM
To: Liu, Kevin; www-ws-desc@w3.org
Cc: public-ws-async-tf@w3.org
Subject: RE: Initial thoughts on WSDL2.0 LC101 - do we need
message level binding properties?
How do you reconcile the WSDL 2.0 in-out mep's requirement that
the out message go to the same "node" with the behavior that sometimes
the subsequent message (in case reply or response is too loaded a term)
goes to the Manager?
________________________________
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 10:43 AM
To: www-ws-desc@w3.org
Cc: public-ws-async-tf@w3.org
Subject: Initial thoughts on WSDL2.0 LC101 - do we need message
level binding properties?
Just noticed that the message was sent to the WSD member-only
list. I am resending it to the WSD public list. Please use the public
list for response.
Sorry for the duplicate if you have already received this
message.
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 01:41 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 operation@mep <mailto: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:binding@wsoap:protocol
<mailto: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 Bindings
<http://www.w3.org/TR/2004/WD-wsdl20-20040803/#WSDL-PART3> ]) 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/@@@@/@@/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.html
<http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jan/0004.htm
l>
[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 Wednesday, 9 February 2005 22:15:17 UTC