RE: [Team 6401]: simplified approach

Doug,

 

Options 3-5 in your email are not in WS-Eventing.  We are not sure if
they should be addressed without a normative definition/reference. 

 

Using raw+wrapped as an example, in composition approach, for 50 raw
events, there will be 50+1 operations in two (1+1) wsdls, one for raw
with 50 raw event operations, and one for wrapped with one wrapped
delivery operation. 

 

If each delivery option is a composable transformation as the wrapped
delivery, for n additional event delivery options beyond raw event
delivery, there will be 50+n operations in (n+1) wsdls,

 

- Wu Chou/Li   Li


________________________________

From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Saturday, June 06, 2009 8:46 AM
To: Chou, Wu (Wu)
Cc: Geoff Bullen; Gilbert Pilz; Li, Li (Li);
public-ws-resource-access@w3.org;
public-ws-resource-access-request@w3.org
Subject: RE: [Team 6401]: simplified approach



Wu, 
  to help me understand your proposal, take an event source that
supports the following Formats: 
1 - raw 
2 - wrapped 
3 - batched 
4 - ws-n compat raw  (yes this is different from #1) 
5 - ws-n compat wrapped 

and there are 50 different events that can be sent, using your proposal,
how many different messages, operations, portTypes... will the Source
need to have in its WSDL?   

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog. 



"Chou, Wu (Wu)" <wuchou@avaya.com> 
Sent by: public-ws-resource-access-request@w3.org 

06/05/2009 05:21 PM 

To
"Gilbert Pilz" <gilbert.pilz@oracle.com> 
cc
"Li, Li (Li)" <lli5@avaya.com>, Doug Davis/Raleigh/IBM@IBMUS, "Geoff
Bullen" <Geoff.Bullen@microsoft.com>, <public-ws-resource-access@w3.org>

Subject
RE: [Team 6401]: simplified approach

	




  
Gil, 
  
We should follow up this discussion with some conference calls, etc.,
maybe starting from our 6401 Task team. Instead of adding more comments
inline (which is too long already), we would like to add some
clarification points and structures to assist the discussion. 
  
WSDL Perspectives: 
A. The current composition approach for issue 6401 is based on the
Notification WSDL published by the Event Source. 
B. The "generative" approach" is based on the special
NotificationDescription metadata about Event Source, and both Event
Source and Event Sink need to separately generate (recover) the
Notification WSDL from NotificationDescription metadata according to a
set of mapping rules which need to be unambiguously specified by
WS-Eventing. 
  
It should be helpful that we organize our discussions by a two step
process: 
1.        Without wrapped event delivery 
If only raw events (no wrapped) delivery is involved, based on what we
heard so far, we can all agree that the current "composition" approach
based on the Notification WSDL is a better one, because the composition
approach is a typical web service development process and takes less
steps than the generative one. 
  
2.        With the additional wrapped event delivery 
As described in our comments, the final wrapped notification service can
be obtained from composing the raw event services and the generic
wrapped notification service. Therefore, it falls naturally to the web
service composition framework.  In your comments, the generative
approach can offer additional flexibility based on a set of mapping
rules to be specified by WS-Eventing. 
  
Some additional comments and analyses 
C1: One additional point to add to the issues/comments is: the
"composition" approach has the flexibility to mix third party service
modules derived from a different WSDL with its own, or it can switch one
service between different delivery options by turning on/off
interceptors. This is difficult to achieve for generative approach as
far as we can see. 
  
To illustrate the point, the following is a comparison of the processing
flows of the composition approach (Flow A) vs. generative approach (Flow
B), while ignoring other issues/details. 
A. Flow A - the "composition" approach 
Flow A (for both event sink and source): Notification WSDLs -->
wsdl2code --> stubs --> implement each stub individually --> deploy
multiple modules (interceptors) as one composed service 
  
For example, the end-to-end event delivery flow for both wrapped and raw
may look this in terms of interceptors: Raw event generator --> [raw
event] --> Wrapped event assembler -->[wrapped event] --> transport -->
Wrapped event disassmebler --> [raw event] --> raw event handler 
  
Adding any additional delivery format would result in an additional
interceptor in the same service. 
  
B. Flow B - the "generative" approach 
Flow B (for both event sink and source): NotificationDescription ->
transformation (mapping rules, control parameters) --> composed
Notification WSDL --> wsdl2code --> stub --> implement one big stub ->
deploy one module (interceptor) as one composed service 
  
For example, the end-to-end event wrapped delivery flow may look like
this in terms of interceptors: Wrapped event generator -->[wrapped
event] --> transport --> Wrapped event handler 
  
To support raw event delivery, it would require the deployment of
another service which corresponds to raw event interceptors. Adding any
additional delivery format would result in an additional service. 
  
Both approaches are for a common goal,  but they differ at the technical
means, and how to reuse existing web service architectures, processes
and tools.  We believe the "composition" approach based on Notification
WSDL is a better one. 
  
Thanks, 
  
- Wu Chou/Li Li 
Avaya Labs Research 



________________________________

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Wednesday, June 03, 2009 2:58 PM
To: Chou, Wu (Wu)
Cc: Li, Li (Li); Doug Davis; Geoff Bullen;
public-ws-resource-access@w3.org
Subject: Re: [Team 6401]: simplified approach

Wu,

Comments inline . . .

On 6/2/2009 9:00 AM, Chou, Wu (Wu) wrote: 
Gil, 
Here are some questions and comments regarding this second approach, and
we attached them below for discussion. 
Background: Two approaches are proposed to address issue 6401. 
A.        Current (composition) approach: 
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. 
B.        Second (generative) approach: 
It is based on the special NotificationDescription metadata information
attached to the event source for the subscriber to fetch and generate
event sink WSDL and construct the subscription messages. 
General Observation 
If needed, the "composition" approach can already support the
"generative" approach, should the subscriber choose to generate the
event sink by applying the WSDL mapping rules as in the "generative"
approach from the notification WSDL instead of the
NotificationDescription metadata information. 

I would say the exact opposite is true. The composition approach is a
subset of the generative approach in that, once you apply the
wsem:NotificationDescriptions->WSDL transformation, the resulting WSDL
is equivalent to the Notification WSDL. The key difference is that the
generative approach is based in XML Schema GEDs which can be easily
inserted into Notifications of various formats without altering the
structure of the Notification Type. The problem with the composition
approach is that, due to its complexity, WSDL is not well suited as a
description language for messages that may take on a variety of
different forms depending upon the value of @Format. 
 There are (multiple) solutions in the composition approach that can be
used to address issues from event sink options, which include the
generative approach as special cases, since the Notification WSDL in the
composition approach entails the NotificationDescription metadata
information. 

It's true that there are multiple solutions to this problem. I would
argue that the composition approach is more complicated than the
generative approach. In addition to this, the "composition" approach
requires the Event Source to advertise multiple Notification WSDLs that
include wsdl:messages, wsdl:operations, etc. for every possible
Notification Type, whereas the generative approach allows the Event Sink
to generate a single WSDL that covers only the subset of Notifications
that it selects (via @Filter) to receive. 
 Questions and Comments 
However, NotificationDescription is not a WSDL based web service
description, and it raises several issues/questions. We list some of
them below for discussion. 
1)     Although it considers the WSDL for notification operations, it is
not clear how to handle the WSDL for solicit-response operations in this
approach. And both operations can co-exist for an event source in some
web services, e.g. ECMA CSTA. 

