Patrick Wright wrote:
On Wed, May 19, 2010 at 4:46 PM, Dennis Reedy <[email protected]> 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
