Jini builds foundation for SOA

The Jini Technology Starter Kit was recently made available under the Apache License 2.0. Jini, best known as a network communications technology, also is a service-oriented architecture with advanced capabilities.

In a nutshell, an SOA allows a client application, or consumer, to use a service provided by another application, or provider. This usually involves some form of asynchronous messaging or the calling of functions in applications on remote systems (remote method invocation).

In addition to this basic SOA capability, Jini offers such features as platform portability, mobile code and platform security. It is easily used in applications with access to a full Java 2 Platform Standard Edition run-time environment. But it also can be used on tiny, embedded devices and in applications written in non-Java programming languages.

Jini’s core concept is services. A service is a Java interface that defines a contract between a service consumer and a service provider. Most people will be interested in consuming services rather than in publishing them. A lookup service helps you to find the proper service instance.

A key point is that you look for services based on their type, not based on a name or a uniform resource identifier. The object that is returned to you by the lookup service is often called a “service proxy,” because it acts as a stand-in for the service implementation that is somewhere else. A service proxy is responsible for all communications between your application and a service implementation.

One of Jini’s most powerful features is that the implementation of a service proxy does not need to be deployed on a service consumer; instead, it can be securely downloaded from another computer (called “codebase server”) that supplies the current implementation of your service proxy.

All that a deployed Jini client needs is a service interface and its directly referenced types. A Jini service client can be updated efficiently, because the service proxy codebase can be updated on the fly, and newly connecting clients will pick it up automatically. Jini will combine a proxy codebase (retrieved from a codebase server) and service data (called a “serialized proxy” and kept by the lookup service) to provide you with your service proxy.

Jini has a pluggable infrastructure that allows users to integrate with any communications protocol with relative ease. The service-proxy type does not necessarily have to talk to service implementations. One way to easily create smart clients is to have a service proxy that executes some method calls on a client and delegates others to a server. Client/service communications can use any protocol.

The lease concept is important to Jini’s reliability and resilience. All service proxies are leased. The lease concept reflects the assumption that services will fail and communications will be interrupted. In order to remain available, a service needs to continually update its registration using convenient utility types. If it fails to do so, it is evicted from the system and will not be available to clients anymore. Clients can discover only available services. The distributed application essentially detects partial failures and takes routes around them. As long as necessary services are deployed redundantly, a Jini application is almost automatically self-healing.

All Jini’s features together combine for an attractive SOA.

Krapf is president and co-founder of CodeMesh, Inc. He can be reached at alex@codemesh.com.