1. Input for issues resolution Antoine Mensch Odonata 16 july 2009

2. Input for issues resolution WSDD-8: WS-Discovery - Announcement messages in case of managed mode WSDD-4: Remove dependency on device transport address from device metadata 16/07/20092OASIS WSDD F2F

3. WSDD-8 Description Scope Scenarios Issues with current situation Reasons for not addressing the issue Proposal for resolution 16/07/20093OASIS WSDD F2F

4. Description Inconsistency between the functional behavior of WS-Discovery ad hoc and managed modes – The ad hoc mode provides two features Announcement mechanism (Hello and Bye messages) Query mechanism (Probe/ProbeMatch and Resolve/ResolveMatch messages) – The managed mode only provides one of these features Query mechanism This introduces functional and performances issues, detailed in the following 16/07/20094OASIS WSDD F2F

5. Scope of the issue Extract from the TC charter (highlights are mine) – A mechanism to: Announce the arrival into a network (Hello message). Announce departure from a network (Bye message). Probe a network for matching services (Probe and ProbeMatch messages) where the match criteria for locating services is limited to the type of the service, the binding used by the service, and the administrative scope URIs assigned to the service. Resolve an endpoint address to a transport address (Resolve and ResolveMatch messages). – Support for the above mechanism in ad hoc networks (based on SOAP-over-UDP) and managed networks (based on SOAP-over-HTTP). 16/07/20095OASIS WSDD F2F

6. Scenario 1 – remote discovery Topology – Devices and Discovery Proxy (DP) are on the same subnet, and client on a different one – P2P interactions possible between all entities – Multicast discovery not available to client Initial state – Devices D1 and D2 are registered with DP – DP address is known by client – Client has subscribed to DP announcement events Scenario – Client sends unicast probe to DP – DP replies with a list of matching devices (D1 and D2), including their transport addresses – Client directly accesses the devices for further exchanges: discovery of services, service invocation… – D3 sends Hello to DP (multicast or unicast) – DP forwards D3 Hello to client – Client directly accesses D3 for further exchanges: discovery of services, service invocation… Use cases – Access to devices on separate subnets in a large site (e.g. for management) – Collaboration between devices across subnets (e.g. through a WAN) Discovery Proxy D1D2D3 Discovery Client GetMetadata Service invocation Hello 16/07/20096OASIS WSDD F2F

7. Scenario 2 – multicast suppression Extension of the multicast suppression principles to Hello and Bye messages on the local network – Further reduction of the multicast traffic in case of large and dynamic number of devices – Allow clients to completely ignore multicast traffic Useful for « multicast-challenged » clients – Reduces the network-generated load on low-power clients Provides support for event filtering at the source: only devices matching a registered interest are announced to the client 16/07/20097OASIS WSDD F2F

8. Issues with current situation Functional issues – A client needs to be programmed in different ways when using ad hoc and managed modes Event-driven approach in ad hoc mode Polling approach in managed mode – No support for incremental updates in managed mode A client receives the complete list of matching target services for each polling probe, and must keep track of existing vs. new target services Performance issues with polling – Larger number of messages – Larger size of messages Each ProbeMatch contains all matching target services, not only new ones – Greater latency 16/07/20098OASIS WSDD F2F

9. Reasons for not addressing the issue Outside the scope of the TC charter, IPR issues – See charter and previous slide Introduces a dependency on WS-Eventing – The proposed mechanism can be made optional Can be solved on a case-by-case basis using WS-* composition – Much better for interoperability to define the mechanism as a standard extension Introduces scalability issues – The extension is defined at the protocol level, so implementations can deal with scalability aspects as they want – The proposed solution addresses the obvious scalability requirements at the protocol level: filtering at the source, batching capabilities (see proposal) – Not dealing with the issue introduces even larger scalability issues (see previous slide) 16/07/20099OASIS WSDD F2F

