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

Antoine,

I can see where you are coming from, though I need some time to think 
about it.

One thing I would like to note is that an Event Source (i.e. the 
endpoint that you send wse:Subscribe messages to) may not necessarily 
support any operations beyond those required to support WS-Eventing. 
Since the WS-Eventing operations are declared implicitly through the use 
of the wsep:EventSource policy assertion, you model this in WSDL with 
wsdl:bindings and wsdl:portTypes that contain no operations. I was 
wondering how this affected your bias towards linking event description 
metadata to wsdl:portTypes?

- gp

On 10/14/2009 12:59 PM, Antoine Mensch wrote:
> 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
>>
>>   
>