[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]