Service lookup without unmarshalling - details

[Gregg Wonderly <gr...@wonderly.org>]

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 RemoteIterator<ServiceEntry> lookupEntries( 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;
	RemoteIterator<ServiceEntry> ents = lu.lookupEntries( tmpl );
	for( ServiceEntry ent : ents ) {
		Set<ServiceDataAccess<Entry>> accs =
			ent.getMarshalledAttributeSets();
		String name = null;
		for( ServiceDataAccess<Entry> entacc : 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!

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.

Gregg Wonderly