W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > October 2009

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

From: Antoine Mensch <antoine.mensch@odonata.fr>
Date: Mon, 19 Oct 2009 14:23:52 +0200
Message-ID: <4ADC5A58.8090706@odonata.fr>
To: Gilbert Pilz <gilbert.pilz@oracle.com>
CC: Doug Davis <dug@us.ibm.com>, public-ws-resource-access@w3.org

WSDL portTypes with no input operations are fine: with the mechanism 
proposed in the previous version of the spec, we've encountered several 
cases of output-only portTypes, which would translate to empty portTypes 
in the new version. The important point is that we can retrieve 
endpoints implementing those event source portTypes in the same way as 
endpoints implementing "regular" portTypes, using the mechanisms 
specified in WS-Discovery and DPWS, which rely on the use of QNames 
referencing portTypes.

Since I sent my first mail, I've been pointed by Doug to the editor's 
draft of the spec, which contains more details on the use of policy 
assertions. Basically, I think we could use assertions to attach the 
required informations to portTypes provided that:
1) EventSource assertions can be attached to portTypes. I don't 
understand why it is explicitly forbidden at the moment. Nothing in the 
information provided by the policy assertion seem directly related to 
transport aspects. Some may be related to deployment aspects (e.g. the 
support of a wall clock), but that remains limited. For us, knowing that 
a portType is the interface of an event source is very important 
(portTypes are the pivot information used in WS-Discovery and DPWS).
2) There is an additional parameter (as an embedded element of the 
assertion) that would somehow reference the event types that can be 
produced by the event source.



Gilbert Pilz a écrit :
> 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
Received on Monday, 19 October 2009 12:24:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:52 UTC