[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] network discovery and distribution questions related to RFC 119 impl
|
Hi Carl,
Carl Cook wrote:
Hi Scott (and all others),
Taking a step back from the implementation of RFC 119, are there clear
use cases for when dynamic service discovery is of genuine use?
I think so. Actually...to me...the uses of dynamic service discovery
are much more obvious and clear than static/file-based discovery...e.g.
peer-to-peer services, where peers come and go (as they are likely to do
these days with notebooks, phones/IPhones, etc., etc).
There are plenty of examples these days of network services that are
published/discovered via network discovery protocols...e.g. iTunes,
networked devices (printers, cameras, etc), iPhones/touch, and plenty of
other things.
There may well be, and if so, please just disregard this email (!),
but after reading the RFC, I saw a clear description of the
implementation, but nothing really on the reasons why such a feature
is justifiable - without overstepping the mark, I am an advocate of
the rule "if you can't use it in three separate contexts, leave it
out" :).
I don't think it's a good idea to disregard this email...I think it's a
good discussion to have. WRT the three different contexts...my initial
set: networked devices, peer-based services, phones/PDAs (I think
that's > 3 for each of 3 categories :).
From my experience, static service configuration seems to be the
mainstream, although dynamic discovery is useful when you have to deal
with versioning of services (where a proxy routes the request to the
appropriate implementation based on IP address, application headers,
etc). However, this can already be achieved (reasonably well) by UDDI,
LDAP/Active Directory, etc.
I agree that static service configuration is the mainstream, but it's
also (IMHO) the degenerate case. That is, it fails to recognize the
dynamic aspect to networking these days...e.g. depending upon fixed IP
addresses and names...as well as assuming a basic asymmetry between
'servers' and 'clients'. But with the rapid growth of network-enabled
devices (in particular) I think this is changing.
Although useful for some application and network architectures, I think
that UDDI, LDAP/Active Directory are going to be limited to certain
types of applications...because of the implicit administration and
maintenance requirements (for example...would you run an LDAP server in
your home?...well, probably for Carl that's a poor question...but is
Carl's grandmother going to run an LDAP server in her home? :).
I like the idea of dynamic service discovery. I can think of all sorts
of applications, such as using a Dependency Injection framework
(Guice, for example) to instantiate and inject a web service (client
side) proxy into an program, where Guice itself has used the discovery
framework to locate the web service (a currency conversion service for
example if the application is in the financial/trading domain).
However, as you point out in your email, there are a lot of hidden
caveats to this, such as security, resolution of service conflicts, etc.
Yes. On the whole though...it's my view that the benefits frequently
outweigh the risks at the user level...just witness the usage of
peer-based services like iTunes sharing and the growth of
network-enabled devices.
Am I reading into this RCF correctly, or have I missed the point of
the RFC (in particular the dynamic service discovery section)?
I don't think you've missed the point of the RFC. RFC 119 actually has
discovery as an optional component...partially, I believe, because the
RFC's starting use cases came more from the enterprise computing realm
(RFC 119 was done by the Enterprise Experts Group in OSGi Alliance),
than for the core experts group or the micro experts group.
I think the network discovery use cases are clear even for
enterprise/server-based systems...as to achieve anything close to the
level of dynamicity supported by the OSGi service registry, there has to
be *some* support for network services that come and go (for whatever
reason...e.g. versioning a service...as you suggest).
Do you feel that there are substantial use cases to support the
implementation of dynamic service discovery?
Yes, see above. I'm quite confident that there are others who can/could
come up with others (Markus, Jan, others?).
Thanks,
Scott
