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

It seems to me that the MOAP proposal would solve their problem IF we 
dropped the restriction of not allowing policy assertions on PortTypes.  I 
have no idea why we have this restriction.  I have a strong feeling that 
when the first proposal was put together the text was just copied the 
WS-Addressing spec and the restriction doesn't need to apply to us - there 
is no binding specific info in our assertions.

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> 
01/22/2010 05:08 AM
Please respond to
antoine.mensch@odonata.fr


To
Doug Davis/Raleigh/IBM@IBMUS
cc
Toby Nixon <Toby.Nixon@microsoft.com>, ws-dd@lists.oasis-open.org, 
public-ws-resource-access-comments@w3.org
Subject
Re: [ws-dd] Re: WS-DD comments on WS-Eventing WD-ws-eventing-20090924






Doug,

Please find below some answers to the questions you raised, as well as a 
couple of proposals for solving the issue.

A little bit of background of our own: part of the misunderstanding may 
come from the fact that applications using WS-Discovery and DPWS make 
use of WSDL documents in a slightly different way than other apps. While 
WSDL documents are normally used by clients to retrieve both the 
abstract information (XSD, messages, portTypes) and the concrete 
information (bindings, policies, network endpoints) about a service, 
WS-Discovery and DPWS clients (e.g. a printer driver) are often 
implemented using only the abstract part, which defines the "service 
interface" and which is known at design time, and use WS-Discovery to 
retrieve network endpoints implementing the corresponding interface at 
runtime, using the service portType QName as identifier for the 
requested interface. In the case of DPWS clients, they may safely assume 
that all services will at least support a "doc/literal, 
SOAP1.2-over-HTTP + WS-Addressing" binding at the network endpoints 
advertised through WS-Discovery messages, thus avoiding the need to 
obtain specific binding information for the service (note that this is 
not the case for the more general WS-Discovery protocol, which assumes 
that binding information is provided though extensibility or 
out-of-band). In short, many DPWS clients do not need and are not 
capable of using WSDL information at run-time.

Reasons for relying on design time information and for limiting the use 
of binding and policy information at runtime and defining a simple 
"standard" binding as a common ground for interoperability include:
1. Many DPWS clients (especially C-based ones) rely on code generation 
approaches for producing the stubs allowing them to interact with 
devices and hosted services, and therefore only use design time 
information.
2. DPWS clients may run on very constrained platforms, and may not have 
the capabilities of interpreting WSDL or policy documents and 
accordingly adapting their behavior.

The mechanism proposed by the WS-Eventing member submission is currently 
used by three different entities:
* Client: The client knows that it can subscribe to a given service 
endpoint implementing a given interface by looking at its portType 
specification, which must have the eventSource attribute set to true.
* Event sink: an event sink can set up the appropriate event handling 
code  (often through static code generation on C-based embedded devices) 
by looking at the events specification expressed as output messages in 
the event source portType. Note that in principle, WSDL binding (and 
event format) information should be necessary to generate the 
appropriate code, but in the specific case of DPWS, we assume 
doc/literal style, raw event format (i.e. the format specified by the 
XML Schema element referenced by the message), and the existence of a 
binding using SOAP1.2 over HTTP and WS-Addressing.
* Event source: notification functions allowing the user to send event 
notifications may also be statically generated on the event source side, 
using the same binding assumptions.

Our main point is that because many existing applications use the 
mechanism proposed in the member submission, it is important that an 
equivalent mechanism be proposed in the final version of the standard. 
The fact that this mechanism relies on design time information is a 
critical aspect of the requirement.

Now to answer your questions more specifically:

    1 - why does the description of the events need to be associated
    with the event source's portType? Is there something special about
    the portType that is of interest to the WSDD community or is it
    simply because that's where the information was available before?

Two complementary answers:

1. From a "theoretical" point of view, the capability of producing 
events can be considered as part of a service interface specification, 
so the portType is the right place to provide or reference this 
information.
2. From a practical point of view, WS-Discovery and DPWS clients use 
portType QNames to look for Target Services on the network (in the Probe 
messages), and select hosted services within devices once the device has 
been discovered (in the DPWS metadata information).
If eventing information is attached to something that is not an event 
source portType (hopefully identified by another QName defined 
elsewhere, otherwise it may not be usable in discovery messages), Target 
Services and hosted services will need to add this information to their 
type characterization (so that a client could look for an event source 
of a certain type), and client will need to add this information to 
their probe or hosted service selection request. The change in 
WS-Eventing would therefore have an impact beyond the mere eventing 
protocol.

    2 - would it be sufficient for the same information to be available 
but just someplace else that's just as easy to examine?
 

