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

> Antoine Mensch
> ...
> 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.

I'm still not totally clear on the exactly scenario here because it 
feels a bit like there are certain assumptions being made.  For example,
it sounds like people are assuming that a single WSDL file is enough
to get their work done.  And while its possible to create a single WSDL
file that contains everything, its also possible that someone could design
things so that the WSDL is split into multiple files, and the schema isn't
part of the WSDL at all.  This means that unless you're going to require 
that
everyone design their WSDL is one particular way, then you need to be 
prepared
to deal with retrieving mulitple files - whethers its WSDLs, XSDs or Event
Descriptions.  And, likewise, any relationship between these various
artifacts would have to be expressed somehow - even if implicit because
they were all sent in one package.  So, to me the relationship to the
portTypes you're referring to can still be achieved at design time.  But
I suspect I'm still missing something.

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

-Doug