Issue 022 - WS-Discovery - Request-Response MEP for communicatingwith pr

This issue is assigned the number 022. For further discussions on this issue, please refer to this issue number or use this thread.

From: Vipul Modi
Sent: Wednesday, September 17, 2008 9:19 AM
To: Ram Jeyaraman
Subject: NEW Issue - WS-Discovery - Request-Response MEP for communicating with proxy

Please defer discussions on this issue until a time this issue is accepted and is assigned a number.

Description:

The current discovery specification describes the same message exchange pattern for sending multicast Probe and Resolve requests in an ad-hoc mode and sending unicast Probe and Resolve request to discovery proxy in a managed mode. This message exchange pattern as described in the specification is a based on two one way messages and requires a client sending Probe or Resolve request to open a back channel to receive the responses. This pattern makes sense in an ad-hoc mode where a client can receive responses from number of services. However in a managed mode the client communicate with a discovery proxy; typically over HTTP. In this case it is more efficient to use the client initiated connection to receive the responses instead of opening a back channel and receiving the responses asynchronously. Asynchronously receiving the responses for Probe and Resolve requires clients to a) manage the lifetime of the Probe and Resolve operations, b) open a back channel and essentially be a server (say HTTP) for receiving the response and c) open a hole in the firewall to allow the responses over back channel.

Proposed Resolution:

Define the MEP for Probe and Resolve operations in managed mode as traditional request-response. When this MEP is bound to HTTP it would allow client to receive the response on the same HTTP connection on which Probe and Resolve requests were issues to Discovery Proxy. The client would not have to open a backchannel and would have to open a hole in the firewall.

ws-dd message