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: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3
Date Thu, 09 Dec 2010 03:15:28 GMT
Dennis Reedy wrote:
> On Dec 8, 2010, at 821AM, Gregg Wonderly wrote:
>   
>> The current situation with how lookup returns an unmarshalled object limits a client
choice to much earlier "binding".  That is, instead of being able to look at multiple service
matches and say "this one is not for me", it needs to, instead, be connected with the service
deployments via an Entry which might indicate what "platform" the server can support.  This
is not always a problem and I don't want to undervalue how Entry can be used to do this.
>>
>> Deferred unmarshalling in lookup could provide some more powerful decision opportunities
for the client by allowing it to better manage when that occurs.
>>
>>     
>
> I agree, deferred marshaling and using lookup attributes can certainly aid in how this
can be accomplished.
>
>
>   
I've got a Service API called StreamServiceRegistrar for just such a 
thing, in skunk/pepe, it was intended to maintain backward compatibility 
with ServiceRegistrar, by extending it.

So after discovery you can check if your ServiceRegistrar is an instance 
of StreamServiceRegistrar.  In older clients, it will only be a 
ServiceRegistrar, but be backward compatible.  It also has a powerful 
filter chaining interface, using the existing filters passed to 
ServiceDiscoveryManager so you can perform pre unmarshalling filtering 
(=) and post unmarshalling filtering (<><=>=), (Entry's are intended to 
be unmarshalled by default if they have local code).

This is intended to be an internet based service registrar, where the 
results may be infinitely streamed, and sent in small chunks and 
handled, where you can process more than your memory can contain, by 
discarding what you don't want, using filtering, then discarding the 
service after performing an operation on it, freeing up a service 
proxy's ClassLoader.

It's inspired by Gregg's work, although it isn't compatible.

I've been waiting for some feedback on the interface, since I know you 
can't change it once it's released.

Different but related topic:

As a totally separate concern, when you obtain a remote object, by means 
other than MarshalledInstance, which we can use to ensure trust, how do 
you ensure that MarshalInputStream will impose the right constraints?  
Eg you lookup a service and hand it an Exported Object or another service.

Because you have a trust relationship with the service already, it could 
reasonably expect that you won't perform an unmarshalling attack on it 
and it will apply suitable constraints at it's end.

Michal was working on preventing unmarshalling attacks using new Module 
implementations of MarshalInputStream and MarshalOutputStream, there are 
two drawbacks currently; it's not backward compatible with the existing 
implementations and it has to annotate a proxy with every object in the 
object stream.  On the plus side it can distinguish different service 
providers with the same codebase.

I've also wondered if we should create a URL handler that enables one to 
append a Subject's Certificate to the stream to ensure we don't have 
different Service proxy's with identical jar files sharing the same 
classloader.  The Certificate's Principal would somehow have to be one 
of the ServerMinPrincipal constraints set on the proxy also.

We could create a URL handler for URL's with the following information:

DNS-SRV domain path
jar filename
Message Digest
Subject unique Certificate.

This might enable redundant Codebase servers, discovered using DNS-SRV, 
message digest's to enable integrity, and a unique Certificate to ensure 
we keep separate identical services in separate ClassLoaders.  Note: 
Isolates would have been perfect for this to save on ClassLoaders and 
memory.  Java SE Embedded and JNode support the Isolates API.  Those 
platforms could use Isolates instead of separate ClassLoaders.


Cheers,

Peter.

Mime
View raw message