RE: [Team 6401]: simplified approach

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.

 

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.

 

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.

 

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.

 

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.

 

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. 

 

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? 

 

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.

 

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. 

 

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.

 

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.

 

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.  

 

 

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