WSRA Scenario

1.1 Scope

The following specifications and technologies are in scope for this scenario:

• SOAP 1.1

• WS-MetadataExchange

• WS-Eventing

• WS-EventDescription

• WS-MakeConnection

• WS-Policy

• WS-Transfer

• WS-Fragment

• WS-Enumeration

• WS-SOAPAssertions

• WSDL 1.1

1.2 XML Namespaces

Table 1-1 lists XML namespaces that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant.

1.3 Preconditions

2.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 [RFC 2119].

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:

  • "?" (0 or 1)

  • "*" (0 or more)

  • "+" (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.

3.1 Predefined Animals/Tags

At a minimum each service side implementation of this scenario MUST initially have at least the following animals/tags:

• ID: -- system defined --
  Name: Howard
  Birthdate: 12/08/2006
  Gender: Male
  Family: Eschrichtiidae
  Genus: Eschrichtius
  Species: robustus
  

• ID: -- system defined --
  Name: Kerry
  Birthdate: 05/22/2008
  Gender: Female
  Family: Delphinidae
  Genus: Orcinus
  Species: orca
  

• ID: -- system defined --
  Name: Oscar
  Birthdate: 03/01/2010
  Gender: Male
  Family: Balaenopteridae
  Genus: Megaptera
  Species: novaeangliae
  

3.2 Events

This scenario defines several events that MUST be generated if the service implementation supports WS-Eventing. The following events are defined:

• NewAnimal
  

  Generated when a new Animal is added to the tracking system.

• UpdateLocation
  

  Generated when an Animal's locationis updated. While in the real world the frequency of this event might be hourly or even daily, for the sake of feasibility we compress time by a scale of 1/120 so that one hour in 'scenario time' is thirty seconds in real-world time. The time data contained in the notifications will reflect scenario time.

• UpdateAnimal
  

  Generated when an Animal's data is updated in the tracking system. Note that this event is different from the updating of the GPS coordinate property. This event is sent when any other property (e.g. Name) is updated.

• RemoveAnimal
  

  Generated when an Animal is removed to the tracking system.

Each of the event that are generated will include the full XML represenation of the Animal within the Body of the event. An EventDescriptions document that describes the structure of the event information within the notifications can be found in 10 EventDescriptions.

3.3 Structure of Test Sections

The following sections describe tests designed to exercise all the mandatory and optional features of indicated specifications. Each of these tests is organized into four parts:

• An overview that describes the purpose of the test and the salient features of the messages that are exchanged.

• An optional sequence diagram that illustrates the sequence of events in the test.

• A list of criteria used to judge the success of the test.

• A conformance section that enumerates the conditions under which conforming implementations are allowed to either not implement the test or fail one or more of the success criteria.

3.4 Scenario Header

Some of the tests in this document require specialized logic by the service in order to create the situations described by the tests. This document defines a SOAP Header that can be used to convey which test is being executed, as well as any other additional information, to allow the service to perform the appropriate actions.

The outline of this header is:

<sce:Scenario ...>
 <sce:Test> x.y </sce:Test>
 <sce:EndTime> xs:duration | xs:dateTime </sce:EndTime>
 ...
</sce:Scenario>

Where "x.y" is the test number. Certain tests define additional elements that might appear as children of the sce:Scenario element.

4.1 GetWSDL Test

This test verifies the ability to retrieve the WSDL associated with a WS-MetadataExchange compliant service.

4.2 Empty GetMetadata Test

This test verifies the ability to retrieve Metadata using the GetMetadata operation. In this test the GetMetadata request will not contain any child elements. In other words, the client is asking for all available metadata to be returned.

4.3 WSDL GetMetadata Test

This test verifies the ability to retrieve Metadata using the GetMetadata operation. In this test the client will specifically ask for the WSDL of the service.

4.4 Unknown GetMetadata Test

This test verifies the ability ask for unknown Metadata using the GetMetadata operation. In this test the client will specifically ask for an unknown Metadata type and the service is expected to ignore the request.

4.5 MultiMetadata GetMetadata Test

This test verifies the ability ask for multiple types of Metadata at the same time using the GetMetadata operation. In this test the client will specifically ask for multiple types of Metadata (both known and unknown types) and the service is expected to process each type appropriately.

4.6 PutMetadata Test

This test verifies the ability to update Metadata using the PutMetadata operation. In this case the client will update the WS-EventDescriptions metadata associated with the Tracker service.

4.7 DeleteMetadata Test

This test verifies the ability to update Metadata using the DeleteMetadata operation. The client will request the deletion of the WS-EventingDescription metadata.

5.1 Basic Test

This test verifies the ability to subscribe and receive notifications. The initial Subscribe request has the following features:

• expiration time chose by Event Source/Subscription Manager - ie. no Expires

• no EndTo EPR

• no Filters

• unwrapped notifications - ie. no Format element

5.1.1 Sequence

The following diagram illustrates the sequence of messages for the Basic Test.

5.2 Wrapped Notifications

This test verifies the simple ability to subscribe and receive wrapped notifications. The initial Subscribe request has the following features:

• expiration time chosen by Event Source/Subscription Manager

• no EndTo EPR

• no Filters

• wrapped notifications

5.3 Duration Expiration Test

This test verifies the correct implementation of the expiration feature on the Event Source/Subscription Manager. The initial Subscribe message has the following features:

• (short) expiration time chosen by Subscriber as xs:duration

• no EndTo EPR

• no Filters

• unwrapped notifications

5.3.1 Sequence

The following diagram illustrates the sequence of messages for the Duration Expiration Test. Note that the Subscriber waits until the expiration time has passed before sending the GetStatus request.

5.4 Specific Time Expiration Test

This test verifies the correct implementation of the expiration feature on the Event Source/Subscription Manager. The initial Subscribe request has the following features:

• (short) expiration time chosen by Subscriber as xs:dateTime

• no EndTo EPR

• no Filters

• unwrapped notifications

5.5 Best Effort Expiration Test

This test verifies the correct implementation of the 'best effort' expiration feature on the Event Source/Subscription Manager. The initial subscription has the following features:

• expiration time chosen by Subscriber as xs:duration with @BestEffort ='true'

• no EndTo EPR

• no Filters

• unwrapped notifications

5.6 Renew Test

This test verifies the ability of a Subscriber to update the expiration time of a Subscription via a Renew request. The initial Subscribe request has the following features:

• (short) expiration time chosen by Subscriber as xs:duration

• no EndTo EPR

• no Filter

• unwrapped notifications

The Renew request has the following features:

• (short) expiration time chosen by Subscriber as xs:duration

5.6.1 Sequence

The following diagram illustrates the sequence of messages for the Renew Test.

5.7 SubscriptionEnd Test

This test verifies the correct implementation of the SubscriptionEnd feature for both the Subscription Manager and the target of the SubscriptionEnd message. The initial Subscribe request has the following features:

• expiration time chosen by Event Source/Subscription Manager

• EndTo EPR

• no Filters

• unwrapped notifications

Note: this test requires the client to include an additional element in the sce:Scenario header:

<sce:EndTime> xs:duration | xs:dateTime </sce:EndTime>

The duration/time specified by this element indicates when the event source is to "unexceptedly" terminate the subscription, thus causes the SubscriptionEnd message to be sent. The value specified in this element must be less than the expires time specified in the Subscribe request message.

5.7.1 Sequence

The following diagram illustrates the sequence of messages for the SubscriptionEnd Test.

5.8 Filter Test - XPath 1.0

This test verifies the ability of the Event Source/Subscription Manager to correctly implement XPath 1.0 filters. The initial Subscribe request has the following features:

• expiration time chosen by Event Source/Subscription Manager

• no EndTo EPR

• Filter in dialect 'http://www.w3.org/2010/08/ws-evt/Dialects/XPath10' that selects those events that apply to the animal named 'Kerry':
  //*[local-name()='Name']/node()='Kerry'

• unwrapped notifications

5.9 Filter Test - XPath 2.0

This test verifies the ability of the Event Source/Subscription Manager to correctly implement XPath 2.0 filters. The initial Subscribe request has the following features:

• expiration time chosen by Event Source/Subscription Manager

• no EndTo EPR

• Filter in dialect 'http://www.w3.org/2010/08/ws-evt/Dialects/XPath20' that selects those events that apply to the animal named 'Oscar':
  //*[local-name()='Name']/node()='Oscar'

• unwrapped notifications

5.10 Non-Addressable Event Sink Test

This test verifies the ability to subscribe and receive notifications in an environment in which the Event Sink cannot accept connections from systems outside its network (i.e. the Event Sink is non-addressable). The facilities described by WS-MakeConnection are used by the Event Sink to poll for Notifications from the Event Source.

The initial Subscribe request has the following features:

• expiration time chose by Event Source/Subscription Manager

• no EndTo EPR

• no Filters

• unwrapped notifications

• the value of wse:Delivery/wse:NotifyTo/wsa:Address is an instance of the MakeConnection anonymous URI (e.g. http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=550e8400-e29b-11d4-a716-446655440000).

5.11 Sequence

The following diagram illustrates the sequence of messages for the Non-Addressable Event Sink Test.

Note that the MakeConnection requests that follow both the Subscribe and the Unsubscribe requests are optional. It may happen that the SubscribeResponse and UnsubscribeResponse are both transmitted on the back-channel of their corresponding requests.

5.12 Success Criteria

• Receipt of a valid Subscribe message by the Event Source.

• Receipt of a valid SubscribeResponse message by Subscriber.

• Receipt of one or more unwrapped Notifications by the Event Sink.

• Receipt of a valid Unsubscribe message by the Subscription Manager.

• Receipt of a valid UnsubscribeResponse message by the Subscriber.

Because this test involves the use of WS-MakeConnection there are a number of failure cases that fall within the boundaries of conforming behavior.

A conforming Subscriber/Event Sink MAY NOT be capable of implementing this test due to its inability to support WS-MakeConnection.

A conforming Event Source MAY respond to the initial Subscribe request with a wse:UnusableEPR fault. However, because WS-Eventing does not require Event Sources to validate the NotifyTo EPR at subscribe-time, it MAY be that the Subscribe request succeeds (although the SubscribeResponse is never delivered to the Subscriber) but Notifications are simply not delivered to the Event Sink.

Because Event Sinks and Subscription Managers are not required to implment WS-MakeConnection, the MakeConnection requests MAY elicit a wsa:ActionNotSupported fault response or some other, unspecified behavior.

6.1 Create Test

This test will verifies the ability to create a new Animal/Tag in the service. The Create message will contain the initial representation of the new Animal/Tag.

6.2 Get Test

This test verifies the ability of a client to retrieve the current representation of an Animal/Tag. The endpoint to which this test is executed against may be any valid endpoint created during the Create test or returned from any other test described in this document as long as it refers to an Animal resource. The use of WS-MetadataExchange is recommeneded to ensure that the endpoint supports WS-Transfer.

6.3 Fragment Get Test

This test verifies the ability of a client to retrieve a subset of the current representation of an Animal/Tag. The endpoint to which this test is executed against may be any valid endpoint created during the Create test or returned from any other test described in this document as long as it refers to an Animal resource. The use of WS-MetadataExchange is recommeneded to ensure that the endpoint supports WS-Transfer.

6.4 Put Test

This test verifies the ability of a client to update the current representation of an Animal/Tag. The endpoint to which this test is executed against may be any valid endpoint created during the Create test or returned from any other test described in this document as long as it refers to an Animal resource. The use of WS-MetadataExchange is recommeneded to ensure that the endpoint supports WS-Transfer.

6.5 Fragment Put Test

This test verifies the ability of a client to update a portion of the current representation of an Animal/Tag. The endpoint to which this test is executed against may be any valid endpoint created during the Create test or returned from any other test described in this document as long as it refers to an Animal resource. The use of WS-MetadataExchange is recommeneded to ensure that the endpoint supports WS-Transfer.

<sce:Animal xmlns:sce="http://www.w3.org/2002/ws/ra/test/scenario">
  <sce:ID> ... </sce:ID>
  <sce:Name> ... </sce:Name>
  <sce:Birthdate> ... </sce:Birthdate>
  <sce:Gender> ... </sce:Gender>
  <sce:Family> ... </sce:Family>
  <sce:Genus> ... </sce:Genus>
  <sce:Species> ... </sce:Species>
  <sce:CurrentLocation> ... </sce:CurrentLocation>
  <sce:History>
    <sce:Entry> ... </sce:Entry>
    <sce:Entry Date="..."> ... </sce:Entry>
  </sce:History>
</sce:Animal>

6.6 Delete Test

This test verifies the ability of a client to delete an Animal/Tag. The endpoint to which this test is executed against may be any valid endpoint created during the Create test or returned from any other test described in this document as long as it refers to an Animal resource. The use of WS-MetadataExchange is recommeneded to ensure that the endpoint supports WS-Transfer.

7.1 Basic Test

This test verifies the ability to enumerate instances of a resource using the default behavior. The initial Enumerate request has the following salient features:

• NewContext element

The subsequent Enumerate requests have the following salient features:

• EnumerationContext element that was provided by the data source

7.1.1 Sequence

The following diagram illustrates the sequence of messages for the Basic Test.

7.2 New Empty Enumeration Test

This test verifies the ability to create a new enumeration without retrieving any of the data items in the first EnumerateResponse message. The initial Enumerate request has the following salient features:

• NewContext element

• MaxElements element equal to 0

The subsequent Enumerate requests have the following salient features:

• EnumerationContext element that was provided by the data source

7.3 Optimized Enumeration Test

This test verifies the ability to enumerate an entire set of instances of a resource with just one Enumerate message. The Enumerate request has the following salient features:

• NewContext element

• MaxElements element with large value

7.3.1 Sequence

The following diagram illustrates the sequence of messages for the Optimized Enumeration Test.

7.4 MaxCharacters Test

This test verifies the ability of a data consumer to limit the size of the items returned from an enumeration using the wsen:MaxCharacters element. The initial Enumerate request has the following salient features:

• NewContext element

• MaxElements element with large value

• MaxCharacters element with a value slightly bigger than one returned item

The subsequent Enumerate requests have the following salient features:

• EnumerationContext element that was provided by the data source

• MaxElements element with a large value

• MaxCharacters element with a value slightly bigger than one returned item

7.5 MaxTime Test

This test verifies the ability of a data consumer to limit the amount of time it takes for the data source to assemble an EnumerateResponse using the wsen:MaxTime element. The initial Enumerate request has the following salient features:

• NewContext element

The second Enumerate request has the following salient features:

• EnumerationContext element that was provided by the data source

• MaxTime element with a very low value. If a data source is designed such that the MaxTime value will have no impact, for the purposes of testing a data source is to return a wsen:TimesOut fault if the MaxTime value is present with a value less than 5 seconds.

The subsequent Enumerate requests have the following salient features:

• EnumerationContext element that was provided by the data source

7.6 Duration Expiration Test

This test verifies the correct implementation of the expiration feature on the data source. The initial Enumerate message has the following salient features:

• NewContext element

• Expires element with a short expiration time as xs:duration

The second Enumerate request has the following salient features:

• EnumerationContext element that was provided by the data source

7.6.1 Sequence

The following diagram illustrates the sequence of messages for the Duration Expiration Test. Note that the data source waits until the expiration time has passed before sending the second Enumerate request.

7.7 Specific Time Expiration Test

This test verifies the correct implementation of the expiration feature on the data source. The initial Enumerate message has the following salient features:

• NewContext element

• Expires element with a short expiration time as xs:dateTime

The second Enumerate request has the following salient features:

• EnumerationContext element that was provided by the data source

7.8 Best Effort Expiration Test

This test verifies the correct implementation of the "best effort expiration feature on the data source. The initial Enumerate message has the following salient features:

• NewContext element

• Expires element with a short expiration time as xs:duration with @BestEffort=true

The second Enumerate request has the following salient features:

• EnumerationContext element that was provided by the data source

7.9 GetStatus Test

This test verifies the ability of a data consumer to get the status of an existing enumeration. The initial Enumerate request has the following salient features:

• NewContext element

The GetStatus message has the following salient features:

• EnumerationContext element that was provided by the data source

7.9.1 Sequence

The following diagram illustrates the sequence of messages for the GetStatus Test.

7.10 Renew Test

This test verifies the ability of a data consumer to renew an existing enumeration. The initial Enumerate request has the following salient features:

• NewContext element

The Renew message has the following salient features:

• EnumerationContext element that was provided by the data source

7.10.1 Sequence

The following diagram illustrates the sequence of messages for the Renew Test.

7.11 Release Test

This test verifies the ability of a data consumer to release an existing enumeration before its data items have all been retrieved. The initial Enumerate request has the following salient features:

• NewContext element

The Release message has the following salient features:

• EnumerationContext element that was provided by the data source

7.11.1 Sequence

The following diagram illustrates the sequence of messages for the Release Test.

7.12 EnumerationEnd Test

This test verifies the ability of a data source to send a notification to a data consumer if it terminates the enumeration unexpectedly. The initial Enumerate request has the following salient features:

• NewContext element

• EndTo element containing an EPR for the data consumer

Note: this test requires the client to include an additional element in the sce:Scenario header:

<sce:EndTime> xs:duration | xs:dateTime </sce:EndTime>

The duration/time specified by this element indicates when the data source is to "unexceptedly" terminate the enumeration, thus causes the EnumerationEnd message to be sent. The value specified in this element must be less than the expires time specified in the Enumerate request message used to create the enumeration.

7.12.1 Sequence

The following diagram illustrates the sequence of messages for the EnumerationEnd Test.

7.13 Filter Test - XPath 1.0

This test verifies the ability of the data source to correctly implement XPath 1.0 filters. The initial Enumerate request has the following salient features:

• NewContext element

• Filter element with @Dialect equal to 'http://www.w3.org/2010/08/ws-enu/Dialects/XPath10' (actual filter expression TBD)

The subsequent Enumerate requests have the following salient features:

• EnumerationContext element that was provided by the data source

7.14 Filter Test - XPath 2.0

This test verifies the ability of the data source to correctly implement XPath 2.0 filters. The initial Enumerate request has the following salient features:

• NewContext element

• Filter element with @Dialect equal to 'http://www.w3.org/2010/08/ws-enu/Dialects/XPath20' (actual filter expression TBD)

The subsequent Enumerate requests have the following salient features:

• EnumerationContext element that was provided by the data source

9.1 Event Source WSDL

TBD

9.2 Notification WSDL

Available here: http://www.w3.org/2002/ws/ra/test/scenario/scenarioSink.wsdl

13.1 Normative References

RFC 2119

Key words for use in RFCs to Indicate Requirement Levels , S. Bradner, Author. Internet Engineering Task Force, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.

SOAP11

W3C Note, "Simple Object Access Protocol (SOAP) 1.1" , D. Box, et al, Editors. World Wide Web Consortium (W3C), 8 May 2000. Available at http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.

SOAP12

W3C Recommendation, "SOAP Version 1.2 Part 1: Messaging Framework" , M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielson, Editors. World Wide Web Consortium (W3C), 27 April 2007. Available at http://www.w3.org/TR/soap12-part1/.

WS-Addressing

W3C Recommendation, "Web Services Addressing 1.0 (WS-Addressing)" , M. Gudgin, M. Hadley, T. Rogers, Editors. World Wide Web Consortium (W3C), 9 May 2006. Available at http://www.w3.org/TR/ws-addr-core.

WS-Enumeration

W3C Working Group Draft, "Web Services Enumeration (WS-Enumeration) 1.1" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. Available at http://www.w3.org/TR/ws-enumeration.

WS-EventDescriptions

W3C Working Group Draft, "Web Services Event Descriptions (WS-EventDescriptions) 1.0" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. Available at http://www.w3.org/TR/ws-event-description.

WS-Eventing

W3C Working Group Draft, "Web Services Eventing (WS-Eventing) 1.1" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. Available at http://www.w3.org/TR/ws-eventing.

WS-Fragment

W3C Working Group Draft, "Web Services Fragment (WS-Fragment) 1.0" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. Available at http://www.w3.org/TR/ws-fragment.

WS-MetadataExchange

W3C Working Group Draft, "Web Services Metadata Exchange (WS-MetadataExchange) 1.1" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. Available at http://www.w3.org/TR/ws-metadata-exchange.

WS-SOAPAssertions

W3C Working Group Draft, "Web Services SOAP Assertions (WS-SOAPAssertions) 1.0" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. Available at http://www.w3.org/TR/ws-soap-assertions.

WS-Transfer

W3C Working Group Draft, "Web Services Transfer (WS-Transfer) 1.1" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. Available at http://www.w3.org/TR/ws-transfer.

WSDL11

W3C Note, "Web Services Description Language (WSDL) 1.1" , E. Christensen, et al., Editors. World Wide Web Consortium (W3C), 15 March 2001 Available at http://www.w3.org/TR/2001/NOTE-wsdl-20010315.

XMLSchema - Part 1

W3C Recommendation, "XML Schema Part 1: Structures (Second Edition)" , H. Thompson, et al., Editors. World Wide Web Consortium (W3C), 28 October 2004. Available at http://www.w3.org/TR/xmlschema-1/.

XMLSchema - Part 2

W3C Recommendation, "XML Schema Part 2: Datatypes (Second Edition)" , P. Biron, A. Malhotra, Editors. World Wide Web Consortium (W3C), 28 October 2004. Available at http://www.w3.org/TR/xmlschema-2/.