avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [RFI] service lookup semantics
Date Wed, 03 Dec 2003 02:47:22 GMT
On Wednesday 03 December 2003 06:09, Hamilton Verissimo de Oliveira 
(Engenharia - SPO) wrote:
> Its from a different world and with different requirements, but its worths
> a closer look:
> http://wwws.sun.com/software/jini/specs/jini1.1html/entry-spec.html#30254

Jini's so called Lookup Service (note "Service"!!) is a marvelous little 
beast. Not only can you look up an implementation you are after, by 
requesting services implementing the service interface, but also known 
instances (Object ID) or arbitrarily any service according to its attributes.

A Service can modify its attributes (Entry) in runtime, so they are not static 
identifiers, but holds a kind of searchable state.
Jini (at least 1.1) uses equals() for searches, so for a given Entry 
implementation, it may contain a lot of info, but it is a "all or nothing" 
kind of search outside of the Entry.

To do the search one, creates a ServiceTemplate, which holds the search info, 
and call lookup.

BUT, more interestingly, one can create a so called LookupCache, which allows 
me to place an listener on the ServiceTemplate and be notified when a service 
joins the federation fulfilling the criteria. This is the key of creating the 
robustness of distributed system possible in Jini.

There are 2 main "problems", IMHO, in Jini.
1. The complexity of it is mindboggling. The amount of design and engineering 
that has gone into it makes one wonder, who are these people behind it.
2. The names of the classes are awfully confusing, most of the contains a mix 
of "Service", "Discovery", "Locator", "Join", "Management", and "Lookup" 
(combine at your on discretion), and it is initially very hard to remember 
what is what (I never figured out the naming system).

And most of this stems from the very layered Jini system, which exposes a lot 
of low-level APIs, but you normally get by using the higher level utilities 
(such as the all-round JoinManager)

Since we are touching the subject, let me give you some snippets...

If you are a service and want to join a federation,

// You need to tell which group you want to belong to (if any).
String[] groups = new String[1] { "org.apache.avalon.sandbox" };

// A LookupDiscoveryManager is needed.
LookupDiscoveryManager ldm = new LookupDiscoveryManager( groups, null, this );

// What attributes do want to register with the service.
// The below can be just about anything.
Entry[] attrs = new Entry[5];
attrs[0] = new Name( "My SuperDuper Service" );
attrs[1] = new Location( "28th floor", "home", "Vista Damai, Kuala Lumpur" );
attrs[2] = new Comment( "Under development" );
attrs[3] = new ServiceInfo( "Marvel Product", "hedhman.org", "hedhman.org", 
"1.0.0" , "My SuperDuper Service", SERIAL_NUMBER );
attrs[4] = new ServiceStatus( StatusType.NORMAL );

// Finally, we need a ServiceProxy. This is the object that will be 
// serialized and transferred to the client, and execute inside the
// client JVM.
// It is also the implementation of the Service Interface !!!!! 
// This fact makes it easy to handle "upgrades" of the backend service,
// without breaking compatibility.
// It is a requirement that all ServiceProxy instances pointing to the
// same service, resolves equals()/hashCode() identically, and I
// used the ID of the service to obtain that.
// id is the serviceID, i.e. an instance identifier, which can/should be
// preserved between activations, since it allows "true lifecycles" 
// of services, i.e. they live beyond the termination of the JVM

ServiceProxy proxy = new MySuperDuperServiceProxy( this, id );

// And feed to a JoinManager

if( id == null )
    m_JoinManager = new JoinManager( m_Proxy, attributes, this, ldm, null );
    m_JoinManager = new JoinManager( m_Proxy, attributes, id, ldm, null );

That is basically IT, if you ignore all the small stuff around to make it 
really work (such as equals() and hashCode(), generation of ID, preservation 
of state, serialization of service proxy, et cetera)  ;o)

The client is both easier and harder;

// You need to tell which group you lookup on.
String[] groups = new String[1] { "org.apache.avalon.sandbox" };

// This is for "local" lookup, i.e. within Multicast range.

LookupDiscovery ld = new LookupDiscovery( groups );
ServiceDiscoveryManager sdm = new ServiceDiscoveryManager( ld, null );

// You want to add listeners to when a particular service becomes 
// available
ServiceDiscoveryListener sdl = ...some listener....

// Let's lookup on a Service interface "clazz".
ServiceTemplate st = new ServiceTemplate( null, new Class[] { clazz }, null );

LookupCache lc = m_sdmLocal.createLookupCache( st, null, sdl );

You also need to keep the reference to "lc", so it doesn't get garbage 
The ServiceDiscoveryListener will be called when a service with the interface 
"clazz" joins the federation. And you need to take it from there.

This is basically it for the client side of a service. Again not that much of 
work, as the initial look at Jini may suggest.

The whole concept is remarkable, IMHO, in that the foundation of the whole 
system, the Lookup Service, is in fact not really different from any other 
service. I can have one or many running, the implementation can be changed 
(theoretically at least) and so forth.
A Service or a Client could possibly do without the Lookup Service altogether, 
by utilizing the really low level network protocols for Discovery and Join, 
but that is a pain. Many people read about this protocols, and then think 
"Oh, Jini is too complicated", and moves on with their lives. I hope the 
above shed some light on what is "actually" required.

A final note. I often get the question, "Is Jini better than J2EE?", or "Is 
Jini better than Tomcat?", and possibly now "Is Jini better than Avalon?"

In all of these questions, the answer is that they are not comparable.
A J2EE implementation could be based on Jini.
Tomcat could be contained in Jini services.
Avalon Merlin could transparently provide the Jini functionality as an 


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message