Web Services Dynamic Discovery (WS-Discovery ...€¦ · Web viewWeb Services Dynamic Discovery (WS-Discovery) Interoperability Test Scenarios Version 1.1 Working Draft 05 19 February

Web Services Dynamic Discovery (WS-Discovery) Interoperability Test Scenarios Version 1.1Working Draft 054

27 19 January February 2009Specification URIs:This Version:

http://docs.oasis-open.org/ws-dd/discovery/1.1/wd-04/wsdd-discovery-1.1-interop_scenarios-wd-04.htmlhttp://docs.oasis-open.org/ws-dd/discovery/1.1/wd-04/wsdd-discovery-1.1- interop_scenarios-wd-04.docx (Authoritative Format)http://docs.oasis-open.org/ws-dd/discovery/1.1/wd-04/wsdd-discovery-1.1- interop_scenarios-wd-04.pdf

Previous Version:N/A

Latest Version:http://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-interop_scenarios.htmlhttp://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-interop_scenarios.docxhttp://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-interop_scenarios.pdf

Technical Committee:OASIS Web Services Discovery and Web Services Devices Profile (WS-DD) TC

Chair(s):Toby Nixon, MicrosoftAlain Regnier, Ricoh

Editor(s):Vipul Modi, Microsoft

Abstract:This document defines the scenarios for testing interoperability between implementations of a Target Service, a Client and a Discovery Proxy in an ad hoc and a managed mode as defined by the WS-Discovery [WS-Discovery] protocol. The document also describes test setup; and example messages.

Status:This document was last revised or approved by the WS-DD TC on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location noted above for possible later revisions of this document.Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/ws-dd/.

wsdd-discovery-1.1-interop_scenarios-wd-054 27 19 January February 2009Copyright © OASIS® 2009. All Rights Reserved. Page 1 of 32

1

2

3

4

5

6789101112131415161718192021222324252627282930313233343536373839

http://www.oasis-open.org/committees/ws-dd/


http://www.oasis-open.org/committees/ws-dd

http://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-interop_scenarios.pdf

http://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-interop_scenarios.docx

http://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-interop_scenarios.html

http://docs.oasis-open.org/ws-dd/discovery/1.1/wd-04/wsdd-discovery-1.1-%20interop_scenarios-wd-04.pdf

http://docs.oasis-open.org/ws-dd/discovery/1.1/wd-04/wsdd-discovery-1.1-%20interop_scenarios-wd-04.pdf

http://docs.oasis-open.org/ws-dd/discovery/1.1/wd-04/wsdd-discovery-1.1-%20interop_scenarios-wd-04.docx

http://docs.oasis-open.org/ws-dd/discovery/1.1/wd-04/wsdd-discovery-1.1-%20interop_scenarios-wd-04.docx

http://docs.oasis-open.org/ws-dd/discovery/1.1/wd-04/wsdd-discovery-1.1-interop_scenarios-wd-04.html

http://docs.oasis-open.org/ws-dd/discovery/1.1/wd-04/wsdd-discovery-1.1-interop_scenarios-wd-04.html

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/ws-dd/ipr.php.The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/ws-dd/.


40414243444546


http://www.oasis-open.org/committees/ws-dd/ipr.php

http://www.oasis-open.org/committees/ws-dd/ipr.php

NoticesCopyright © OASIS® 2009. All Rights Reserved.All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.The name "OASIS" is trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.


47

48495051525354555657585960616263646566676869707172737475767778798081828384858687888990

http://www.oasis-open.org/who/trademark.php

Table of Contents1 Introduction......................................................................................................................................... 6

1.1 Scope................................................................................................................................................ 61.2 XML Namespaces............................................................................................................................. 61.3 Terminology....................................................................................................................................... 61.4 Requirements.................................................................................................................................... 61.5 Normative References....................................................................................................................... 7

2 Test Setup........................................................................................................................................... 82.1 Test Actors........................................................................................................................................ 8

2.1.1 Calculator Service (TS1)............................................................................................................82.1.2 HelloWorld Service (TS2)...........................................................................................................82.1.3 Calculator Service (TS3)............................................................................................................92.1.4 Secure Calculator Service (S-TS1)............................................................................................92.1.5 Client........................................................................................................................................ 102.1.6 Secure Client (S-C1)................................................................................................................102.1.7 Discovery Proxy (DP)...............................................................................................................10

2.2 Test Certificate................................................................................................................................ 102.2.1 CER1....................................................................................................................................... 11

2.3 Network Topology........................................................................................................................... 112.4 Measuring Success......................................................................................................................... 12

3 Scenarios.......................................................................................................................................... 133.1 Scenario 1.1.1 – Hello-ad hoc.........................................................................................................133.2 Scenario 1.1.2 – Hello-ad hoc-DP...................................................................................................133.3 Scenario 1.2.1 – Hello-managed.....................................................................................................133.4 Scenario 2.1.1 – Bye-ad hoc...........................................................................................................133.5 Scenario 2.1.2 – Bye-ad hoc-DP.....................................................................................................143.6 Scenario 2.2.1 – Bye-managed.......................................................................................................143.7 Scenario 3.1.1 – Probe-ad hoc-empty criteria.................................................................................143.8 Scenario 3.1.2 – Probe-ad hoc-types..............................................................................................153.9 Scenario 3.1.3 – Probe-ad hoc-scopes-RFC3986...........................................................................153.10 Scenario 3.1.4 – Probe-ad hoc-scopes-STRCMP0.......................................................................163.11 Scenario 3.1.5 – Probe-ad hoc-scopes-UUID...............................................................................173.12 Scenario 3.1.6 – Probe-ad hoc-scopes-LDAP...............................................................................173.13 Scenario 3.1.7 – Probe-ad hoc-types-scopes-RFC3986...............................................................183.14 Scenario 3.1.8 – Probe-ad hoc-DP................................................................................................183.15 Scenario 3.1.9 – Probe-ad hoc-suppress......................................................................................183.16 Scenario 3.1.10 – Probe-ad hoc-scopes-none..............................................................................193.17 Scenario 3.2.1 – Probe-managed-empty criteria...........................................................................193.18 Scenario 3.2.2 – Probe-managed-types........................................................................................203.19 Scenario 3.2.3 – Probe-managed-scopes-RFC3986.....................................................................203.20 Scenario 3.2.4 – Probe-managed-scopes-STRCMP0...................................................................213.21 Scenario 3.2.5 – Probe-managed-scopes-UUID...........................................................................223.22 Scenario 3.2.6 – Probe-managed-scopes-LDAP...........................................................................22


91

9293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133

3.23 Scenario 3.2.7 – Probe-managed-types-scopes-RFC3986...........................................................223.24 Scenario 3.2.8 – Probe-managed-scopes-none............................................................................233.25 Scenario 4.1.1 – Resolve-ad hoc..................................................................................................233.26 Scenario 4.1.2 – Resolve-ad hoc-suppress...................................................................................243.27 Scenario 4.2.1 – Resolve-managed..............................................................................................243.28 Scenario 5.1.1 – Compact Signature-Hello-ad hoc.......................................................................253.29 Scenario 5.1.2 – Compact Signature-Bye-ad hoc.........................................................................253.30 Scenario 5.1.3 – Compact Signature-Probe-ad hoc......................................................................263.31 Scenario 5.1.4 – Compact Signature-Resolve-ad hoc...................................................................26

4 Test Service WSDLs.........................................................................................................................284.1 Calculator Service WSDL................................................................................................................284.2 HelloWorld Service WSDL...............................................................................................................29

A. Acknowledgements........................................................................................................................... 31B. Revision History................................................................................................................................ 32


134135136137138139140141142143144145146147148149

1 Introduction1.1 ScopeThis document defines the setup and scenarios for testing protocol level interoperability between implementations of WS-Discovery [WS-Discovery] protocol specification. The scenarios cover the positive functionality and are not meant to provide the full conformance coverage.

1.2 XML NamespacesThe XML Namespace used by the test services in this document is:

http://example.org/ws-dd/discoverytest

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

Table 1: Prefix 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/ [SOAP 1.1]

s12 http://www.w3.org/2003/05/soap-envelope [SOAP 1.2]

a http://www.w3.org/2005/08/addressing [WS-Addressing]

d http://docs.oasis-open.org/ws-dd/discovery/2008/09 [WS-Discovery]

xs http://www.w3.org/2001/XMLSchema [XML Schema Part 1, 2]

test http://example.org/ws-dd/discoverytest This Specification

1.3 TerminologyThe key words “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].

