[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Understanding WS-Discovery operational modes - WS-D Primer
Thanks for taking time to review the document. Following are some of the high level points that address many of your concerns listed below.
* The ad-hoc and managed mode are characterized by the MEPs used for the discovery of services. For example, an actor say a Target Service; is in an ad-hoc mode if it sends multicast Hello, Bye, listens for multicast Probe and Resolve. A Target Service is in a managed mode if it sends unicast Hello and Bye. A client is in an ad-hoc mode if it sends multicast Probe, Resolve and listens to multicast Hello and Bye. It is in a managed mode if it sends unicast Probe and Resolve.
* The operational modes per actor are not mutually exclusive. For example, a Target Service can be in an ad-hoc mode and a managed mode at the same time. Additionally, various actors on a physical network can be in operating in different modes.
Please find additional comments below.
thanks for the document.
Following are some questions/feedback on the WS-D Primer.
“. In this mode the protocol messages are sent multicast on the network.
not all messages are sent multicast.
[vipul] The scenario is illustrating one of the high level point I mentioned above, i.e. a Target Service can be in more than one mode at the same time depending upon its configuration.
Figure 4: This figure shows a client receiving unicast Hello: it should probably be mentioned in the bullet points above the figure, since it is not strictly ad-hoc mode messages, or removed and placed in section 3.3 instead.
[vipul] This is a multicast suppression Hello that a Client operating in an ad hoc mode receives from a Discovery Proxy.
[vipul] Agree, that this can be reworded better. At a high level there are two main functionalities of a Discovery Proxy.
1. Support discovery in a managed mode
2. Suppress multicast on an ad hoc network by redirecting the traffic to its managed endpoint.
There are scenarios for both functionality. For example, for an enterprise service registry in a data center it does not make sense to participate in a multicast suppression as there may not be any multicast traffic in the data center for the services it represents.
should be a section about security, and particularly things like man in the
[vipul] As I mentioned earlier on a physical network different actors can be in different mode. One actor can be in more than one mode at the same time.
[vipul] Conceptually a Discovery Proxy that is suppressing multicast has two endpoints,
1. A managed endpoint that is operating in a managed mode (managed mode MEP).
2. An ad hoc endpoint that is operating in an ad hoc mode that does multicast suppression and redirect the clients to the managed endpoint.
The proxy is operating in both modes and continue to do so. If Clients sends multicast Probe/Resolve, the proxy receives this through the ad hoc endpoint and try to suppress it by sending unicast Hello that contains information about managed endpoint. The client upon receiving this information switches to the managed mode and sends messages to the managed endpoint of the proxy.
[vipul] Good catch. Thanks.
[vipul] Ok, in
this context it is an endpoint of a Discovery Proxy that supports managed mode
message exchange pattern (or d:DiscoveryProxy).
Figure 9: the figure is difficult to read... it could help if the numbers were ordered.
[vipul] I know it has a lot of information, I tried best to have relevant information and yet fit it in one page. The point that this is illustrating is that Target Services that operate in an ad-hoc mode are unaffected by the presence of a Discovery Proxy that does multicast suppression and continue to operate normally.
[vipul] This is
up to a service implementation. The protocol defines the message exchanges in each
mode for all of the roles. For each implemented mode and role the protocol
exchanges must follow the specification. A higher level profile for example in
this case DPWS can define requirement and conditions to operate in a particular
[vipul] If a DP
does not have information about a Target Service it should not be doing
multicast suppression. This would be an implementation issue.
Target Service can opt to not operate in a managed mode and send information to
DP. In an ad hoc mode a Target Service multicast its information so it does not
have any control over who uses this information.
document assumes that a Service needs to know in advance what a DP is,
preventing a seemless integration.
may need a broader discussion about the expected goals of a Discovery Proxy...
[vipul] I agree with the requirement you mentioned about seamless integration in an ad hoc mode. The document isn’t making any assumptions otherwise If you introduce a discovery proxy that does multicast suppression to an ad hoc network, the Target Services would not change. The proxy would obtain information about the Target Services on the network by sending multicast Probe and listening for multicast Hello/Bye. It would then suppress the clients on a ad hoc network and redirect them to managed mode.
From: Vipul Modi
During the first face to face, some of us felt that the current WS-Discovery specification does not provide a clear description of requirements and responsibilities of various actors in an ad hoc mode and a managed mode. We made good progress on this during the technical discussions and white boarded our understanding of the specification in this regard. We filed and accepted a number of issues called “managed cluster” in this regard.
Please find the attached document titled “WS-Discovery Primer” that captures the essence of our discussions and understanding, and explains the behavior of a Target Service, a Client and a Discovery Proxy in a managed mode and an ad hoc mode as defined by the current specification. This document should allows us to be on the same page with respect to understanding ad hoc and managed modes and message exchanges in these modes, and help us make progress on the “managed cluster” issues.
Senior Development Lead, Microsoft Corporation.
email@example.com | 425-707-2402