Reintroducing Jini 2.1
This is a almost live blog of the OCI internal Java lunch. Today our speaker is Ryan Withers. He is talking about Jini.
First person is Ryan now.
Why the reintroduction
Jini has been introduced seven years ago by Sun. At the time it had focus on devices. The product was mis-marketted and the device-orientation didn't work.
Jini is now an Apache incubator project named River.
I started investigating Jini from version 2.1, for an SOA initiative.
Jini does have impressive features. It's been in existence since 1999 and is very service oriented many years before SOA became a popular phrase.
Getting it
You can get the Jini 2.1 starter kit from jini.org under an Apache 2.0 license.
he Jini name does not stand for anything, but is rumored to be an acronym of "Jini is not initials".
Architectural goals of Jini
- Infrastructure for services, possibly federated
- Simplified sharing of services and resources
- Ease of access; location transparency
- Painless administration and maintenance
These goals parallels those of SOA to some extent.
Known uses of Jini
- Rubean A.G
- Magneti Marelli
- Nedap N.V.
- Orbitz
- Orange
Books
Apress book "Fundamentals of Jini 2". Also available online.
What's in Jini Spec
- Architecture
- Core services: Discovery/Join, Entry, Leasing, Event, etc.
- Utilities
- JavaSpaces, etc.
(Brian Coyner asked about the relation between Jini and ZeroConf and Apple's Bon Jour.)
The Demo
Two windows were brought up. One is the Service Browser. The other is a Converter application that uses one of the services.
The Service Browser now shows several services, all in a list box with names resembling full Java class names. One of them is the Registrar. Another one is a sample UppercaseConverter. Double click on a service brings up a metadata inspector for that service.
The Converter application has a data entry field and a convert button. Typing something into the entry field and then click the button will cause the text of the entry field to be converted and printed on an area below the entry field. There is also a menu that allows the user to choose the type of the conversion. At this moment, there is only an "Upper" menu item that corresponds to the UppercaseConverter service. The conversion does the obvious thing.
Another service is started from NetBeans. And the ServiceBrowser now shows one more service—MorseService. The Converter application's conversion type menu now has one more menu item "Morse". Select "Morse" and then click the button causes the text to be converted to Morse code and printed.
The MorseConverter service is shutdown now. It disappears from the Service Browser. A moment later, the "Morse" conversion type also disappears from the Converter application.
What is interesting is that all of these happens without restarting the application.
When the MorseConverter starts up, it makes its implementation classes available to any application that wishes to use it. The Converter application has registered with the Service Registrar its interest in services that implements the Converter interface (which apparently both UppercaseConverter and MorseConverter do). The Registrar notified the Converter application of the newly available service and the Converter application retrieved the classes of the MorseConverter. When it did the conversion, it is running the Java classes from its own JVM. There were no remote calls.
Of course, the service implementer may choose to implement a service as a remote service and export only a stub to the service registrar. In that case the service calls will be remote calls.
(Brian Coyner asked about the relationship between Jini and OSGi.)
Code
The server and the client uses the same code to talk with the Discovery service and the Lookup service.
public class Foo implements DiscoveryListener {
public void doIt() {
LookupDiscovery discover = new LookupDiscovery(LookupDiscovery.ALL_GROUPS);
discover.addDiscoveryListener(this);
}
public void discovered(DiscoveryEvent e) {
}
public void discarded(DiscoveryEvent e) {
}
}
Jini services are just interfaces:
public interface Converter {
public String convert(String input) throws RemoteException;
}
public interface MorseConverter extends Converter {
}
public interface UppercaseConverter extends Converter {
}
Some other interesting classes
RemoteEventListener, ServiceRegistrar.
The events are fired because we specified a ServiceTemplate:
lookup(template, MAX_MATCHES);
where the template was constructed with parameters that contains the Converter interface.
Discussion
(First person is Weiqi now.)
Dean Wette commented that what is presented today is significantly simpler then Jini 1.0.
Eric Burke commented on the Swing code for the Converter applciation emphasizing the importance of wrapping the menu.addMenuItem() call with SwingUtilities to ensure its execution on the EDT.
I asked a question about the order in which various Jini services should be started. The answer is that it mostly doesn't matter. It's more like a peer-to-peer thing in that reguard.
I asked the question about the maturity of Jini. The answer is that Jini is indeed a technology that can be put into production use right away by people who know how to use it. Dean added that any infrastructure that can support telemetry transmission from a Formula One pit (Magneti Marelli) is mature.
Re: Reintroducing Jini 2.1
Re: Reintroducing Jini 2.1
Utilizing this technology, unfortunately, can be pretty problematic. I do not recommend its use unless you are into a lot of frustration.
1. The technology depends on a good working network. The network must be configured just right or registrars will not work properly. For example, suppose you have two development machines, each with a Jini registrar installed. Without proper network settings you can have some weird behavior, like registrar A seeing registrar B but registrar B only seeing its own services. You can also have situations where if registrar A attempts to browse registrar B's services, it can "hang" due to some unknown failure. What this means is that you will have situations where services that are intended to be shared across machines cannot be due to unknown network problems. Unfortunately, with the poor documentation and a community that is apparently unfriendly towards beginners, the problems you run into often remain unknown.
2. Even ignoring the problems described above, you can still at least create and test some nice services, right? Wrong. There is an awful lot of setup that you have to do, like putting various classes and interfaces in the right places. Unfortunately, neither the documentation nor the book referenced in this blog makes it clear exactly where things should go. There are instructions for deploying a Jini service, they just aren't complete. For that reason, expect to get a log of ClassDefNotFound or ClassNotFound exceptions even when you try to register a service.
3. As alluded to in (1) and (2) the documentation for this technology is a joke. There are some pretty good instructions, both on the net and in the "Foundations of Jini 2 Programming" book, but the instructions are neither detailed nor complete. They do not cover many of the circumstances people have to deal with when setting up Jini registrars, services, or clients on the network. For example: no one talks about what to do when you have a network of machines that use DHCP. Another example: there needs to be better descriptions of the mechanisms used to share services, as well as more extensive troubleshooting for dealing with the inevitable failures that you will run into while attempting to deploy a service. If the documentation isn't bad enough, the Jini community is pretty useless, as well. Go on to several forums and ask basic questions about setup and deployment, and watch as your questions are ignored. Granted, not all problems are ignored; some people actually get help when they have little coding problems or if they ask questions comparing Jini to other technologies. But try asking why a service, which you deployed *according to the instructions*, is failing to register properly. Then make sure that you don't hold your breath while waiting for some help.
My strong suggestion: unless you are very lucky, into frustration, or you have a large team and a lot of time on your hands, *do not* even think of using this technology. It has been around for a long time, but it still isn't ready for "prime time".
Until it is better documented, has more detailed setup and deployment instructions, and a friendlier community, it isn't worth your time.