1.4 RequirementsFollowing are the requirements for implementing the scenarios defined in this document.

An implementation MAY implement a Target Service, a Client or a Discovery Proxy role (see Terminology section in WS-Discovery [WS-Discovery]). However for each implemented role it MUST implement all of the actors defined in Table 2 for that role.

A Target Service implementation MUST at least support an ad hoc mode (see Terminology section in WS-Discovery [WS-Discovery]).

A Client implementation MUST at least support an ad hoc mode. A Discovery Proxy implementation MUST at least support a managed mode (see Terminology

section in WS-Discovery [WS-Discovery]). Implementation MUST at least support IPv4. Implementations MUST at least support SOAP 1.2 [SOAP 1.2]. Implementations MAY support compact signature for securing messages in an ad hoc mode.


150

151

152153154

155

156

157

158159

160

161

162163164

165

166167168169170171172173174175176177


http://www.w3.org/2001/XMLSchema

http://docs.oasis-open.org/ws-dd/discovery/2008/09

http://www.w3.org/2003/05/soap-envelope

http://schemas.xmlsoap.org/soap/envelope/


1.5 Normative References[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels,

http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[SOAP 1.1] W3C Note, Simple Object Access Protocol (SOAP) 1.1, http://www.w3.org/TR/2000/NOTE-SOAP-20000508/, 08 May 2000.

[SOAP 1.2] W3C Recommendation, SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), http://www.w3.org/TR/2007/REC-soap12-part1-20070427/, April 2007.

[WS-Addressing] W3C Recommendation, Web Services Addressing 1.0 - Core, http://www.w3.org/TR/2006/REC-ws-addr-core-20060509, 9 May 2006.

[WS-Discovery] OASIS Committee Draft 02, Web Services Dynamic Discovery (WS-Discovery) Version 1.1, http://docs.oasis-open.org/ws-dd/discovery/1.1/cd-02/wsdd-discovery-1.1-spec-cd-02.docx, 20 October 2008.

[XML Schema, Part 1] W3C Recommendation, XML Schema Part 1: Structures, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/, 2 May 2001.

[XML Schema, Part 2] W3C Recommendation, XML Schema Part 2: Datatypes, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/, 02 May 2001.


178

179180181182183184185186187188189190191192193194195196197198199200

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/

http://docs.oasis-open.org/ws-dd/discovery/1.1/cd-02/wsdd-discovery-1.1-spec-cd-02.docx

http://docs.oasis-open.org/ws-dd/discovery/1.1/cd-02/wsdd-discovery-1.1-spec-cd-02.docx

http://www.w3.org/TR/2006/REC-ws-addr-core-20060509

http://www.w3.org/TR/2007/REC-soap12-part1-20070427/

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

http://www.ietf.org/rfc/rfc2119.txt

2 Test Setup2.1 Test ActorsThe test scenarios described in this document uses following actors and the roles they implement.

Table 2: Test actors and roles.

Actor WS-Discovery Role

Calculator Service (TS1) Target Service

HelloWorld Service (TS2) Target Service

Calculator Service (TS3) Target Service

Secure Calculator Service (S-TS1) Target Service

Client Client

Secure Client (S-C1) Client

Discovery Proxy (DP) Discovery Proxy

2.1.1 Calculator Service (TS1)The Calculator Service implements the Target Service role defined in the WS-Discovery [WS-Discovery]. specification. Section 4.1 Calculator Service WSDL lists the Calculator Service WSDL. The service has following metadata. Note that messages from TS1 MAY include additional metadata including addition Types and Scopes as permitted by WS-Discovery [WS-Discovery] specification.

Table 3: Discoverable metadata of Calculator Service (TS1)

Metadata Name Value

Endpoint Reference [WS-Addressing]

EPR1 urn:uuid:ad9beb3c-fcd5-4f95-afe4-db8eed7c8cb8 ([address] property of Endpoint Reference)No reference parameters.

Types T1 test:CalculatorService

Scopes S1-1 http://example.org/ws-dd/discoverytest/services/calculator

S1-2 http://example.org/ws-dd/discovery/testservices

XAddrs X1 List of transport addresses for TS1.

MetadataVersion M1 [unsigned integer]

2.1.2 HelloWorld Service (TS2)The HelloWorld Service implements the Target Service role defines in the WS-Discovery [WS-Discovery] specification. Section 4.2 HelloWorld Service WSDL lists the HelloWorld Service WSDL. The service has following metadata including additional Types and Scopes as permitted by WS-Discovery [WS-Discovery] specification.


201

202

203

204

205

206207208209

210

211

212213214215

http://example.org/ws-dd/discovery/testservices

http://example.org/ws-dd/discoverytest/services/calculator

Table 4: Discoverable metadata of HelloWorld Service (TS2)

Metadata Name Value


EPR2 http://[IP address]/services/HelloWorldService ([address] property of Endpoint Reference)No reference parameters.

Types T2 test:HelloWorldService

Scopes S2-1 http://example.org/ws-dd/discoverytest/services/helloworld

S2-2 urn:uuid:dd41aab9-8a9e-4ac5-b83c-cd00e4b00000

S2-3 ldap:///ou=floor1,ou=building1,ou=engineering,o=exampleorg,c=us


2.1.3 Calculator Service (TS3)This is another instance of a Calculator Service that is not configured with any Scopes. Section 4.1 Calculator Service WSDL lists the Calculator Service WSDL. The service has following metadata. Note that messages from TS3 MAY include additional metadata including additional Types as permitted by WS-Discovery [WS-Discovery] specification.

