river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Maven repository Entry was Re: Codebase service?
Date Tue, 25 May 2010 14:57:25 GMT

On May 25, 2010, at 1041AM, Gregg Wonderly wrote:

> Peter Firmstone wrote:
>> Dennis Reedy wrote:
>>> - Given the capability above, the need for a codebase service may not be required
>> Agreed
> One of the things that we need to consider, I believe, is the ability for a client/UI
to run without any service/network visability.  Imagine devices using a services UI in a disconnected
environment and later connecting for interaction with the service.  The codebase server, today
requires caching downloading and many interesting twists to how the content of the clients
"classpath" is managed for disconnected operation.  Using a more detached update mechanism
more like we see in more modern network environments can really help.  It does, however, present
more of an opportunity for codebase rot to occur which can cause a client to run without the
right software in place when it attempts to connect to a service.
> The existing codebase mechanism has the benefit that you automatically, always get exactly
the software that the service needs you to use on the client end.
> We should think about how to deal with the chasm that exists between these two mechanisms.
> It is true that there are some service evolution practices that make this less likely.
> If there are things that we can document or compartmentalize to make it easier to use
a deferred update mechanism that would be great.
> I worry about what might happen if a client is started off the network, and then brought
into a network environment where it can make contact with the service without having updated
the code because of how the order of events transpired.

These are all good issues. I think more rigor needs to be put into how service artifacts are
updated, and what attributes we look for when we seek to discover services. Using version
numbers in both the produced artifacts and ensuring that services advertise version numbers
(as part of net.jini.lookup.entry.ServiceInfo), and that we look for specific version numbers
for a service we want to use can help with this issue.

Perhaps (and I'm not sure this has been discussed before) having a range of versions that
a service provides support for could also help address this issue. If the client determines
it is out of synch, the deferred update approach certainly allows the client to choose to
use remote class loading or provision that requisite jars.
View raw message