ini technology is an open architecture that enables Java developers to build distributed systems that are highly adaptive to change. As the complexities associated with building and managing service-based systems become clearer, more and more developers are relying on Jini technology’s dynamic networking capabilities and service-oriented architecture to build distributed systems today.

Jini technology introduced the concept of dynamic networking, a very simple, yet unique networking approach. The fundamental difference between dynamic networking and traditional networking is one of perspective. If you build your system with the assumption that the environment it will run in is dynamic, and therefore actively consider that the system will need to detect and respond to changes in its runtime environment, then you are working in a dynamic networking mindset. If you don’t think about this at all as you design and code your system, then you’re not working in a dynamic networking mindset. Today’s deployment environments are increasingly dynamic, and in these environments systems that are built to respond to change both flexibly and automatically often perform better than their static counterparts, which rely largely on human intervention to deal with change.

Exactly What Is Jini Technology?
Jini technology is a set of specifications that describe how to build adaptive distributed systems that run on the Java platform. The specifications presume, fundamentally, that any aspect of a distributed system is subject to change without notice, and so they provide systems designers and developers with the mechanism needed to recognize, acknowledge, and build their systems to accommodate change.

Jini technology specifications are straightforward and minimalist. They describe the following:

1. A very simple dynamic system assembly mechanism that enables clients to find and connect to services in a dynamic network
2. An associated programming model that extends the Java programming model to function in a dynamic, distributed environment
3. Key infrastructure services, such as shared memory and transaction management services, which enable important functionality to be delivered in a dynamic, distributed environment

Sun Microsystems created Jini technology and contributed it to the Jini Community in 1999. At this same time, Sun also contributed the first implementation of the original Jini technology specifications, packaged together with supporting utilities and examples as the Jini Technology Starter Kit.

Today, Jini technology remains freely available, and individual and corporate members of the Jini Community are advancing it through the open Jini Community Decision Process. Sun continues to advance and provide the Jini Technology Starter Kit free of charge to the Jini Community. In addition, numerous commercial and non-commercial implementations of Jini technology, created by members of the Jini Community, are also available.

First Things First: the Java Platform
The core of most modern systems architectures is a distributed object model, and Jini technology has been developed around the Java object model. This means much more than simply presenting Jini services through Java interfaces; it also means that you have access to the sorts of capabilities, built into Java technology, that make dynamic networking really work. Things such as:

• A single, object-oriented language for both defining and implementing service interfaces
• A powerful service ontology in the form of a true object type system
• A rich runtime environment, which includes “sandbox” security
• A distributed object model that encapsulates network communications and client-side service code as service implementation details
• Dynamic service delivery via downloadable code
• A remote method invocation mechanism that recognizes the possibility of network failure

Using the Java platform mandates certain minimal system requirements for Jini technology systems, most notably:

1. Agreements between Jini clients and services must be described using Java interfaces
2. Each Jini client and service must be at least wrapped (though not necessarily entirely coded) in a Java language implementation of their interfaces
3. At least one Java virtual machine must be running somewhere on the network.

For that price, Jini technology gives you unique and powerful dynamic networking capabilities that only the Java platform can support.

If you’re starting to get even a fuzzy sense of what Jini technology and Java dynamic networking are all about at this point, you’re doing great. A closer look now at what Jini technology does and how it works ought to help you pull it all together.

First, consider what Jini technology does. Put simply, Jini technology:

1. Tracks the services currently available in dynamic runtime environments
2. Identifies services among those currently available that can satisfy client needs
3. Assembles services as needed into a running system
4. Enables coordinated interaction of distributed components

Part 1 of this introduction explains how Jini technology tracks services, identifies their capabilities, and assembles them into systems. Part 2 will continue with an introduction to the ways in which Jini technology supports distributed component interactions. It will conclude with a review of some of the kinds of applications that Jini technology is being used in today.

