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.