[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Understanding WS-Discovery operational modes - WS-D Primer
Hi Alain, 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, Vipul From: Alain Regnier
[mailto:alain@ricoh-tech.com] Hi Vipul, thanks
for the document. Following
are some questions/feedback on the WS-D Primer. -- 1.2.1
“. In this mode the protocol messages are sent multicast on the network.
“ [vipul] Agree,
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. There
should be a section about security, and particularly things like man in the
middle attacks
[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] d:DiscoveryProxy.
[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). [vipul] Agree. 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
mode. [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.
[vipul] A
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. The
document assumes that a Service needs to know in advance what a DP is,
preventing a seemless integration. We
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. Alain From: Vipul Modi
[mailto:Vipul.Modi@microsoft.com] Hello all, 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. Thanks, Vipul Modi Senior Development Lead,
Microsoft Corporation. vipul.modi@microsoft.com |
425-707-2402 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]