Java Dynamic Networking with Jini Technology, Part 2

art 1 of this series began an introduction to Jini? technology, an open software architecture that enables Java? dynamic networking, which developers can use to create highly adaptive distributed systems. It briefly described the approach that Jini technology takes to tracking, selecting, and assembling services into a running system. Part 2 concludes the introduction with an overview of the various mechanisms that Jini technology provides to support distributed component interactions. It also identifies some common dynamic networking problems to which Jini technology is typically applied today.

Distributed Component Interactions
As any application developer knows, much of the work when coding a system involves coordinating the interactions of various system components and the flow of work through the system. This leaves developers to contend with a number of considerations: Will an event over here trigger a reaction over there? Or should component A make a proactive request for component B to perform some work? Should A wait for a response, or would it be better to communicate asynchronously? How should a transaction be structured so that multiple related operations either complete or fail in a consistent way? A sound distributed application architecture should provide support for such distributed component interactions?and Jini technology does.

Jini technology defines distributed transaction and event models for you, and also provides mechanisms that you can use to manage workflows, messaging, and shared memory needs in dynamic, distributed environments. Jini technology’s component interaction models, as well as its service tracking, selection, and dynamic system assembly approaches, are designed around the fundamental notion that they will be used in dynamic, distributed environments. This means that they are designed to help you accommodate network inconsistencies that may manifest as partial failures or variable communications latencies, for example. Their design also follows suit with the technology’s minimalist philosophy?that is, the interaction models are generally specified as the smallest set of agreements needed to achieve a goal, enabling you to augment them with additional capabilities to best meet your application needs.

Jini Technology’s Distributed Leasing Model
One of the most important differences between distributed and non-distributed systems is in the way that failures happen in them. In non-distributed systems, failures affect all system components simultaneously, and recovery of all components is also simultaneous?the system is either wholly running or completely failed. In distributed systems, the most common failure scenario is one in which some, but not all, system components cannot be accessed. This partial failure can be the result of a host machine failure, a network partition, a software failure, or simple neglect (say, for example, one component decides to cease responding to another component).

Jini technology introduced the concept of distributed leasing to help you address the resource management issues that partial failures present. Fundamentally, the leasing model enables distributed components to explicitly limit the duration of their agreed cooperation. This removes any possible ambiguity about when such agreements are terminated and thereby allows components to safely reclaim resources that had been associated with them.

How Leasing Works
Distributed leasing provides the mechanisms needed for two components to agree on an amount of time through which one will allocate resources on behalf of the other. For example, suppose you’ve written a Jini technology service. When your Jini technology service registers with a lookup service, a lease is used to establish an agreement about how long the lookup service will maintain a directory entry on behalf of your service. The resources being leased are those that the lookup service uses to maintain the service registration in its service directory. Since the resources belong to the lookup service, it grants the lease to your registering service.

The lease grantor establishes the duration of a lease, but it can be based on input that the lease requestor supplies. This means that the duration of each agreement can be specified independently, so you can tailor them individually to best meet the needs of each resource-leasing situation.

Leases can then be renewed, they can be canceled, or they can expire. The responsibility for initiating a lease renewal request belongs to the original lease requestor. In your example, if your service would like the lookup service to continue listing your service’s availability, it must request that the lookup service renew its service registration lease before the time specified, as its original lease duration has passed.

A lease requestor can also cancel a lease at any time, thereby terminating the agreements represented in it. If a lease is neither renewed nor canceled before its specified duration time elapses, the lease automatically expires. In this case, as with a canceled lease, the lease grantor and lease requestor are both freed from obligations associated with the lease. In your example, if your service’s registration lease terminates, either by being canceled or by expiring, the lookup service is no longer obligated to maintain a registration entry on behalf of your service. Both parties understand that, in this situation, the lookup service will release your service’s registration and reclaim the resources that had been used to maintain it.

The Jini technology distributed leasing model operates effectively in partial failure scenarios. Partial failures simply result in lease expirations, which are managed according to well-understood lease terms. And, since lease grantors and the lease requestors both understand the terms of the lease, both are independently able to recognize and respond appropriately to a failure. Imagine the case of a network partition, where components that cannot communicate with one another are nonetheless both independently operational. The lease grantor and leaseholder both understand exactly when the agreement they share becomes void, and when both are free from their lease obligations. The expired lease also makes clear to both parties that, once the network is restored, the lease will need to be re-established.