WS-Eventing should not support solicit-response operations. As you are
doubtlessly aware, they are forbidden by R2303
<http://www.ws-i.org/Profiles/BasicProfile-1.1.html#Allowed_Operations>
of the Basic Profile. We shouldn't encourage users of WS-Eventing to
create non-BP compliant applications. We shouldn't require vendors to
support non-BP compliant operations in their tooling. Of course, people
are still free to use solicit-response operations if they wish, but
WS-Eventing is not required to help them in this effort. 
2)     It loses port types and operations, which are used by many web
services standards to define normative profiles. 
3)     Because of losing port types and operations, the event source
loses the ability to attach WS-Policy to operations, port types or
bindings for the subscriber to check before the event subscriptions. And
these capabilities are crucial. 

You must have missed the part in my previous email where I said: 
What has been lost in this proposal are the mechanisms for supporting
policy advertisement and agreement for Notifications. I believe that (a)
this should be handled as a separate issue and (b) we shouldn't
advertise an Event Source's policies by attaching them to WSDLs that are
intended to implemented by the Event Source; rather we should use policy
nesting to indicate the policies that apply to the application endpoint,
the WS-Eventing protocol, and the Notifications. 
No one is debating the importance of allowing the Event Source to
advertise the set of policies that may be applied to Notifications, it's
simply a matter of (again) what is the simplest, most effective way of
doing this. Requiring the Event Source author/administrator to maintain
a consistent set of policies across a potentially large set of
Notification WSDLs is burdensome and error prone.

