Entries Tagged as 'Distributed'

Distributed object

Distributed objects are software modules that are designed to work together, but reside either in multiple computers connected via a network or in different processes inside the same computer. One object sends a message to another object in a remote machine or process to perform some task. The results are sent back to the calling object.

See also Internet protocol suite.


Local vs Distributed Objects

Local and distributed objects differ in many respects.<ref>W. Emmerich (2000) Engineering distributed objects, John Wiley & Sons Ltd.</ref> Here are some of them:

  1. Life cycle : Creation, migration and deletion of distributed objects is different from local objects
  2. Reference : Remote references to distributed objects are more complex than simple pointers to memory addresses
  3. Request Latency : A distributed object request is orders of magnitude slower than local method invocation
  4. Object Activation : Distributed objects may not always be available to serve an object request at any point in time
  5. Parallelism : Distributed objects may be executed in parallel.
  6. Communication : There are different communication primitives available for distributed objects requests
  7. Failure : Distributed objects have far more points of failure than typical local objects
  8. Security : Distribution makes them vulnerable to attack.


Examples

Distributed objects are implemented in Objective-C using the Cocoa API with the NSConnection class and supporting objects.

Distributed objects are used in Java RMI.

CORBA lets one build distributed mixed object systems.

DCOM is a framework for distributed objects on the Microsoft platform.

DDObjects is a framework for distributed objects using Borland Delphi.

JavaSpaces is a Sun specification for a distributed, shared memory (spaces based)

Pyro is a framework for distributed objects using the Python programming language.

dRuby is a framework for distributed objects using the Ruby programming language.


References

Tags: Uncategorized by admin
No Comments »

Distributed database management system

A distributed database management system is a software system that permits the management of a distributed database and makes the distribution transparent to the users. A distributed database is a collection of multiple, logically interrelated databases distributed over a computer network. Sometimes “distributed database system” is used to refer jointly to the distributed database and the distributed DBMS.


References

  • M. T. Özsu and P. Valduriez, Principles of Distributed Database Systems (2nd edition), Prentice-Hall, 1999. ISBN 0-13-659707-6.

Tags: Uncategorized by admin
No Comments »

Distributed transaction

A distributed transaction is an operations bundle, in which two or more network hosts are involved. Usually, hosts provide transactional resources, while the transaction manager is responsible for creating and managing a global transaction that encompasses all operations against such resources. Distributed transactions, as any other transactions, must have all four ACID properties, where atomicity guarantees all-or-nothing outcomes for the unit of work (operations bundle).

Open Group, a vendor consortium, proposed the X/Open Distributed Transaction Processing (DTP) Model, which became a de-facto standard for behavior of transaction model components.

Databases are common transactional resources and, often, transactions span a couple of such databases. In this case, a distributed transaction can be seen as a database transaction that must be synchronized (or provide ACID properties) among multiple participating databases which are distributed among different physical locations. The isolation property (the I of ACID) poses a special challenge for multi database transactions, since the (global) serializability property could be violated, even if each database provides it (see also global serializability). In practice most commercial database systems use strong strict two phase locking (SS2PL) for concurrency control, which ensures global serializability, if all the participating databases employ it. (see also commitment ordering for multidatabases.)

A common algorithm for ensuring correct completion of a distributed transaction is the two-phase commit. This algorithm is usually applied for updates able to commit in a short period of time, ranging from couple of milliseconds to couple of minutes.

There are also long-lived distributed transactions, for example a transaction to book a trip, which consists of booking a flight, a rental car and a hotel. Since booking the flight might take up to a day to get a confirmation, two-phase commit is not applicable here, it will lock the resources for this long. In this case more sophisticated techniques that involve multiple undo levels are used. The way you can undo the hotel booking by calling a desk and cancelling the reservation, a system can be designed to undo certain operations (unless they are irreversibly finished).

In practice, long-lived distributed transactions are implemented in systems based on Web Services. Usually these transactions utilize principles of Compensating Transactions, Optimism and Isolation Without Locking. X/Open standard does not cover long-lived DTP.

A couple of modern technologies, including Enterprise Java Beans (EJBs) and Microsoft Transaction Server (MTS) fully support distributed transaction standards.


References

Tags: Uncategorized by admin
No Comments »