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.
>
>    1. 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.
>
>    2. 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"/>
    </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