Tracking Services
Jini Lookup Services (LUSs) and the Discovery, Join, and Leasing protocols collectively allow a Jini system to accurately, efficiently, and automatically track the set of services currently available in dynamic environments. These capabilities provide a Jini technology system with a level of self-awareness, in that the system always knows which services are available to it, even though services are expected to come, go, and move around while the system is running.

When they start up, Jini clients and services “discover” Jini LUSs by multicasting (or unicasting) requests for Lookup Services. Each LUS responds to discovery requests by delivering its proxy, a Java object that implements the LUS interface, to the discovering client or service. Jini services then use the LUS proxies to “join” the Jini network by registering themselves in each LUS. Jini clients use the proxies to “lookup” services as they need them.

Figure 1: Dynamic Networking with Jini Technology ? 1

The discovery protocol also supports the late arrival of LUSs. At startup, and periodically thereafter, LUSs send out availability announcements. Interested Jini clients and services that are already up and running respond to those announcements by initiating unicast discovery requests back to the LUS. This also allows running LUSs to reconnect with clients and services after a network recovers from a failure.

As part of its registration with a LUS, a Jini service agrees to terms of a lease, which it negotiates with the LUS and which specifies how long the LUS will maintain the service’s registration. If the service does not renew its lease before it expires, the LUS automatically drops the service’s registration. Leasing helps a Jini system define network failures, which can be a tricky thing to do: how can you tell the difference between a slow network connection and a lost connection? Leasing enables the LUS and service to agree in advance about exactly how long is too long to wait. And, because lease terms are negotiated between the LUS and each registered service, their durations may vary from one service to another within the same LUS, or from one LUS to another for the same service. This gives you a level of flexibility that you may need to accommodate variations in availability requirements and network stability among different services within a single system.

Jini LUSs are themselves Jini services, so it’s natural for them to come, go, move around, and change like any other component of a Jini system. If you take advantage of this self-referencing architecture you can be sure that the infrastructure supporting your Jini system will also be adaptive to change. For example, you can provide redundancy by simply running multiple LUS instances.

Selecting Services
Jini clients select Jini services according to the Java interfaces that they implement. This means any Jini client you write will automatically recognize services that provide the functionality you need without you ever needing to know what those services are named, where they are located, who provided them, or anything else about them. Besides making it easier to code your client, you also gain tremendous flexibility in terms of service substitution. As new or changed service implementations become available anywhere on the network, you can automatically recognize and use them.

Using interfaces to identify service capabilities also eliminates “mistaken capability” problems that can arise when relying on potentially ambiguous names or other conventions to describe service capabilities indirectly. For example, if you mistakenly rename a service, systems that rely on that service’s name to identify its capabilities may assume incorrectly that your service has new capabilities suggested by its new name. Jini systems do not depend upon service names in this way (Jini services don’t even need to be named). Instead, Jini service capabilities are identified directly, according to the interfaces they implement.

Figure 2: Dynamic Networking with Jini Technology ? 2

As a useful aside, Jini services can register with additional attributes to help differentiate them from other services that provide the same capabilities. If the ability to refine your service selection is important to you (maybe you want to be sure you’re using an implementation that meets certain requirements you may have for cost or performance), you can use attributes to help you do that too.

Since the Java type system is a true object-oriented type system and supports polymorphism and inheritance, any Java program readily understands the relationships between Jini service types. So the Java type system provides a built-in service ontology that Jini clients use. Among other benefits, this allows you to evolve your system by replacing older versions of Jini services with new ones without needing to simultaneously update older clients that may still be looking for the original service functionality. The same Jini services that you extend with additional functionality will still be automatically recognized as able to implement their original interfaces too.

Figure 3: Java Type System as a Jini Service Ontology

System Assembly
As do most other component-based systems today, a Jini system assembles itself at runtime by integrating individual services into the whole as needed. Systems architectures that support this “runtime binding” capability are more adaptive than those that are fully bound at compile or deploy time because they can incorporate the very latest versions of components that are available when the system needs them. That said, all systems architectures that support runtime binding are not the same, and their levels of adaptivity vary.