The distributed leasing concept is usefully applied wherever one distributed component allocates and uses resources on behalf of another. Jini technology widely leverages it. For example, lookup services lease registration entries to other services; event generators lease event registrations to clients that want to receive event notifications; and transaction managers lease transaction-processing resources to transaction initiators.

Jini Technology’s Distributed Transaction Model
The Jini technology distributed transaction model is designed to enable the coordination of multiple distributed operations, such that they all succeed or they all fail. Using the model, transaction participants coordinate their efforts through a transaction manager, which is responsible for managing the two-phase commit protocol across transaction participants.

To begin a transaction, a transaction initiator requests the transaction manager to create a new transaction. The transaction manager leases the resources it uses on behalf of the transaction to the initiator, which is responsible for keeping the transaction alive (by renewing the lease) until the work of all transaction participants has been initiated.

The transaction manager provides the initiator with a transaction object, through which transaction participants can interact with the transaction manager. This object is then passed to each participant as part of the transaction initiator’s request that the participant do work under the transaction. Participants first use the transaction object to register themselves with the transaction manager as participants in a particular transaction, and then they perform their transaction work.

Once the initiator has contacted all transaction participants, it uses the transaction object to tell the transaction manager the transaction is ready to be committed. The transaction manager then collects readiness votes from all participants that have registered with the transaction, issues commit or rollback instructions to them as appropriate, and notifies the initiator of the transaction’s successful completion or its failure.

In this transaction-processing model, voting cannot take place, and hence the transaction cannot complete, before the initiator tells the transaction manager that all participants have been successfully engaged. This is why transactions are leased: if the initiator fails before contacting all participants, the transaction’s lease will also expire before the transaction manager has been asked to complete the transaction. The expired lease signals the transaction manager to abort the open transaction.

Because lease durations can vary, and because input from the transaction initiator can be used to establish the duration of a transaction’s lease, you may improve the efficiency of transaction failure detection by using leasing. This is especially true if the time generally needed to complete transactions varies greatly from one kind of transaction to another. For example, you can detect failures more rapidly by using shorter lease durations for transactions that generally require less time to complete and longer lease durations to process transactions that generally take longer to complete, reducing the number of renewals that you need to keep them alive.

Jini Technology’s Distributed Event Model
The Jini technology distributed event model allows one distributed component to register interest in and receive notifications of events generated by another component. Again, the basic model is straightforward yet powerful, and specifically designed to operate well in dynamic, distributed environments.

In its simplest form, an object that wants to be notified of an event’s occurrence registers its interest in the event with the event generator, using some interface that the generator exposes to allow such registration. The event notification registration is leased, which means that the event generator will maintain the notification registration on behalf of the notification receiver and send event notifications to the receiver for as long as the receiver continues to renew the lease. If a partial failure prevents the event receiver from being able to renew the lease, the event generator will remove the event notification registration and discontinue notifications.

The Jini technology distributed event model also allows an object to specify that event notifications be sent to a third party, rather than directly back to the object that registered interest in the event. This powerful feature enables you to process event notifications in any number of ways that may best meet the needs of the object that is (or objects that are) ultimately interested in the events. For example, an object might request that event notifications for multiple events be sent to a filter, so that the filter will pass through notifications only when a complete series of events has transpired. Alternatively, events might be held for batch retrieval.

The Jini technology distributed event model also acknowledges that properly ordering the sequence of remote events can be a challenge in distributed computing. The basic problem is that, given the unpredictable and inconsistent network latencies that characterize distributed computing environments, notification of an event that was actually generated before another event may nonetheless arrive after notification of the later event. Precise synchronization of all clocks in a distributed system generally is not possible. So time stamping cannot necessarily resolve this problem.

Furthermore, this ordering problem is compounded if the events were not generated by the same source. This situation proves logically impossible to resolve (or so they tell me, without breaking the space-time continuum in some strange way that would enable time to be viewed identically from all frames of reference. Wow, let’s not go there!). The problem of tracking the sequence of events generated by a single source is tractable however, and the Jini technology distributed event model resolves it simply by enabling the attachment of sequence numbers to events.

