Jini Services

To help simplify the process of developing clients and services for the Jini environment, several helper services have been defined. The Jini specifications define two categories of helper entities: helper utilities and helper services. These utilities and services provide a basis for building applications that demonstrate desirable behavior in a Jini community.

Helper utilities are programming components that aid in the construction of Jini services and clients. They help to reduce the coding effort required. They are not services that register with a lookup service, but rather aid in the process of being a good Jini citizen. Helper utilities include the following:

• LookupDiscovery

• LeaseRenewalManager

• JoinManager

• ServiceDiscoveryManager

A helper service, on the other hand, is a Jini service. Helper services register with lookup services and can be invoked on remote hosts. A helper service consists of an interface or set of interfaces and an associated implementation encapsulating behavior that is either required or highly desirable in services that adhere to the Jini technology programming model. Helper services include the following:

• Lookup Discovery Service

• Lease Renewal Service

• Event Mailbox Service

Lookup Discovery Service

The Lookup Discovery Service (LDS) is a helper service that uses the Jini discovery protocols to find LUSs in which an entity (a client or service) has expressed interest, and to notify the entity when a previously unavailable LUS becomes available. An activatable service that deactivates might want to use the LDS to perform discovery duties on its behalf.

Lease Renewal Service

The Jini framework supports the notion of leasing. In a Jini environment, resources like service references are not simply created and deleted. They must be managed and maintained. You must periodically inform the service that has granted you access to a resource that you are still using that resource and want to continue using that resource. If you fail to renew the lease on a leased resource, the Jini framework or specific service instance will release the resource from your control. The Lease Renewal Service (LRS) is a helper service that can be employed by both Jini clients and services to perform all lease renewal duties on their behalf.

Event Mailbox Service

The Event Mailbox Service (EMS) is a helper service that can be used by entities to store event notifications on their behalf. This permits a service to deactivate and not miss events of interest while deactivated. The service in effect has more control over when and where events are delivered. Services register with the event mailbox service using the MailboxRegistration interface. The using entity retrieves a RemoteEventListener object from the EMS and uses this reference in any method call that requires a remote listener. The using entity can then disconnect from the network and not worry about losing events. The events will be directed and stored by the mailbox listener. The using entity can then activate at some point and request delivery of the stored events. You might think of this as implementing store-and-forward semantics for distributed event processing.

The general theme in the usage patterns mentioned previously is support for disconnected entities, and entities or environments where computational conservation is of paramount importance.

Enabling P2P Transactions

As P2P gains popularity in commercial applications, support for transactions will become critical. Jini defines a two-phase, commit-based interface to support the notion of distributed transactions.

The Transaction Service

Jini uses the traditional two-phase commit transaction protocol. Transaction monitors specialize in managing transactions from clients across one or more servers. When a transaction ends, the TP monitor ensures that all systems involved in the transaction are left in a consistent state. The classic example of the bank credit transaction followed by the bank debit transaction is often cited to demonstrate the need for transactional integrity.

Transaction monitors are able to cross system boundaries to manage the transaction process. This includes starting server processes, routing and monitoring their execution, and balancing their workloads. In addition, TP monitors are used to guarantee the ACID properties to all programs that run under its control:

• Atomicity All the operations grouped under a transaction occur or none of them do.

• Consistency The completion of a transaction must leave the system in a consistent state. If the transaction cannot achieve stable end-state, it must return the system to its initial state.

• Isolation Transactions should not be affected by other transactions that execute concurrently. Participants in a transaction should see only intermediate states resulting from the operations of their own transaction, not the intermediate states of other transactions.

• Durability The results of a transaction should be as persistent as the entity on which the transaction commits.

TP monitors often use thread pools to assign work to available threads that act as a mechanism to balance and control the load on any one-server process. The TP monitor is able to funnel work to shared server processes and act as a gatekeeper for the OS. This load-balancing function is a primary benefit to systems that must scale to support high transaction volumes. TP monitors are able to establish priorities for tasks, and thus prioritize transactions within the system.

Fundamentally, the TP monitor assures the ACID properties while enabling high throughput. This alleviates much of the work application programmers would normally have to be concerned with, such as network failures, concurrency, load balancing, and the synchronization of resources across multiple nodes.

Implementers of the Jini transaction service are free to develop various levels of transactional assurance. In other words, the degree to which a Jini transaction service ensures the ACID properties of transactions is implementation-dependent. Some implementations might go to great lengths to ensure recovery from failures, whereas others might simply rollback transactions in light of any failure, and attempt to optimize other aspects of distribution such as performance, or minimize the resources required to support distributed transactions. Jini provides a lightweight reference implementation of the transaction service named mahalo.

Enabling P2P Communication (JavaSpaces)

One of the most important services for Jini-P2P is the JavaSpaces service.

JavaSpaces is a Jini service that supports distributed persistence and the design of distributed algorithms. JavaSpaces is closely tied to the Jini architecture. JavaSpaces was heavily influenced by the concept of the tuple space, first described in 1982 in a programming language called Linda that was developed at Yale University. Linda was designed as a coordination language for ensemble (distributed and parallel) computing. Like Linda, JavaSpaces is designed to significantly ease the development of distributed and parallel processing systems.

