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:
- Encapsulate all service-related code on the server machine
- 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.
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.