Sponsored Link •
Developers should distinguish between the systems themselves and the computations they wish to perform on them. While a distributed system, or parts of it, might fail occasionally, computations performed on those systems can still be highly dependable. This shows how multiple Jini services can dependably cooperate via transactions.
Failure, according to Merriam-Webster's Dictionary, is a state in which something is "unable to perform a normal function." Inasmuch as a network's normal function is to transmit information between two or more hosts, experience shows that most networks often cannot perform that function as expected. In other words, failure is as much a characteristic of the network as is its normal operation.
Read the whole "Survival of the Fittest Jini Services" series:
In many aspects of life, we have learned to live in the presence of failure. In a large city, many new shops spring up all the time, while others close their doors for good. Unless you are a shop owner, you are not likely to lose sleep over that fact. Instead, you are interested in being able to obtain the goods you are looking to buy, at a reasonable price and in close proximity.
Taking a similar approach to building Jini-based distributed systems might be helpful. We cannot make a large network, such as the Internet, more reliable. But we can make the computations we wish to perform over that network as reliable as possible. Your users -- whether people or other Jini services -- are primarily interested in the computations your service provides. Ensuring the reliability of those computations in the presence of network and component failures will likely lead to your service's longevity.
By reliability I mean a set of guarantees that hold, no matter what. In other words, as long as the computation produces a result, that result should keep with a set of guarantees. If the computation cannot ensure those guarantees, then it should abort and not return a result.
We are all familiar with this notion of reliability: When people wish to accomplish a goal together, they typically agree to a verbal or written contract, which thereafter binds each party to its terms. Thenceforth, the participants perform all their actions related to the common task in accord with those promises. And, should the parties fail to keep their promises, all actions under contract will produce "unreliable" and unpleasant results.
The equivalent of such "rules of the game" between components of software-based distributed systems is the transaction: components participating in a computation agree to a set of rules, and each component thereafter adheres to those rules during the computation.
In distributed systems, such as Jini networks, components typically reside on distant network hosts. This is significant, because it means that no component can, by itself, ascertain whether the other components adhere to the rules. A component can only implement the rules and then communicate to the others that it, indeed, keeps with those rules.
Distributed transactions, therefore, are made up of the rules (semantics) by which the services must abide, and a coordination mechanism between the services that ensures that the rules hold for the whole computation. If even one service indicates that it cannot guarantee its promise, that mechanism will abort the transaction.