It has to be part of the event source contract known at design time. If 
you find a way to associate it to the contract (e.g. through policy), it 
would be fine. However, it cannot be attached to a particular binding, 
as this is not used in discovery and DPWS metadata. Attaching it to 
another QName could work, but with some significant impact (see above). 
So to be clear attaching it to the portType seems the best solution.
Providing the information without formally relating it to the event 
source portType (e.g. through a totally independent Notification WSDL or 
Event Descriptions document with no link to the event source portType) 
would just mean that the client would have to be told in an unspecified, 
out-of-band way that when a service implements a given portType, it is 
actually also an event source that produces the specified events.

    3 - is it the shape of the events that's of interest or is it the 
shape
    of the notifications?  or both?   To be clear, events represent the 
raw
    data itself, while notifications represent the format/serialization of 
those events on the wire within a SOAP envelope.
 

As explained above, DPWS so far assumes raw events and the "DPWS" 
binding. So raw events would be enough to maintain the existing level of 
functionality.

    4 - for what purpose is this "shape" needed?  For example, is it 
because the sink needs to know what kind of soap messages to expect, or is 
it so the Subscriber knows what kind of xpath expression to create for the 
filter?  Or for event process later on down stream long after the event 
has been extracted from the soap envelope?
 

The shape of events is often needed for code generation on both the 
event sink (server skeletons) and event source (client stubs) sides. 
DPWS has profiled out XPath filtering, so it is not an issue for the 
client.

    5 - the topic of having access to this information at design time, 
rather than runtime, is mentioned - this implies that the use of WS-MEX to 
get the EventDescription data or Notification WSDL might not be an option. 
 However, if the WSDL of the Event Source is available at design time how 
was this made available to the Subscriber?
 

The Subscriber is a client that can be designed to interact with a 
number of services, some of which being event sources (think of a 
printer driver designed to interact with a given printer model, which of 
course has an available abstract WSDL description for all its hosted 
services). Because DPWS assumes a predefined binding, needed subscriber 
code generation can be performed based on schema, messages and portTypes 
information available statically. When going live, the subscriber can 
use WS-Discovery and the service portTypes to find devices and hosted 
services compliant with the specification it has been coded for. So to 
answer your question about availability, the WSDL can be made available 
through many different means (as an appendix to a specification 
document, through e-mail, on a vertical standards Web site, on a vendor 
Web site, etc...), not relevant to the behavior of the subcriber at 
run-time.

    6 - is there something special about the Event Source WSDL, or the 
mechanism by which it was made available, that would preclude other 
metadata from also being made available through this same mechanism?
     For example, does this mechanism only allow a single document to be 
shared instead of multiple?
 

Event source WSDLs are handled like any other WSDL in the development of 
DPWS clients and services. The only specificity is the necessary 
adaptation of the code generation mechanisms to the use of output-only 
operations, and the fact that clients may need to become servers to 
handle notifications. I don't know what type of metadata you have in 
mind, but what is important is that this metadata is available at design 
time.
I think there is a misunderstanding about the "single document" issue. 
There is no specific requirement about having a single WSDL document: 
information can be spread in various documents, linked together using 
the usual XSD and WSDL import directives. Because eventing information 
in the member submission is provided in the event source portType, and 
because WSDL portTypes are defined as a single monolithic XML element, 
DPWS tools currently obtain all the needed eventing information from a 
single document, but they could be adapted to retrieve this information 
in different documents if needed, as long as navigation links are 
provided to build the "complete picture".

Possible solutions (based on basic extensions of mechanisms proposed in 
the latest WS-Eventing editor copy):
- *Add an attribute **to the Notification WSDL portType that **contains 
the event source portType QName * (this assumes that the Notification 
WSDL imports the event source WSDL): this will allow a client knowing 
the existence of the Notification WSDL to retrieve the corresponding 
event source portType. This approach will have the additional advantage 
of explicitly identifying the Notification portType as a notification 
portType (currently, there is no intrinsic information that 
distinguishes a Notification WSDL from a standard WSDL). The main 
drawback of this approach is that the Notification WSDL becomes the 
"entry point" for the complete service interface description: just 
looking at the event source portType does not indicate that it is an 
event source.
- *Add an attribute ** to the event source portType that **contains the 
Notification WSDL portType(s) * (this assumes that the event source WSDL 
imports the Notification WSDL): This would be equivalent to the 
information provided in the member submission: the event source portType 
is clearly identified as such, and the event specifications are 
available in the Notification WSDL portTypes. The fact that there could 
be several Notification portTypes could be handled by allowing a list of 
QNames in the attribute (although only one is required to achieve the 
level of functionality currently used by DPWS).
- *Add a attribute to the event source portType that contains a QName 
identifying a set of event types in an Event Description document* (note 
that this would require the introduction of a named EventSet element in 
event descriptions): because DPWS only require the abstract descriptions 
of events, event descriptions can be used, as they provide the right 
amount of information.
- *Use policy attachments to establish the above associations*: they 
would allow more flexibility to establish the kind off 1-n or n-m 
association that are needed. However, it is important that such policy 
attachments be attached to portTypes, and not bindings or endpoints (I 
don't understand why this is explicitly prohibited in the current 
version of the spec).

