RE: issue 6401 - 6661 satisfaction by Notification wsdl approach

Gil,
 
Your example is about multipart notification message with one part goes
to the SOAP header. As discussed in the WS-RA WG meeting, the use of
multipart notification message is not encouraged and no one showed
interest to implement such support. Therefore, this main problem you
have on Notification WSDL (approach A), e.g.  "It was this use case that
caused me to abandon my support of the "Notification WSDL" approach"
should be a separate issue and should not be a factor for approach A.
 
One extra comment is: Notification WSDL for the event sink is specified
by the event source. Therefore, the event source knows how to support,
e.g. binding, etc., because Notification WSDL is what the event source
wants the event sink to do based on its (event source) own capability.
It is not the case as in your example that an event sink has the Event
Sink WSDL which requires  the event source to match and support.  
 
Other comments (BLUE) are in line which is after yours to my email.
 
Thanks,
 
- Wu Chou.


________________________________

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Tuesday, July 21, 2009 3:11 PM
To: Chou, Wu (Wu)
Cc: Bob Freund; public-ws-resource-access@w3.org
Subject: Re: issue 6401 - 6661 satisfaction by Notification wsdl
approach


The main problem with Approach A involves Use Case V
<http://www.w3.org/2002/ws/ra/wiki/Use_Cases_for_6401-6661> . It was
this use case that caused me to abandon my support of the "Notification
WSDL" approach in favor of the "Abstract Event Types" approach in my
current proposal. As I've illustrated previously, suppose the Event Sink
WSDL contained the following:

  <wsdl:message name="Ping">
    <wsdl:part name="Ping" element="sc002:Ping"/>
    <wsdl:part name="Fooble" element="sc002:Fooble"/>
  </wsdl:message>

  <wsdl:portType name="sc003Port11">
    <wsdl:operation name="Ping">
      <wsdl:input message="tns:Ping"
 
wsaw:Action="http://www.wstf.org/docs/scenarios/sc002/Ping"
<http://www.wstf.org/docs/scenarios/sc002/Ping> />
    </wsdl:operation>
  </wsdl:portType>

  <wsdl:binding name="sc003SOAP11Binding" type="tns:sc003Port11">
    <soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"
<http://schemas.xmlsoap.org/soap/http> />
    <wsdl:operation name="Ping">
      <soap:operation soapAction=""/>
      <wsdl:input>
        <soap:header use="literal" part="Fooble" message="tns:Ping"/>
        <soap:body use="literal" parts="Ping"/>
      </wsdl:input>
    </wsdl:operation>
  </wsdl:binding>

Notice how the "Fooble" wsdl:part is mapped to a SOAP header in the
binding. Nothing in the proposal for Approach A tells us how this part
will be mapped to a Wrapped Notification. Will it be included inside the
wse:Notify message or as a SOAP header?

This is only one example of why WSDL is ill suited to the task of
describing Event Types. The use of RPC/Literal bindings is another and,
given enough time, I'm sure I could think of at least a dozen more. The
truth is that WSDL, by design, includes both the description of the
contents of a message as well as the binding of those contents to a
particular SOAP serialization. The later is inextricably wrapped up in
our notion of Notification formats. It is impossible to use WSDL to
describe an Event Sinks interface in a way that does not pre-suppose the
Notification format that will be used for the Subscription. It is also
possible to use WSDL to describe interfaces which have no mapping to any
currently defined Notification format.

The "Abstract Event Types" proposal (Proposal B) avoids this problem by
simply describing, in XML Schema, the format/shape of the Events
independently from the Notification format. It doesn't have to encompass
all the flexibility of WSDL because the Event Sinks WSDL is generated
from the EventDescriptions element using a fairly constrained mapping
(Doc/Lit only, no multi-part messages, etc.)

Further comments inline . . .

On 7/21/2009 8:40 AM, Chou, Wu (Wu) wrote: 

	Bob,

	We attach the summary of satisfaction of  issue 6401-6661 (
approach A) with this email to provide information towards a closure of
this issue at F2F meeting. 

	To provide some background, two approaches are proposed to
address issue 6401 -6661:

	Approach A (Ours): It is based on the notification wsdls and
(optional) ws-policy assertions to link the operations of the event sink
with the events of the event source. 

	Approach B (Gill): It is based on customized
NotificationDescription (ND) xml dialect for subscriber to fetch and
generate event sink wsdl.

	The main difference between these two approaches is:  approach A
is based on wsdl and approach B is based on customized xml dialect ND
for wsdl generation. ND is a simplified version of wsdl and anything
expressible by ND should be expressible by wsdl. 

	However, as a non-standard private xml dialect, here are some
issues/differences with ND  based approach B comparing to the wsdl based
approach A. 

	1. As a non-standard xml dialect, it requires extra processing