Table 5: Discoverable metadata of HelloWorld Service (TS3)

Metadata Name Value


EPR3 urn:uuid:5397d289-6e2c-4631-8065-792182dcb52f ([address] property of Endpoint Reference)No reference parameters.

Types T3 test:CalculatorService

Scopes None. This service does not have any Scopes.

XAddrs X3 List of transport addresses for TS3.


2.1.4 Secure Calculator Service (S-TS1)This instance of a calculator service is configured to send and receive messages that signed using the compact signature mechanism with certificate CER1 (see Section 2.2.1 CER1). Section 4.1 Calculator Service WSDL lists the Calculator Service WSDL. The service has following metadata. Note that messages from S-TS1 MAY include additional metadata including additional Types as permitted by WS-Discovery [WS-Discovery] specification.

Table 6: Discoverable metadata of Secure HelloWorld Service (S-TS1)

Metadata Name Value


S-EPR1 urn:uuid:9869cf40-faeb-4243-9d47-5e2388772f44urn:uuid:5397d289-6e2c-4631-8065-792182dcb52f ([address] property of Endpoint Reference)No reference parameters.


216

217

218219220221

222

223

224225226227228

229

http://example.org/ws-dd/discoverytest/services/helloworld

Types S-T1 test:CalculatorService

Scopes S-S1 http://example.org/ws-dd/discoverytest/secureservices/helloworld

XAddrs S-X1 List of transport addresses for S-TS1.

MetadataVersion S-M1 [unsigned integer]

2.1.5 ClientThe Client implements the Client role defined in the WS-Discovery [WS-Discovery] protocol. As part of the test scenarios the Client discovers information about the Calculator Service(s) and the HelloWorld service present on the network. It MAY connect to the service using the discovered information and invoke the operations as defined by their respective WSDLs.

2.1.6 Secure Client (S-C1)The secure client implements the Client role defined in the WS-Discovery [WS-Discovery] protocol. Additionally it is configured to send and receive messages that are signed using the compact signature mechanism with CER1 (see Section 2.2.1 CER1). As part of the test scenarios the Client discovers information about the Calculator Service(s) and the HelloWorld service present on the network. It MAY connect to the service using the discovered information and invoke the operations as defined by their respective WSDLs.

2.1.7 Discovery Proxy (DP)The Discovery Proxy implements the Discovery Proxy role defined in the WS-Discovery [WS-Discovery] protocol. The Discovery Proxy is a Target Service with the following metadata. Note that messages from DP MAY include additional metadata including additional Types and Scopes as permitted by WS-Discovery [WS-Discovery] specification.

Table 7: Discoverable metadata of Discovery Proxy (DP)

Metadata Name Value


EPR-DP http://[IP address]/DiscoveryProxy ([address] property of Endpoint Reference)No reference properties.

Types T-DP d:DiscoveryProxy

Scopes S-DP http://example.org/ws-dd/discoverytest/discoveryproxy

MetadataVersion M-DP [unsigned integer]

For the managed mode scenarios Target Service and Client actors need the address of the discovery proxy. The Target Service and Client (expect for the multicast suppression scenarios) that implement managed mode scenarios MUST have a mechanism to supply the DP address.

2.2 Test CertificateThe compact signature related test scenarios require a security token using which to sign/verify the messages.


230

231232233234

235

236237238239240241

242

243244245246

247

248249250

251

252253

http://example.org/ws-dd/discoverytest/discoveryproxy/helloworld

http://example.org/ws-dd/discoverytest/secureservices/helloworld

http://example.org/ws-dd/discoverytest/secureservices/helloworld

2.2.1 CER1This X.509 certificate should be used by both Target Service and Client to sign and verify the messages signed using the compact signature. The certificate includes the private key that is required to sign the messages. The certificate is in Personal Information Exchange - PKCS #12 (.PFX) format. This certificate is embedded in this document below and is located alongside this document in the document repository. The certificates private key is protected with the password “ws-dd”. The Thumbprint of the certificate is “7f 1a 3c 3c eb 05 98 61 59 b4 33 04 ec 21 0f ca 71 38 f6 02”.

2.3 Network TopologyFigure 1 shows the network topology that is used for testing. As shown in the figure the participating actors MUST be connected to a network hub ensuring that they are on the same subnet. The actors MAY be co-located on the same physical machine. There SHOULD be a DHCP server connected to the same hub. The machines hosting the actors SHOULD be able to obtain IP addresses via DHCP. In the absence of the DHCP server IP addresses can be manually configured ensuring that no two machines get the same IP address.


254

255256257258259260261

262

263

264265266267268269

Figure 1: Network Topology for WS-Discovery Version 1.1 Interoperability Testing

2.4 Measuring SuccessThe test scenarios define expected result from the actors involved in the scenario. For a test scenario to pass, all of the actors MUST achieve expected results. Some of the test scenarios are run with more than one test values as described in the procedure. For a test scenario to pass, it MUST pass for all of the test values.


270271

272

273274275276

3 Scenarios3.1 Scenario 1.1.1 – Hello-ad hocThis scenario tests the transmission of Hello message by a Target Service in an ad hoc mode, as well as the ability of the Client to receive and understand the Hello message in an ad hoc mode.Initialization

- Client starts listening for multicast HelloProcedure

- TS1 is brought online – it sends a multicast HelloExpected Result

- Client receives multicast Hello from TS1. The Hello contains at least EPR1 and metadata version.

3.2 Scenario 1.1.2 – Hello-ad hoc-DPThis scenario tests the transmission of Hello message by a Discovery Proxy in an ad hoc mode.Initialization

- Client starts listening for multicast HelloProcedure

- DP is brought online – it sends a multicast HelloExpected Result

- Client receives multicast Hello from DP. The Hello contains at least EPR-DP and metadata version.

3.3 Scenario 1.2.1 – Hello-managedThis scenario tests:

- The ability of a Target Service to send a Hello message in a managed mode.- The ability of a DP to receive and understand a Hello message in a managed mode.

Initialization - DP starts listening for unicast Hello.- TS1 is given the address (EPR-DP) of the DP.

Procedure- TS1 is brought online – it sends a unicast Hello to DP.

Expected Result- DP receives the unicast Hello from TS1. The Hello contains the metadata for TS1 as defined in

Table 3.

3.4 Scenario 2.1.1 – Bye-ad hocThis scenario tests:

- The ability of a Target Service to send a Bye message in an ad hoc mode when it is about to go offline.

- The ability of a Client to receive and understand a Bye message in an ad hoc mode. Initialization


277

278

279280281282283284285286

287

288289290291292293294295

296

297298299300301302303304305306307

308

309310311312313

- Client starts listening for multicast ByeProcedure

- TS1 is instructed to go offline– it sends a multicast Bye message.Expected Result

- Client receives the multicast Bye from TS1. The Hello message at least contain EPR1.

3.5 Scenario 2.1.2 – Bye-ad hoc-DPThis scenario tests the transmission of Bye message by a Discovery Proxy in an ad hoc mode.Initialization

- Client starts listening for multicast ByeProcedure