The key to Jini technology’s runtime assembly flexibility derives from its concept of a distributed service. Jini services are designed in a way that adds flexibility to runtime system assembly. To appreciate this design, let’s first explore the idea of runtime binding (and while we’re at it, object-oriented development too) in the context of distributed systems.

Runtime binding is possible only if the parts that will eventually connect together understand in advance how they will interface with one another when the time comes. Defining such component interfaces is fairly straightforward in non-distributed systems (thanks especially to object-oriented programming models, which demand clear agreement on interfaces while allowing variable implementations to be encapsulated behind those interfaces), but it gets more complicated when a network is positioned between distributed clients and services.

Most distributed systems architectures include agreements about how the network will be used to communicate to remote code as part of the interface definition that will be used later to bind distributed clients and services together.

Figure 4: Traditional Distributed Clients and Services

Unfortunately, this design decision forces the client/service interface to be positioned—always—across the physical network connection that sits between client and server machines. It does not support the notion that a logical service might include code that runs on both the client and server sides of a network. In other words, most popular distributed computing models compromise the object-oriented notion of encapsulation, which demands that a service be fully implemented behind its interface, whenever the logical service boundary does not align with the physical network boundary. As a consequence, service developers must choose between the lesser of two evils:

1. Encapsulate all service-related code on the server machine
2. Break encapsulation and coordinate with client developers to include service code within the client implementation

Jini technology takes a different approach. It utilizes mobile Java code to deliver services to clients as needed. Having the ability to move code over the network and directly to the client eliminates the traditional need to embed client-side service processing (filtering or aggregating large amounts of data to minimize what gets sent over the wire, for example) and network communications code into the client. Put another way, mobile Java code enables you to create distributed network services that encapsulate all of the client-side, server-side, and network communications code needed to implement the complete service functionality.

Figure 5: Jini Clients and Services

If you’re a service developer, this means that you control all the code that is part of your service’s implementation – not just that part of the service that runs on the remote server machine. For example, when you write a Jini service, you can write code that will validate the input to your service, and you can choose to have that part of your service code delivered to the client machine and execute there. You can also decide, without agreement from any (let alone all) of the clients that will use your service, which wire protocol (or protocols) you will use to communicate across the network, between the client-side and server-side parts of your distributed Jini service. What’s more, at any time, you can change any aspect of your Jini service code, including network communications and client-side processing features, without mandating any changes to clients.

If you’re developing a Jini client, you do not need to worry about embedding service-specific code for any (let alone all) of the services that you may want to use into your client. Nor do you need to know anything about how to communicate across the wire to each of the services you might want to use. Any Jini service code that needs to run on your client’s machine will be delivered to you at runtime, and you will be able to use all Jini services, regardless of how they implemented client-side processing or network-usage features, automatically and without having to recode and redeploy your client.

Figure 6: Dynamic Networking with Jini Technology ? 3

Dynamic service delivery is a key enabler of Java Dynamic Networking with Jini technology. It carries the ideal of object-oriented programming to the network by enabling truly distributed services that can evolve completely independently of the clients that will use them. When you couple this together with dynamic system assembly in your Jini technology system, you will realize a higher degree of adaptivity than most other distributed systems support today.

Part 2 Preview
That’s a wrap for Part 1 of this introduction to Jini technology. While the ability to dynamically and flexibly assemble systems at runtime, which was covered here, is important to dynamic networking, the need to coordinate the interactions of these distributed components after they have been connected is equally important. Part 2 will explore how Jini technology addresses these needs, including its support of distributed shared memory, distributed garbage collection, asynchronous messaging, distributed events and transactions, and distributed systems security. It also will look at some of the prime use cases in which Jini technology is being applied today.

If you’d like to learn more about Jini technology in the mean time, please check out the Jini Community Web site or Sun’s Jini technology Web site.