Important note: in the above proposals, the use of Notification 
*portType*s is on purpose, as it is the only information that is 
guaranteed to be available at design time.

Cheers

Antoine Mensch


Doug Davis a écrit :
>
> Toby/WSDD members,
>   For point #1 we opened issue 8198 [1].  We'd like to better 
> understand your concerns with the changes that have gone into 
> WS-Eventing and how we might be able to address them. 
>
>   First a bit of history/background..., as observed in your note the 
> mechanism by which a Subscriber can determine the shape of the events, 
> and the notifications that are sent, has changed from the member 
> submission.  In the member submission, there was a single portType 
> that contained the Event Source's operations (e.g. Subscribe) as well 
> as the definition of the outgoing Notifications as output-only 
> operations.  As I'm sure everyone knows, the output-only operations 
> were removed mainly due to our attempt to be WS-I Basic Profile 
> compliant.  However, there are other factors that play into it.
>
>   One of the first changes that we made in WS-Eventing was to define 
> the notion of a Notification Format. This allows a Subscriber to ask 
> the Event Source to format the Notifications in a particular way.  For 
> example, one Format may ask for the Events to be transmitted in a 
> 'raw' format, meaning pretty much untouched and each Event is simply 
> copied into the SOAP Body of the Notification message.  While another 
> format may ask for them to be 'wrapped' with a well-defined/common 
> element - thus allowing Event Sinks to have a single 
> operation/receiver to process all Notifications.  With this ability, 
> and extensibility point, a single Event Source might support sending 
> out Events in a large number of different formats.  This means that 
> even if we did allow the use of output-only operations, putting all of 
> these into a single portType would be quite overwhelming - almost to 
> the point of being useless unless there was a way for a Subscriber to 
> know which operations/messages/notifications were actually of interest 
> it.  Thus, as you've noted, the Event Source's WSDL was separated from 
> the description of the Events as well as the description of the 
> Notification messages themselves.  Given the potentially large number 
> of WSDLs available, it makes more sense to have people ask for the 
> Notification WSDL based on the Format used within their particular 
> Subscribe request.  And, all of this is available through the use of 
> WS-MetadataExchange with the Event Source.
>
>   Now, to your note... it talks about the need to be able to associate 
> the events produced by an event source with the event source's 
> portType.  However, I'd like to dig a little deeper into this by 
> asking some questions:
> 1 - why does the description of the events need to be associated with 
> the event source's portType?  Is there something special about the 
> portType that is of interest to the WSDD community or is it simply 
> because that's where the information was available before? 
> 2 - would it be sufficient for the same information to be available 
> but just someplace else that's just as easy to examine?
> 3 - is it the shape of the events that's of interest or is it the 
> shape of the notifications?  or both?   To be clear, events represent 
> the raw data itself, while notifications represent the 
> format/serialization of those events on the wire within a SOAP envelope.
> 4 - for what purpose is this "shape" needed?  For example, is it 
> because the sink needs to know what kind of soap messages to expect, 
> or is it so the Subscriber knows what kind of xpath expression to 
> create for the filter?  Or for event process later on down stream long 
> after the event has been extracted from the soap envelope?
> 5 - the topic of having access to this information at design time, 
> rather than runtime, is mentioned - this implies that the use of 
> WS-MEX to get the EventDescription data or Notification WSDL might not 
> be an option.  However, if the WSDL of the Event Source is available 
> at design time how was this made available to the Subscriber?
> 6 - is there something special about the Event Source WSDL, or the 
> mechanism by which it was made available, that would preclude other 
> metadata from also being made available through this same mechanism? 
>  For example, does this mechanism only allow a single document to be 
> shared instead of multiple?
>
> I'm trying to get a sense of the higher-level requirements that are 
> trying to be addressed rather than focus on one particular solution.
>
> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8198
>
> thanks
> -Doug Davis
> ______________________________________________________
> 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.
>
>
> *Toby Nixon <Toby.Nixon@microsoft.com>*
> Sent by: public-ws-resource-access-comments-request@w3.org
>
> 10/13/2009 01:07 PM
>
> 
> To
>                "public-ws-resource-access-comments@w3.org" 
> <public-ws-resource-access-comments@w3.org>, Bob Freund 
> <bob.freund@hitachisoftware.com>
> cc
>                "ws-dd@lists.oasis-open.org" 
<ws-dd@lists.oasis-open.org>, Toby Nixon 
> <Toby.Nixon@microsoft.com>, Lawrence Lamers <ljlamers@vmware.com>, 
> Michael McIntosh/Watson/IBM@IBMUS, Chris Kaler <ckaler@microsoft.com>, 
> "Anthony Nadalin" <tonynad@microsoft.com>, Mike Edwards 
> <mike_edwards@uk.ibm.com>, Alain Regnier <alain@ussj.ricoh.com>, Xiao 
> Chuan <cxiao@fudan.edu.cn>, "Gert Sylvest" <gert.sylvest@avanade.com>, 
> Josh Cohen <joshco@microsoft.com>, Jonathan Marsh <jonathan@wso2.com>, 
> Marc Goodner <mgoodner@microsoft.com>, Paul Fremantle <paul@wso2.com>, 
> Mikkel Hippe Brun <mhb@itst.dk>
> Subject
>                WS-DD comments on WS-Eventing WD-ws-eventing-20090924
>
>
>
> 
>
>
>
>
>
> Dear colleagues in W3C WS-RA WG:
> 
> The OASIS Web Services Discovery and Web Services Devices Profile 
> (WS-DD) Technical Committee reviewed the draft WS-Eventing, 
> WS-MetadataExchange, and WS-Transfer specifications as requested in 
> your email on September 26 (we did not review the other specifications 
> because they are not referenced in DPWS). As a result of this review, 
> we submit to you the following substantive comment and several minor 
> editorial/clarification comments on WS-Eventing:
> 
> 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 at runtime.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 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).
> 
> 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).
> 
> Thank you very much for the opportunity to participate in the preview 
> of the Last Call drafts.
> 
> Best regards,
> 
> Toby Nixon
> Alain Regnier
> Co-Chairs, OASIS WS-DD TC
> 
>
> ------------------------------------------------------------------------
>
> *From:* Bob Freund [mailto:bob.freund@hitachisoftware.com]*
> Sent:* Sat 9/26/2009 7:32 AM*
> To:* public-ws-resource-access@w3.org; 
> public-ws-resource-access-comments@w3.org*
> Cc:* Toby Nixon; Lawrence Lamers; Michael McIntosh; Chris Kaler; 
> Anthony Nadalin; Mike Edwards; Alain Regnier; Xiao Chuan; Gert 
> Sylvest; Josh Cohen; Jonathan Marsh; Marc Goodner; Paul Fremantle; 
> Mikkel Hippe Brun*
> Subject:* To WS-RA reviewers
>
> Dear WS-RA Reviewers,
> The WS-RA working group has published new Working Drafts on 2009-09-24:
>
> WS-Enumeration at _http://www.w3.org/TR/2009/WD-ws-enumeration-20090924_
> WS-Eventing athttp://www.w3.org/TR/2009/WD-ws-eventing-20090924
> WS-MetadataExchange at 
> _http://www.w3.org/TR/2009/WD-ws-metadata-exchange-20090924_
> WS-Transfer at _http://www.w3.org/TR/2009/WD-ws-transfer-20090924_
>
> Please review these specifications and provide comment to 
> _public-ws-resource-access-comments@w3.org_ 
> <mailto:public-ws-resource-access-comments@w3.org>
>
> The WS-RA Working group hopes to be able to transition these
> specification to Last Call status in the month of November 2009, so to
> make that work well, and to help prevent comments received after Last-
> Call causing a return to that status, we are seeking your comments
> early and within the next three weeks (2009-10-12)
> The working group will endeavor to resolve those comments received
> before Last Call publication.
>
> There are still some issues being worked in parallel with your review
> as well as a few that have been resolved after the publication
> preparation date of the 2009-09-24 WDG which was 2009-09-02.  Those
> may be seen on our bug list at 
> _http://www.w3.org/Bugs/Public/buglist.cgi?product=WS-Resource%20Access_
>
> The following specification was also published, but we are not seeking
> review of it at this time
> WS-ResourceTransfer at 
> _http://www.w3.org/TR/2009/WD-ws-resource-transfer-20090924_
>
> Thank you
> Bob Freund
> Chair W3C WS-RA Working Group
>
> ------------------------------------------------------------------------
>
>
> Ce message entrant est certifié sans virus connu.
> Analyse effectuée par AVG - www.avg.fr 
> Version: 9.0.725 / Base de données virale: 270.14.137/2617 - Date: 
01/12/10 20:35:00
>
> 

Received on Friday, 22 January 2010 13:14:41 UTC