river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Codebase service?
Date Thu, 20 May 2010 06:45:02 GMT
Patrick Wright wrote:
> On Wed, May 19, 2010 at 4:46 PM, Dennis Reedy <dennis.reedy@gmail.com> wrote:
>> On May 19, 2010, at 1007AM, Patrick Wright wrote:
>>> It seems you would want
>>> - the service to post a hash of the required dependency/DL JAR file
>>> that it expects you to use; this not only helps guarantee
>>> authenticity,
>> True, but I suggest that in general you already know what these are. You would need
to in order to build your client (or service) that uses the associated service.
> Yes, what I meant though was that when the service launches, it may or
> need to register (via Entries) identifying information for the DL JAR,
> in case that has changed. If it's posted via the entry (or even the
> codebase attribute) then the client will know whether it has the JARs
> or not, whether it has the correct version, and whether it needs to
> download them.
> Of course, this isn't necessary. It just allows for a little more
> dynamic behavior in case you deploy services and clients on different
> cycles, and the client is deployed with access to an older version of
> the DL JAR. If you deploy both sides at the same time, you wouldn't
> need this.
A big benefit your approach has, is to enable different *-dl.jar proxy's 
for different platforms.  Entry's could allow the client to select from 
a list of available proxy *-dl.jar that best match the platform.  If 
there's some new fandangled latest functionality available, you can take 
advantage of it in your new proxy implementation, while your earlier or 
simpler Java client platforms (hello cdc) use a different proxy.  Your 
no longer stuck with the lowest common denominator.

Yes I definitely like your Codebase Entry suggestion, in addition, it 
enables a client to filter out unwanted ServiceInterface versions.

The client user wouldn't even have to worry about this information, the 
client platform, can provide a filter that removes any Services that it 
can't support, using the new ServiceResultStreamFilter, filter chaining 
with ServiceItemFilter's consuming from a StreamServiceRegistrar, based 
on your Entry's.

The filter chain (ServiceResultStreamFilter) can be made up of several 
ServiceItemFilter's that ignore, discard, divert or process ServiceItems 
from the ResultStream.  An Abstract subclass of ServiceItem , called 
MarshalledServiceItem also provides for delayed unmarshalling, in 
addition, StreamServiceRegistrar allows you to selectively unmarshall 
your Entries.  Using your CodeSource Entry, one could first filter out 
incompatible Service Proxy's, then divert ServiceItem's by CodeSource, 
into Blocking Queues for processing, then unmarshall and process one 
proxy at a time using the one CodeSource, you could even utilise the 
same ClassLoader, by revoking all permissions for that ClassLoader after 
each proxy reference is set null, then grant permissions after the next 
proxy is verified by another filter. If you've got enough memory, these 
blocking queue's can be processed concurrently.  While all this is 
happening, the next CodeSource can be downloading in the background.

Hmm, you could do some Serious Batch processing like that.

Have a look on SVN in net.jini.lookup and net.jini.core.lookup for the 
new classes.

> I think the Maven coordinate would work as well, but I have had Maven
> burp every now and then and I need to delete artifacts from my local
> repository to clear up some confusion it has with an older artifact.
> Hence I suggest a hash as a more accurate key to verifying we have the
> right JAR.
+1  Peter.
> Patrick

View raw message