- DP is instructed to go offline – it sends a multicast ByeExpected Result

- Client receives multicast Bye from DP. The Bye contains at least EPR-DP.

3.6 Scenario 2.2.1 – Bye-managedThis scenario tests:

- The ability of a Target Service to send a Bye message in a managed mode.- The ability of a DP to receive and understand a Bye message in a managed mode.

Initialization - DP starts listening for unicast Bye.- TS1 is given the address (EPR-DP) of the DP.

Procedure- TS1 is instructed to go offline – it sends a unicast Bye to DP.

Expected ResultDP receives the unicast Bye from TS1. The Bye at least contains EPR1.

3.7 Scenario 3.1.1 – Probe-ad hoc-empty criteriaThis scenario tests:

- The ability of a Client to send a Probe message with empty criteria in an ad hoc mode.- The ability of a Target Service to receive a Probe message with empty criteria, process it and

respond with a Probe Match message in an ad hoc mode.Initialization

- TS1 is online and listening for multicast Probe.- TS2 is online and listening for multicast Probe.

Procedure- Client sends a multicast Probe message with no criteria.

Expected Result- TS1 receives the Probe message from Client and responds with a Probe Match.- TS2 receives the Probe message from Client and responds with a Probe Match.- Client receives the Probe Match message from TS1. The Probe Match message at least contains

EPR1, X1 and M1 (see Table 3).- Client receives the Probe Match message from TS2. The Probe Match message at least contains

EPR2 and M2 (see Table 4).


314315316317318

319

320321322323324325326

327

328329330331332333334335336337

338

339340341342343344345346347348349350351352353354

3.8 Scenario 3.1.2 – Probe-ad hoc-typesThis scenario tests:

- The ability of a Client to send a Probe message with Types criteria in an ad hoc mode.- The ability of a Target Service to receive a Probe message with Types criteria, process it and

respond appropriately in an ad hoc mode.Initialization

- TS1 is online and listening for multicast Probe.- TS2 is online and listening for multicast Probe.

ProcedureA. Client sends a multicast Probe message with Types criteria containing T1

(test:CalculatorService).

Expected Result- TS1 receives the Probe message from Client and responds with a Probe Match.- TS2 receives the Probe message from Client and does not respond.- Client receives the Probe Match message from TS1. The Probe Match message at least

contains EPR1, X1 and M1 (see Table 3).- Client does not receive a Probe Match message from TS2.

B. Client sends a multicast Probe message with Types criteria containing T2 (test:HelloWorldService).

Expected Result- TS1 receives the Probe message from Client and does not respond.- TS2 receives the Probe message from Client and responds with a Probe Match. - Client does not receive a Probe Match message from TS1.- Client receives the Probe Match message from TS2. The Probe Match message at least

contains EPR2 and M2 (see Table 4).

3.9 Scenario 3.1.3 – Probe-ad hoc-scopes-RFC3986This scenario tests:

- The ability of a Client to send a Probe message with RFC3986 matching rule Scopes criteria in an ad hoc mode.

- The ability of a Target Service to receive a Probe message with RFC3986 matching rule Scopes criteria, process it and respond appropriately in an ad hoc mode.

Initialization - TS1 is online and listening for multicast Probe.- TS2 is online and listening for multicast Probe.

ProcedureA. Client sends a multicast Probe message with Scopes containing

http://example.org/ws-dd/discoverytest/services with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/rfc3986.

Expected Result- TS1 receives the Probe message from Client and responds with a Probe Match.- TS2 receives the Probe message from Client and responds with a Probe Match.- Client receives the Probe Match message from TS1. The Probe Match message at least

contains EPR1, X1 and M1 (see Table 3).- Client receives the Probe Match message from TS2. The Probe Match message at least



355

356357358359360361362363364365

366367368369370371372373374

375376377378379380

381

382383384385386387388389390391392393

394395396397398399400401

http://docs.oasis-open.org/ws-dd/discovery/2008/09/rfc3986



B. Client sends a multicast Probe message with Scopes containing http://example.org/ws-dd/discovery with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/rfc3986.

Expected Result- TS1 receives the Probe message from Client and responds with a Probe Match.- TS2 receives the Probe message from Client and does not respond.- Client receives the Probe Match message from TS1. The Probe Match message at least


C. Client sends a multicast Probe message with Scopes containing http://example.org/ws-dd/discoverytest/services/helloworld/ with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/rfc3986.

Expected Result- TS1 receives the Probe message from Client and does not respond.- TS2 receives the Probe message from Client and responds with a Probe Match.- Client does not receive a Probe Match message from TS1.- Client receives the Probe Match message from TS2. The Probe Match message at least


3.10 Scenario 3.1.4 – Probe-ad hoc-scopes-STRCMP0This scenario tests:

- The ability of a Client to send a Probe message with STRCMP0 matching rule Scopes criteria in an ad hoc mode.

- The ability of a Target Service to receive a Probe message with STRCMP0 matching rule Scopes criteria, process it and respond appropriately in an ad hoc mode.


ProcedureA. Client sends a multicast Probe message with Scopes containing

http://example.org/ws-dd/discoverytest/services/calculator with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/strcmp0.

Expected Result- TS1 receives the Probe message from Client and responds with a Probe Match.- TS2 receives the Probe message from Client and does not respond with a Probe Match.- Client receives the Probe Match message from TS1. The Probe Match message at least


B. Client sends a multicast Probe message with Scopes containing http://example.org/ws-dd/discoverytest/SERVICES/helloworld with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/strcmp0.

Expected Result- TS1 receives the Probe message from Client and does not respond.- TS2 receives the Probe message from Client and does not respond.- Client does not receive a Probe Match message from TS1.- Client does not receive a Probe Match message from TS2.


402403404

405406407408409410411412413414

415416417418419420

421

422423424425426427428429430431432433

434435436437438439440441442443

444445446447448449

http://docs.oasis-open.org/ws-dd/discovery/2008/09/strcmp0

http://example.org/ws-dd/discoverytest/SERVICES/helloworld




http://example.org/ws-dd/discoverytest/services/helloworld/



http://example.org/ws-dd/discovery

C. Client sends a multicast Probe message with Scopes containing http://example.org/ws-dd/discoverytest/services/helloworld/ with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/strcmp0.


3.11 Scenario 3.1.5 – Probe-ad hoc-scopes-UUIDThis scenario tests:

- The ability of a Client to send a Probe message with UUID matching rule Scopes criteria in an ad hoc mode.

- The ability of a Target Service to receive a Probe message with UUID matching rule Scopes criteria, process it and respond appropriately in an ad hoc mode.


ProcedureA. Client sends a multicast Probe message with Scopes containing uuid:DD41AAB9-8a9e-4ac5-

b83c-cd00e4b00000 with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/uuid.

Expected Result- TS1 receives the Probe message from Client and does not respond.- TS2 receives the Probe message from Client and responds with a Probe Match.- Client does not receive a Probe Match message from TS1.- Client receives the Probe Match message from TS2. The Probe Match message at least