Distribution also introduces the problem of unreliable event delivery: it is impossible to guarantee that a network will not fail and, therefore, impossible to guarantee that event notifications will be reliably received. That said, an event generator can implement any number of re-try strategies to make a best effort to deliver event notifications. You can implement these strategies within objects that use the Jini technology distributed event model, but they are not explicitly defined as part of the model.

The JavaSpaces Service
The JavaSpaces service enables distributed components to store and/or exchange objects across a network. Many consider it one of Jini technology’s most intriguing and useful innovations. The JavaSpaces service is well employed to meet a wide range of distributed computing needs, including distributed shared memory, communications buffering, workflow processing, asynchronous messaging, message switching, and more.

The JavaSpaces service derives its power from the following three key features:

  1. The simplicity of its interface
  2. Its ability to hold and pass objects, rather than just data
  3. The anonymity is gives to clients that interact across it

The synergistic value of this feature combination is uncommon, and it is what makes the JavaSpaces service so extraordinary.

Most developers find the JavaSpaces service interface simple and easy to use. In fact, you can coordinate highly sophisticated interactions through a JavaSpaces service using only four basic methods: read, write, take, and notify. Clients use the write method to put entries into a “space.” They use the read method to examine entries in a space, and the take method to remove entries from a space. When performing a read or take operation, a JavaSpaces service returns entries that match a template that the client provides as part of the read or take method call. Using these methods, distributed components can use the JavaSpaces service as an intermediary through which they conduct asynchronous communications, or simply as a distributed shared memory store.

The fourth commonly used method, notify, further enhances the JavaSpaces interaction paradigm. Clients use it to instruct a JavaSpaces service to inform them whenever an entry that matches a template (that the client provided) is written into the space. This method is often used to facilitate the processing of workflows through a JavaSpaces service: whenever a particular kind of entry is placed into a space, a client that can process that entry is notified. That client takes the entry, works on it, and writes a new entry back into the space. The arrival of the new entry in the space triggers notification to a different client, which in turn takes the entry from the space, and the workflow continues.

The JavaSpaces service also supports the Jini technology transaction model, enabling entries to be read, written, or taken under a transaction. While a transaction is being processed, the work performed under the transaction is visible only to transaction participants. Any entries that have been taken under the transaction will still be visible outside of the transaction (but will be read accessible only) for the transaction’s duration. Once the transaction commits, the final results are made visible to all JavaSpaces clients. If a transaction is aborted, the JavaSpaces service rolls back all work performed under the transaction.

The JavaSpaces service is additionally powerful because it enables objects, rather than just data, to be exchanged through it. Leveraging this capability, you can use a JavaSpaces service to help distribute and run executable code across a network. One common pattern for doing this employs generic “workers” that are designed specifically to take executable entries from a space and run them. Using this model yields the added benefit of automatic load balancing: rather than having work pushed to them from a centralized load balancer, workers in this model each regulates its own load independently by taking entries at its own pace when it is ready to process them.

Finally, JavaSpaces clients can exchange objects through a space anonymously. Clients that write entries into a space need not know anything about clients that will later read or take those entries from the space, nor vice versa. This makes it quite easy for you to change the participants in an exchange. It even makes it possible to change the number of participants engaged in a distributed interaction, and is commonly leveraged to facilitate dynamic scaling.

Jini Technology’s Security Model
Although the subjects of distributed systems security and Jini technology’s treatment of it are beyond the scope of this introductory article, it is essential to recognize the importance of security in distributed systems, and to acknowledge the value that the Jini technology security model provides. Distributed systems must have the capability to secure remote communications, so that their privacy and integrity can be assured, and the capability to control programmatic access to resources or other assets. Programs (not just people) within the systems also must be able to authenticate their identities to one another. The Jini technology security model extends the Java platform security model to enable secure distributed interactions between Jini technology clients and services. It enables you to build authentication, authorization, integrity, and confidentiality into interactions between software components that communicate using remote calls over a network. It also provides support for verifying that downloaded code?so critical to Jini technology?can be trusted.

