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

+1

I see no harm in allowing designer to indicate, at an abstract interface 
level, that all implementations of an interface MUST support WS-Eventing 
(and/or WS-Enumeration, and/or WS-Transfer, and/or WS-MetadataExchange). 
It certainly isn't something that one should do *lightly* as it imposes 
some fairly large support burdens down the road, but there are, 
obviously, cases where it is desirable and/or necessary.

- gp

On 1/22/2010 5:08 AM, Doug Davis wrote:
>
> 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
> >
> >
>