B. Client sends a multicast Probe message with Scopes containing uuid:e46b9c9e-9ad6-46ce-8530-8c6cc4a9bd81 with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/uuid.


3.12 Scenario 3.1.6 – Probe-ad hoc-scopes-LDAPThis scenario tests:

- The ability of a Client to send a Probe message with LDAP matching rule Scopes criteria in an ad hoc mode.

- The ability of a Target Service to receive a Probe message with LDAP matching rule Scopes criteria, process it and respond appropriately in an ad hoc mode.


Procedure


450451452

453454455456457

458

459460461462463464465466467468469470

471472473474475476477478479480

481482483484485

486

487488489490491492493494495

http://docs.oasis-open.org/ws-dd/discovery/2008/09/uuid




- Client sends a multicast Probe message with Scopes containing ldap:///ou=floor1,ou=building1,ou=engineering,o=exampleorg,c=us with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/ldap.

Expected Result- TS1 receives the Probe message from Client and does not respond.- TS2 receives the Probe message from Client and responds with a Probe Match.- Client does not receive a Probe Match message from TS1.- Client receives the Probe Match message from TS2. The Probe Match message at least contains

EPR2 and M2 (see Table 4).

3.13 Scenario 3.1.7 – Probe-ad hoc-types-scopes-RFC3986This scenario tests:

- The ability of a Client to send a Probe message with Types and Scopes criteria in an ad hoc mode.

- The ability of a Target Service to receive a Probe message with Types and Scopes criteria, process it and respond appropriately in an ad hoc mode.


Procedure- Client sends a multicast Probe message with Types containing test:CalculatorService and

Scopes containing http://example.org/ws-dd/discoverytest/services with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/rfc3986.

Expected Result- TS1 receives the Probe message from Client and responds with a Probe Match.- TS2 receives the Probe message from Client and does not respond.- Client receives the Probe Match message from TS1. The Probe Match message at least contains

EPR1, X1 and M1 (see Table 3).- Client does not receive a Probe Match message from TS2.

3.14 Scenario 3.1.8 – Probe-ad hoc-DPThis scenario tests:

- The ability of a Client to Probe for DP in an ad hoc mode.- The ability of a Discovery Proxy to receive and respond to the Probes for itself in an ad hoc

mode.Initialization

- DP is online and listening for multicast Probe.Procedure

- Client sends a multicast Probe message with Types containing d:DiscoveryProxy

Expected Result- DP receives the Probe message and respond with a Probe Match message. The Probe Match

contains at least EPR-DP and M-DP (see Table 7).

3.15 Scenario 3.1.9 – Probe-ad hoc-suppressThis scenario tests:

- The ability of a Discovery Proxy to suppress Probe messages in an ad hoc mode.


496497498

499500501502503504

505

506507508509510511512513514515516517

518519520521522523

524

525526527528529530531532

533534535

536

537538



http://docs.oasis-open.org/ws-dd/discovery/2008/09/ldap

- The ability of a Client to receive and process suppression Hello messages in response to a multicast Probe in an ad hoc mode.

Initialization - DP is online and listening for multicast Probe. It is configured to suppress multicast Probes for

other Target Services.Procedure

A. Client sends a multicast Probe message with no criteria. Expected Result- DP receives the Probe message and responds with a Hello message. The Hello message

contains information about the DP as specified in Table 7.

B. Client sends a multicast Probe message with Types containing test:CalculatorService and Scopes containing http://example.org/ws-dd/discoverytest/services with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/rfc3986.

Expected Result- DP receives the Probe message and responds with a Hello message. The Hello message

contains information about the DP as specified in Table 7.

3.16 Scenario 3.1.10 – Probe-ad hoc-scopes-noneThis scenario tests:

- The ability of a Client to search for target services that do not have any scopes.- The ability of a Target Service to receive a Probe message with “none” scope matching rule

criteria, process it and respond appropriately in an ad hoc mode.Initialization

- TS1 is online and listening for multicast Probe.- TS2 is online and listening for multicast Probe.- TS3 is online and listening for multicast Probe.

Procedure- Client sends a multicast Probe message with empty Scopes element and with MatchBy as

http://docs.oasis-open.org/ws-dd/discovery/2008/09/none.

Expected Result- TS1 receives the Probe message from Client and does not respond.- TS2 receives the Probe message from Client and does not respond.- TS3 receives the Probe message from Client and responds with a Probe Match.- Client does not receive a Probe Match message from TS1.- Client does not receive a Probe Match message from TS2.- Client receives the Probe Match message from TS3. The Probe Match message at least contains

EPR3, X3 and M3 (see Table 5).

3.17 Scenario 3.2.1 – Probe-managed-empty criteriaThis scenario tests:

- The ability of a Client to send a Probe request with empty criteria in a managed mode to a DP.- The ability of a DP to receive a Probe request with empty criteria, process it and respond with a

Probe Match in a managed mode.Initialization

- DP is online and listening for Probe requests. DP has information about TS1 and TS2 in its cache.


539540541542543544545546547548549550551552

553554555

556

557558559560561562563564565566567

568569570571572573574575

576

577578579580581582583

http://docs.oasis-open.org/ws-dd/discovery/2008/09/none



Procedure- Client sends a Probe request with no criteria.

Expected Result- DP receives the Probe request from Client and responds with a Probe Match. - The Client receives the Probe Match response from the DP. The Probe Match response contains

information about both TS1 (see Table 3) and TS2 (see Table 4).

3.18 Scenario 3.2.2 – Probe-managed-typesThis scenario tests:

- The ability of a Client to send a Probe request with Types criteria in a managed mode to a DP.- The ability of a DP to receive a Probe request with Types criteria, process it and respond with a

Probe Match in a managed mode.Initialization

- DP is online and listening for Probe requests. DP has information about TS1 and TS2 in its cache.

ProcedureA. Client sends a Probe request with Types criteria containing T1 (test:CalculatorService).

Expected Result- DP receives the Probe request from Client and responds with a Probe Match.- The Client receives the Probe Match response from the DP. The Probe Match response

contains information about TS1 (see Table 3).

B. Client sends a Probe request with Types criteria containing T2 (test:HelloWorldService).



C. Client sends a Probe request with Types criteria containing test:EchoService.

Expected Result- DP receives the Probe request from Client and responds with a Probe Match.- The Client receives the Probe Match response from the DP. The Probe Match response does

not contain information about any Target Services. It is empty.

3.19 Scenario 3.2.3 – Probe-managed-scopes-RFC3986This scenario tests:

- The ability of a Client to send a Probe request with RFC3986 matching rule Scopes criteria in a managed mode to a DP.

- The ability of a DP to receive a Probe request with RFC3986 matching rule Scopes criteria, process it and respond with a Probe Match in a managed mode.

Initialization - DP is online and listening for Probe requests. DP has information about TS1 and TS2 in its

cache.Procedure

A. Client sends a Probe request with Scopes containing http://example.org/ws-dd/discoverytest/services with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/rfc3986.


584585586587588589

590

591592593594595596597598599

600601602603604605

606607608609610611

612613614615

616

617618619620621622623624625626627628