4)     If code generation is the motivation behind the generative
approach, it is unclear how the event source generates client side code
to send appropriate notifications according to the
NotificationDescription based on the current web services tooling. 

I'm sorry, but I thought that this was obvious. For raw Notifications
the Event Source behaves as if it (1) generates the raw Notification
WSDL from the wsem:NotificationDescriptions, (2) generates client stubs
from this WSDL, (3) uses those client stubs to transmit Notifications. I
say "as if" because it is up to the implementation of the Event Source
whether or not these steps are literally followed. In the case of
wrapped Notifications it may not need/want to generate any code. In the
case of raw Notifications it may know how to interpret the
wsem:NotificationDescriptions directly. What is important is that, given
a description of a Notification Type in a wsem:NotificationDescriptions
and the Format of the subscription (raw, wrapped, batched, etc.), it is
possible to deterministically describe what the Notification messages
look like on the wire. The
wsem:NotificationDescriptions->WSDL->wire-level-message mapping provides
us a way to leverage the existing standards and tools to make sure there
is no ambiguity about what will appear on the wire. 
 5)     If the flexibility is the motivation behind the generative
approach, it is unclear if the event source needs to generate all
possible client side code and implement the support for all possible
event sink combinations that the potential subscribers may generate from
NotificationDescription. If this is the case, there is no savings for
the event source. 

You are right, there is no savings for the Event Source in the
generative approach, but there is a potential savings for the Event
Sink. 
 6)     From (5), it is not clear how to ensure the client side code
generated by the source can match the event sink generated by the
subscriber. In other words, how to ensure that the notification WSDL
generated by the sink side from NotificationDescription metadata is
compatible with the event source side client code as they are generated
separately by each side and not communicated to each other? 

Again, this seems rather obvious; the rules for generating the raw
Notification WSDL from the wsem:NotificationDescriptions are the same
for the Event Source as they are for the Event Sink. Given the same
wsem:NotificationDescriptions and the same set of rules, you arrive at
the same WSDL, which brings us in line with the composition approach. 
 7)     It is unclear what the conformance requirement will look like
for the event source based on NotificationDescription metadata and not
based on a WSDL description in a web service standard. 

I don't understand what you mean by this. 
 8)     It introduces a new transformation from the metadata
NotificationDescription->WSDL in addition to WSDL->code. This may
require a significant upgrade to the current toolkits to support
NotificationDescription->WSDL mapping, which is at another layer and
something can go wrong without sufficient debugging support. 

This is the same argument I made when Avaya asserted that it was
possible to transform a WSDL-based description of a raw Notification
into it's equivalent wrapped Notification. The difference is that the
generative approach includes a simple set of rules for performing the
wsem:NotificationDescriptions->WSDL transformation whereas the
compositional approach, so far, has no description of how to transform a
WSDL-based description of a raw Notification into it's equivalent
wrapped Notification. I can build a simple XSLT that will perform the
transformation from NotificationDescriptions to WSDL, whereas you are
going to have a very hard time telling me how to transform the following
message/operation into its wrapped equivalent:

 <wsdl:message name="Notification">
   <wsdl:part name="body" element="ns:Event"/>
   <wsdl:part name="header" element="ns:Topic"/>
 </wsdl:message>

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

 <wsdl:binding ...>
   ...
   <wsdl:operation name="Notification">
     <wsdl:input>
       <soap:header use="literal" part="header"
message="tns:Notification"/>
       <soap:body use="literal" parts="body"/>
     </wsdl:input>
   </wsdl:operation>
   ...
 </wsd:binding>

See the problem? What are you going to do with the ns:Topic header
element? And this is only one example of the fun things that I can do
with WSDL that might cause you problems. I'm not saying that it is
impossible to define the transformations you require, only that it will
be far more complex because, so far, the composition approach has done
nothing to constrain the optionality of the Notification WSDL (i.e.
Notification WSDLs can use RPC-literal binding styles etc.) 
 9)     It may lead to a situation where many sinks and sources waste
their resources and time to repeatedly generate the same notification
WSDL file (except the service location).  Whereas in the composition
approach, one copy of Notification WSDL at the event source can be
shared by millions of similar sinks to generate code. This is critical
to make web services light on small devices. 