JavaSpaces, however, extends this model of communication by defining the data as objects. So, rather than simply passing data between processes, you are able to pass objects, and thus behavior. JavaSpaces uses RMI and object serialization from the Java programming language to provide these features. In addition, JavaSpaces leverages the Jini infrastructure that includes distributed events, leasing, and lightweight transactions.

A JavaSpaces server is used to mediate the communications between networked systems. It provides much of the common functionality required for distributed systems, which simplifies the development task, particularly when you can model your task as a flow of objects between systems distributed over a network.

With JavaSpaces, distributed processes communicate by reading and writing entries into space. A space is defined by JavaSpaces as a shared, network-accessible repository for objects. This shared repository can save objects written to a space beyond the lifetime of the process that created them. Spaces provide reliable storage for objects and support leases. The JavaSpace API provides an event notification mechanism, which enables processes to register for notification when a specific object is written to space.

Objects in a space are located via associative lookup, as opposed to more traditional keys or identifiers. More is said about associative lookup when entries are discussed in the next chapter. When you read or take an object from a space, a local copy of the object is created. As with any other local object, you can modify its public fields and invoke its methods. In addition, JavaSpaces supports transactions for single operations, such as writing an object to a single space, as well as multiple operations over one or more spaces.

So, how does JavaSpaces differ from traditional message-oriented middleware or traditional database technology?

Message Oriented Middleware (MOM)

MOM permits general message exchange using message queues. MOM has become a popular approach to integrating inter- and intra-enterprise applications. The message queuing facility enables clients and servers to communicate indirectly, which provides several advantages:

• Applications are provided a higher level of abstraction when dealing with network communication. Destinations, or queues, can have logical names and be built up hierarchically.

• Clients and servers do not have to be running at the same time to carry on a conversation. Messaging products can therefore help support the disconnected client.

• Traffic can be distributed or the load balanced across multiple queues and multiple systems. This provides a scalable solution to high-throughput requirements.

• Messaging queues are versatile. They enable you to define communication models that support one-to-one or one-to-many patterns of message transfer.

• MOM products offer various levels of message assurance, from best effort to guaranteed delivery. This is provided through persistent queues that are capable of storing messages until acknowledged.

Messaging products should continue to gain in popularity because of their broad range of capabilities in application communication. However, these products are more prevalent within an enterprise rather than between enterprises because of the proprietary protocols that often need to be supported. Popular commercial products include IBM's MQSeries, Microsoft's MSMQ, and BEA's MessageQ.

JavaSpaces Versus MOM

Although JavaSpaces also provides loose coupling for distributed processes and MOM models of communication, there are a number of important differences:

• MOM supports messages; JavaSpaces supports objects. Most messaging products support the exchange of data. JavaSpaces supports the exchange of objects, and therefore active processes or behavior.

• MOM products often involve extensive administrative overhead. JavaSpaces are simple to set up and administer.

• Messaging products have proprietary interfaces, which means that two different messaging products might not be able to communicate without some gateway or bridging technology.

• JavaSpaces supports persistent messaging. A JavaSpaces message is an object in its own right, and can persist and manage its lifecycle independent of the originating process.

• JavaSpaces supports transactions and leases inherently. The concept of leases has no counterpart in MOM products.

SQL Middleware

Unfortunately, while SQL has been standardized for years, vendor extensions and variations still make access across products a challenge. Many middleware products exist to provide access to multiple databases and transform SQL calls to a native database server's access language.

Typically, SQL middleware must deal with vendor-proprietary APIs across Windows, Linux, Macintosh, and Unix clients. In conjunction with the API is a unique driver that handles runtime calls and formats SQL messages. The driver typically provides a proprietary transport exchange format with the server. Therefore, the format and protocols defined to access the database are vendor-defined.

Most vendors support multiple protocol stacks that might include a common transport interface, such as sockets or named pipes. Even providing a common SQL interface still requires management of multiple vendor drivers. In addition, although a common API exists, multiple formats and protocols are still supported under the covers. A number of solutions, such as ODBC and JDBC, have emerged, but often run into performance and scalability issues in high-access scenarios. Gateway protocol converters are often used, such as Remote Data Access (RDA), and IBM's Distributed Relational Data Access (DRDA).

JavaSpaces Versus Traditional Database Technology

JavaSpaces is not a database, although it does have database characteristics. For instance, the capability to persist objects would lead to comparing it to object database technology. However, you will find that the API to JavaSpaces is so simple that it could not possibly cover all the functions and features normally associated with databases.

The differences include the following:

• Objects are retrieved with templates, not a specifically designed query language such as SQL or OQL.

• No transparent access provided to objects: Rather than blurring the distinction between in-memory and storage access of objects, JavaSpaces works on serialized copies of entries.

• A general lack of database tools and utilities: JavaSpaces provides a simple API and defines a minimal and lightweight persistence engine.

JavaSpaces' strength lies in its capability to simplify the programming required to coordinate distributed communication and parallel processing.

Although comparisons to database technology and message-oriented middleware are valid, JavaSpaces still provides significant differences. These differences point to a new environment supporting networked-applications as the norm, rather than the exception.