Summary
I've been working on an enhancement to Jini servce lookup in my reef project over on jini.org. I've still got more work to do before getting to the proposal stage. Here's where I'm at.

---

Advertisement

Some Background

The Jini service lookup specification and implementation present in the ServiceRegistrar presents some interesting issues for large numbers of services, all of which might be of interest to desktop environments.

ServiceRegistrar's lookup(ServiceTemplate,int) method returns a ServiceMatches object that then provides access to an array of ServiceItem Objects. The ServiceItem class has no accessor methods, and just provides fields with access to the unmarshalled form of the service registration data values, namely the ServiceID, an Entry[] and service object.

What happens with this implementation is that if a ServiceTemplate matches more than just a couple of services, a whole bunch of code downloads can occur and a lot of time can elapse while the service code is downloaded and the service registration objects are instantiated. This API doesn't provide any real flexibility in controlling when unmarshalling occurs or which values are unmarshalled.

Over on my reef project at jini.org, I'm trying to deal with a number of things related to service lookup.

The Problem

I have a collection of about 12 services that are ran simultaneously as part of a larger application framework. In a recent customer deployment, we would have 4 of machines running this 12 services. Each of the services have 2 or more serviceUIs that are advertised. One for managing the service's Jini configuration (an AdminUI) and one for the MainUI. This results in about 25 total UI instances per machine. There are about 15 distinct jar files associated with these 12 services that would need to be downloaded too.

With 4 machines, that means about 100 serviceUIs and about 60 download requests using ServiceRegistrar to lookup these services. The kicker is that some of the users of these clients connect with a cellphone dialup or similar low bandwidth connection to access the mainUI for some of these services.

I was confronted with a real need to greatly reduce and explicitly control the moment of downloading code. The client computers are not big computers either, so I really need to control the total number of live objects too.

Some Background on Service Lookup Variations

An intesting collection of discussions have happened on the jini-users mailing list over the years regarding variations on service lookup. Over the years a number of different people have asked about controlling service lookup more explicitly with pattern matching and other requests. The standing theme of many of the replies has always been, "Create a service which does what you need, and have the client use that service to do the lookups."

This is largely a valid response from a number of perspectives, but it doesn't make it any easier to get the results one might really need. It is an architecture which uses existing functionality and extends it to be more useful. The fact that there is some additional work involved in creating and deploying another service creates some barries however.

The Issues I'd Like to Resolve

There are a number of barries that ServiceRegistrar presents to the user. Some of these are part of past implementation details. Some of the barriers are only in place now because of new additions to Jini, such as JERI. Here's my view on the important things.

Marshalling

In the world of RMI, object passed between JVMs are marshalled implicitly through serialization or explicitly as MarshalledObject instances into a network transportable form. On the other end, they must be unmarshalled and instantiated back into live objects. Serialization doesn't carry codebase information with the object. So, if both ends don't know about the same version (serial version id) of the class, there will be problems. The java.rmi.MarshalledObject class provides support for use of a codebase annotation that allows the receiving JVM to download code to have the correct version of the class active. In the typical deployment, the contract of use between two JVMs will be manifested in an interface. The downloaded class is just the implementation of the interface(s).

One of the issues with the service lookup/matching specification is that it doesn't demand marshalling it just says that lookup comparisons must be equivalent to MarshalledObject.equals() behavior. There are some interesting reasons why one might choose to not specify the required implementation. But, this, to me, leaves the door opened for lookup service implementations that won't use marshalling, and thus won't provide the client the opportunity to control the unmarshalling.

Constraints

The Jini Extensible Remote Invocation (JERI) stack implemented in Jini2.0 provides a nice, plugable stack of remote method invocation control. You can start at the bottom with endpoints that provide transport control. Next up the stack, the invocation layer provides a way to translate between invocation paradigms on each end. This allows native java objects on one end to be translated into XML based messaging for instance. Next up the stack is the Exporter (service end) and Proxy Preparer (client end). These two objects present the final remote call transport contract to each end.

The BasicILFactory class provides the ability to supply MethodConstraints to dictate what types of criteria the transport, invocation and client environments must meet to use the service. There are some interesting interactions here from the perspective that you can tell the invocation layer that your service needs to have a secure transport, with the endpoint implementation providing this guarentee. There are some interactions through the layers that make it possible for the question of "is this constraint met?" to be answered. This happens through a number of paths of execution from both the client side (proxy preparation) and the service side (proxy verification and invocation layer validation during inbound calls).

I'd like for service lookup results to allow the client software to query the service for its requirements so that a first time use of a service could allow the client to assert the required constraint implementations through dialogs or wizards that would help users understand more about the service requirements. Currently, these implementation details are manually managed and the deployment environment is assumed to be managed by well trained people who most likely already know the requirements that need to be met.

Login identities for authentication and authorization are one barrier, but there are other constraints that the user can meet with explicit control of their environment.

Filtering

One of the common question about using service lookup on the jini-users mailing list has involved more sophisticated filtering of returned results. In particular, partial string matches as well as "and" vs "or" matching logic of the ServiceTemplate fields has been discussed.

This basic filtering request has come up in the Javaspaces realm too. There are a wide diversity of potential needs for matching/discovering/filtering in the real world. There needs to be some more flexibility in matching. One of the problems is that matching in the server to control returned results is going to be limited because of the desires to keep user supplied code out of the lookup service to manage integrity and reliability issues. The current ServiceTemplate provides exact matching using simple equals() comparisons.

I'd like to extend this ability to include some more explicit control over the results of matching to better control bandwidth based performance. It would be nice to get 1 result efficiently (getting access to a single well known service), but not be burdened by the API when 100 results (all services that provide a serviceUI) would make sense as well.

Compatibility Issues

One of the primary concerns that I've sensed from others is that changing service lookup APIs at a basic level is problematic, because it will affect the interworking of services and clients. My plan of action is to manage this issue by creating a new ServiceDiscovery Manager like API that wraps both the ServiceRegistrar interface use and my ServiceLookup interface use, under the covers, into a new API for service lookup. This API will make ServiceRegistrar implementations and ServiceLookup implementations usable with the same, new API. There will be a few issues that need to be worked through though.

What's Next

I'll be trying to put together a buildable version of reggie with ServiceLookup extensions in it next. Tearing apart the existing build and breaking it down into just building reggie will take a bit of time for the disection of the ant files. Once I have the build working outside of the JTSK build, then I'll be ready to start supporting a trial version that will be more consumable then what is currently in CVS.

Talk Back!

Have an opinion? Readers have already posted 3 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Gregg Wonderly adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Gregg Wonderly graduated from Oklahoma State University in 1988 with an MS in COMSCI. His areas of concentration include Operating Systems and Languages. His first job was at the AT&T Bell Labs facilities in Naperville IL working on software retrofit for the 5ESS switch. He designed a procedure control language in the era of the development of Java with similar motivations that the Oak and then Java language development was driven by. Language design is still at the top of his list, but his focus tends to be on application languges layered on top of programming languages such as Java. Some just consider this API design, but there really is more to it! Gregg now works for Cyte Technologies Inc., where he does software engineering and design related to distributed systems in highly available environments.