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