contains information about both TS1 (see Table 3) and TS2 (see Table 4).

B. Client sends a Probe request with Scopes containing http://example.org/ws-dd/discovery with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/rfc3986.



C. Client sends a Probe request with Scopes containing http://example.org/ws-dd/discoverytest/services/helloworld/ with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/rfc3986.



3.20 Scenario 3.2.4 – Probe-managed-scopes-STRCMP0This scenario tests:

- The ability of a Client to send a Probe request with STRCMP0 matching rule Scopes criteria in a managed mode to a DP.

- The ability of a DP to receive a Probe request with STRCMP0 matching rule Scopes criteria, process it and respond with a Probe Match in a managed mode.


cache.Procedure

A. Client sends a Probe request with Scopes containing http://example.org/ws-dd/discoverytest/services/calculator with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/strcmp0.



B. Client sends a Probe request with Scopes containing http://example.org/ws-dd/discoverytest/SERVICES/helloworld with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/strcmp0.



C. Client sends a Probe request with Scopes containing http://example.org/ws-dd/discoverytest/services/helloworld/ with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/strcmp0.


629630631632633634635

636637638639640641642643

644645646647

648

649650651652653654655656657658659660

661662663664665666667668

669670671672673674675676




http://example.org/ws-dd/discoverytest/SERVICES/helloworld






http://example.org/ws-dd/discovery



3.21 Scenario 3.2.5 – Probe-managed-scopes-UUIDThis scenario tests:

- The ability of a Client to send a Probe request with UUID matching rule Scopes criteria in a managed mode to a DP.

- The ability of a DP to receive a Probe request with UUID matching rule Scopes criteria, process it and respond with a Probe Match in a managed mode.


cache.Procedure

A. Client sends a Probe request with Scopes containing uuid:DD41AAB9-8a9e-4ac5-b83c-cd00e4b00000 with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/uuid.



B. Client sends a Probe request with Scopes containing uuid:e46b9c9e-9ad6-46ce-8530-8c6cc4a9bd81 with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/uuid.



3.22 Scenario 3.2.6 – Probe-managed-scopes-LDAPThis scenario tests:

- The ability of a Client to send a Probe request with LDAP matching rule Scopes criteria in a managed mode to a DP.

- The ability of a DP to receive a Probe request with LDAP matching rule Scopes criteria, process it and respond with a Probe Match in a managed mode.


cache.Procedure

- Client sends a Probe request with Scopes containing ldap:///ou=floor1,ou=building1,ou=engineering,o=exampleorg,c=us with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/ldap.

Expected Result- DP receives the Probe request from Client and responds with a Probe Match.- The Client receives the Probe Match response from the DP. The Probe Match response contains

information about TS2 (see Table 4).


677678679680

681

682683684685686687688689690691692693

694695696697698699700701

702703704705

706

707708709710711712713714715716717718

719720721722

http://docs.oasis-open.org/ws-dd/discovery/2008/09/ldap



3.23 Scenario 3.2.7 – Probe-managed-types-scopes-RFC3986This scenario tests:

- The ability of a Client to send a Probe request with Types and Scopes criteria in a managed mode to a DP.

- The ability of a DP to receive a Probe request with Types and Scopes criteria, process it and respond with a Probe Match in a managed mode.


cache.Procedure

- Client sends a Probe request with Types containing test:CalculatorService and Scopes containing http://example.org/ws-dd/discoverytest/services with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/rfc3986.



3.24 Scenario 3.2.8 – Probe-managed-scopes-noneThis scenario tests:

- The ability of a Client to send a Probe request with “none” matching rule Scopes criteria in a managed mode to a DP.

- The ability of a DP to receive a Probe request with “none” matching rule Scopes criteria, process it and respond with a Probe Match in a managed mode.

Initialization - DP is online and listening for Probe requests. DP has information about TS1, TS2 and TS3 in its

cache.Procedure

- Client sends a multicast Probe message with empty Scopes element and with MatchBy as http://docs.oasis-open.org/ws-dd/discovery/2008/09/none.



3.25 Scenario 4.1.1 – Resolve-ad hocThis scenario test:

- The ability of a Client to send a Resolve message in an ad hoc mode.- The ability of a Target Service to receive a Resolve message and respond appropriately in an ad

hoc mode.Initialization

- TS1 is online and listening for multicast Resolve.- TS2 is online and listening for multicast Resolve.

ProcedureA. Client sends a multicast Resolve message containing EPR1 (see Table 3). Expected Result


723

724725726727728729730731732733734735

736737738739

740

741742743744745746747748749750751

752753754755

756

757758759760761762763764765766

http://docs.oasis-open.org/ws-dd/discovery/2008/09/none



- TS1 receives the Resolve message and responds with a Resolve Match.- TS2 receives the Resolve message and does not respond.- Client receives the Resolve Match message from TS1. The Resolve Match message at least

contains EPR1, X1 and M1 (see Table 3).

B. Client sends a multicast Resolve message containing EPR2 (see Table 4). Expected Result

- TS1 receives the Resolve message and does not respond.- TS2 receives the Resolve message and responds with a Resolve Match.- Client receives the Resolve Match message from TS2. The Resolve Match message at least


C. Client sends a multicast Resolve message with EPR3 (Endpoint Reference [address] property to be urn:uuid:a4ccabb6-0952-4c51-a8e0-fd6944013e74).

Expected Result- TS1 receives the Resolve message and does not respond.- TS2 receives the Resolve message and does not respond.- Client does not receive a Resolve Match message from TS1 or TS2.

3.26 Scenario 4.1.2 – Resolve-ad hoc-suppressThis scenario tests:

- The ability of a Discovery Proxy to suppress Resolve messages in an ad hoc mode.- The ability of a Client to receive and process suppression Hello messages in response to a

multicast Resolve in an ad hoc mode.Initialization

- DP is online and listening for multicast Resolve. It is configured to suppress multicast Resolves for other Target Services.

ProcedureA. Client sends a multicast Resolve message with EPR1 (see Table 3). Expected Result

- DP receives the Resolve message and responds with a Hello message. The Hello message contains information about the DP as specified in Table 7.

B. Client sends a multicast Resolve message with EPR3 (Endpoint Reference [address] property to be urn:uuid:a4ccabb6-0952-4c51-a8e0-fd6944013e74).

Expected Result- DP receives the Resolve message and responds with a Hello message. The Hello message

contains information about the DP as specified in Table 7. Note that even though DP may not have information about the Target Service with EPR3, it effectively represents the ad hoc network and suppresses the resolve for non matching resolve requests as well.

3.27 Scenario 4.2.1 – Resolve-managedThis scenario test:

- The ability of a Client to send a Resolve request to a DP in a managed mode.- The ability of a DP to receive a Resolve message and respond appropriately in a managed mode.

Initialization - DP is online and listening for Resolve requests. DP has information about TS1 and TS2 in its

cache.


767768769770771772773774775776777778779780

781782783784

785

786787788789790791792793794795796797798799800

801802803804805

806

807808809810811812

