Sponsored Link •
Bill Venners: Jini is a useful tool in certain situations. Can you shed any light on when developers should consider pulling that tool out of the toolbox?
Sean Neville: Certain situations do come to mind. Jini may make sense when you start doing wild things with JNDI. Jini may make sense if you find yourself doing a lot of static lookups, then storing the names that you looked up. The Jini lookup service is an option if you want to do something more dynamic in terms of JNDI lookup, which is fundamentally a static mechanism.
Bill Venners: What do you mean by static in this sense?
Sean Neville: In JNDI, you just look up by name.
Bill Venners: So I have to know a logical name for everything.
Sean Neville: Right.
Bill Venners: And what kind of object do I get back?
Sean Neville: It could be a remote object or something that was passed by value.
Bill Venners: And I have to know what type the logical name corresponds to.
Sean Neville: You have to know a least a supertype of what you are looking up.
Bill Venners: Does JNDI have an automatic expiration mechanism like the Jini lookup service does? Or does each binding have to actually be removed?
Sean Neville: Each binding has to be explicitly unbound.
Bill Venners: So that's another difference. Things in JNDI can become stale; whereas in the Jini lookup service, registrations are automatically kicked out of the lookup service if their lease expires. So once again it sounds like Jini makes sense in more dynamic situations, in which services are expected to come and go regularly.
Sean Neville: We implement JNDI remoting through this whole Jini mechanism. If you are performing a lookup and this JNDI naming server dies, you can failover to another naming server. Because when you deploy a clustered EJB, its reference is bound to all JNDI trees across the cluster.
Another situation has to do with network failure: EJBs have system exceptions and application exceptions. A system exception causes a roll back and an instance loss. That indicates that something really messed up on the network, like the process died. But beyond that, EJBs assume that you're running on an enterprise system that, because of clustering or administration or whatever, the remote object will be there. If you work in an environment that lacks that sort of assurance, and you need to be more cognizant that things could disappear, then the Jini leasing mechanism could help make things more robust.
Bill Venners: The network is always unreliable to some extent, but it has a spectrum of unreliability. At some point, the network is reliable enough to ignore the fact that it might be unreliable. So you're saying that if you get far enough down that spectrum, you need to deal with the chance for failure, and that's where leasing may make sense.
Sean Neville: Yes.