Re: WS-DD comments on WS-Eventing WD-ws-eventing-20090924

Doug,

Please see comments inline.

Cheers

Antoine Mensch
> My take on these....
> > 1.     A mechanism to relate the portType(s) of an event source Web
> > Service to the abstract description of the events it can produce is
> > needed. This mechanism cannot be solely based on WS-
> > MetadataExchange, as this information may be needed by clients at
> > design time, before any service endpoints are available. The draft
> > replaces the previous mechanism for advertising events produced by a
> > source, based on a portType extension (using both the wse:
> > EventSource attribute and notification and solicit/response
> > operations), by two new mechanisms, one introducing a new language
> > (Event Descriptions), the second one using a WSDL definition for the
> > sink. Both mechanisms provide an abstract description of the events,
> > but no mechanisms to relate them to the portType of the event
> > source. Rather, it is suggested to use new WS-Eventing dialects in
> > conjunction with WS-MetadataExchange to retrieve the descriptions 
> atruntime.
>
> I've heard similar comments before and I'm still confused by them.  :-)
> How did the Subscriber get the Event Source's WSDL to begin with? 
>  Whatever
> mechanism it used to retrieve that WSDL should be used to retrieve the
> Sink's WSDL or the Event Description stuff.  Not sure what we can do
> with this one - perhaps we should ask them for a proposal since, to me
> anyway, I'm not sure what the issue is.
In the context of DPWS, the Event Source's WSDL may be part of a Web 
Services specification describing a particular class of devices (such as 
a Printer, or a Dimmer, or a Valve). Clients may be written against such 
a specification and use the late binding mechanisms provided by 
WS-Discovery to retrieve actual devices and their hosted services using 
the Web Services portTypes described in the specification. Knowing that 
Web Services implementing a given portType also produce a given set of 
notifications is a valuable information that can help the client 
designer and developer. For instance, in our DPWS implementation, we use 
this information to generate handler skeletons used to process incoming 
notifications on the client side (Note that in the context of DPWS, we 
can normally assume that the binding used to send the notifications will 
be doc/literal, SOAP1.2 over HTTP + WS-Addressing, so information 
available in the abstract part of the WSDL in in general enough). The 
key point here is the explicit relation between the portType and the 
event types: I agree that we could retrieve Event Descriptions at design 
time in a way similar to that used to retrieve the WSDL, however if we 
cannot relate them to portTypes, we would need to introduce a new 
runtime mechanism, similar to the types mechanism used in WS-Discovery, 
to discover Event Sources based on a description of the notifications 
they can produce. This would seem highly redundant with the existing 
WS-Discovery mechanisms.

A proposal to solve this issue could be:
a) When using Event Descriptions:
- Introduce the Event Description language as a standard extension to 
WSDL 1.1, thus allowing Event Descriptions to be embedded in the local 
WSDL or imported from another WSDL.
- Optionally, introduce a new EventSet or EventInterface element in the 
Event Description language. This element would allow grouping of 
eventTypes in a single element, thus making external reference easier 
(much like a portType groups several operations).
- Introduce a new wse:EventSet (or wse:EventInterface) attribute, 
holding a QName, that could be used in WSDL portTypes to reference the 
EventSet element representing the list of events that can be produced by 
Web Services implementing the portType. Alternatively, if the EventSet 
element is not introduced, introduce a new wse:EventTypes attribute, 
holding a list of QNames, that could be used in WSDL portTypes to 
reference the list of eventTypes representing the list of events that 
can be produced by Web Services implementing the portType.

b) When using Notification WSDLs:
It is simpler, as the Notification WSDL could be directly inserted in 
the event source WSDL, or imported by it. The only extension required 
would be a new wse:NotificationPortType attribute that could be used in 
WSDL portTypes to reference the Notification Port type, which defines 
(although looking at them from the sink perspective) the set of events 
that can be produced by the portType.

Note that this proposal is only outlined to try to clarify the issue, 
and that any alternative solution that would solve the issue would be 
equally welcome.
>
>
> > 2.     Minor comments / requests for clarification:
> > In Section 4.1 Subscribe, it would be helpful to clarify if there is
> > any difference in behavior between a missing Filter element and a
> > Filter element that is present but empty.
>
> Behavior for an empty Filter is pretty much Dialect specific. 
>  Ignoring that the
> default is XPath, its possible that some filter dialects will in fact 
> filter
> stuff even w/o any child elements of the Filter element.  Maybe even 
> saying this
> is what they're looking for?  Perhaps getting them to formalize an
> issue and proposal would help make sure we address their concerns.
>
> > In Section 4.1 Subscribe, the description of wse:Filter says that
> > the Event Source MUST generate a wse:EmptyFilter fault if it
> > receives a Subscribe request with a filter that will never evaluate
> > to true for the lifetime of the Subscription, but Section 6.11 
> EmptyFilter
> > says that the fault MAY be sent. This should be made consistent. A
> > similar inconsistency exists with the wse:UnusableEPR fault.
>
> +1 - I think we should change the MAY to a MUST in section 6.11. I think
> this is just a consistency issue and can be editorial if the WG is ok 
> with it.
>
> > In Section 4.4 Unsubscribe, the text references faults defined for
> > Renew, mentioning that they are also applicable to Unsubscribe.
> > However, the only fault defined in Renew is wse:UnableToRenew, which
> > does not seem applicable to Unsubscribe.
>
> I think the latest editor's copy fixes this by talking about the soap
> faults.
>
> > In Section 4.4 Unsubscribe and Section 5 Notifications, the term
> > "subscribing event sink" is used several times. Should these be
> > replaced with the term "Subscriber" (defined in section 3.4
> > Terminology) to avoid confusion?
>
> Fixed
>
> > In Section 4.2 Renew and Section 4.4 Unsubscribe, the status of the
> > subscription after the failure of either request could be clarified
> > (e.g., that any existing subscription is unaffected).
>
> +1 - we should clarify this.  In fact we should probably check this
> for all specs in all fault conditions.  The state tables should help
> with this too.
>
> > In Section 5 Notifications: Uses of the XPath expression /s:
> > Envelope/s:Body/wse:Subscribe/wse:NotifyTo/ should be replaced by
> > /s:Envelope/s:Body/wse:Subscribe/wse:Delivery/wse:NotifyTo/ (in two
> > instances).
>
> Fixed.
>
> -Doug
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.421 / Virus Database: 270.14.13/2432 - Release Date: 10/13/09 06:35:00
>
>

Received on Tuesday, 13 October 2009 20:20:13 UTC