ProcedureA. Client sends a Resolve request containing EPR1 (see Table 3). Expected Result

- DP receives the Resolve request and responds with a Resolve Match.- Client receives the Resolve Match response from DP. The Resolve Match at least contains

EPR1, X1 and M1 (see Table 3).

B. Client sends a Resolve request containing EPR2 (see Table 4). Expected Result

- DP receives the Resolve request and responds with a Resolve Match.- Client receives the Resolve Match response from DP. The Resolve Match message at least


C. Client sends a Resolve request with EPR3 (Endpoint Reference [address] property to be urn:uuid:a4ccabb6-0952-4c51-a8e0-fd6944013e74)..

Expected Result- DP receives the Resolve request and responds with a Resolve Match.- Client receives Resolve Match response from DP. The Resolve Match does not contain

information about any Target Services. It is empty.

3.28 Scenario 5.1.1 – Compact Signature-Hello-ad hocThis scenario tests:

- The ability of a Target Service to send a Hello message signed using compact signature.- The ability of a Client to verify the Hello messages signed using compact signature.

Initialization - Client S-C1 is configured to accept Hello messages signed using the compact signature

mechanism with a certificate CER1. - Target Service S-TS1 is configured to sign Hello messages using the compact signature

mechanism with a certificate CER1.Procedure

- Client S-C1 starts listening for multicast Hello.- Client (normal client that is not configured with security) starts listening for multicast Hello.- TS1 is brought online – it sends a multicast Hello that is not signed.- S-TS1 is brought online – it sends a multicast Hello that is signed using the compact signature

mechanism with a certificate CER1. Expected Result

- S-C1 receives the multicast Hello from TS1 (it is rejected as it is not signed). - S-C1 receives the multicast Hello from S-TS1 (it is accepted as it is property signed). The Hello

message contains at least S-EPR1 (see Table 6).- Normal Client receives the multicast Hello from TS1. The Hello message contains at least EPR1

(see Table 3).- Normal Client receives the multicast Hello from S-TS1. The Hello message contains at least S-

EPR1 (see Table 6).

3.29 Scenario 5.1.2 – Compact Signature-Bye-ad hocThis scenario tests:

- The ability of a Target Service to send a Bye message signed using compact signature.- The ability of a Client to verify the Bye messages signed using compact signature.


813814815816817818819820821822823824825826827

828829830831

832

833834835836837838839840841842843844845846847848849850851852853854

855

856857858

Initialization - Client S-C1 is configured to accept Bye messages signed using the compact signature

mechanism with a certificate CER1. - Target Service S-TS1 is configured to sign Bye messages using the compact signature

mechanism with a certificate CER1.- S-TS1 is online.- TS1 is online.

Procedure- Client S-C1 starts listening for multicast Bye.- Client (normal client that is not configured with security) starts listening for multicast Bye.- TS1 is brought offline – it sends a multicast Bye that is not signed.- S-TS1 is brought offline – it sends a multicast Bye that is signed using the compact signature

mechanism with a certificate CER1. Expected Result

- S-C1 receives the multicast Bye from TS1 (it is rejected as it is not signed). - S-C1 receives the multicast Bye from S-TS1 (it is accepted as it is property signed). The Bye

message contains at least S-EPR1 (see Table 6).- Normal Client receives the multicast Bye from TS1. The Bye message contains at least EPR1

(see Table 3).- Normal Client receives the multicast Bye from S-TS1. The Bye message contains at least S-

EPR1 (see Table 6).

3.30 Scenario 5.1.3 – Compact Signature-Probe-ad hocThis scenario tests:

- The ability of a Client to send a Probe message signed using compact signature.- The ability of a Target Service to verify the Probe message signed using compact signature.- The ability of a Target Service to send a Probe Match message signed using compact signature.- The ability of a Client to verify the Probe Match messages signed using compact signature.

Initialization - Target Service S-TS1 is online.

o S-TS1 is configured to accept Probe messages signed using the compact signature mechanism with a certificate CER1.

o S-TS1 is also configured to respond to the signed Probe messages with appropriate Probe Match messages signed using the compact signature mechanism with a certificate CER1.

- Target Service TS1 is online and it is not configured to process the Probe messages signed using the compact signature or sign the response Probe Match messages using the compact signature.

- Client S-C1 is configured to send Probe messages signed using the compact signature mechanism with CER1 and accept only the Probe Match responses signed using the compact signature mechanism with CER1.

Procedure- Client S-C1 sends a multicast Probe message containing no criteria. The Probe message is

signed using compact signature with a certificate CER1.Expected Result

- S-TS1 receives the Probe message, verifies the signature and responds to it with a Probe Match message that is signed using the compact signature mechanism with CER1.

- TS1 receives the Probe message and responds to it with a Probe Match message that is not signed using the compact signature mechanism.

- Client S-C1 receives the Probe Match from S-TS1 as it is properly signed. The Probe Match contains at least S-EPR1, S-X1 and S-M1 (see Table 6).

- Client S-C1 does not receive the Probe Match from TS1 as it is not signed.


859860861862863864865866867868869870871872873874875876877878879

880

881882883884885886887888889890891892893894895896897898899900901902903904905906907908

3.31 Scenario 5.1.4 – Compact Signature-Resolve-ad hocThis scenario tests:

- The ability of a Client to send a Resolve message signed using compact signature.- The ability of a Target Service to verify the Resolve message signed using compact signature.- The ability of a Target Service to send a Resolve Match message signed using compact

signature.- The ability of a Client to verify the Resolve Match messages signed using compact signature.

Initialization - Target Service S-TS1 is online.

o S-TS1 is configured to accept Resolve messages signed using the compact signature mechanism with a certificate CER1.

o S-TS1 is also configured to respond to the matching Resolve messages with appropriate Resolve Match messages signed using the compact signature mechanism with a certificate CER1.

- Target Service TS1 is online and it is not configured to process the Resolve messages signed using the compact signature or sign the response Resolve Match messages using the compact signature.

- Client S-C1 is configured to send Resolve messages signed using the compact signature mechanism with CER1 and accept only the Resolve Match responses signed using the compact signature mechanism with CER1.

ProcedureA. Client S-C1 sends a multicast Resolve message containing S-EPR1 (see Table 6). The Resolve

message is signed with the compact signature mechanism using CER1.Expected Result

- S-TS1 receives the Resolve message, verifies the signature and responds with a Resolve Match. The Resolve Match message is signed with the compact signature mechanism using CER1.

- TS1 receives the Resolve message and does not respond.- Client S-C1 receives the Resolve Match message from S-TS1 as it is property signed. The

Resolve Match message at least contains S-EPR1, S-X1 and S-M1 (see Table 6).

B. Client S-C1 sends a multicast Resolve message containing EPR1 (see Table 3). The Resolve message is signed with the compact signature mechanism using CER1.

Expected Result- S-TS1 receives the Resolve message, verifies the signature and does not respond as it does

not match.- TS1 receives the Resolve message and responds with a Resolve Match.- Client S-C1 does not receive the Resolve Match message from TS1 as it is not signed.


909

910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946

