- From: Gilbert Pilz <gilbert.pilz@oracle.com>
- Date: Mon, 24 Aug 2009 12:06:24 -0700
- To: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <4A92E4B0.5080006@oracle.com>
It should be noted that this proposal takes the form of a new version of
WS-Eventing. The new material is confined to Appendix A where it
replaces the original Appendix A.
- gp
On 8/24/2009 11:23 AM, Gilbert Pilz wrote:
> Attached (or inlined as the case may be) is draft 6 of a proposal for
> issues 6401/6661. This proposal allows for the use of both the
> EventDescriptions element and Format-specific Notification WSDLs.
> There are still some open issues with this version of the proposal,
> but these can be worked out by the WG. Note that, as per our agreement
> at the last F2F, the section that describes the binding of
> wse:EventDescriptions to a Unwrapped Notification WSDL has been marked
> "TBD".
>
> Thanks to Ram, Wu, and Li for their help and feedback. Thanks to their
> input I think we've got something in which the combination of
> EventDescriptions and Notification WSDLs offers some value beyond
> merely serving as a political compromise.
>
> - gp
>
> ------------------------------------------------------------------------
>
> ?xml version="1.0" encoding="UTF-8"?>
>
>
> Web Services Eventing (WS-Eventing)
>
>
> Editor's Draft $Date: 2009/08/05 02:09:23 $
>
> Latest version:
> http://www.w3.org/TR/ws-eventing <http://www.w3.org/TR/ws-eventing>
> Previous version:
> http://www.w3.org/TR/2009/WD-ws-eventing-20090317
> Editors:
> Doug Davis, IBM
> Ashok Malhotra, Oracle
> Katy Warr, IBM
> Wu Chou, Avaya
>
> Copyright <http://www.w3.org/Consortium/Legal/ipr-notice#Copyright> ©
> 2009 W3C <http://www.w3.org/>^® (MIT <http://www.csail.mit.edu/>,
> ERCIM <http://www.ercim.org/>, Keio <http://www.keio.ac.jp/>), All
> Rights Reserved. W3C liability
> <http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer>,
> trademark
> <http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks> and
> document use <http://www.w3.org/Consortium/Legal/copyright-documents>
> rules apply.
>
> ------------------------------------------------------------------------
>
>
> Abstract
>
> This specification describes a protocol that allows Web services to
> subscribe to or accept subscriptions for event notification messages.
>
>
> Status of this Document
>
> *This document is an editors' copy that has no official standing.*
>
>
> Table of Contents
>
> 1 Composable Architecture <#composable>
> 2 Introduction <#intro>
> 2.1 Requirements <#reqs>
> 2.2 Delivery <#Delivery>
> 2.3 Notification Formats <#NotificationFormats>
> 2.4 Subscription Managers <#SubMgr>
> 2.5 Example <#example>
> 3 Notations and Terminology <#notterms>
> 3.1 Notational Conventions <#conventions>
> 3.2 Considerations on the Use of Extensibility Points <#extensions>
> 3.3 XML Namespaces <#namespaces>
> 3.4 Terminology <#terms>
> 3.5 Compliance <#compliance>
> 4 Subscription Messages <#SubMsgs>
> 4.1 Subscribe <#Subscribe>
> 4.2 Renew <#Renew>
> 4.3 GetStatus <#GetStatus>
> 4.4 Unsubscribe <#Unsubscribe>
> 4.5 Subscription End <#SubscriptionEnd>
> 5 Notifications <#Notifications>
> 6 Faults <#Faults>
> 6.1 Fault Detail RetryAfter Element <#FaultDetailRetryElement>
> 6.2 InvalidExpirationTime <#InvalidExpirationTime>
> 6.3 UnsupportedExpirationType <#UnsupportedExpirationType>
> 6.4 FilteringNotSupported <#FilteringNotSupported>
> 6.5 FilteringRequestedUnavailable <#FilteringRequestedUnavailable>
> 6.6 EventSourceUnableToProcess <#EventSourceUnableToProcess>
> 6.7 UnableToRenew <#UnableToRenew>
> 6.8 InvalidMessage <#InvalidMessage>
> 6.9 DeliveryFormatRequestUnavailable
> <#DeliveryFormatRequestedUnavailable>
> 6.10 EmptyFilter <#EmptyFilter>
> 6.11 UnusableEPR <#UnusableEPR>
> 7 Security Considerations <#Security>
> 7.1 Message Security <#MessageSecurity>
> 7.2 Access Control <#AccessControl>
> 8 Implementation Considerations <#ImplConsideration>
> 9 Acknowledgements <#acks>
> 10 References <#refs>
>
>
> Appendices
>
> A Advertising Event Information <#advertising>
> A.1 Event Types <#EventTypes>
> A.2 Event Descriptions <#EventDescriptions>
> A.2.1 Retrieving Event Descriptions <#RetrievingEventDescriptions>
> A.2.2 Bindings for Event Descriptions <#BindingEventDescriptions>
> A.2.2.1 Binding for Unwrapped Notifications
> <#BindingUnwrappedNotifications>
> A.2.2.2 Binding for Wrapped Notifications
> <#BindingWrappedNotifications>
> A.3 Notification WSDLs <#NotificationWSDLs>
> A.3.1 Retrieving Notification WSDLs <#RetrievingNotificationWSDLs>
> A.4 Multiple Event Information Metadata Sections
> <#MultipleEventInfoMetadata>
> B XML Schema <#Schema>
> C WSDL <#WSDL>
> D WSDL for Standard Wrapped Delivery <#wrappedWSDL>
> E XML Schema for EventDescriptions <#EventDescripSchema>
> F Change Log <#changelog>
>
> ------------------------------------------------------------------------
>
>
> 1 Composable Architecture
>
> By using the XML, SOAP [SOAP 1.1] <#SOAP11>, [SOAP 1.2] <#SOAP121>,
> and WSDL [WSDL 1.1] <#WSDL11> extensibility models, the Web service
> specifications (WS-*) are designed to be composed with each other to
> provide a rich set of tools to provide security in the Web services
> environment. This specification specifically relies on other Web
> service specifications to provide secure, reliable, and/or transacted
> message delivery and to express Web service and client policy.
>
>
> 2 Introduction
>
> Web services often want to receive messages when events occur in other
> services and applications. A mechanism for registering interest is
> needed because the set of Web services interested in receiving such
> messages is often unknown in advance or will change over time. This
> specification defines a protocol for one Web service (called a
> "subscriber") to register interest (called a "subscription") with
> another Web service (called an "event source") in receiving messages
> about events (called "notifications"). The subscriber may manage the
> subscription by interacting with a Web service (called the
> "subscription manager") designated by the event source.
>
> To improve robustness, a subscription may be leased by an event source
> to a subscriber, and the subscription expires over time. The
> subscription manager provides the ability for the subscriber to renew
> or cancel the subscription before it expires.
>
> There are many mechanisms by which event sources may deliver events to
> event sinks. This specification provides an extensible way for
> subscribers to identify the delivery mechanism they prefer.
>
>
> 2.1 Requirements
>
> This specification intends to meet the following requirements:
>
> *
>
> Define means to create and delete event subscriptions.
>
> *
>
> Define expiration for subscriptions and allow them to be renewed.
>
> *
>
> Define how one Web service can subscribe on behalf of another.
>
> *
>
> Define how an event source delegates subscription management to
> another Web service.
>
> *
>
> Allow subscribers to specify how notifications should be delivered.
>
> *
>
> Leverage other Web service specifications for secure, reliable,
> transacted message delivery.
>
> *
>
> Support complex eventing topologies that allow the originating
> event source and the final event sink to be decoupled.
>
> *
>
> Provide extensibility for more sophisticated and/or currently
> unanticipated subscription scenarios.
>
> *
>
> Support a variety of encoding formats, including (but not
> limited to) both SOAP 1.1 [SOAP 1.1] <#SOAP11> and SOAP 1.2
> [SOAP 1.2] <#SOAP121> Envelopes.
>
>
> 2.2 Delivery
>
> This specification defines a method for transmitting notifications
> from the event source to the event sink through the use of the
> wse:NotifyTo element. Other methods or combination of methods may be
> defined through the use of delivery extensions.
>
>
> 2.3 Notification Formats
>
> This specification specifies two delivery formats: wrapped and
> unwrapped. Use of wrapped format indicates that notification messages
> should be contained in a wrapper element defined by this
> specification. Use of unwrapped format indicates that notification
> messages are not contained in a wrapper element.
>
> Filtering occurs prior to any formatting of notification messages.
> This ensures that regardless of what type of formatting might occur,
> the same Filter dialect/expression can be used to subset the event
> stream.
>
>
> 2.4 Subscription Managers
>
> In some scenarios the event source itself manages the subscriptions it
> has created. In other scenarios, for example a geographically
> distributed publish-and-subscribe system, it may be useful to delegate
> the management of a subscription to another Web service. To support
> this flexibility, the response to a subscription request to an event
> source will include the EPR of a service that the subscriber may
> interact with to manage this subscription. This EPR should be the
> target for future requests to renew or cancel the subscription. It may
> address the same Web service (Address and ReferenceParameters) as the
> event source itself, or it may address some other Web service to which
> the event source has delegated management of this subscription;
> however, the full subscription manager EPR (Address and Reference
> Parameters) must be unique for each subscription.
>
> We use the term "subscription manager" in this specification to refer
> to the Web service that manages the subscription, whether it is the
> event source itself or some separate Web service.
>
>
> 2.5 Example
>
> Example 2-1 <#Table1> lists a hypothetical request to create a
> subscription for storm warnings.
>
> Example 2-1: Hypothetical request to create a subscription
> (01) <s12:Envelope
> (02) xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (03) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (04) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (05) xmlns:ew="http://www.example.com/warnings" >
> (06) <s12:Header>
> (07) <wsa:Action>
> (08) http://www.w3.org/2009/02/ws-evt/Subscribe
> (09) </wsa:Action>
> (10) <wsa:MessageID>
> (11) uuid:d7c5726b-de29-4313-b4d4-b3425b200839
> (12) </wsa:MessageID>
> (13) <wsa:ReplyTo>
> (14) <wsa:Address>http://www.example.com/MyEventSink</wsa:Address>
> (15) </wsa:ReplyTo>
> (16) <wsa:To>http://www.example.org/oceanwatch/EventSource</wsa:To>
> (17) </s12:Header>
> (18) <s12:Body>
> (19) <wse:Subscribe>
> (20) <wse:Delivery>
> (21) <wse:NotifyTo>
> (22) <wsa:Address>
> (23) http://www.example.com/MyEventSink/OnStormWarning
> (24) </wsa:Address>
> (25) <wsa:ReferenceParameters>
> (26) <ew:MySubscription>2597</ew:MySubscription>
> (27) </wsa:ReferenceParameters>
> (28) </wse:NotifyTo>
> (29) </wse:Delivery>
> (30) </wse:Subscribe>
> (31) </s12:Body>
> (32) </s12:Envelope>
>
> Lines (07-09) in Example 2-1 <#Table1> indicate the message is a
> request to create a subscription, and line (16) indicates that it is
> sent to a hypothetical event source of ocean events.
>
> While lines (13-15) indicate where a reply should be sent, lines
> (20-29) indicate where and how notifications should be delivered;
> there is no requirement that these match. The absence of any
> extensions to the wse:Delivery or wse:NotifyTo elements indicates that
> notifications should be sent as SOAP messages to the endpoint
> described in lines (21-28). Note that lines (25-27) illustrate a
> typical pattern where the event sink lists a reference parameter (line
> 26) that identifies the subscription and will be included in each
> notification.
>
> Example 2-2 <#Table2> lists a hypothetical response to the request in
> Example 2-1 <#Table1>.
>
> Example 2-2: Hypothetical response to a subscribe request
> (01) <s12:Envelope
> (02) xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (03) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (04) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (05) xmlns:ow="http://www.example.org/oceanwatch" >
> (06) <s12:Header>
> (07) <wsa:Action>
> (08) http://www.w3.org/2009/02/ws-evt/SubscribeResponse
> (09) </wsa:Action>
> (10) <wsa:RelatesTo>
> (11) uuid:d7c5726b-de29-4313-b4d4-b3425b200839
> (12) </wsa:RelatesTo>
> (13) <wsa:To>http://www.example.com/MyEventSink</wsa:To>
> (14) </s12:Header>
> (15) <s12:Body>
> (16) <wse:SubscribeResponse>
> (17) <wse:SubscriptionManager>
> (18) <wsa:Address>
> (19) http://www.example.org/oceanwatch/SubscriptionManager
> (20) </wsa:Address>
> (21) <wsa:ReferenceParameters>
> (22) <ow:MyId>
> (23) 28
> (24) </ow:MyId>
> (25) </wsa:ReferenceParameters>
> (26) </wse:SubscriptionManager>
> (27) <wse:Expires>P0Y0M0DT30H0M0S</wse:Expires>
> (28) </wse:SubscribeResponse>
> (29) </s12:Body>
> (30) </s12:Envelope>
>
> Lines (07-09) in Example 2-2 <#Table2> indicate this message is a
> response to a request to create a subscription, and lines (10-12)
> indicate that it is a response to the request in Example 2-1
> <#Table1>. lines (17-26) provide the subscription manager EPR for this
> subscription, and line (27) indicates the subscription will expire in
> 30 hours unless renewed.
>
>
> 3 Notations and Terminology
>
> This section specifies the notations, namespaces, and terminology used
> in this specification.
>
>
> 3.1 Notational Conventions
>
> The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119 [RFC2119]
> <#RFC2119>.
>
> This specification uses the following syntax to define normative
> outlines for messages:
>
> *
>
> The syntax appears as an XML instance, but values in italics
> indicate data types instead of values.
>
> *
>
> Characters are appended to elements and attributes to indicate
> cardinality:
>
> o
>
> "?" (0 or 1)
>
> o
>
> "*" (0 or more)
>
> o
>
> "+" (1 or more)
>
> *
>
> The character "|" is used to indicate a choice between
> alternatives.
>
> *
>
> The characters "(" and ")" are used to indicate that contained
> items are to be treated as a group with respect to cardinality
> or choice.
>
> *
>
> The characters "[" and "]" are used to call out references and
> property names.
>
> *
>
> Ellipsis (i.e. "...") indicate a point of extensibility.
>
> *
>
> XML namespace prefixes (see Table 3-1 <#Table3>) are used to
> indicate the namespace of the element being defined.
>
> In addition to Message Information Header properties [WS-Addressing]
> <#AddrCore>, this specification uses the following properties to
> define messages:
>
> *[Headers]*
>
> Unordered message headers.
>
> *[Action]*
>
> The value to be used for the wsa:Action URI.
>
> *[Body]*
>
> A message body.
>
> These properties bind to a SOAP Envelope as follows:
>
> <s:Envelope>
> <s:Header>
> *[Headers]*
> <wsa:Action>*[Action]*</wsa:Action>
> ...
> </s:Header>
> <s:Body>*[Body]*</s:Body>
> </s:Envelope>
>
>
> 3.2 Considerations on the Use of Extensibility Points
>
> The elements defined in this specification MAY be extended at the
> points indicated by their outlines and schema. Implementations MAY add
> child elements and/or attributes at the indicated extension points but
> MUST NOT contradict the semantics of the parent and/or owner,
> respectively. If a receiver does not recognize an extension, the
> receiver SHOULD ignore that extension. Senders MAY indicate the
> presence of an extension that has to be understood through the use of
> a corresponding SOAP Header with a soap:mustUnderstand attribute with
> the value "1".
>
> Extension elements and attributes MUST NOT use the Web Services
> Eventing namespace URI.
>
>
> 3.3 XML Namespaces
>
> The XML namespace URI that MUST be used by implementations of this
> specification is:
>
> http://www.w3.org/2009/02/ws-evt
>
> Table 3-1 <#Table3> lists XML namespaces that are used in this
> specification. The choice of any namespace prefix is arbitrary and not
> semantically significant.
>
> Table 3-1: Prefixes and XML namespaces used in this specification
> Prefix XML Namespace Specification(s)
> s (Either SOAP 1.1 or 1.2) (Either SOAP 1.1 or 1.2)
> s11 http://schemas.xmlsoap.org/soap/envelope/
> <http://schemas.xmlsoap.org/soap/envelope/> SOAP 1.1 [SOAP 1.1]
> <#SOAP11>
> s12 http://www.w3.org/2003/05/soap-envelope
> <http://www.w3.org/2003/05/soap-envelope> SOAP 1.2 [SOAP 1.2] <#SOAP121>
> wsdl http://schemas.xmlsoap.org/wsdl/
> <http://schemas.xmlsoap.org/wsdl/> WSDL [WSDL 1.1] <#WSDL11>
> wsa http://www.w3.org/2005/08/addressing
> <http://www.w3.org/2005/08/addressing> WS-Addressing [WS-Addressing]
> <#AddrCore>
> wse http://www.w3.org/2009/02/ws-evt
> <http://www.w3.org/2009/02/ws-evt> This specification
> xs http://www.w3.org/2001/XMLSchema
> <http://www.w3.org/2001/XMLSchema> XML Schema [XML Schema, Part 1]
> <#XMLSchema1>, [XML Schema, Part 2] <#XMLSchema2>
>
> The working group intends to update the value of the Web Services
> Eventing namespace URI each time a new version of this document is
> published until such time that the document reaches Candidate
> Recommendation status. Once it has reached Candidate Recommendation
> status, the working group intends to maintain the value of the Web
> Services Eventing namespace URI that was assigned in the Candidate
> Recommendation unless significant changes are made that impact the
> implementation or break post-CR implementations of the specification.
> Also see http://www.w3.org/2001/tag/doc/namespaceState.html
> <http://www.w3.org/2001/tag/doc/namespaceState.html> and
> http://www.w3.org/2005/07/13-nsuri <http://www.w3.org/2005/07/13-nsuri>.
>
>
> 3.4 Terminology
>
> Event Source
>
> A Web service that sends notifications and accepts requests to
> create subscriptions.
>
> Event Sink
>
> A Web service that receives notifications.
>
> Notification
>
> A one-way message sent to indicate that an event, or events, have
> occurred.
>
> Subscriber
>
> A Web service that sends requests to create, renew, and/or delete
> subscriptions.
>
> Subscription Manager
>
> A Web service that accepts requests to manage, get the status of,
> renew, and/or delete subscriptions on behalf of an event source.
>
>
> 3.5 Compliance
>
> An implementation is not compliant with this specification if it fails
> to satisfy one or more of the MUST or REQUIRED level requirements
> defined herein. A SOAP Node MUST NOT use the XML namespace identifier
> for this specification (listed in *3.3 XML Namespaces* <#namespaces>)
> within SOAP Envelopes unless it is compliant with this specification.
>
> Normative text within this specification takes precedence over the XML
> Schema and WSDL descriptions, which in turn take precedence over
> outlines, which in turn take precedence over examples.
>
> All messages defined by this specification MUST be sent to a Web
> service that is addressable by an EPR (see [WS-Addressing] <#AddrCore>).
>
>
> 4 Subscription Messages
>
> To create, renew, and delete subscriptions, subscribers send request
> messages to event sources and subscription managers.
>
> When an event source accepts a request to create a subscription, it
> typically does so for a given amount of time, although an event source
> may accept an indefinite subscription with no time-based expiration.
> If the subscription manager accepts a renewal request, it updates that
> amount of time. During that time, notifications are delivered by the
> event source to the requested event sink. An event source may support
> filtering to limit notifications that are delivered to the event sink;
> if it does, and a subscribe request contains a filter, the event
> source sends only notifications that match the requested filter. The
> event source sends notifications until one of the following happens:
> the subscription manager accepts an unsubscribe request for the
> subscription; the subscription expires without being renewed; or the
> event source cancels the subscription prematurely. In this last case,
> the event source makes a best effort to indicate why the subscription
> ended.
>
> In the absence of reliable messaging at the application layer (e.g.
> [WS-ReliableMessaging] <#WSReliableMessaging>), messages defined
> herein are delivered using the quality of service of the underlying
> transport(s) and on a best-effort basis at the application layer.
>
>
> 4.1 Subscribe
>
> To create a subscription, a subscriber sends a request message of the
> following form to an event source:
>
> *[Action]*
> http://www.w3.org/2009/02/ws-evt/Subscribe
>
> *[Body]*
> <wse:Subscribe ...>
> <wse:EndTo> /endpoint-reference/ </wse:EndTo> ?
> <wse:Delivery ...> /xs:any/* </wse:Delivery>
> <wse:Format Name="/xs:anyURI/"? > /xs:any/* </wse:Format> ?
> <wse:Expires> (/xs:dateTime/ | /xs:duration/) </wse:Expires> ?
> <wse:Filter Dialect="/xs:anyURI/"? ...> /xs:any/* </wse:Filter> ?
> /xs:any/*
> </wse:Subscribe>
>
> The following describes additional, normative constraints on the
> outline listed above:
>
> *[Body]*/wse:Subscribe/wse:EndTo
>
> Where to send a SubscriptionEnd message if the subscription is
> terminated unexpectedly. (See *4.5 Subscription End*
> <#SubscriptionEnd>.) If present, this element MUST be of type
> wsa:EndpointReferenceType. Default is not to send this message.
> The endpoint to which the EndTo EPR refers MUST support the
> SubcriptionEndPortType portType.
>
> Note, subscribers wishing to correlate SubscriptionEnd messages
> with the subscription to which they apply MAY wish to add a
> distinguishing reference parameter to the EndTo EPR.
>
> *[Body]*/wse:Subscribe/wse:Delivery
>
> This element contains the information necessary to convey
> notification messages from the event source to the event sink in a
> manner required by the subscriber. This element MUST contain at
> least one child element.
>
> *[Body]*/wse:Subscribe/wse:Delivery/wse:NotifyTo
>
> This specification defines one OPTIONAL element, wse:NotifyTo, to
> be used as a child of the wse:Delivery element. When present this
> element indicates that notifications MUST be sent to the
> EndpointReference identified by this element.
>
> *[Body]*/wse:Subscribe/wse:Format
>
> This optional element contains the delivery format to be used for
> notification messages sent in relation to this subscription.
> Implied value is
> "http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Unwrap", which
> indicates that unwrapped delivery should be used. See Section *2.3
> Notification Formats* <#NotificationFormats> for details.
>
> If the event source does not support the requested delivery
> format, the request MUST generate a
> wse:DeliveryFormatRequestedUnavailable fault indicating that the
> requested delivery format is not supported.
>
> *[Body]*/wse:Subscribe/wse:Format@Name="http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Unwrap"
>
>
> Indicate the unwrapped event delivery format.
>
> *[Body]*/wse:Subscribe/wse:Format@Name="http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Wrap"
>
>
> Indicate the wrapped event delivery format.
>
> *[Body]*/wse:Subscribe/wse:Expires
>
> Requested expiration time for the subscription. (No implied
> value.) The event source defines the actual expiration and is not
> constrained to use a time less or greater than the requested
> expiration. The expiration time may be a specific time or a
> duration from the subscription's creation time. Both specific
> times and durations are interpreted based on the event source's
> clock.
>
> If this element does not appear, then the request is for a
> subscription that will not expire. That is, the subscriber is
> requesting the event source to create a subscription with an
> indefinite lifetime. If the event source grants such a
> subscription, it may be terminated by the subscriber using an
> Unsubscribe request, or it may be terminated by the event source
> at any time for reasons such as connection termination, resource
> constraints, or system shut-down.
>
> If the expiration time is either a zero duration or a specific
> time that occurs in the past according to the event source, then
> the request MUST fail, and the event source MUST generate a
> wse:InvalidExpirationTime fault indicating that an invalid
> expiration time was requested.
>
> Some event sources may not have a "wall time" clock available, and
> so are only able to accept durations as expirations. If such a
> source receives a Subscribe request containing a specific time
> expiration, then the request MAY fail; if so, the event source
> MUST generate a wse:UnsupportedExpirationType fault indicating
> that an unsupported expiration type was requested.
>
> *[Body]*/wse:Subscribe/wse:Filter
>
> A Boolean expression in some dialect, either as a string or as an
> XML fragment (see *[[Body]/wse:Subscribe/wse:Filter/@Dialect
> <#Dialect>]*). If the expression evaluates to false for a
> notification, the notification MUST NOT be sent to the event sink.
> Implied value is an expression that always returns true. If the
> event source does not support filtering, then a request that
> specifies a filter MUST fail, and the event source MUST generate a
> wse:FilteringNotSupported fault indicating that filtering is not
> supported.
>
> If the event source supports filtering but cannot honor the
> requested filtering, the request MUST fail, and the event source
> MUST generate a wse:FilteringRequestedUnavailable fault indicating
> that the requested filter dialect is not supported.
>
> It is possible for a Subscribe request to contain a filter that
> will never evaluate to true for the lifetime of the Subscription.
> If an Event Source detects this condition it MUST generate a
> wse:EmptyFilter fault in response to the Subscribe request message.
>
> *[Body]*/wse:Subscribe/wse:Filter/@Dialect
>
> Implied value is "http://www.w3.org/TR/1999/REC-xpath-19991116".
>
> While an XPath predicate expression provides great flexibility and
> power, alternate filter dialects may be defined. For instance, a
> simpler, less powerful dialect might be defined for
> resource-constrained implementations, or a new dialect might be
> defined to support filtering based on data not included in the
> notification message itself. If desired, a filter dialect could
> allow the definition of a composite filter that contained multiple
> filters from other dialects.
>
> *[Body]*/wse:Subscribe/wse:Filter/@Dialect="
> http://www.w3.org/TR/1999/REC-xpath-19991116
> <http://www.w3.org/TR/1999/REC-xpath-19991116>"
>
> Value of *[Body]*/wse:Subscribe/wse:Filter is an XPath [XPath 1.0]
> <#XPath1> predicate expression (PredicateExpr); the context of the
> expression is:
>
> *
>
> Context Node: the root of the event XML.
>
> *
>
> Context Position: 1.
>
> *
>
> Context Size: 1.
>
> *
>
> Variable Bindings: None.
>
> *
>
> Function Libraries: Core Function Library [XPath 1.0]
> <#XPath1>.
>
> *
>
> Namespace Declarations: The [in-scope namespaces] property
> [XML Infoset] <#XMLInfoset> of /s:Envelope/s:Body/*/wse:Filter.
>
> Other message information headers defined by WS-Addressing
> [WS-Addressing] <#AddrCore> MAY be included in the request and
> response messages, according to the usage and semantics defined in
> WS-Addressing.
>
> Other components of the outline above are not further constrained by
> this specification.
>
> If included within the Subscribe request message, the wse:NotifyTo and
> wse:EndTo SHOULD have some cursory validity checking performed before
> the Subscribe response is returned. While not all errors can be
> detected prior to sending a message to those EPRs, some obvious ones
> can be detected. For example, an unsupported transport specified
> within the wsa:Address IRI. Detecting these errors during Subscribe
> processing will lessen the chances of the subscriber creating an
> unusable subscription. If this check is performed and a problem is
> detected then the event source MUST generate a wse:UnusableEPR fault
> rather than returning the SubscribeResponse message.
>
> If the event source accepts a request to create a subscription, it
> MUST reply with a response of the following form:
>
> *[Action]*
> http://www.w3.org/2009/02/ws-evt/SubscribeResponse
>
> *[Body]*
> <wse:SubscribeResponse ...>
> <wse:SubscriptionManager>
> /wsa:EndpointReferenceType/
> </wse:SubscriptionManager>
> <wse:Expires>(/xs:dateTime/ | /xs:duration/)</wse:Expires>
> /xs:any/*
> </wse:SubscribeResponse>
>
> The following describes additional, normative constraints on the
> outline listed above:
>
> *[Body]*/wse:SubscribeResponse/wse:SubscriptionManager
>
> The EPR of the subscription manager for this subscription.
>
> In some cases, it is convenient for all EPRs issued by a single
> event source to address a single Web service and use a reference
> parameter to distinguish among the active subscriptions.
>
> *[Body]*/wse:SubscribeResponse/wse:Expires
>
> The expiration time assigned by the event source. The expiration
> time MAY be either an absolute time or a duration but SHOULD be of
> the same type as the requested expiration (if any).
>
> If this element does not appear, then the subscription will not
> expire. That is, the subscription has an indefinite lifetime. It
> may be terminated by the subscriber using an Unsubscribe request,
> or it may be terminated by the event source at any time for
> reasons such as connection termination, resource constraints, or
> system shut-down.
>
> Other components of the outline above are not further constrained by
> this specification.
>
> If the event source chooses not to accept a subscription, the request
> MUST fail, and the event source MUST generate a
> wse:EventSourceUnableToProcess fault indicating that the request was
> not accepted.
>
> Example 4-1 <#Table4> lists another hypothetical request to create a
> subscription.
>
> Example 4-1: Second hypothetical request to create a subscription
> (01) <s12:Envelope
> (02) xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (03) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (04) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (05) xmlns:ew="http://www.example.com/warnings" >
> (06) <s12:Header>
> (07) <wsa:Action>
> (08) http://www.w3.org/2009/02/ws-evt/Subscribe
> (09) </wsa:Action>
> (10) <wsa:MessageID>
> (11) uuid:e1886c5c-5e86-48d1-8c77-fc1c28d47180
> (12) </wsa:MessageID>
> (13) <wsa:ReplyTo>
> (14) <wsa:Address>http://www.example.com/MyEvEntsink</wsa:Address>
> (15) <wsa:ReferenceParameters>
> (16) <ew:MySubscription>2597</ew:MySubscription>
> (17) </wsa:ReferenceParameters>
> (18) </wsa:ReplyTo>
> (19) <wsa:To>http://www.example.org/oceanwatch/EventSource</wsa:To>
> (20) </s12:Header>
> (21) <s12:Body>
> (22) <wse:Subscribe>
> (23) <wse:EndTo>
> (24) <wsa:Address>
> (25) http://www.example.com/MyEventSink
> (26) </wsa:Address>
> (27) <wsa:ReferenceParameters>
> (28) <ew:MySubscription>2597</ew:MySubscription>
> (29) </wsa:ReferenceParameters>
> (30) </wse:EndTo>
> (31) <wse:Delivery>
> (32) <wse:NotifyTo>
> (33) <wsa:Address>
> (34) http://www.other.example.com/OnStormWarning
> (35) </wsa:Address>
> (36) <wsa:ReferenceParameters>
> (37) <ew:MySubscription>2597</ew:MySubscription>
> (38) </wsa:ReferenceParameters>
> (39) </wse:NotifyTo>
> (40) </wse:Delivery>
> (41) <wse:Expires>2004-06-26T21:07:00.000-08:00</wse:Expires>
> (42) <wse:Filter xmlns:ow="http://www.example.org/oceanwatch" >
> (43) /*/ow:Speed/[node() > 50]
> (44) </wse:Filter>
> (45) </wse:Subscribe>
> (46) </s12:Body>
> (47) </s12:Envelope>
>
> Like the request in Example 2-1 <#Table1>, lines (07-09) of Example
> 4-1 <#Table4> indicate the message is a request to create a
> subscription. Line (19) indicates that it is sent to a hypothetical
> event source of ocean events.
>
> Lines (13-18) indicate where to send the response to this request,
> lines (23-30) indicate where to send a SubscriptionEnd message if
> necessary, and lines (31-34) indicate how and where to send
> notifications.
>
> Line (41) indicates the event sink would prefer to have the
> subscription expire on 26 June 2004 at 9:07 PM Pacific time.
>
> Lines (42-44) indicate the event sink only wants weather reports where
> the speed of wind is greater than 50.
>
> Example 4-2 <#Table5> lists a hypothetical response to the request in
> Example 4-1 <#Table4>.
>
> Example 4-2: Hypothetical response to second subscribe request
> (01) <s12:Envelope
> (02) xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (03) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (04) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (05) xmlns:ew="http://www.example.com/warnings"
> (06) xmlns:ow="http://www.example.org/oceanwatch" >
> (07) <s12:Header>
> (08) <wsa:Action>
> (09) http://www.w3.org/2009/02/ws-evt/SubscribeResponse
> (10) </wsa:Action>
> (11) <wsa:RelatesTo>
> (12) uuid:e1886c5c-5e86-48d1-8c77-fc1c28d47180
> (13) </wsa:RelatesTo>
> (14) <wsa:To>http://www.example.com/MyEventSink</wsa:To>
> (15) <ew:MySubscription wsa:IsReferenceParameter="true">
> (16) 2597
> (17) </ew:MySubscription>
> (18) </s12:Header>
> (19) <s12:Body>
> (20) <wse:SubscribeResponse>
> (21) <wse:SubscriptionManager>
> (22) <wsa:Address>
> (23) http://www.example.org/oceanwatch/SubscriptionManager
> (24) </wsa:Address>
> (25) <wsa:ReferenceParameters>
> (26) <x:SubID xmlns:x="http://example.com">
> (27) uuid:22e8a584-0d18-4228-b2a8-3716fa2097fa
> (28) </x:SubID>
> (29) </wsa:ReferenceParameters>
> (30) </wse:SubscriptionManager>
> (31) <wse:Expires>2004-07-01T00:00:00.000-00:00</wse:Expires>
> (32) </wse:SubscribeResponse>
> (33) </s12:Body>
> (34) </s12:Envelope>
>
> Like the response in Example 2-2 <#Table2>, lines (08-10) of Example
> 4-2 <#Table5> indicate this message is a response to a request to
> create a subscription, and lines (11-13) indicate that it is a
> response to the request in Example 4-1 <#Table4> . Lines (14-17)
> indicate the response is sent to the event sink indicated in lines
> (13-18) of Example 4-1 <#Table4>. Lines (21-30) provide the address of
> the subscription manager for this subscription; note that this
> particular response uses the x:SubID element as a reference parameter
> to distinguish this subscription EPR from other subscription EPRs.
> Finally, line (31) indicates the subscription will expire on 1 July
> 2004 unless renewed; there is no requirement that this time be
> necessarily longer or shorter than the requested expiration (line (41)
> of Example 4-1 <#Table4>).
>
>
> 4.2 Renew
>
> To update the expiration for a subscription, subscription managers
> MUST support requests to renew subscriptions.
>
> To renew a subscription, the subscriber sends a request of the
> following form to the subscription manager:
>
> *[Action]*
> http://www.w3.org/2009/02/ws-evt/Renew
>
> *[Body]*
> <wse:Renew ...>
> <wse:Expires>(/xs:dateTime/ | /xs:duration/)</wse:Expires> ?
> /xs:any/*
> </wse:Renew>
>
> Components of the outline listed above are additionally constrained as
> for a request to create a subscription (see *4.1 Subscribe*
> <#Subscribe>). Other components of the outline above are not further
> constrained by this specification.
>
> If the subscription manager accepts a request to renew a subscription,
> it MUST reply with a response of the following form:
>
> *[Action]*
> http://www.w3.org/2009/02/ws-evt/RenewResponse
>
> *[Body]*
> <wse:RenewResponse ...>
> <wse:Expires>(/xs:dateTime/ | /xs:duration/)</wse:Expires> ?
> /xs:any/*
> </wse:RenewResponse>
>
> Components of the outline listed above are constrained as for a
> response to a subscribe request (see *4.1 Subscribe* <#Subscribe>)
> with the following addition(s):
>
> *[Body]*/wse:RenewResponse/wse:Expires
>
> If the requested expiration is a duration, then the implied start
> of that duration is the time when the subscription manager starts
> processing the Renew request.
>
> If the subscription manager chooses not to renew this subscription,
> the request MUST fail, and the subscription manager MUST generate a
> wse:UnableToRenew fault indicating that the renewal was not accepted.
>
> Other components of the outline above are not further constrained by
> this specification.
>
> Example 4-3 <#Table6> lists a hypothetical request to renew the
> subscription created in Example 4-2 <#Table5>.
>
> Example 4-3: Hypothetical request to renew second subscription
> (01) <s12:Envelope
> (02) xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (03) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (04) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (05) xmlns:ow="http://www.example.org/oceanwatch" >
> (06) <s12:Header>
> (07) <wsa:Action>
> (08) http://www.w3.org/2009/02/ws-evt/Renew
> (09) </wsa:Action>
> (10) <wsa:MessageID>
> (11) uuid:bd88b3df-5db4-4392-9621-aee9160721f6
> (12) </wsa:MessageID>
> (13) <wsa:ReplyTo>
> (14) <wsa:Address>http://www.example.com/MyEventSink</wsa:Address>
> (15) </wsa:ReplyTo>
> (16) <wsa:To>
> (17) http://www.example.org/oceanwatch/SubscriptionManager
> (18) </wsa:To>
> (19) <x:SubID wsa:IsReferenceParameter="true" xmlns:x="http://example.com">
> (20) uuid:22e8a584-0d18-4228-b2a8-3716fa2097fa
> (21) </x:SubID>
> (22) </s12:Header>
> (23) <s12:Body>
> (24) <wse:Renew>
> (25) <wse:Expires>2004-06-26T21:07:00.000-08:00</wse:Expires>
> (26) </wse:Renew>
> (27) </s12:Body>
> (28) </s12:Envelope>
>
> Lines (07-09) indicate this is a request to renew a subscription.
> Lines (19-21) contain the reference parameter that indicates the
> subscription to be renewed is the one created in Example 4-2
> <#Table5>. Line (25) in Example 4-3 <#Table6> indicates the request is
> to extend the subscription until 26 June 2004 at 9:07 PM Pacific.
>
> Example 4-4 <#Table7> lists a hypothetical response to the request in
> Example 4-3 <#Table6>.
>
> Example 4-4: Hypothetical response to renew request
> (01) <s12:Envelope
> (02) xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (03) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (04) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (05) xmlns:ow="http://www.example.org/oceanwatch" >
> (06) <s12:Header>
> (07) <wsa:Action>
> (08) http://www.w3.org/2009/02/ws-evt/RenewResponse
> (09) </wsa:Action>
> (10) <wsa:RelatesTo>
> (11) uuid:bd88b3df-5db4-4392-9621-aee9160721f6
> (12) </wsa:RelatesTo>
> (13) <wsa:To>http://www.example.com/MyEventSink</wsa:To>
> (14) </s12:Header>
> (15) <s12:Body>
> (16) <wse:RenewResponse>
> (17) <wse:Expires>2004-06-26T12:00:00.000-00:00</wse:Expires>
> (18) </wse:RenewResponse>
> (19) </s12:Body>
> (20) </s12:Envelope>
>
> Line (17) in Example 4-4 <#Table7> indicates the subscription has been
> extended only until 26 June 2004 at noon.
>
>
> 4.3 GetStatus
>
> To get the status of a subscription, the subscriber sends a request of
> the following form to the subscription manager:
>
> *[Action]*
> http://www.w3.org/2009/02/ws-evt/GetStatus
>
> *[Body]*
> <wse:GetStatus ...>
> /xs:any/*
> </wse:GetStatus>
>
> Components of the outline listed above are additionally constrained as
> for a request to renew a subscription (see *4.2 Renew* <#Renew>).
> Other components of the outline above are not further constrained by
> this specification.
>
> If the subscription is valid and has not expired, the subscription
> manager MUST reply with a response of the following form:
>
> *[Action]*
> http://www.w3.org/2009/02/ws-evt/GetStatusResponse
>
> *[Body]*
> <wse:GetStatusResponse ...>
> <wse:Expires>(/xs:dateTime/ | /xs:duration/)</wse:Expires> ?
> /xs:any/*
> </wse:GetStatusResponse>
>
> Components of the outline listed above are constrained as for a
> response to a renew request (see *4.2 Renew* <#Renew>). Other
> components of the outline above are not further constrained by this
> specification.
>
> Example 4-5 <#Table8> lists a hypothetical request to get the status
> of the subscription created in Example 4-2 <#Table5>.
>
> Example 4-5: Hypothetical request to get the status of the second
> subscription
> (01) <s12:Envelope
> (02) xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (03) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (04) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (05) xmlns:ow="http://www.example.org/oceanwatch" >
> (06) <s12:Header>
> (07) <wsa:Action>
> (08) http://www.w3.org/2009/02/ws-evt/GetStatus
> (09) </wsa:Action>
> (10) <wsa:MessageID>
> (11) uuid:bd88b3df-5db4-4392-9621-aee9160721f6
> (12) </wsa:MessageID>
> (13) <wsa:ReplyTo>
> (14) <wsa:Address>http://www.example.com/MyEventSink</wsa:Address>
> (15) </wsa:ReplyTo>
> (16) <wsa:To>
> (17) http://www.example.org/oceanwatch/SubscriptionManager
> (18) </wsa:To>
> (19) <x:SubID wsa:IsReferenceParameter="true" xmlns:x="http://example.com">
> (20) uuid:22e8a584-0d18-4228-b2a8-3716fa2097fa
> (21) </x:SubID>
> (22) </s12:Header>
> (23) <s12:Body>
> (24) <wse:GetStatus />
> (25) </s12:Body>
> (26) </s12:Envelope>
>
> Lines (07-09) indicate this is a request to get the status of a
> subscription. Lines (16-21) indicate that the request is sent to the
> subscription manager for the subscription created in Example 4-2
> <#Table5>.
>
> Example 4-6 <#Table9> lists a hypothetical response to the request in
> Example 4-5 <#Table8>.
>
> Example 4-6: Hypothetical response to get status request
> (01) <s12:Envelope
> (02) xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (03) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (04) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (05) xmlns:ow="http://www.example.org/oceanwatch" >
> (06) <s12:Header>
> (07) <wsa:Action>
> (08) http://www.w3.org/2009/02/ws-evt/GetStatusResponse
> (09) </wsa:Action>
> (10) <wsa:RelatesTo>
> (11) uuid:bd88b3df-5db4-4392-9621-aee9160721f6
> (12) </wsa:RelatesTo>
> (13) <wsa:To>http://www.example.com/MyEventSink</wsa:To>
> (14) </s12:Header>
> (15) <s12:Body>
> (16) <wse:GetStatusResponse>
> (17) <wse:Expires>2004-06-26T12:00:00.000-00:00</wse:Expires>
> (18) </wse:GetStatusResponse>
> (19) </s12:Body>
> (20) </s12:Envelope>
>
> Line (17) in Example 4-6 <#Table9> indicates the subscription will
> expire on 26 June 2004 at noon.
>
>
> 4.4 Unsubscribe
>
> Though subscriptions expire eventually, to minimize resources, the
> subscribing event sink SHOULD explicitly delete a subscription when it
> no longer wants notifications associated with the subscription.
>
> To explicitly delete a subscription, a subscribing event sink sends a
> request of the following form to the subscription manager:
>
> *[Action]*
> http://www.w3.org/2009/02/ws-evt/Unsubscribe
>
> *[Body]*
> <wse:Unsubscribe ...>
> /xs:any/*
> </wse:Unsubscribe>
>
> Components of the outline above are additionally constrained only as
> for a request to renew a subscription (see *4.2 Renew* <#Renew>). For
> example, the faults listed there are also defined for a request to
> delete a subscription.
>
> If the subscription manager accepts a request to delete a
> subscription, it MUST reply with a response of the following form:
>
> *[Action]*
> http://www.w3.org/2009/02/ws-evt/UnsubscribeResponse
>
> *[Body]*
> <wse:UnsubscribeResponse ...>
> /xs:any/*
> </wse:UnsubscribeResponse>
>
> Components of the outline listed above are not further constrained by
> this specification.
>
> Example 4-7 <#Table10> lists a hypothetical request to delete the
> subscription created in Example 4-2 <#Table5>.
>
> Example 4-7: Hypothetical unsubscribe request to delete second
> subscription
> (01) <s12:Envelope
> (02) xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (03) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (04) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (05) xmlns:ow="http://www.example.org/oceanwatch" >
> (06) <s12:Header>
> (07) <wsa:Action>
> (08) http://www.w3.org/2009/02/ws-evt/Unsubscribe
> (09) </wsa:Action>
> (10) <wsa:MessageID>
> (11) uuid:2653f89f-25bc-4c2a-a7c4-620504f6b216
> (12) </wsa:MessageID>
> (13) <wsa:ReplyTo>
> (14) <wsa:Address>http://www.example.com/MyEventSink</wsa:Address>
> (15) </wsa:ReplyTo>
> (16) <wsa:To>
> (17) http://www.example.org/oceanwatch/SubscriptionManager
> (18) </wsa:To>
> (19) <x:SubID wsa:IsReferenceParameter="true" xmlns:x="http://example.com">
> (20) uuid:22e8a584-0d18-4228-b2a8-3716fa2097fa
> (21) </x:SubID>
> (22) </s12:Header>
> (23) <s12:Body>
> (24) <wse:Unsubscribe />
> (25) </s12:Body>
> (26) </s12:Envelope>
>
> Lines (07-09) in Example 4-7 <#Table10> indicate the message is a
> request to delete a subscription. Lines (16-21) indicate that the
> request is addressed to the manager for the subscription created in
> Example 4-2 <#Table5>.
>
> Example 4-8 <#Table11> lists a hypothetical response to the request in
> Example 4-7 <#Table10>.
>
> Example 4-8: Hypothetical response to unsubscribe request
> (01) <s12:Envelope
> (02) xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (03) xmlns:wsa="http://www.w3.org/2005/08/addressing" >
> (04) <s12:Header>
> (05) <wsa:Action>
> (06) http://www.w3.org/2009/02/ws-evt/UnsubscribeResponse
> (07) </wsa:Action>
> (08) <wsa:RelatesTo>
> (09) uuid:2653f89f-25bc-4c2a-a7c4-620504f6b216
> (10) </wsa:RelatesTo>
> (11) <wsa:To>http://www.example.com/MyEventSink</wsa:To>
> (12) </s12:Header>
> (13) <s12:Body>
> (14) <wse:UnsubscribeResponse/>
> (15) </s12:Body>
> (16) </s12:Envelope>
>
>
> 4.5 Subscription End
>
> If the event source terminates a subscription unexpectedly, the event
> source SHOULD send a Subscription End SOAP message to the endpoint
> reference indicated when the subscription was created (see *4.1
> Subscribe* <#Subscribe>). This endpoint reference MUST refer to an
> endpoint that supports the SubscriptionEndPortType portType. The
> message MUST be of the following form:
>
> *[Action]*
> http://www.w3.org/2009/02/ws-evt/SubscriptionEnd
>
> *[Body]*
> <wse:SubscriptionEnd ...>
> <wse:Status>
> ( http://www.w3.org/2009/02/ws-evt/DeliveryFailure |
> http://www.w3.org/2009/02/ws-evt/SourceShuttingDown |
> http://www.w3.org/2009/02/ws-evt/SourceCancelling )
> </wse:Status>
> <wse:Reason xml:lang="/language identifier/" >/xs:string/</wse:Reason> ?
> /xs:any/*
> </wse:SubscriptionEnd>
>
> The following describes additional, normative constraints on the
> outline listed above:
>
> *[Body]*/wse:SubscriptionEnd/wse:Status =
> "http://www.w3.org/2009/02/ws-evt/DeliveryFailure"
>
> This value MUST be used if the event source terminated the
> subscription because of problems delivering notifications.
>
> *[Body]*/wse:SubscriptionEnd/wse:Status =
> "http://www.w3.org/2009/02/ws-evt/SourceShuttingDown"
>
> This value MUST be used if the event source terminated the
> subscription because the source is being shut down in a controlled
> manner; that is, if the event source is being shut down but has
> the opportunity to send a SubscriptionEnd message before it exits.
>
> *[Body]*/wse:SubscriptionEnd/wse:Status =
> "http://www.w3.org/2009/02/ws-evt/SourceCancelling"
>
> This value MUST be used if the event source terminated the
> subscription for some other reason before it expired.
>
> *[Body]*/wse:SubscriptionEnd/wse:Reason
>
> This optional element contains text, in the language specified by
> the @xml:lang attribute, describing the reason for the unexpected
> subscription termination.
>
> Other message information headers defined by WS-Addressing
> [WS-Addressing] <#AddrCore> MAY be included in the message, according
> to the usage and semantics defined in WS-Addressing.
>
> Other components of the outline above are not further constrained by
> this specification.
>
> Example 4-9 <#Table12> lists a hypothetical SubscriptionEnd message
> corresponding to an early termination of the subscription created in
> Example 4-1 <#Table4>.
>
> Example 4-9: Hypothetical subscription end message
> (01) <s12:Envelope
> (02) xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (03) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (04) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (05) xmlns:ew="http://www.example.com/warnings" >
> (06) <s12:Header>
> (07) <wsa:Action>
> (08) http://www.w3.org/2009/02/ws-evt/SubscriptionEnd
> (09) </wsa:Action>
> (10) <wsa:To>http://www.example.com/MyEventSink</wsa:To>
> (11) <ew:MySubscription wsa:IsReferenceParameter="true">
> (12) 2597
> (13) </ew:MySubscription>
> (14) </s12:Header>
> (15) <s12:Body>
> (16) <wse:SubscriptionEnd>
> (17) <wse:Status>wse:SourceShuttingDown</wse:Status>
> (18) <wse:Reason xml:lang="en-US" >
> (19) Event source going off line.
> (20) </wse:Reason>
> (21) </wse:SubscriptionEnd>
> (22) </s12:Body>
> (23) </s12:Envelope>
>
> Line (08) is the action URI for Subscription End. Lines (10-13)
> indicate the message is sent to the EndTo of the subscribe request
> (lines (23-30) in Example 4-1 <#Table4> .). Line (17) indicates the
> event source is shutting down, and lines (18-20) indicate that the
> event source was going off line.
>
>
> 5 Notifications
>
> This specification does not constrain notifications because any
> message MAY be a notification.
>
> However, if a subscribing event sink wishes to have notifications
> specifically marked, it MAY specify literal SOAP header blocks in the
> Subscribe request, in the
> /s:Envelope/s:Body/wse:Subscribe/wse:NotifyTo/wsa:ReferenceParameters
> element; per WS-Addressing [WS-Addressing] <#AddrCore>, the event
> source MUST include each such literal SOAP header block in every
> notification sent to the endpoint addressed by
> /s:Envelope/s:Body/wse:Subscribe/wse:NotifyTo.
>
> Example 5-1 <#Table13> lists a hypothetical notification message sent
> as part of the subscription created by the subscribe request in
> Example 4-1 <#Table4>.
>
> Example 5-1: Hypothetical notification message
> (01) <s12:Envelope
> (02) xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (03) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (04) xmlns:ew="http://www.example.com/warnings"
> (05) xmlns:ow="http://www.example.org/oceanwatch" >
> (06) <s12:Header>
> (07) <wsa:Action>
> (08) http://www.example.org/oceanwatch/2003/WindReport
> (09) </wsa:Action>
> (10) <wsa:MessageID>
> (11) uuid:568b4ff2-5bc1-4512-957c-0fa545fd8d7f
> (12) </wsa:MessageID>
> (13) <wsa:To>http://www.other.example.com/OnStormWarning</wsa:To>
> (14) <ew:MySubscription wsa:IsReferenceParameter="true">
> (15) 2597
> (16) </ew:MySubscription>
> (18) </s12:Header>
> (19) <s12:Body>
> (20) <ow:WindReport>
> (21) <ow:Date>030701</ow:Date>
> (22) <ow:Time>0041</ow:Time>
> (23) <ow:Speed>65</ow:Speed>
> (24) <ow:Location>BRADENTON BEACH</ow:Location>
> (25) <ow:County>MANATEE</ow:County>
> (26) <ow:State>FL</ow:State>
> (27) <ow:Lat>2746</ow:Lat>
> (28) <ow:Long>8270</ow:Long>
> (29) <ow:Comments xml:lang="en-US" >
> (30) WINDS 55 WITH GUSTS TO 65. ROOF TORN OFF BOAT HOUSE. REPORTED
> (31) BY STORM SPOTTER. (TBW)
> (32) </ow:Comments>
> (33) </ow:WindReport>
> (34) </s12:Body>
> (35) </s12:Envelope>
>
> Lines (13-15) indicate the message is sent to the endpoint indicated
> by the subscribe request (lines (32-39) in Example 4-1 <#Table4>).
> Line (17) matches the filter in the subscribe request (lines (42-45)
> in Example 4-1 <#Table4>).
>
>
> 6 Faults
>
> All fault messages defined in this specification MUST be sent
> according to the rules described in WS-Addressing section 4. They are
> sent to the [fault endpoint], if present and valid. Otherwise they are
> sent to the [reply endpoint] if present. If neither is present faults
> may be sent to the [source endpoint].
>
> Endpoints compliant with this specification MUST include required
> message information headers on all fault messages. Fault messages are
> correlated as replies using the [relationship] property as defined in
> WS-Addressing. The [action] property below designates fault messages:
> http://www.w3.org/2009/02/ws-evt/fault
>
> The definitions of faults use the following properties:
>
> *[Code]* The fault code.
> *[Subcode]* The fault subcode.
> *[Reason]* The English language reason element.
> *[Detail]* The detail element. If absent, no detail element is
> defined for the fault.
>
> The properties above bind to a SOAP 1.2 fault as follows:
>
> <S:Envelope>
> <S:Header>
> <wsa:Action>
> http://www.w3.org/2009/02/ws-evt/fault
> </wsa:Action>
> <!-- Headers elided for clarity. -->
> </S:Header>
> <S:Body>
> <S:Fault>
> <S:Code>
> <S:Value> *[Code]* </S:Value>
> <S:Subcode>
> <S:Value> *[Subcode]* </S:Value>
> </S:Subcode>
> </S:Code>
> <S:Reason>
> <S:Text xml:lang="en"> *[Reason]* </S:Text>
> </S:Reason>
> <S:Detail>
> *[Detail]*
> </S:Detail>
> </S:Fault>
> </S:Body>
> </S:Envelope>
>
> The SOAP 1.1 fault is less expressive and map only *[Subcode]* and
> *[Reason]*. These the properties bind to a SOAP 1.1 fault as follows:
>
> <S11:Envelope>
> <S11:Body>
> <S11:Fault>
> <faultcode> *[Subcode]* </faultcode>
> <faultstring xml:lang="en"> *[Reason]* </faultstring>
> </S11:Fault>
> </S11:Body>
> </S11:Envelope>
>
>
> 6.1 Fault Detail RetryAfter Element
>
> The following element is used to convey additional information in the
> faults.
>
> /wse:RetryAfter
>
> This element (whose content is of type xs:unsignedLong) is a
> suggested minimum duration in milliseconds to wait before
> retransmitting the message. Omission of this element indicates
> that a retry is never likely to succeed.
>
> /wse:RetryAfter/@any
>
> Optional extensibility attributes that do not affect processing.
>
>
> 6.2 InvalidExpirationTime
>
> This fault is sent when a Subscribe request specifies an expiration
> time that is in the past or an expiration duration of zero.
>
> *[Code]* s12:Sender
> *[Subcode]* wse:InvalidExpirationTime
> *[Reason]* The expiration time requested is invalid.
> *[Detail]* /none/
>
>
> 6.3 UnsupportedExpirationType
>
> This fault is sent when a Subscribe request specifies an expiration
> time and the event source is only capable of accepting expiration
> durations; for instance, if the event source does not have access to
> absolute time.
>
> *[Code]* s12:Sender
> *[Subcode]* wse:UnsupportedExpirationType
> *[Reason]* Only expiration durations are supported.
> *[Detail]* /none/
>
>
> 6.4 FilteringNotSupported
>
> This fault is sent when a Subscribe request contains a filter and the
> event source does not support filtering.
>
> *[Code]* s12:Sender
> *[Subcode]* wse:FilteringNotSupported
> *[Reason]* Filtering is not supported.
> *[Detail]* /none/
>
>
> 6.5 FilteringRequestedUnavailable
>
> This fault is sent when a Subscribe request specifies a filter dialect
> that the event source does not support. Optionally, this fault may
> contain a list of supported filter dialect URIs in the Detail property.
>
> *[Code]* s12:Sender
> *[Subcode]* wse:FilteringRequestedUnavailable
> *[Reason]* The requested filter dialect is not supported.
> *[Detail]* <wse:SupportedDialect> +
> /Optional; one per filter dialect supported by the receiver/
>
>
> 6.6 EventSourceUnableToProcess
>
> This fault is sent when the event source is not capable of fulfilling
> a Subscribe request for local reasons unrelated to the specific request.
>
> *[Code]* s12:Receiver
> *[Subcode]* wse:EventSourceUnableToProcess
> *[Reason]* /Text explaining the failure; e.g., "The event source has
> too many subscribers"./
> *[Detail]* <wse:RetryAfter> ? /(Optional)/
>
>
> 6.7 UnableToRenew
>
> This fault is sent when the event source is not capable of fulfilling
> a Renew request for local reasons unrelated to the specific request.
>
> *[Code]* s12:Receiver
> *[Subcode]* wse:UnableToRenew
> *[Reason]* /Text explaining the failure; e.g., "The event source has
> too many subscribers"./
> *[Detail]* <wse:RetryAfter> ? /(Optional)/
>
>
> 6.8 InvalidMessage
>
> If a request message does not comply with the corresponding outline
> listed above, the request MUST fail and the event source or
> subscription manager MUST generate the following fault indicating that
> the request is invalid:
>
> *[Code]* s12:Sender
> *[Subcode]* wse:InvalidMessage
> *[Reason]* The message is not valid and cannot be processed.
> *[Detail]* /The invalid message/
>
>
> 6.9 DeliveryFormatRequestUnavailable
>
> This fault is sent when a Subscribe request specifies a delivery
> format that is not supported by the event source. Optionally, this
> fault may contain a list of supported delivery format URIs in the
> Detail property.
>
> *[Code]* s12:Sender
> *[Subcode]* wse:DeliveryFormatRequestedUnavailable
> *[Reason]* The requested delivery format is not supported.
> *[Detail]* <wse:SupportedDeliveryFormat> +
> / Optional, one per delivery format supported by the receiver./
>
>
> 6.10 EmptyFilter
>
> This fault MAY be generated when an Event Source detects a
> wse:Subscribe request containing a filter that, for whatever reason,
> will never evaluate to true.
>
> *[Code]* s12:Sender
> *[Subcode]* wse:EmptyFilter
> *[Reason]* The wse:Filter would result in zero Notifications.
> *[Detail]* / The wse:Filter value. /
>
>
> 6.11 UnusableEPR
>
> This fault MAY be generated when an Event Source detects that the
> wse:NotifyTo or wse:EndTo EPR is unusable.
>
> *[Code]* s12:Sender
> *[Subcode]* wse:UnusableEPR
> *[Reason]* An EPR in the Subscribe request message is unusable.
> *[Detail]* / The specific EPR that generated the error and why. /
>
>
> 7 Security Considerations
>
>
> 7.1 Message Security
>
> It is strongly RECOMMENDED that the communication between services be
> secured using the mechanisms described in WS-Security [WS-Security]
> <#WSSecurity>. In order to properly secure messages, the body and all
> relevant headers need to be included in the signature. Specifically,
> any headers identified in the |<wse:NotifyTo>| element and standard
> messaging headers, such as those from WS-Addressing [WS-Addressing]
> <#AddrCore>, need to be signed with the body in order to "bind" the
> two together. For messages with empty bodies, the |<s12:Body>| element
> should be signed so content cannot be added in transit.
>
> Different security mechanisms may be desired depending on the
> frequency of messages. For example, for infrequent messages, public
> key technologies may be adequate for integrity and confidentiality.
> However, for high-frequency events, it may be more performant to
> establish a security context for the events using the mechanisms
> described in WS-Trust [WS-Trust] <#WSTrust> and WS-SecureConversation
> [WS-SecureConversation] <#WSSecureConversation>.
>
> It should be noted that if a shared secret is used it is RECOMMENDED
> that derived keys be used to strengthen the secret as described in
> WS-SecureConversation.
>
> The following list summarizes common classes of attacks that apply to
> this protocol and identifies the mechanism to prevent/mitigate the
> attacks:
>
> *
>
> Message alteration - Alteration is prevented by including
> signatures of the message information using WS-Security.
>
> *
>
> Message disclosure - Confidentiality is preserved by encrypting
> sensitive data using WS-Security.
>
> *
>
> Key integrity - Key integrity is maintained by using the
> strongest algorithms possible (by comparing secured policies -
> see WS-Policy [WS-Policy] <#WSPolicy> and WS-SecurityPolicy
> [WS-SecurityPolicy] <#WSSecurityPolicy>).
>
> *
>
> Authentication - Authentication is established using the
> mechanisms described in WS-Security and WS-Trust. Each message
> is authenticated using the mechanisms described in WS-Security.
>
> *
>
> Accountability - Accountability is a function of the type of and
> string of the key and algorithms being used. In many cases, a
> strong symmetric key provides sufficient accountability.
> However, in some environments, strong PKI signatures are required.
>
> *
>
> Availability - All reliable messaging services are subject to a
> variety of availability attacks. Replay detection is a common
> attack and it is RECOMMENDED that this be addressed by the
> mechanisms described in WS-Security. Other attacks, such as
> network-level denial of service attacks are harder to avoid and
> are outside the scope of this specification. That said, care
> should be taken to ensure that minimal state is saved prior to
> any authenticating sequences.
>
> *
>
> Replay - Messages may be replayed for a variety of reasons. To
> detect and eliminate this attack, mechanisms should be used to
> identify replayed messages such as the timestamp/nonce outlined
> in WS-Security. Alternatively, and optionally, other
> technologies, such as sequencing, can also be used to prevent
> replay of application messages.
>
>
> 7.2 Access Control
>
> It is important for event sources to properly authorize requests. This
> is especially true for Subscribe requests, as otherwise the ability to
> subscribe on behalf of a third-party event sink could be used to
> create a distributed denial-of-service attack.
>
> Some possible schemes for validating Subscribe requests include:
>
> *
>
> Send a message to the event sink that describes the requested
> subscription, and then wait for a confirmation message to be
> returned by the event sink, before the event source accepts the
> subscription request. While this provides strong assurance that
> the event sink actually desires the requested subscription, it
> does not work for event sinks that are not capable of sending a
> confirmation, and requires additional logic on the event sink.
>
> *
>
> Require user authentication on the Subscribe request, and allow
> only authorized users to Subscribe.
>
> Other mechanisms are also possible. Note that event sources that are
> not reachable from the Internet have less need to control Subscribe
> requests.
>
>
> 8 Implementation Considerations
>
> Implementations SHOULD generate expirations in subscribe and renew
> request and response messages that are significantly larger than
> expected network latency.
>
> Event sinks should be prepared to receive notifications after sending
> a subscribe request but before receiving a subscribe response message.
> Event sinks should also be prepared to receive notifications after
> receiving an unsubscribe response message.
>
>
> 9 Acknowledgements
>
> This specification has been developed as a result of joint work with
> many individuals and teams, including: Ashok Malhotra (Oracle Corp.),
> Asir Vedamuthu (Microsoft Corp.), Bob Freund (Hitachi, Ltd.), Doug
> Davis (IBM), Fred Maciel (Hitachi, Ltd.), Geoff Bullen (Microsoft
> Corp.), Gilbert Pilz (Oracle Corp.), Greg Carpenter (Microsoft Corp.),
> Jeff Mischkinsky (Oracle Corp.), Katy Warr (IBM), Li Li (Avaya
> Communications), Mark Little (Red Hat), Prasad Yendluri (Software AG),
> Sreedhara Narayanaswamy (CA), Sumeet Vij (Software AG), Vikas Varma
> (Software AG), Wu Chou (Avaya Communications), Yves Lafon (W3C)
>
>
> 10 References
>
> RFC2119
> Key words for use in RFCs to Indicate Requirement Levels
> <http://www.ietf.org/rfc/rfc2119.txt> , S. Bradner, March 1997.
> (See http://www.ietf.org/rfc/rfc2119.txt.)
> RFC 3986
> Uniform Resource Identifier (URI): Generic Syntax
> <http://www.ietf.org/rfc/rfc3986.txt> , T. Berners-Lee, W3C/MIT,
> January 2005. (See http://www.ietf.org/rfc/rfc3986.txt.)
> SOAP 1.1
> Simple Object Access Protocol (SOAP) 1.1
> <http://www.w3.org/TR/2000/NOTE-SOAP-20000508/> , D. Box, et al,
> May 2000. (See http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.)
> SOAP 1.2
> SOAP Version 1.2 Part 1: Messaging Framework
> <http://www.w3.org/TR/2003/REC-soap12-part1-20030624/> , M.
> Gudgin, et al, June 2003. (See
> http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.)
> WS-Addressing
> W3C Recommendation, "Web Services Addressing 1.0 (WS-Addressing)"
> <http://www.w3.org/2005/08/addressing/> , May 2006. (See
> http://www.w3.org/2005/08/addressing/.)
> WS-MetadataExchange
> Web Services Metadata Exchange (WS-MetadataExchange)
> <http://www.w3.org/2009/02/ws-mex> , K. Ballinger, et al,
> September 2004. (See http://www.w3.org/2009/02/ws-mex.)
> WS-Policy
> W3C Recommendation, "Web Services Policy 1.5 - Framework"
> <http://www.w3.org/TR/ws-policy/> , September 2007. (See
> http://www.w3.org/TR/ws-policy/.)
> WS-ReliableMessaging
> Web Services Reliable Messaging Protocol (WS-ReliableMessaging)
> <http://schemas.xmlsoap.org/ws/2005/02/rm> , R. Bilorusets, et al,
> February 2005. (See http://schemas.xmlsoap.org/ws/2005/02/rm.)
> WS-SecureConversation
> Web Services Secure Conversation Language (WS-SecureConversation)
> <http://schemas.xmlsoap.org/ws/2005/02/sc> , S. Anderson, et al,
> February 2005. (See http://schemas.xmlsoap.org/ws/2005/02/sc.)
> WS-Security
> Web Services Security: SOAP Message Security 1.0
> <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf>
> , A. Nadalin, et al, March 2004. (See
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf.)
> WS-SecurityPolicy
> Web Services Security Policy Language (WS-SecurityPolicy), Version
> 1.1 <http://schemas.xmlsoap.org/ws/2005/07/securitypolicy> , G.
> Della-Libera, et al, July 2005. (See
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy.)
> WS-Trust
> Web Services Trust Language (WS-Trust)
> <http://schemas.xmlsoap.org/ws/2005/02/trust> , S. Anderson, et
> al, February 2005. (See http://schemas.xmlsoap.org/ws/2005/02/trust.)
> WSDL 1.1
> Web Services Description Language (WSDL) 1.1
> <http://www.w3.org/TR/2001/NOTE-wsdl-20010315> , E. Christensen,
> et al, March 2001. (See http://www.w3.org/TR/2001/NOTE-wsdl-20010315.)
> XML Infoset
> XML Information Set
> <http://www.w3.org/TR/2004/REC-xml-infoset-20040204/> , J. Cowan,
> et al, February 2004. (See
> http://www.w3.org/TR/2004/REC-xml-infoset-20040204/.)
> XML Schema, Part 1
> XML Schema Part 1: Structures
> <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/> , H.
> Thompson, et al, October 2004. (See
> http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/.)
> XML Schema, Part 2
> XML Schema Part 2: Datatypes
> <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/> , P. Biron,
> et al, October 2004. (See
> http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.)
> XPath 1.0
> XML Path Language (XPath) Version 1.0
> <http://www.w3.org/TR/1999/REC-xpath-19991116> , J. Clark, et al,
> November 1999. (See http://www.w3.org/TR/1999/REC-xpath-19991116.)
>
>
> A Advertising Event Information
>
> There are many use cases for WS-Eventing in which it is necessary for
> the Subscriber and the Event Sink to know the structure and contents
> of the Notifications that may result from a successful Subscribe
> request. For example, a developer may wish to use WSDL-based tools to
> generate service stubs capable of marshalling and dispatching
> Notifications. In addition to this, the effective use filters
> (including those in the XPath dialect defined in Section 4.1
> <#Subscribe> as well as other dialects not defined in this
> specification) requires some knowledge of the schema of the Events
> over which the filter will be applied.
>
> There are many ways in which an Event Source could describe and
> advertise the structure of the Events for which it will issue
> Notifications. To provide a basic level of interoperability, this
> specification defines the following two optional mechanisms for
> describing and advertising Event information. If an implementation of
> a WS-Eventing Event Source chooses to describe the structure of its
> Events and advertise this description to Subscribers and Event Sinks,
> it is RECOMMENDED that at least one of these mechanisms be used.
> Mechanisms other than these MAY be used to describe and advertise the
> structure of Events, but the definition of such mechanisms is out of
> the scope of this specification.
>
>
> A.1 Event Types
>
> A key concept in the description and advertisement of Event
> information is the "Event Type". An Event Type is a description of the
> syntactic structure and value space of the set of Events that share
> that type. Event Types are independent of both the WS-Eventing
> protocol and the format of the Notifications used to transmit those
> Events. For example, the following Notification, although transmitted
> using the Wrapped Notification Format defined in Section 4.1
> <#Subscribe>, has the same Event Type as the Notification in Example
> 5-1 <#Table13>:
>
> Example A-1: Hypothetical Wrapped Notification
> (01) <s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (02) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (03) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (04) xmlns:ow="http://www.example.org/oceanwatch">
> (05) <s12:Header>
> (06) <wsa:Action>
> (07) http://www.w3.org/2009/02/ws-evt/wrap/GenericSinkPortType/NotifyEvent
> (08) </wsa:Action>
> (09) . . .
> (10) </s12:Header>
> (11) <s12:Body>
> (12) <wse:Notify actionURI="http://www.example.org/oceanwatch/2003/WindReport">
> (13) <ow:WindReport>
> (14) <ow:Date>030701</ow:Date>
> (15) <ow:Time>0041</ow:Time>
> (16) <ow:Speed>65</ow:Speed>
> (17) <ow:Location>BRADENTON BEACH</ow:Location>
> (18) <ow:County>MANATEE</ow:County>
> (19) <ow:State>FL</ow:State>
> (20) <ow:Lat>2746</ow:Lat>
> (21) <ow:Long>8270</ow:Long>
> (22) <ow:Comments xml:lang="en-US" >
> (23) WINDS 55 WITH GUSTS TO 65. ROOF TORN OFF BOAT HOUSE. REPORTED
> (24) BY STORM SPOTTER. (TBW)
> (25) </ow:Comments>
> (26) </ow:WindReport>
> (27) </wse:Notify>
> (28) </s12:Body>
> (29) </s12:Envelope>
>
>
>
> A.2 Event Descriptions
>
> Event Types MAY be described within an EventDescriptions element where
> they are defined by Global Element Declarations in XML Schema [XML
> Schema, Part 1] <#XMLSchema1>, [XML Schema, Part 2] <#XMLSchema2>. The
> EventDescriptions element has the following form:
>
> <wse:EventDescriptions targetNamespace="/xs:anyURI/" ...>
> <wse:types>
> [ <xs:import namespace="/xs:anyURI/" schemaLocation="/xs:anyURI/"/> ? |
> <xs:schema targetNamespace="/xs:anyURI/"/> ? |
> /other extension elements/ ] *
> </wse:types>
> <wse:eventType name="/xs:NCName/" element="/xs:QName/" actionURI="/xs:anyURI/" ...>
> /xs:any/ *
> </wse:eventType> +
> /xs:any/ *
> </wse:EventDescriptions>
>
>
> The XML Schema for the EventDesciptions element can be found in
> Apppendix E <#EventDescripSchema>. The following describes additional,
> normative constraints on the outlined listed above:
>
> */wse:EventDescriptions*
>
> This element contains the declarations of all the Event Types that
> apply to a given context, such as a particular Event Source.
>
> */wse:EventDescriptions/@targetNamespace*
>
> This attribute defines the namespace affiliation of the Event
> Types declared within the EventDescriptions element. Its value
> MUST be an absolute IRI [IETF RFC 3987] <#TODO>. It MAY be
> dereferencable.
>
> */wse:EventDescriptions/wse:types*
>
> As described earlier, an Event Type is defined by a Global Element
> Declaration (GED) in XML Schema. This element contains collections
> of imported and inlined schema components that describe the GEDs
> that are used to define Event Types.
>
> */wse:EventDescriptions/wse:eventType*
>
> This element describes a specific Event Type.
>
> */wse:EventDescriptions/wse:eventType/@name*
>
> This attribute provides a unique name for this Event Type amongst
> all the Event Types defined by the enclosing wse:EventDescriptions
> element. In conjunction with a Prefix that is associated with the
> value of /wse:EventDescriptions/@targetNamespace namespace URI,
> the value of this attribute MAY be used as the LocalPart of a
> QName that identifies this Event Type outside the context of the
> enclosing wse:EventDescriptions element.
>
> */wse:EventDescriptions/wse:eventType/@element*
>
> This attribute refers to a GED defined or imported in the
> /wse:EventDescriptions/wse:types element. The referenced GED
> serves as the definition of this Event Type.
>
> */wse:EventDescriptions/wse:eventType/@actionURI*
>
> This attribute provides a value for the various 'action'
> properties and attributes which, depending upon the format of the
> Notification used to transmit the Event, serve as a potential aide
> to identifying the semantics implied by the message.
>
> The following is an example of a EventDescriptions element that could
> serve as a description of the Event Type used in Example 5-1
> <#Table13> and Example A-1 <#Table14>.
>
> Example A-2: EventDescriptions
> (01) <wse:EventDescriptions targetNamepace="http://www.example.org/oceanwatch/notifications"
> (02) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (03) xmlns:ow="http://www.example.org/oceanwatch">
> (04) <wse:types>
> (05) <xs:schema targetNamepace="http://www.example.org/oceanwatch">
> (06) <xs:include schemaLocation="http://www.example.org/schemas/oceanwatch.xsd"/>
> (07) <xs:element name="WindReport" type="ow:WindReportType"/>
> (08) </xs:schema>
> (09) </wse:types>
> (10)
> (11) <wse:eventType name="WindReportEvent"
> (12) element="ow:WindReport"
> (13) actionURI="http://www.example.org/oceanwatch/2003/WindReport"/>
> (14) </wsem:EventDescriptions>
>
>
> Lines (11-13) describe an Event Type with a QName of
> "{http://www.example.org/oceanwatch/notifications}:WindReportEvent".
> The GED for this Event Type is defined on line (07) as being of type
> "{http://www.example.org/oceanwatch}:WindReportType".
>
>
> A.2.1 Retrieving Event Descriptions
>
> Although there are many ways in which an Event Source can make its
> EventDescriptions available to potential Subscribers and Event Sinks,
> this specification RECOMMENDS the use of the mechanisms described in
> WS-MetadataExchange [WS-MetadataExchange] <#MEX>. This specification
> defines the following URI to serve as the Dialect URI for the
> wse:EventDescriptions element.
>
> http://www.w3.org/2009/02/ws-evt/EventDescriptions
>
>
> When a mex:GetMetadata request is targeted to a Subscription Endpoint
> with a mex:Dialect@URI of either
> "http://www.w3.org/2009/02/ws-evt/EventDescriptions" or
> "http://www.w3.org/2009/06/ws-mex/Dialects/ws-mex-all", the
> mex:Metadata element of the mex:GetMetadataResponse MAY include (in
> addition to other Metadata Sections that may be present) a single
> Metadata Section with a wse:EventDescriptions as the dialect specific
> element. The value of the @Dialect attribute for this Metadata Section
> MUST be "http://www.w3.org/2009/02/ws-evt/EventDescriptions". The
> value of the @Identifier attribute for this Metadata Section MUST be
> equal to the value of its wse:EventDescriptions/@targetNamespace.
>
> The following GetMetadata request, when sent to the Subscription
> Endpoint used in Example 2-1 <#Table1>
>
> Example A-3: GetMetadata Request for EventDescriptions
> (01) <s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (02) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (03) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (04) xmlns:mex="http://www.w3.org/2009/02/ws-mex">
> (05) <s12:Header>
> (06) <wsa:Action>
> (07) http://www.w3.org/2009/02/ws-mex/GetMetadata
> (08) </wsa:Action>
> (09) <wsa:MessageID>
> (10) uuid:126287f0-521d-11de-8a39-0800200c9a66
> (11) </wsa:MessageID>
> (12) <wsa:To>http://www.example.org/oceanwatch/EventSource</wsa:To>
> (13) </s12:Header>
> (14) <s12:Body>
> (15) <mex:GetMetadata>
> (16) <mex:Dialect URI="http://www.w3.org/2009/02/ws-evt/EventDescriptions"/>
> (17) </mex:GetMetadata>
> (18) </s12:Body>
> (19) </s12:Envelope>
>
>
> returns the following GetMetadataResponse element
>
> Example A-4: GetMetadataResponse with EventDescriptions
> (01) <s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (02) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (03) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (04) xmlns:mex="http://www.w3.org/2009/02/ws-mex">
> (05) <s12:Header>
> (06) <wsa:Action>
> (07) http://www.w3.org/2009/02/ws-mex/GetMetadataResponse
> (08) </wsa:Action>
> (09) <wsa:RelatesTo>
> (10) uuid:126287f0-521d-11de-8a39-0800200c9a66
> (11) </wsa:RelatesTo>
> (12) </s12:Header>
> (13) <s12:Body>
> (14) <mex:Metadata>
> (15) <mex:MetadataSection Dialect="http://www.w3.org/2009/02/ws-evt/EventDescriptions"
> (16) Identifier="http://www.example.org/oceanwatch/notifications">
> (17) <wse:EventDescriptions targetNamepace="http://www.example.org/oceanwatch/notifications"
> (18) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (19) xmlns:ow="http://www.example.org/oceanwatch">
> (20) <wse:types>
> (21) <xs:schema targetNamepace="http://www.example.org/oceanwatch">
> (22) <xs:include schemaLocation="http://www.example.org/schemas/oceanwatch.xsd"/>
> (23) <xs:element name="WindReport" type="ow:WindReportType">
> (24) </xs:schema>
> (25) </wse:types>
> (26)
> (27) <wse:eventType name="WindReportNotification"
> (28) element="ow:WindReport"
> (29) actionURI="http://www.example.org/oceanwatch/2003/WindReport"/>
> (30) </wsem:EventDescriptions>
> (31) </mex:MetadataSection
> (32) </mex:Metadata>
> (33) </s12:Body>
> (34) </s12:Envelope>
>
>
>
> A.2.2 Bindings for Event Descriptions
>
> For any Notification Format it should be possible to determine how a
> given |wse:eventType| will appear on the wire as a Notification in a
> Subscription created with that format. The following sections define
> how |wse:eventType|'s bind to Notifications for the two Notification
> Formats defined in this specification; Unwrapped and Wrapped.
> Specifications or profiles that define additional Notification Formats
> SHOULD define how |wse:eventType|s bind to the Notifications for those
> formats. In the absence of a mapping for a particular Notification
> Format, implementations MAY provide a Notification WSDL (see below)
> that explicitly describes the Notification operations.
>
>
> A.2.2.1 Binding for Unwrapped Notifications
>
> *TBD*
>
>
> A.2.2.2 Binding for Wrapped Notifications
>
> The information about a Event Type contained in the |eventType|
> element binds to a Wrapped Notification for that type as follows:
>
> * The |/soap:Envelope/soap:Body/wse:Notify/@actionURI| attribute
> of the Wrapped Notification has the value of the |actionURI|
> attribute of the |eventType| element corresponding to the type
> of the Event being transmitted.
> * The |/soap:Envelope/soap:Body/wse:Notify| element has a single
> child element. This child element is an instance of the Global
> Element Declaration referenced by the |element| attribute of the
> |eventType| element corresponding to the type of the Event being
> transmitted.
>
>
> A.3 Notification WSDLs
>
> As described previously, Event Sources transmit Events to Event Sinks
> as SOAP messages called "Notifications". These Notifications MAY be
> described via a Web Services Definition Language [WSDL 1.1] <#WSDL11>
> |definitions| element termed a "Notification WSDL". A Notification
> WSDL describes the interface that the Event Sink is required to
> implement to receive and process the Notifications that might result
> from a successful Subscribe request that used a particular Format URI.
> Notification WSDLs contain abstract port types and concrete bindings.
> The port types contain operations that correspond to the Events that
> are transmitted. The bindings describe the Notification Formats (e.g.
> Unwrapped or Wrapped) for those Events. The following is an example of
> a Notification WSDL:
>
> Example A-5: Notification WSDL
> (01) <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> (02) targetNamespace="http://www.example.org/oceanwatch/notifications"
> (03) xmlns:xs="http://www.w3.org/2001/XMLSchema"
> (04) xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
> (05) xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
> (06) xmlns:ow="http://www.example.org/oceanwatch"
> (07) xmlns:tns="http://www.example.org/oceanwatch/notifications">
> (08) <wsdl:types>
> (09) <xs:schema targetNamepace="http://www.example.org/oceanwatch">
> (10) <xs:include schemaLocation="http://www.example.org/schemas/oceanwatch.xsd"/>
> (11) <xs:element name="WindReport" type="ow:WindReportType">
> (12) </xs:schema>
> (13) </wsdl:types>
> (14)
> (15) <wsdl:message name="WindReportNotificationMsg">
> (16) <wsdl:part name="event" element="ow:WindReport"/>
> (17) </wsdl:message>
> (18)
> (19) <wsdl:portType name="WindReportPortType">
> (20) <wsdl:operation name="WindReportNotificationOp">
> (21) <wsdl:input message="tns:WindReportNotificationMsg"
> (22) wsam:Action="http://www.example.org/oceanwatch/2003/WindReport"/>
> (23) </wsdl:operation>
> (24) </wsdl:portType>
> (25)
> (26) <wsdl:binding name="WindReportBinding" type="tns:WindReportPortType">
> (27) <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
> (28) <wsdl:operation name="WindReportNotificationOp">
> (29) <soap:operation soapAction=""/>
> (30) <wsdl:input>
> (31) <soap:body use="literal"/>
> (32) </wsdl:input>
> (33) </wsdl:operation>
> (34) </wsdl:binding>
> (35) </wsdl:definitions>
>
>
> The abstract portion of this Notification WSDL is in lines (08-24).
> The concrete binding in lines (26-34) corresponds to the Unwrapped
> Notification Format.
>
>
> A.3.1 Retrieving Notification WSDLs
>
> Although there are many ways in which an Event Source can make
> Notification WSDLs available to potential Subscribers and Event Sinks,
> this specification RECOMMENDS the use of the mechanisms described in
> WS-MetadataExchange [WS-MetadataExchange] <#MEX>. This specification
> defines the following URI to serve as the Dialect URI for the
> Notification WSDL.
>
> http://www.w3.org/2009/02/ws-evt/NotificationWSDL
>
>
> Because the Notification Format specified in a Subscribe request can
> affect various aspects of the Notification WSDL, it is necessary to
> correlate Notification WSDLs with their corresponding Notification
> Formats. When using WS-MetadataExchange to transfer Notification
> WSDLs, the corresponding Format URI for that Notification WSDL is
> represented via the @Identifier attribute.
>
> When a mex:GetMetadata request is targeted to a Subscription Endpoint
> with a mex:Dialect@URI of either
> "http://www.w3.org/2009/02/ws-evt/NotificationWSDL" or
> "http://www.w3.org/2009/06/ws-mex/Dialects/ws-mex-all", the
> mex:Metadata element of the mex:GetMetadataResponse MAY include (in
> addition to other Metadata Sections that may be present) one or more
> Metadata Sections with a @Dialect attribute with the value of
> "http://www.w3.org/2009/02/ws-evt/NotificationWSDL" and a
> |wsdl:definitions| element as their dialect specific element. The
> value of the @Identifier attribute for these Metadata Sections MUST
> equal the Format URI associated with that Notification WSDL
> (e.g."http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Unwrap"). For
> any particular Format URI/@Identifier, there MUST NOT exist more than
> one Metadata Section containing a Notification WSDL.
>
> The following GetMetadata request, when sent to the Subscription
> Endpoint used in Example 2-1 <#Table1>
>
> Example A-6: GetMetadata Request for Notification WSDLs
> (01) <s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (02) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (03) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (04) xmlns:mex="http://www.w3.org/2009/02/ws-mex">
> (05) <s12:Header>
> (06) <wsa:Action>
> (07) http://www.w3.org/2009/02/ws-mex/GetMetadata
> (08) </wsa:Action>
> (09) <wsa:MessageID>
> (10) uuid:126287f0-521d-11de-8a39-0800200c9a66
> (11) </wsa:MessageID>
> (12) <wsa:To>http://www.example.org/oceanwatch/EventSource</wsa:To>
> (13) </s12:Header>
> (14) <s12:Body>
> (15) <mex:GetMetadata>
> (16) <mex:Dialect URI="http://www.w3.org/2009/02/ws-evt/NotificationWSDL"
> (17) Identifier="http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Unwrap"/>
> (18) </mex:GetMetadata>
> (19) </s12:Body>
> (20) </s12:Envelope>
>
>
> returns the following GetMetadataResponse element
>
> Example A-7: GetMetadataResponse with Notification WSDL
> (01) <s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> (02) xmlns:wsa="http://www.w3.org/2005/08/addressing"
> (03) xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> (04) xmlns:mex="http://www.w3.org/2009/02/ws-mex">
> (05) <s12:Header>
> (06) <wsa:Action>
> (07) http://www.w3.org/2009/02/ws-mex/GetMetadataResponse
> (08) </wsa:Action>
> (09) <wsa:RelatesTo>
> (10) uuid:126287f0-521d-11de-8a39-0800200c9a66
> (11) </wsa:RelatesTo>
> (12) </s12:Header>
> (13) <s12:Body>
> (14) <mex:Metadata>
> (15) <mex:MetadataSection Dialect="http://www.w3.org/2009/02/ws-evt/NotificationWSDL"
> (16) Identifier="http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Unwrap">
> (17) <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> (18) targetNamespace="http://www.example.org/oceanwatch/notifications"
> (19) . . .
> (20) xmlns:tns="http://www.example.org/oceanwatch/notifications">
> (21) <wsdl:types>
> (22) <xs:schema targetNamepace="http://www.example.org/oceanwatch">
> (23) <xs:include schemaLocation="http://www.example.org/schemas/oceanwatch.xsd"/>
> (24) <xs:element name="WindReport" type="ow:WindReportType">
> (25) </xs:schema>
> (26) </wsdl:types>
> (27)
> (28) <wsdl:message name="WindReportNotificationMsg">
> (29) <wsdl:part name="event" element="ow:WindReport"/>
> (30) </wsdl:message>
> (31)
> (32) . . .
> (33) </wsdl:definitions>
> (34) </mex:MetadataSection
> (35) </mex:Metadata>
> (36) </s12:Body>
> (37) </s12:Envelope>
>
>
>
> A.4 Multiple Event Information Metadata Sections
>
> When WS-MetadataExchange [WS-MetadataExchange] <#MEX> is used to
> retrieve metadata about an Event Source, recipients of mex:Metadata
> elements that contain Metadata Sections with both the
> "http://www.w3.org/2009/02/ws-evt/EventDescriptions" and
> "http://www.w3.org/2009/02/ws-evt/NotificationWSDL" dialects MUST
> regard these Metadata Sections as relating to the same set of Events.
> In cases where the mex:Metadata element contains multiple Notification
> WSDLs (i.e. multiple Metadata Sections with a @Dialect of
> "http://www.w3.org/2009/02/ws-evt/NotificationWSDL"), recipients MUST
> similarly regard these Notification WSDLs as relating to the same set
> of Events although their Notification Formats differ.
>
>
> B XML Schema
>
> A normative copy of the XML Schema [XML Schema, Part 1] <#XMLSchema1>,
> [XML Schema, Part 2] <#XMLSchema2> description for this specification
> may be retrieved from the following address:
>
> http://www.w3.org/2009/02/ws-evt/eventing.xsd
>
> A non-normative copy of the XML schema is listed below for convenience.
>
> <xs:schema
> targetNamespace="http://www.w3.org/2009/02/ws-evt"
> xmlns:tns="http://www.w3.org/2009/02/ws-evt"
> xmlns:wsa="http://www.w3.org/2005/08/addressing"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified"
> blockDefault="#all">
>
> <xs:import
> namespace="http://www.w3.org/XML/1998/namespace"
> schemaLocation="http://www.w3.org/2001/xml.xsd" />
> <xs:import
> namespace="http://www.w3.org/2005/08/addressing"
> schemaLocation="http://www.w3.org/2005/08/addressing/ws-addr.xsd" />
>
> <!-- Types and global elements -->
> <xs:complexType name="DeliveryType" mixed="true">
> <xs:sequence>
> <xs:element ref="tns:NotifyTo" minOccurs="0" maxOccurs="1" />
> <xs:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded" />
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
>
> <xs:complexType name="FormatType" mixed="true">
> <xs:sequence>
> <xs:any namespace="##any" processContents="lax"
> minOccurs="0" maxOccurs="unbounded" />
> </xs:sequence>
> <xs:attribute name="Name" type="xs:anyURI" use="optional"
> default="http://http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Unwrap" />
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
>
> <xs:simpleType name="NonNegativeDurationType">
> <xs:restriction base="xs:duration">
> <xs:minInclusive value="P0Y0M0DT0H0M0S" />
> </xs:restriction>
> </xs:simpleType>
>
> <xs:simpleType name="ExpirationType">
> <xs:union memberTypes="xs:dateTime
> tns:NonNegativeDurationType" />
> </xs:simpleType>
>
> <xs:complexType name="FilterType" mixed="true">
> <xs:sequence>
> <xs:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded" />
> </xs:sequence>
> <xs:attribute name="Dialect" type="xs:anyURI" use="optional"
> default="http://www.w3.org/TR/1999/REC-xpath-19991116" />
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
>
> <xs:complexType name="LanguageSpecificStringType">
> <xs:simpleContent>
> <xs:extension base="xs:string">
> <xs:attribute ref="xml:lang" />
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:extension>
> </xs:simpleContent>
> </xs:complexType>
>
> <xs:element name="NotifyTo" type="wsa:EndpointReferenceType" />
>
> <!-- Subscribe request -->
> <xs:element name="Subscribe">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="EndTo" type="wsa:EndpointReferenceType"
> minOccurs="0" />
> <xs:element name="Delivery" type="tns:DeliveryType" />
> <xs:element name="Format" type="tns:FormatType"
> minOccurs="0" />
> <xs:element name="Expires" type="tns:ExpirationType"
> minOccurs="0" />
> <xs:element name="Filter" type="tns:FilterType"
> minOccurs="0" />
> <xs:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded" />
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
> </xs:element>
>
> <!-- Subscribe response -->
> <xs:element name="SubscribeResponse">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="SubscriptionManager"
> type="wsa:EndpointReferenceType" />
> <xs:element name="Expires" type="tns:ExpirationType" />
> <xs:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded" />
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
> </xs:element>
>
> <!-- Used in a fault if there's an unsupported dialect -->
> <xs:element name="SupportedDialect" type="xs:anyURI" />
>
> <!-- Used in a fault if there's an unsupported format name -->
> <xs:element name="SupportedDeliveryFormat" type="xs:anyURI" />
>
> <!-- Renew request -->
> <xs:element name="Renew">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="Expires" type="tns:ExpirationType"
> minOccurs="0" />
> <xs:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded" />
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
> </xs:element>
>
> <!-- Renew response -->
> <xs:element name="RenewResponse">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="Expires" type="tns:ExpirationType"
> minOccurs="0" />
> <xs:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded" />
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
> </xs:element>
>
> <!-- GetStatus request -->
> <xs:element name="GetStatus">
> <xs:complexType>
> <xs:sequence>
> <xs:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded" />
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
> </xs:element>
>
> <!-- GetStatus response -->
> <xs:element name="GetStatusResponse">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="Expires" type="tns:ExpirationType"
> minOccurs="0" />
> <xs:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded" />
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
> </xs:element>
>
> <!-- Unsubscribe request -->
> <xs:element name="Unsubscribe">
> <xs:complexType>
> <xs:sequence>
> <xs:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded" />
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
> </xs:element>
>
> <!-- Unsubscribe response -->
> <xs:element name="UnsubscribeResponse">
> <xs:complexType>
> <xs:sequence>
> <xs:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded" />
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
> </xs:element>
>
> <!-- SubscriptionEnd message -->
> <xs:element name="SubscriptionEnd">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="Status"
> type="tns:OpenSubscriptionEndCodeType" />
> <xs:element name="Reason"
> type="tns:LanguageSpecificStringType"
> minOccurs="0" maxOccurs="unbounded" />
> <xs:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded" />
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
> </xs:element>
>
> <xs:simpleType name="SubscriptionEndCodeType">
> <xs:restriction base="xs:anyURI">
> <xs:enumeration value=
> "http://www.w3.org/2009/02/ws-evt/DeliveryFailure" />
> <xs:enumeration value=
> "http://www.w3.org/2009/02/ws-evt/SourceShuttingDown" />
> <xs:enumeration value=
> "http://www.w3.org/2009/02/ws-evt/SourceCancelling" />
> </xs:restriction>
> </xs:simpleType>
>
> <xs:simpleType name="OpenSubscriptionEndCodeType">
> <xs:union memberTypes="tns:SubscriptionEndCodeType xs:anyURI" />
> </xs:simpleType>
>
> <!-- RetryAfter Fault Detail Element -->
> <xs:element name="RetryAfter" type="tns:RetryAfterType"/>
> <xs:complexType name="RetryAfterType">
> <xs:simpleContent>
> <xs:extension base="xs:nonNegativeInteger">
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:extension>
> </xs:simpleContent>
> </xs:complexType>
>
> <xs:attribute name="EventSource" type="xs:boolean" />
>
> <!-- Wrapped Events -->
> <xs:complexType name="EventType" mixed="true">
> <xs:sequence>
> <xs:any namespace="##any" processContents="lax" minOccurs="0"
> maxOccurs="unbounded"/>
> </xs:sequence>
> <xs:attribute name="actionURI" type="xs:anyURI" use="optional" />
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
> <xs:element name="Notify" type="tns:EventType" />
>
> </xs:schema>
>
>
> C WSDL
>
> A normative copy of the WSDL [WSDL 1.1] <#WSDL11> description can be
> retrieved from the following address:
>
> http://www.w3.org/2009/02/ws-evt/eventing.wsdl
>
> A non-normative copy of the WSDL description is listed below for
> convenience.
>
> <wsdl:definitions
> targetNamespace="http://www.w3.org/2009/02/ws-evt"
> xmlns:wsa="http://www.w3.org/2005/08/addressing"
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
> xmlns:wse="http://www.w3.org/2009/02/ws-evt"
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> xmlns:xs="http://www.w3.org/2001/XMLSchema" >
>
> <wsdl:types>
> <xs:schema>
> <xs:import
> namespace="http://www.w3.org/2009/02/ws-evt"
> schemaLocation=
> "http://www.w3.org/2009/02/ws-evt/eventing.xsd" />
> </xs:schema>
> </wsdl:types>
>
> <wsdl:message name="SubscribeMsg" >
> <wsdl:part name="body" element="wse:Subscribe" />
> </wsdl:message>
> <wsdl:message name="SubscribeResponseMsg" >
> <wsdl:part name="body" element="wse:SubscribeResponse" />
> </wsdl:message>
>
> <wsdl:message name="RenewMsg" >
> <wsdl:part name="body" element="wse:Renew" />
> </wsdl:message>
> <wsdl:message name="RenewResponseMsg" >
> <wsdl:part name="body" element="wse:RenewResponse" />
> </wsdl:message>
>
> <wsdl:message name="GetStatusMsg" >
> <wsdl:part name="body" element="wse:GetStatus" />
> </wsdl:message>
> <wsdl:message name="GetStatusResponseMsg" >
> <wsdl:part name="body" element="wse:GetStatusResponse" />
> </wsdl:message>
>
> <wsdl:message name="UnsubscribeMsg" >
> <wsdl:part name="body" element="wse:Unsubscribe" />
> </wsdl:message>
> <wsdl:message name="UnsubscribeResponseMsg" >
> <wsdl:part name="body" element="wse:UnsubscribeResponse" />
> </wsdl:message>
>
> <wsdl:message name="SubscriptionEnd" >
> <wsdl:part name="body" element="wse:SubscriptionEnd" />
> </wsdl:message>
>
> <message name="notifyEvent">
> <part name="parameter" element="tns:Notify"/>
> </message>
>
> <wsdl:portType name="EventSource" >
> <wsdl:operation name="SubscribeOp" >
> <wsdl:input
> message="wse:SubscribeMsg"
> wsam:Action="http://www.w3.org/2009/02/ws-evt/Subscribe"/>
> <wsdl:output
> message="wse:SubscribeResponseMsg"
> wsam:Action="http://www.w3.org/2009/02/ws-evt/SubscribeResponse"/>
> </wsdl:operation>
> </wsdl:portType>
>
> <wsdl:portType name="SubscriptionEndPortType" >
> <wsdl:operation name="SubscriptionEnd" >
> <wsdl:input
> message="wse:SubscriptionEnd"
> wsam:Action="http://www.w3.org/2009/02/ws-evt/SubscriptionEnd"/>
> </wsdl:operation>
> </wsdl:portType>
>
> <wsdl:portType name="SubscriptionManager" >
> <wsdl:operation name="RenewOp" >
> <wsdl:input
> message="wse:RenewMsg"
> wsam:Action="http://www.w3.org/2009/02/ws-evt/Renew"/>
> <wsdl:output
> message="wse:RenewResponseMsg"
> wsam:Action="http://www.w3.org/2009/02/ws-evt/RenewResponse"/>
> </wsdl:operation>
> <wsdl:operation name="GetStatusOp" >
> <wsdl:input
> message="wse:GetStatusMsg"
> wsam:Action="http://www.w3.org/2009/02/ws-evt/GetStatus"/>
> <wsdl:output
> message="wse:GetStatusResponseMsg"
> wsam:Action="http://www.w3.org/2009/02/ws-evt/GetStatusResponse"/>
> </wsdl:operation>
> <wsdl:operation name="UnsubscribeOp" >
> <wsdl:input
> message="wse:UnsubscribeMsg"
> wsam:Action="http://www.w3.org/2009/02/ws-evt/Unsubscribe"/>
> <wsdl:output
> message="wse:UnsubscribeResponseMsg"
> wsam:Action="http://www.w3.org/2009/02/ws-evt/UnsubscribeResponse"/>
> </wsdl:operation>
> </wsdl:portType>
>
> <portType name="WrappedSinkPortType">
> <operation name="NotifyEvent">
> <input message="tns:notifyEvent" name="NotifyEvent"
> wsam:Action="http://www.w3.org/2009/02/ws-evt/WrappedSinkPortType/NotifyEvent"/>
> </operation>
> </portType>
> </wsdl:definitions>
>
>
> D WSDL for Standard Wrapped Delivery
>
> If an Event Subscriber specifies the wrapped event delivery format
> http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Wrap in the Subscribe
> request message, then the Event Sink MUST implement the following
> abstract WSDL and the Event Source MUST send the Notification messages
> wrapped in the element defined in the WSDL.
>
> <definitions
> xmlns="http://schemas.xmlsoap.org/wsdl/"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
> xmlns:wsa="http://www.w3.org/2005/08/addressing/"
> xmlns:tns="http://www.w3.org/2009/02/ws-evt"
> targetNamespace="http://www.w3.org/2009/02/ws-evt">
>
> <types>
> <xs:schema
> targetNamespace="http://www.w3.org/2009/02/ws-evt">
>
> <xs:complexType name="EventType" mixed="true">
> <xs:sequence>
> <xs:any namespace="##any" processContents="lax" minOccurs="0"
> maxOccurs="unbounded"/>
> </xs:sequence>
> <xs:attribute name="actionURI" type="xs:anyURI" use="optional" />
> <xs:anyAttribute namespace="##other" processContents="lax" />
> </xs:complexType>
>
> <xs:element name="Notify" type="tns:EventType" />
> </xs:schema>
> </types>
>
> <message name="notifyEvent">
> <part name="parameter" element="tns:Notify"/>
> </message>
>
> <portType name="WrappedSinkPortType">
> <operation name="NotifyEvent">
> <input message="tns:notifyEvent" name="NotifyEvent"
> wsam:Action="http://www.w3.org/2009/02/ws-evt/WrappedSinkPortType/NotifyEvent"/>
> </operation>
> </portType>
> </definitions>
>
>
> E XML Schema for EventDescriptions
>
> A normative copy of the XML Schema [XML Schema, Part 1] <#XMLSchema1>,
> [XML Schema, Part 2] <#XMLSchema2> description for the
> EventDescriptions element may be retrieved from the following address:
>
> http://www.w3.org/2009/02/ws-evt/EventDescriptions.xsd <http://www.w3.org/2009/02/ws-evt/eventing.xsd>
>
>
> A non-normative copy of the XML schema is listed below for convenience.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> targetNamespace="http://www.w3.org/2009/02/ws-evt"
> elementFormDefault="qualified" attributeFormDefault="unqualified">
> <xs:element name="EventDescriptions">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="types">
> <xs:annotation>
> <xs:documentation>Data type definitions that are relevant to described notifications.</xs:documentation>
> </xs:annotation>
> <xs:complexType>
> <xs:sequence>
> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> <xs:anyAttribute namespace="##other" processContents="lax"/>
> </xs:complexType>
> </xs:element>
> <xs:element name="eventType" maxOccurs="unbounded">
> <xs:complexType>
> <xs:sequence>
> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> <xs:attribute name="name" type="xs:NCName" use="required"/>
> <xs:attribute name="element" type="xs:QName" use="required"/>
> <xs:attribute name="action" type="xs:anyURI" use="required"/>
> <xs:anyAttribute namespace="##other" processContents="lax"/>
> </xs:complexType>
> </xs:element>
> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> <xs:attribute name="targetNamespace" type="xs:anyURI" use="required"/>
> <xs:anyAttribute namespace="##other" processContents="lax"/>
> </xs:complexType>
> </xs:element>
> </xs:schema>
>
>
>
> F Change Log
>
> Data Author Description
> 2009/03/04 DD Added resolution of issue 6391
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6391>
> 2009/03/04 DD Added resolution of issue 6519
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6519>
> 2009/03/04 DD Added resolution of issue 6427
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6427>
> 2009/03/04 DD Added resolution of issue 6459
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6459>
> 2009/03/09 DD Added resolution of issue 6397
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6397>
> 2009/03/09 DD Added resolution of issue 6426
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6426>
> 2009/03/11 DD Added change log
> 2009/03/11 DD Added resolution of issue 6641
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6641>
> 2009/03/11 DD Added resolution of issue 6498
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6498>
> 2009/03/11 DD Added resolution of issue 6425
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6425>
> 2009/03/16 KW Added resolution of issue 6587
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6587>
> 2009/03/17 KW Added resolution of issue 6400
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6400>
> 2009/03/17 DD Added resolution of issue 6428
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6428>
> 2009/03/17 DD Added resolution of issue 6687
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6687>
> 2009/03/23 DD Added resolution of issue 6666
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6666>
> 2009/03/23 DD Added resolution of issue 6681
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6681>
> 2009/03/24 DD Added resolution of issue 6595
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6595>
> 2009/03/24 DD Added resolution of issue 6648
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6648>
> 2009/04/07 DD Added resolution of issue 6727
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6727>
> 2009/04/07 DD Added resolution of issue 6725
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6725>
> 2009/04/07 DD Added resolution of issue 6715
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6715>
> 2009/04/22 KW Added resolution of issue 6739
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6739>
> 2009/04/28 DD Added resolution of issue 6787
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6787>
> 2009/04/28 DD Added resolution of issue 6788
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6788>
> 2009/05/13 KW Added resolution of issue 6472
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6472>
> 2009/05/13 DD Added resolution of issue 6850
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6850>
> 2009/05/13 DD Added resolution of issue 6696
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6696>
> 2009/05/19 DD Added resolution of issue 6907
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6907>
> 2009/05/19 DD Added resolution of issue 6429
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6429>
> 2009/05/21 DD Added resolution of issue 6674
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6674>
> 2009/05/27 DD Added resolution of issue 6906
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6906>
> 2009/06/04 DD Added resolution of issue 6955
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6955>
> 2009/06/04 DD Added resolution of issue 6916
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6916>
> 2009/06/04 DD Added resolution of issue 6986
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6986>
> 2009/07/07 DD Added resolution of issue 7039
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7039>
> 2009/07/21 DD Added resolution of issue 6980
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6980>
> 2009/07/28 DD Added resolution of issue 6692
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692>
> 2009/08/04 DD Added resolution of issue 7136
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7136>
>
Received on Monday, 24 August 2009 19:07:48 UTC