Jini: The Natural Fit for Web Services

Evolving the Reusable Species

First, we reused functions and packaged them into subroutines. Then, object-oriented programming came along. We reused objects and stuffed them as class libraries into middleware. Now, we are about to reuse applications by turning them into services.

In effect, Web services are nothing more than reusable, componentized Web applications. Perhaps next, we would reuse "service ensembles," and then reuse "ensembles of service ensembles," and so on, the limit being set only by our own human tolerance for working with increasingly complex systems. Underneath, the concept of reusable components remains the same. It is simply a matter of scale as to what we are able to reuse over time.

In parallel, when we were programming with subroutines, we were programming the computer. When we were programming with class libraries, we were programming to include other computers in "n-tier" client-server systems. Now that we are programming with services, we are finally programming to include the network.

If we were to view the network as a graph with nodes and edges, then our developmental evolution shows that we have moved from "node-centric" computing towards "network-centric" computing, from tightly coupled systems to loosely coupled systems, from being edge-oblivious to making edge patterns essential for computation. The relationships between and among the nodes have become important.

Our reusable components are now about to be packaged to function within networks instead of just within computers. The era of hiding the realities of fallible and mutable networks from enterprise developers is over. Services, our newly evolved reusable species, thrive in networked environments, not in single machines.

Fractal Amplification and Impedance Mismatch

Nature does it all the time. She discovers a pattern and uses it repeatedly in increasingly larger scales where it makes sense. For example, the fractal bifurcations of blood vessels to deliver oxygenated blood -- from the aorta, to the arteries, to the arterioles, to the capillaries -- is a pattern seen again in the branching of the airways in the lungs. This same pattern is seen in the branches of trees, in the forks of rivers flowing out to the sea, and so on. Self-similar structures tend to scale optimally in natural systems. I call this the Principle of Fractal Amplification.

At GroupServe, we learned this the hard way. Coming from the groupware space, we found out that collaborative systems were extremely hard to scale dynamically because of an "impedance mismatch" between the inherently distributed groupware application layer and the tightly coupled n-tier client-server-supporting infrastructure. Applying the Principle of Fractal Amplification, we built the RMIEngine, really a bunch of RMIServerServlets, to distribute the resources being used by the groupware layer, such as DB access, mail server access, file I/O, and so forth. This self-similar infrastructure provided the dynamic scaling needed by inherently distributed collaborative systems.

By now, everyone has memorized the "publish, find, bind" triangular diagram of Web services, with "service provider," "service requestor," and "service broker" occupying each of the three spaces. Applying the Principle of Fractal Amplification, what technology out there is similar to the Web services architecture?

The answer is Jini. Jini has service producers, service consumers, and a service registry. It provides the natural infrastructure to support Web services. When Jini came out, the architecture of our RMIEngine was so similar to Jini that it only took us six weeks to convert the RMIEngine modules into Jini services. When Web services came out, we immediately saw its similarity to Jini. We knew then and there that Jini should be the underlying infrastructure for Web services.

Serviceware: The New Class of Service-Oriented Software

In the services dimension, where the reusable species are services, and where the network is essential to the functioning of the services, there is, in a sense, no software that can be installed in single machines. Rather, there is "serviceware," the components of which are built for distribution across networks. The creation of "serviceware" is being explored extensively within the Jini community by multiple vendors through multiple projects. Like Web services, "serviceware" provides the service broker, service producer, and service requester components.

Within these projects the service broker is the Jini lookup service. A special Jini2UDDI program is available so an application service registered with the Jini Lookup Service can be registered automatically in the UDDI registry used by Web services.

Then there's the notion of "service libraries" as service providers. There appear to be three types of services in the service libraries. The "infrastructural services" provide the essential Jini services, such as service management, transaction management, and so forth. Others are adding "enterprise services," back-end services that provide the essential building blocks of Web applications, such as database access service, file I/O service, email access service, search engine service, task scheduling service, and so on. For example, instead of installing email access classes in each and every application server, why not just let the applications access an email access service?

The third type of services, "application services," is an emergent type. When a developer creates a Web application using the available enterprise services, that application itself can be registered in the lookup as a service. Another application can use this application service, which in turn uses the enterprise services, which in turn use the infrastructural services in a cascading manner.

The Jini community is even exploring the use of the J2EE Connector Architecture and Message-Driven Beans to link EJB containers with the service libraries. Service access templates in the form of JSPs, servlets, and Java programs have been created to compose the service requestor component. Tag libraries are also being explored so that Web developers can use Jini services directly.

True to the distributed nature of serviceware, new Jini-based products can be tried without ever having to download the server itself. Go to jini.org or GroupServe's developer site, and start perpetuating the reusable service species.

Teddy Achacoso, Ph.D. is co-founder and CTO of GroupServe, Inc., a leading provider of distributed application technologies and the leader in Jini-enabled web services.

Return to ONJava.com.