4 Test Service WSDLs4.1 Calculator Service WSDL<?xml version="1.0" encoding="utf-8"?><wsdl:definitions targetNamespace="http://example.org/ws-dd/discoverytest/" xmlns:tns="http://example.org/ws-dd/discoverytest/" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"> <wsdl:types> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://example.org/ws-dd/discoverytest/" xmlns:tns="http://example.org/ws-dd/discoverytest/" elementFormDefault="qualified"> <xs:element name="Add"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" name="a" type="xs:int" /> <xs:element minOccurs="0" name="b" type="xs:int" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="AddResponse"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" name="AddResult" type="xs:int" /> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> </wsdl:types> <wsdl:message name="CalculatorService_Add_InputMessage"> <wsdl:part name="parameters" element="tns:Add"/> </wsdl:message> <wsdl:message name="CalculatorService_Add_OutputMessage"> <wsdl:part name="parameters" element="tns:AddResponse"/> </wsdl:message> <wsdl:portType name="CalculatorService"> <wsdl:operation name="Add"> <wsdl:input wsa:Action="http://example.org/ws-dd/discoverytest/CalculatorService/Add" message="tns:CalculatorService_Add_InputMessage"/> <wsdl:output wsa:Action="http://example.org/ws-dd/discoverytest/CalculatorService/AddResponse" message="tns:CalculatorService_Add_OutputMessage"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="CustomBinding_CalculatorService" type="tns:CalculatorService"> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="Add"> <soap12:operation soapAction="http://example.org/ws-dd/discoverytest/CalculatorService/Add" style="document"/> <wsdl:input>


947

948

9499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003

<soap12:body use="literal"/> </wsdl:input> <wsdl:output> <soap12:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding></wsdl:definitions>

4.2 HelloWorld Service WSDL<?xml version="1.0" encoding="utf-8"?><wsdl:definitions targetNamespace="http://example.org/ws-dd/discoverytest/" xmlns:tns="http://example.org/ws-dd/discoverytest/" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"> <wsdl:types> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://example.org/ws-dd/discoverytest/" xmlns:tns="http://example.org/ws-dd/discoverytest/" elementFormDefault="qualified"> <xs:element name="Greeting"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" name="name" nillable="true" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="GreetingResponse"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" name="GreetingResult" nillable="true" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> </wsdl:types> <wsdl:message name="HelloWorldService_Greeting_InputMessage"> <wsdl:part name="parameters" element="tns:Greeting"/> </wsdl:message> <wsdl:message name="HelloWorldService_Greeting_OutputMessage"> <wsdl:part name="parameters" element="tns:GreetingResponse"/> </wsdl:message> <wsdl:portType name="HelloWorldService"> <wsdl:operation name="Greeting"> <wsdl:input wsa:Action="http://example.org/ws-dd/discoverytest/HelloWorldService/Greeting" message="tns:HelloWorldService_Greeting_InputMessage"/> <wsdl:output wsa:Action="http://example.org/ws-dd/discoverytest/HelloWorldService/GreetingResponse" message="tns:HelloWorldService_Greeting_OutputMessage"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="HelloWorldServiceSoap12Binding" type="tns:HelloWorldService"> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="Greeting">


10041005100610071008100910101011

1012

1013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064

<soap12:operation soapAction="http://example.org/ws-dd/discoverytest/HelloWorldService/Greeting" style="document"/> <wsdl:input> <soap12:body use="literal"/> </wsdl:input> <wsdl:output> <soap12:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding></wsdl:definitions>


106510661067106810691070107110721073107410751076

A. AcknowledgementsThe following individuals have participated in the creation of this specification and are gratefully acknowledged:Participants:!!br0ken!!

Geoff Bullen, Microsoft CorporationSteve Carter, NovellDan Conti, Microsoft CorporationDoug Davis, IBMScott deDeugd, IBMDan Driscoll, Microsoft CorporationColleen Evans, Microsoft CorporationMax Feingold, Microsoft CorporationTravis Grigsby, IBMFrancois Jammes, Schneider ElectricRam Jeyaraman, Microsoft CorporationMike Kaiser, IBMSupun Kamburugamuva, WSO2Devon Kemp, Canon Inc.Akira Kishida, Canon Inc.Mark Little, Red HatDr. Ingo Lueck, Technische Universitaet DortmundJonathan Marsh, WSO2Carl MattocksAntoine MenschJaime Meritt, Progress SoftwareVipul Modi, Microsoft CorporationAnthony Nadalin, IBMTadahiro Nakamura, Canon Inc.Masahiro Nishio, Canon Inc.Toby Nixon, Microsoft CorporationShin Ohtake, Fuji Xerox Co., Ltd.Venkat Reddy, CAAlain Regnier, Ricoh Company, Ltd.Hitoshi Sekine, Ricoh Company, Ltd.Hiroshi Tamura, Ricoh Company, Ltd.Minoru Torii, Canon Inc.Asir S Vedamuthu, Microsoft CorporationDavid Whitehead, Lexmark International Inc.Don Wright, Lexmark International Inc.Prasad Yendluri, Software AG, Inc.Elmar Zeeb, University of RostockGottfried Zimmermann

The following individuals have provided invaluable input to the original contributions and are gratefully acknowledged:

Anurag Pandit, Microsoft CorporationScott Duren, Microsoft CoporationVaishnav Kidambi, Microsoft CorporationAshay Chaudhary, Microsoft CorporationRob Hain, Microsoft Corporation


1077

1078107910801081108210831084108510861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108110911101111111211131114111511161117111811191120112111221123112411251126

B. Revision History[optional; should not be included in OASIS Standards]

Revision Date Editor Changes Made

wd-01 October 23, 2008 Vipul Modi The submitted version of Interop scenario document is converted to OASIS template. Sections of the documents are better organized. WSDL for the test services is added.

wd-02 November 26, 2008 Vipul Modi Included the resolution of following issues:

IP001: Allow additional types to be sent in WS-Discovery messages used in WS-Discovery interop scenarios

IP002: WS-Discovery Interop scenario document has wrong schema for CalculatorService WSDL

wd-03 December 2, 2008 Vipul Modi IP003: WS-Discovery interop scenarios - Clarification to Scenario 4.2.1

wd-04 January 27, 2009 Vipul Modi Added following new scenarios to cover compact signature and new scope matching rule.Scenario 5.1.1 – Compact Signature-Hello-ad hocScenario 5.1.2 – Compact Signature-Bye-ad hocScenario 5.1.3 – Compact Signature-Probe-ad hocScenario 5.1.4 – Compact Signature-Resolve-ad hocScenario 3.2.8 – Probe-managed-scopes-none

Changed the expected Probe Match results to include the transport addresses when applicable.

WS-Discovery reference updated to CD02 specification.

WS-Addressing reference updated to WS-Addressing 1.0 version.


1127

11281129

1130

Documents

Web Services Dynamic Discovery (WS-Discovery ...€¦ · Web viewWeb Services Dynamic Discovery (WS-Discovery) Interoperability Test Scenarios Version 1.1 Working Draft 05 19 February