river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Service lookup without unmarshalling - details
Date Sat, 13 Dec 2008 19:44:11 GMT
----- Original Message ----
> From: Gregg Wonderly <gregg@wonderly.org>
> To: river-dev@incubator.apache.org
> Sent: Friday, December 12, 2008 1:57:28 PM
> Subject: Service lookup without unmarshalling - details
> Wade Chandler wrote:
> > Heh heh, yes, there needs to be a way to inspect the service, some 
> credentials,
> > without unmarshalling. A way to ask for all services out there, the class or 
> interface they implement, along with other user identification information such 
> as a displayable name, description, version, etc I would think. What about this
> > list? Anyone have a link to an archive? I want to find your other email Gregg
> > and see what you wrote about there.
> I was just in my list of things I still wanted to put back into River.  I did 
> this about 2-3 years ago, and have been using it since then.  The Reggie 
> architecture makes it easy to do.  I want it to be an optional interface 
> supported by lookup services.
> As an example, the current definition of lookup(ServiceTemplate,int) in the 
> Reggie proxy is shown here.
>     // Inherit javadoc
>     public ServiceMatches lookup(ServiceTemplate tmpl, int maxMatches)
>     throws RemoteException
>     {
>     return server.lookup(new Template(tmpl), maxMatches).get();
>     }
> If you look closely, you will see the "get()" on the end of the line, above, 
> which does the unmarshalling.  So, just before it gives you the results, they 
> are unmarshalled.
> The following method is one of the ones that I added which is in the 
> ServiceLookup interface API.
>     public RemoteIteratorlookupEntries( ServiceTemplate tmpl,
>             int maxMatches ) throws RemoteException {
>         return new LocalEntryIterator( server.lookup(new Template(tmpl),
>         maxMatches ) );
>     }
> So, it's possible for Reggie to have a simple conversion done to provide this 
> capability.  However, I don't think it's realistic to ask that all 
> ServiceRegistrar instances support this as the Primary mechanism.
> What I've done so far, works.  Are the names and relationships exactly what I'd 
> want to see in a production system?  Perhaps not.  Below is an example usage of 
> the API.
> If you had a ServiceRegistrar instance which also implemented ServiceLookup, 
> you'd do something like the following to perform a lookup and get a name for all 
> the service instances and add them to a list via addService().
> // make sure no downloading occurs to resolve these classes
> ClassLoading.neverPrefer( Name.class );
> ClassLoading.neverPrefer( ServiceInfo.class );
> ServiceTemplate tmpl = ...
> ServiceRegistrar reg = ...
> if( reg instanceof ServiceLookup ) {
>     ServiceLookup lu = (ServiceLookup)reg;
>     RemoteIteratorents = lu.lookupEntries( tmpl );
>     for( ServiceEntry ent : ents ) {
>         Set> accs =
>             ent.getMarshalledAttributeSets();
>         String name = null;
>         for( ServiceDataAccessentacc : accs ) {
>             if( entacc.getDataClassNames().
>                 contains(Name.class.getName() ) {
>                 // Will resolve to local VM class
>                 name = ((Name)entacc.getData()).getName();
>             // Prefer Name, but allow ServiceInfo
>             } else if( entacc.getDataClassNames().
>                 contains(ServiceInfo.class.getName() &&
>                     name == null ) {
>                 // Will resolve to local VM class
>                 name = ((ServiceInfo)
>                     entacc.getData()).getName();
>             }
>         }
>         if( name == null )
>             name = ...find a name from classes...
>         addService( name, ent );
>     }
> } else {
>     // you can do regular lookup here and get live objects, or
>     // you can ignore all instances that don't support
>     // access to the marhalled results.
> }
> So in this case, only the Entry values for a Name instance of a ServiceInfo 
> instance will ever be instantiated.  My changes to ClassLoading, to provide the 
> ability to short circuit PreferredClassLoader from downloading the first jar in 
> the codebase to find the PREFERRED.LIST to see how to resolve the classes being 
> unmarshalled, keep unneeded code from being unmarshalled.  Imagine what would 
> happen to your VM where 200 developers are working on the same project, all 
> running netbeans, and using a service proxy that unmarshalls into a 1MB class 
> instance.  Suddenly, you do a lookup and 200MB goes aways!

Yes, something like that. Using common types such as Name, Location, ServiceInfo, Comment,
etc and maybe defining a few more and if any of those are available use them. Then, only load
and use any more complex types in some automated system or something of that nature. Seems
to be able to have that RemoteIterator to remotely iterate over the services over the network
would be good so that limited memory systems can inspect all services without loading all
that at one time. Too, to be able to set limits on how much information a given class can
contain before we want to look at it in this context would be nice as well; thinking about
very memory limited devices or systems here.

I was thinking of some XML type descriptors which could be returned by services etc, but maybe
that isn't needed as long as we can inspect all the marshalled information and dig out what
we need. Some use of XML descriptors though might help simplify the join and discovery process
though as that can be examined to determine if signatures, types, etc match without marshalling
of objects though. It all starts to run together with marshalled objects and formats when
talking of XML descriptors. 

Essentially we can glean the same things from specific interfaces, but what we don't have
as much control over is the serialized size of that information as we can with XML schemas
and restrictions. Though we can always do some checks on both sides and limit things as needed
as it relates to size and performance I suppose. I'm interested in talking about the possibility
to lookup an XML stream which contains service descriptions though. I feel some things could
be simplified that way though that does add some over head for smaller devices with less processing
capabilities. Does any of MTOMs new features support binary and indexed XML to make that type
of thing faster?

> Nicalas, and others desires to have a no-network environment could help deal 
> with some of the issues of rogue code.  At some point, you will want to not have 
> all of the services running on your computer when you are testing a client. You 
> might in fact not be able to run the server on your computer.  Both network and 
> non-network environments are interesting to explore.  My investigation into 
> these issues and how to get away from downloading anything, until you use it, 
> has been very revealing of the issues to me.

Security is where I need to understand Jini much better, but it seems if we had or used some
signing mechanisms this could all be simpler. Essentially a signature gets sent in the protocols
with each set of information and at different levels. Much seems supported now. Looking at
everything I see some ways to do insecure activities and I see ways to do secure activities.

Looking in discovery and join there are some things for security which can be tied to user
activities and automated activities given a security repository or configuration:


Signatures can be used for multi-cast to short circuit before unicast ever comes into play,
though this may not be as important. Essentially, a server or client a like can ignore anyone
know in the trusted keystore. As it relates to user actions in an IDE they can could be given
tools to do all this through a UI, define server security configuration and client alike and
import keys and certs etc.


Using SSL or Kerberos one can secure a system to only use verified and trusted or imported
certificates from a specific group/domain/company/entity. Then, when a service is to be accessed
only allowed servers can be used period. The same thing for joining a group, a server can
check to see if they are allowed to allow someone to publish services. Again, in IDE tooling
this can all be setup for the user through UIs to make getting going safely much easier.

In all of the above, if we install a module in NetBeans or Eclipse, then certificates can
be generated at that point to allow for unique and protected development keys and certs for
the developer, and those can be shared by teams or what ever. Too, they can be created as

Now, that takes care of high level security. I need to better understand, and I'm working
on it, what Jini configurations are supported at this level, if any, or if this is all just
JVM level stuff basically outside of the Jini unless a custom HTTPS or other SSL authentication
class is setup. Regardless, DSA and RSA will have to be done at the Jini level, and I don't
know what configuration is available for that yet, but will soon...relatively soon :-D 

Seems JERI (extensible) and Jini security packages also support extensions to security. Seems
then we start to get down to finer grained security:

Both of these things seem pluggable. For the marshelling etc IntegrityVerifiers that tie into
tooling or automatic systems can be setup. Then one can configure specifically allowed signers
to always allow their code to execute, and that can be done though a UI in user environments
and through configuration in automated systems either through files, JMX beans, etc. Of course,
I bet many extensions already do a lot of this, and maybe the default services in River do;
at least I'm guessing, but I haven't gotten to look into everythings sources at this point,
at least not as much as I need to.

So, given all of the above, and getting back to tooling and IDEs to hook it all together,
including your ideas on accessing attributes (entries) and displaying things to the user,
I don't see where the security manager in something like NetBeans matters. We can add what
ever we need as pluggable components to the core and specific modules for different IDEs.
Too, as long as those things allow us to affect the given classloader in a module, as NB does,
then we won't be hampered there. Essentially the Jini stuff running in some IDE modules will
make the determination whether to show this or that service or not and individually if used
in RCP type applications those modules can load whatever remote classes they need through
Jini and any dependent modules can still work against those modules fine.

I see all of the above as good places for improvements in security from a good set of standard
items to use in the core to a good set of common classes we can use in NetBeans and Eclipse
for tooling. Of course the UIs will be different as one is Swing and the other SWT. I don't
know much about SWT and Swing interaction, so that will need to be sorted out for JavaBeans
with user interfaces, components, in them. i.e. a service has some SWT UIs in it or Swing
UIs in it then those won't work in NB or Eclipse respectfully. 


Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team
Member, and NetBeans Board Member

View raw message