10. Resolution: event source portType A new optional portType is added to the DiscoveryProxy WSDL – When implemented, the portType will be included in DP Hello/ProbeMatch/ResolveMatch to indicate eventing support to clients – The portType will be a wse:EventSource and will expose two output- only operations, for HelloEvent and ByeEvent messages – HelloEvent and ByeEvent messages may contain several occurrences of standard Hello and Bye bodies (same approach as for ProbeMatches) This addresses the issue of batching, as a DP may coalesce several individual events in a single one We could also have a single AnnouncementEvent containing a mix of Hello and Bye bodies Note: the design and syntax of the portType may have to be adjusted to the changes proposed by the WS-RA WG – Hopefully the new proposal will provide equivalent (or even better) features for exposing event sources 16/07/200910OASIS WSDD F2F

11. Resolution: subscription mechanism The subscription mechanism is based on the standard WS- Eventing mechanism It is extended with a WS-Discovery-specific filtering mechanism, as – Writing an XPath expression filtering on both types and scopes is at best cumbersome, and almost impossible if scope matching rules are to be taken into account – WS-Discovery already defines two « queries » that evaluate to boolean values and can be reused as is Probe request body Resolve request body No specific support for batch control is proposed – Batching remains a Discovery Proxy implementation choice – Batch control could be added later on if required 16/07/200911OASIS WSDD F2F

12. Example of subscription message http://192.168.0.4/myNotificationEndpoint PT10M i:PrintBasic ldap:///ou=engineering,o=examplecom,c=us 16/07/200912OASIS WSDD F2F

13. WSDD-4 Description Issues with current situation Proposal for resolution 16/07/200913OASIS WSDD F2F

14. Description WS-Discovery defines a metadata version mechanism for controlling metadata information changes – Intrinsic information: UUID, model information, serial number… – Implementation information: Types, hosted services – Configuration information: Scopes, friendly name A target service transport address is not considered metadata by WS-Discovery, but becomes part of a device relationship metadata in DPWS, as hosted service EPRs generally use their hosting device transport address – This requires devices to update their metadata version each time their transport address changes (potentially at each reboot) 16/07/2009OASIS WSDD F2F14

15. Issues with current situation Inefficient management of metadata exchange – The increment of metadata version triggers extra requests from clients, which are already aware of a device address change (through discovery messages) Dynamic generation of metadata information on devices – Although most of the metadata information is static and could be stored in Flash/ROM, the required inclusion of a device transport address requires dynamic generation of the metadata Increased complexity in multi-homed scenarios – When device metadata is requested on different network interfaces, it may be necessary to take the interface into account to generate reachable addresses in hosted services EPRs. 16/07/2009OASIS WSDD F2F15

16. Proposed resolution Replace absolute transport URLs in hosted services EPRs included in relationship metadata by alternative information allowing a client to construct the absolute transport URL by combining this information with a device transport URL (used for WS-Transfer GET request). This information should include – Scheme: optional, default to device transport URL scheme – Port: optional, default to device transport URL port – Path: mandatory Possible approaches (illustrated in next slide) – Use a constant predefined URI plus query syntax – Use an alternative DPWS-specific XML element – Use a URI template 16/07/2009OASIS WSDD F2F16

17. Examples of possible solutions 16/07/2009OASIS WSDD F2F17 http://192.168.2.5:9090/myService/DPWSEndpoint … http://192.168.2.5:9090/myService/DPWSEndpoint … … … WS-Transfer GET request sent to http://192.168.2.5:8080/myDevice http://docs.oasis-open.org/ws-dd/ns/dpws/2009/07/HostAddress?port=9090&path=/myService/DPWSEndpoint … http://docs.oasis-open.org/ws-dd/ns/dpws/2009/07/HostAddress?port=9090&path=/myService/DPWSEndpoint … http://0.0.0.0:9090/myService/DPWSEndpoint … http://0.0.0.0:9090/myService/DPWSEndpoint … Current version of hosted service EPRs Predefined URI DPWS-specific EPR element URI template