Sponsored Link •
If lock management is a key aspect of a transaction-participant Jini service, and if it is so difficult, you might ask, "Why doesn't Jini aim to automate this chore?" This area is open for discussion in the Jini community; I encourage you to contribute to this ongoing debate.
In my opinion, the reason why Jini doesn't provide an infrastructure for container-managed transactions, or some other automated way of ensuring transaction semantics, cuts directly to the heart of how Jini differs from application servers and other Java distributed enterprise technologies. While TP monitors and app servers provide particular services on the network, Jini itself is an infrastructure that ties all such services together reliably and preserves their dependable interaction even in the face of constant network change.
By divorcing services from servers, Jini places the network at the center of a distributed system. In a Jini federation, the network provides particular services -- not individual nodes, or specific software components. Shifting a system's design center to the network lends a Jini system enormous scalability and resilience in the presence of partial failures and network change. However, programmers must realize that no container can hold the network as such.
Further, a Jini federation does not assume the continuous presence of any centralized controlling entity on which any Jini service can depend. This is true even for lookup services: Jini does not assume the continuous presence of a particular lookup service in a federation; instead, it mandates that services continuously discover lookup services, and register with those that advertise appropriate lookup groups.
For transactions, not assuming a continuously present controlling entity implies that ensuring transaction semantics remains each service's responsibility. In other words, Jini does not hide a service's transactional nature -- it makes that explicit on the network, and delegates implementation to the service. This is analogous to the way Jini doesn't hide the possibility of partial network failures; it declares that possibility explicitly (for example, in terms of leases and remote exceptions), and leaves it up to each service to handle partial failure conditions. Finally, a similarity exists also in Jini's making concurrency on the network explicit: Jini services are accessed concurrently, and every implementation must explicitly address concurrency needs.
Transactions, partial failure, and concurrency are characteristics of any networked environment. While papering over these network features might make programming initially easier, it also can reduce a system's stability in the long run.
The reason has as much to do with philosophy as with software systems. As the English philosopher Francis Bacon said, "Nature to be commanded must be obeyed." In other words, we must recognize that things have particular, identifiable characteristics, and that those characteristics determine how things interact with their environment. If we are to command something to our benefit, we can only do so if we obey and respect its characteristics. But to do that, we must first make those characteristics explicit, and then base our interaction with the thing on those characteristics. In essence, Jini's design philosophy could be summarized with a paraphrase of Bacon's dictum: "A network to be commanded must be obeyed."
"Survival of the Fittest Jini Services, Part I" by Frank Sommers was originally published by JavaWorld (www.javaworld.com), copyright IDG,
October 2001. Reprinted with permission.