Re: [Team 6401]: simplified approach

Wu,

Once again, comments inline . . .

On 6/5/2009 2:21 PM, Chou, Wu (Wu) wrote:
>  
>
> 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.
>
I'm not sure I agree with this. Even if we didn't have to worry about 
Raw Notifications, the simplified/generative approach has the following 
advantages:

   1. The simplified/generative approach is . .  well . . simpler. One
      only has to look at Figure B-1 from your latest version of
      "6401_proposal
      <http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/0170.html>"
      to be convinced of this. To be honest, I still don't understand
      how the latest version of the composition approach is supposed to
      work. There are a lot of linkages between Event Source WSDL
      components and Notification WSDL components, but no clear example
      of how you expect this information to be used. Another thing that
      worries me is your use of local IDs as generic labels to identify
      multiple, different policy expressions.
   2. The (previously mentioned) fact that the Event Sink is not
      required to generate service stubs for every possible Notification
      Type that the Event Source supports; only those that it is
      interested in receiving.
   3. If I, as a Subscriber, am interested in constructing a filter I
      need to be able to trace a path from the Subscription Endpoint to
      a set of XML Schema GEDs that define the Notification Types that
      may result from a successful subscription. It is much easier to
      follow this linkage using the simplified/generative approach than
      the one described by the composition approach (which, again, I
      don't really understand). 

>    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.
>
I'm sorry, but I really don't know what you mean when you say "obtained 
from composing the raw event services and the generic wrapped wrapped 
notification service", and this frustrates me a great deal. You refer to 
"interceptors", and "service modules" below but it's not explicitly 
clear how all of this would work and, more importantly, whether it would 
work on any SOAP stack other than the one Avaya is using.
>
> *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.
>
Before we get into whether or not the simplified/generative approach can 
support "mixing third party service modules derived from different 
WSDLs", could we discuss why you would want to do such a thing? We're 
missing any explanation of the use case for this functionality.
>
> 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.
>
If you are writing an Event Sink that is capable of receiving Raw 
Notifications and you've  generated service stubs that can process and 
dispatch those Notifications, why would you want to create additional 
code modules for processing those same Notification Types as Wrapped 
Notifications? It seems like a lot of extra deployment and configuration 
work coupled with extra, per-Notification runtime overhead just to get 
the same information.
>
>  *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.
>
Again, I don't understand the use case but, FWIW, none of this is true. 
Since the simplified/generative approach defines the mapping between 
Notification Types and both Raw and Wrapped Notifications, it would be 
straightforward to write a SOAP message handler that looked for the 
presence of the wse:Notify element as the first/only child of the SOAP 
Body and, if it were there, transformed the message into it's Raw 
equivalent by promoting wse:Notify/[child] to SOAP Body [child] and 
setting [action] to wse:Notify/@actionURI.
>
>  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.
>
I think we've reached the limit of what can be discussed and agreed to 
in the abstract. I'm going to submit a concrete proposal that contains 
the simplified/generative approach. If you would like to write a 
concrete proposal that contains the composition approach, we can compare 
proposals.

- gp
>
>  
>
> 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.
>>
>>    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