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.