steps/procedures to transform ND into wsdl before the service can be
used and implemented. And this process is private to WS-Eventing and not
in any other WS-* standards.

 (Gill: The process of "linking" the Event Source WSDL to the Event Sink
WSDL via WS-Policy assertions (as described by Approach A) is also
non-standard and unique to WS-Eventing. Approach A is also woefully
underspecified in a number of areas including (as mentioned above) how
to map a WSDL-defined description of a Raw Notification to its Wrapped
equivalent,  how the resolve the out:Outbound policy/links that may
occur at different levels in the same hierarchy, etc. )
 
(Wu: Using policy to decorate the WSDL and policy assertions to specify
requirements are all standard practice specified by WS-Policy. Policy
assertions are specific to the particular standard or WSDLs, and this
practice is also standard as illustrated in other WS-* standards, e.g.
WS-Security, Policy, etc. In addition, how to map a raw notification to
its wrapped equivalent is defined in this approach, e.g.
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/at
t-0028/Web_Services_Eventing__WS-Eventing_.htm )


	

	2. It is new knowledge beyond wsdl 1.1/2.0 specifications with a
non-standard data type.

 (Gill: Ditto for linking components in one WSDL to components in
another WSDL. )
 
(Wu: Using policy and policy assertions to decorate WSDL are not new
knowledge as explained above, and it fits without change to existing web
service infrastructures, e.g. UDDI, etc. Moreover, the use of policy in
approach A is Optional, etc. as described in
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/at
t-0048/6401_6661_satisfication_0720_wu.pdf ) 


	

	3. Most policies are attached to the WSDL subjects (endpoint,
message, operation and service) and they will not be available to ND
anymore.

 (Gill: Approach A does not contain any description of how to
interpret/handle any policies that may be attached the Event Sink WSDL.
For example, suppose there is an Event Sink WSDL with 3 effective policy
alternatives for a given Notification listener. How does the Event
Source choose from among these alternatives? What if the Event Source is
not capable of supporting any of these alternatives? )
 
(Wu: In approach A, Notification WSDL for the event sink is specified by
the event source, NOT by the event sink. The event sink needs to follow
the Notification WSDL and related event source policies to receive event
notification from the event source. It is not the case that an event
sink has an  Event Sink WSDL/policy  which  requires  the event source
to match and support.  Therefore, event sink policy is not a concern
here. How to match the event sink capability/policy with the
capability/policy of the event source is addressed in a separate
contribution to 6692 -a, b, c, and d through policy negotiation, i.e.
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/00
50.html
<http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0
050.html>  )

	

	4. The ND does not support other MEPs (message exchange
patterns) in WSDL 1.1 and 2.0 except outbound, whereas wsdl based
approach (approach A) can supports     them out-of-the-box.

(Gill:  WS-Eventing does not require support for anything other than
one-way Notifications so this point is irrelevant. The EventDescriptions
element could easily be extended to support additional Notification MEPs
by some other spec. )
 
(Wu: This point is relevant as we should allow WS-Eventing to be
extended to support other use case with ease. The problem with
EventDescriptions is: it is a private data type outside wsdl 1.1/2.0 .
It is totally unclear what new inventions are needed for
EventDescription to support other MEPs, and if we should recommend other
spec to take this private data type further which is outside and
parallel to the standard wsdl specification. Even for the sake of
interoperability and WS-I Basic Profile (BP )  compliant, I am not sure
if it is a good practice to  introduce /use  private data types outside
wsdl 1.1/2.0  in web services.  )


	

	5. It requires tools and developers to familiarize with a new
XML dialect and its ND semantics, whereas in approach A, both WSDL and
optionally WS-Policy are well defined and widely used by the Industry
and other WS-* standards.

 (Gill:  Both approaches require developers to familiarize themselves
with new concepts and both approaches require either new tools or
changes to existing tools. The EventDescriptions approach relies on the
concept of transforming one XML document (containing the
wsem:EventDescriptions element) into another XML document (containing
the wsdl:definitions element). I assert that most web services
developers are familiar with the concept of transforming one XML
document into another and that the transformation described in Appendix
F of the EventDesriptions is simple and straightforward enough that most
people could do it by hand (though we probably should provide an XSLT
for convenience). Meanwhile the concept of linking individual WSDL
components to components in other WSDLs introduces a level of complexity
that is (a) difficult to describe in the level of detail necessary to
prevent interoperability problems (the current proposal certainly does
not do this) and (b) difficult for people to understand. For example,
the fact that you can use out:Outbound to create a single wsdl:port that
supports multiple bindings seems to contradict the normal WSDL semantics
of a 1-to-1 relationship between wsdl:port and wsdl:binding. )
 
(Wu: I would like to assert that it is not comfortable or a recommended
practice for developers to work outside the scope of the standard WSDL.
I also assert there is no need in approach A to provide any XSLT
transform or any private data type. The use of WS-Policy in approach A
is  o ptional, and it is consistent with the Industry trend of using
policy, instead of private data types, to address WSDL extensions.)


	

	Many thanks,

	- Wu Chou/Li Li