Reintroducing Jini 2.1

Fri, 28 Sep 2007 21:52:15 GMT

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.

Go Listen To Jim Waldo!

Thu, 06 Oct 2005 01:58:15 GMT

(Via Charles Ditzel)

Jim Waldo (audio, slides): If you don't have a failure model, what you do have is a failure model that says any failure will be catastrophic.

Jim Waldo is one of the authors of the classic paper: A Note on Distributed Computing.

Weiqi Gao's Observations - jini tag