Jini Technology in the Real World Today
With this brief introduction to Jini technology as a foundation, you may better understand what it can do from a technical perspective. To translate that into real world value, however, consider a few of the common use case scenarios in which Jini technology is being successfully deployed today. Each of the following types of distributed systems is characterized by its need for adaptivity?a need that Java dynamic networking with Jini technology is serving:

  • Edge Networking
    Distributed systems deployed beyond the data center differ from their data center-focused counterparts in that they are subject to a wider range of failure modes and they are not readily accessible to a systems administrator. These systems must be able to automatically recover from failure at the network edge, and they must be easy to update and manage without manual administration. Jini technology is being used today to enable the creation of self-healing edge-networking systems, and to allow new or updated services to be introduced into these systems without the need for an administrator to restart the system.
  • Compute grids
    Jini technology is being used today as the underlying infrastructure supporting compute grid applications in financial services, defense, logistics planning, life sciences, image processing, scientific research, manufacturing, and other domains. Jini technology-based grids automatically accommodate the runtime addition, removal, or loss of compute resources, which means that these grids can scale dynamically to accommodate changing loads, and they keep running even though most grid networks operate in a near constant state of partial failure.
  • Dynamic systems integration
    Jini technology is today supporting many companies’ needs to keep their systems up and running while dynamically integrating in-house or third party services whenever they are available. The technology is helping these users deal with service failures, updates, and implementation details that are beyond their control, often stemming from their need to integrate services from external sources. Also, by isolating clients from the need to implement any of the multiple proprietary communications protocols that many different service providers use, Jini technology is simplifying these users’ approach to integrating third-party services.
  • Dynamic clustering
    Whether they are used to increase availability or scalability, clusters created with Jini technology are successfully accommodating the run time addition, loss, or removal of clustered services for many users today. These Jini technology-based clusters scale out readily with the simple addition of service instances to be clustered, and they scale down just as easily by removing unneeded service instances. The location, name, or provider or any service to be clustered can be changed without the need to bring these clusters down.
  • Workflow/message switching
    Jini technology, especially the JavaSpaces service, provides a simple way to share objects across a dynamic network. Telecommunications, financial services, and other applications are exploiting the technology’s support for loosely coupled interactions and its ability to transfer data (and/or code) through the system.
  • Ad-hoc networking
    Jini technology is being used to enable the spontaneous bootstrapping of networks of services that come together in an ad-hoc fashion. Current deployments are using this capability to power solutions in a range of new ad-hoc networking markets, including home networking, telematics systems, and sensor networks, to name a few.
  • Dynamic service provisioning
    The ability to flexibly provision networks to offer specific configurations of services that may be re-provisioned to accommodate changing needs over time is what underlies the move to utility computing today. Developers have leveraged Jini technology’s support for dynamic service discovery and delivery, as well as its straightforward service substitution capabilities, to create such dynamic service provisioning infrastructures.

That Concludes the Tour
I hope you’ve enjoyed this whirlwind tour of Jini technology. Hopefully, this intro provided you with enough information to determine whether or not Jini technology is worth a deeper look. Certainly, if you have hit a wall in your ability to deal with change in your distributed systems, you should invest more time into learning about it.

If you decide that you’d like to learn more about Jini technology, make your first stop the Jini Community(SM) Web site. As an active participant or a quiet observer in the Community, you are welcome to join other individuals, companies, and organizations who collaborate through Jini technology-focused development projects, discussion lists, and events. Hope to meet you there soon!

Share the Post:
Share on facebook
Share on twitter
Share on linkedin


The Latest

homes in the real estate industry

Exploring the Latest Tech Trends Impacting the Real Estate Industry

The real estate industry is changing thanks to the newest technological advancements. These new developments — from blockchain and AI to virtual reality and 3D printing — are poised to change how we buy and sell homes. Real estate brokers, buyers, sellers, wholesale real estate professionals, fix and flippers, and beyond may

man on floor with data

DevX Quick Guide to Data Ingestion

One of the biggest trends of the 21st century is the massive surge in internet usage. With major innovations such as smart technology, social media, and online shopping sites, the internet has become an essential part of everyday life for a large portion of the population. Due to this internet

payment via phone

7 Ways Technology Has Changed Traditional Payments

In today’s digital world, technology has changed how we make payments. From contactless cards to mobile wallets, it’s now easier to pay for goods and services without carrying cash or using a checkbook. This article will look at seven of the most significant ways technology has transformed traditional payment methods.