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

Doug,

Even if you limit the role of the WSDL to the description of the 
contract that a service offers to clients, I think it is still important 
that, as part of this contract, a service that is also an event source 
advertise:
1) The fact that the service is an event source, and so can serve 
subscription requests.
2) The set of events that one may receive when subscribing to the event 
source. This set should be somehow linked to one of the WSDL objects 
representing the service, in order to allow both people and tools to 
relate the service and the events.

Again, the proposal I sent as a complement to the issue is just an 
illustration of a possible solution, but any alternative that would 
fulfill the above requirements would be equally fine. For instance, if 
you feel that the use of a "master" WSDL is not the most appropriate, 
the Event Descriptions document could be used instead to import the 
event source WSDL and reference the portType of the event source using 
its QName, thus establishing the logical link between the event source 
and the event types. Such an approach would have the advantage of not 
requiring any extensions to the standard WSDL syntax.

Cheers

Antoine


Doug Davis a écrit :
>
> Antoine,
>   thanks, that helps.  And I'm sure that this thread will be an 
> interesting one within the WG :-).  It seems that the main issue here 
> is whether or not WSDL is the "master" document that you call it.  I 
> think people will agree that from the perspective of advertising how a 
> client can initiate MEPs with the service, yes it is the "master". 
>  However, whether that same WSDL file is the "master" for all MEPs 
> initiated by the service is not something I'm sure we have agreement 
> on.  Once BP banned the use of Notification style MEPs it, IMO, helped 
> solidify the idea that WSDL from a ?WSDL query is really a one-way 
> contract (client->service) and not a general purpose doc that 
> describes all comings and goings for a service.  But, as I said, it 
> should be an interesting discussion.
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
>
>
> *Antoine Mensch <antoine.mensch@odonata.fr>*
>
> 10/14/2009 03:59 PM
> Please respond to
> antoine.mensch@odonata.fr
>
>
> 	
> To
> 	Doug Davis/Raleigh/IBM@IBMUS
> cc
> 	public-ws-resource-access@w3.org
> Subject
> 	Re: [ws-dd] Re: WS-DD comments on WS-Eventing WD-ws-eventing-20090924
>
>
>
> 	
>
>
>
>
>
> Doug,
>
> let me try to clarify (see below)
>
> Cheers
>
> Antoine
>
> Doug Davis a écrit :
> >
> > 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.
> >
> >
> The issue is not related to the way WSDL information is organized or to
> the number of documents used to hold the information: I assume (like
> most tools do) that there is a master WSDL document that can import or
> include additional WSDL or XSD documents using both namespace references
> and absolute or relative URIs (note however that I don't know how I
> would include or import an Event Descriptions document from a master
> WSDL, unless it is embedded in some way in a WSDL - but that's only a
> minor part of the issue).
>
> Rather, the issue relates to the lack of logical relationship between
> the WSDL information model and the event types. A WSDL defines a number
> of objects (endpoints, services, bindings, portTypes, operations,
> messages) that are linked by navigable relations, so for instance it is
> possible to know the set of operations and messages supported by an
> endpoint by navigating from the endpoint to its binding and its
> portType. The previous version of the spec used Notification and
> Solicit/Response operations (that are built-in WSDL objects) to describe
> event types, so the built-in WSDL relations could be used to relate a
> portType or an endpoint to the events it would generate. Because the new
> version of the spec introduces new objects in the information model
> without defining a way to relate them to existing WSDL objects, it is
> impossible to use the WSDL to relate portTypes or endpoints to event
> types. So my suggestion was just to add a way to relate the new event
> types to existing WSDL objects, and in particular to portTypes, which
> seems the appropriate concept (event types, which are abstract, can be
> seen as part of the interface of a service, much like operations are).
> > ------------------------------------------------------------------------
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 8.5.421 / Virus Database: 270.14.15/2434 - Release Date: 
> 10/13/09 19:11:00
> >
> >  
>

Received on Thursday, 15 October 2009 09:09:00 UTC