Skip to main content

[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 Scott,

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).

Great point. I based my view on enterprise applications rather than also considering ad-hoc/peer to peer networking.
 
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.

Interesting that you mention iPhones. The next version of the OS/SDK (version 3) introduces peer to peer networking for the iPhone (via BlueTooth).  This opens up a new class of applications (transient connections/networks).

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 :).

Yes, now that you mention phones/PDAs, peer to peer services (such as bit torrent, etc), the possibilities/permutations are mind blowing!
 
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.

Agreed. Particularly with the emergence of location-based services (in particular those that serve mobile phones, such as GPS-ranked search results).
 
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?...

:) No LDAP servers in my house (!), and yes, administration is a nightmare, which in effect makes the infrastructure "fixed" due purely to the prohibitive cost of reconfiguration.
 
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.

Right, that makes sense. The RFC does come across rather "enterprisy". 
 
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).

Well, using the growth of peer to peer, location-based, and on-demand services as motivation, I can now clearly see the reasoning behind investigating the dynamic discovery section of the RCF.

So, my next question is: how does the ECF fit into this? Again, I am showing my ignorance/lack of knowledge here, but the ECF is used primarily for supporting communication between RCP applications, eclipse plugins and the like. If I am correct regarding this, is the OSGi implementation intended to support these classes of applications, or branch out to provide framework support for mobile devices, new types of servers/services, etc? Again, this could be an incredibly stupid question, but I am intrigued to find out more!

As mentioned previously, solving the challenges as to what the "default" behavior should be for service discovery, resolution, security, service lifetimes, etc seems like a great topic to tackle.

Back to the top