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 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"/>
    </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] 
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
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