You seem to have a particular model in mind in which the Notification
WSDL needs to be re-generated at runtime for every subscription, but
nothing in my proposal mandates or even recommends such a model. There
is nothing to prevent one from obtaining the NotificationDescriptions
element at build time, transforming it to WSDL, and generating code from
that. 
 10)  It is not clear how a subscriber can verify the generated event
sink WSDL to be a correct one. In the worst case, many sinks and sources
can incorrectly generate incompatible WSDL files from the same
NotificationDescription metadata, due to different mapping
implementations. And service interoperability and compatibility can be
in question. 

It's up to WS-Eventing to clearly and unambiguously define the mapping
from NotificationDescriptions to WSDL. If, given such a description, an
implementation of the tools used by the Event Source and Event Sink does
the wrong thing, what can one say? Implementations are not always
correct, but I fail to see how that applies particularly to my proposal.
In actuality, the mapping from NotificationDescriptions to WSDL is so
straightforward that any reasonably skilled programmer should be able to
look at the generated WSDL and determine if it is correct. 
11)  The "composition" approach is inline with current WS-* practices
where services defined in different WSDL files are composed at runtime
according to predefined rules. Following this approach, there is no need
to expand all possible compositions in WSDL files. 
Take WS-Addressing as an example, it can be composed with many web
services, but none of these web services needs to expand their WSDL
message definitions to include the WS-A headers. Rather, these services
just use WS-A metadata to insert a few policy assertions to indicate
they are composed with the WS-A. How the WS-A is actually composed with
a service is defined by the WS-A soap binding rules. 
In the "composition" approach, the wrapped notification WSDL and a raw
notification WSDL can be regarded as two web services that can be
composed and the composition rule is defined by the wrapped notification
service. 

This would be fine if we could constrain Event Sources to only
supporting one kind of Format per a given set of Notification Types. If,
however, we need to support a use case in which a single Event Source
(defined by a single Subscription Endpoint EPR) must support either raw
or wrapped (and potentially batched and other extended Formats) delivery
of the same set of Notification Types, selectable at runtime by the
Subscriber (via the @Format attribute), then the composition approach
isn't going to cut it. 
Wu Chou/Li Li   
Avaya Labs Research 



________________________________

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com
<mailto:gilbert.pilz@oracle.com> ] 
Sent: Thursday, May 28, 2009 7:56 PM
To: Chou, Wu (Wu); Li, Li (Li); Doug Davis; Geoff Bullen
Cc: public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org> 
Subject: [Team 6401]: simplified approach

Attached is an outline of a new proposal for addressing 6401. As I
stated on last week's concall, the previous approach (based on the idea
that the Event Source should advertise a separate Notification WSDL that
described the notification interface from the Event Sink's perspective)
had run into a number of issues. Foremost amongst these was how to
describe the relationship between the Notification Type as expressed in
the form of a raw Notification in WSDL and that same Notification Type
as it may appear in a wrapped Notification. Another problem was how to
handle the case where there are a very large number of possible
Notification Types, but the Event Sink is only interested in, and (via
filtering) will only receive a small subset of those Notifications.

The attached proposal is similar to the previous proposal but simplifies
things to a certain extent. Rather than attempting to express
Notification Types directly in WSDL, it simply describes them in XML
Schema. The Notification Types, their schema, and their associated
action URI are encapsulated in a new WS-MEX dialect called
NotificationDescriptions. Once retrieved, a NotificationDescriptions
document can be used to generate a WSDL (via a simple set of mapping
rules), but it can be used in other ways depending upon the @Format of
the subscription. Finally this proposal touches on the notion of a new
filter dialect that directly references the information in the
NotificationDescriptions for a more efficient way of selecting
individual Notifications from a set.

What has been lost in this proposal are the mechanisms for supporting
policy advertisement and agreement for Notifications. I believe that (a)
this should be handled as a separate issue and (b) we shouldn't
advertise an Event Source's policies by attaching them to WSDLs that are
intended to implemented by the Event Source; rather we should use policy
nesting to indicate the policies that apply to the application endpoint,
the WS-Eventing protocol, and the Notifications. For example:

<wsp:Policy>
 <foo:PolicyThatAppliesToApplicationEndpoint/>
 <wsep:Eventing>
   <bar:PolicyThatAppliesToWSEventingProtocol/>
   <wsep:NotificationPolicy>
     <zoo:PolicyThatAppliesToNotifications/>
   </wsep:NotificationPolicy>
 </wsep:Eventing>
<wsp:Policy>
 
- gp