EETimes

Embedded Systems November 2000 Vol13_12

Issue link: http://dc.ee.ubm-us.com/i/71849

Contents of this Issue

Navigation

Page 145 of 189

• Access transparency masks out differ- ences in data representation and the invocation mechanism used to access a service (as in the case of CORBA) • Failure transparency hides the fai lure and recovery of fai led objects from clients through some form of mask- ing redundancy • Location transparency masks out the information about the specific loca- tion of some function or service (for example, whether it is local or remote) • Relocation transparency allows an object to be moved to a different location without disturbing the clients of that object • Replication transparency masks out the fact that a server may be redun- dantly implemented (for perfor- mance or availabili ty) • Transaction transparency hides from clients the complex mecha- n isms and activities required to ensure consistency in a distrib- uted environment. Summary There is a common misconception among software practitioners that, with the introduction of the remote proce- dure call concept, programming of dis- tributed applications becomes pretty much equivalent to more traditional centralized programming. In this arti- cle, we demonstrated that thjs is not the case. Distributed systems introduce a whole new class of phenomena that must be accounted for in program design and implementation. They can be traced ultimately to the physical world: processors fail, communications facilities are unreliable and finite, and so on. The net result is a major increase in the degree of programming difficulty. We covered some of the basic dis- tributed agreeme nt protocols, com- monly encountered in practice, including tl1e Byzantine Generals pro- tocol, distributed mutual exclusion, and distributed election. These all serve to further illustrate the complex- ity associated with d istribution. As pragmatic ways of realizing tl1ese types of systems, we discussed some basic implementation techniques such as reliable broadcasts, distributed system groups, and centralized arbiter . Finally, we described CORBA as an example of the kjnd of off-the-shelf technologies that are avai lable to mod- ern-day distributed systems designers. Such technologies and related tools can greatly reduce the complexity of distributed system development. esp Bran Selic is principal engineer at Rational Software in Kanata, Ontario, Canada. He has been involved with the development of distributed and fault-toler- ant real-time systems for many years and has written a textbook on the subject. Bran is a member of the original team that defin ed the industry-standard Unified Modeling Language and has recently been working on defining a real-time refinement of this standard. He is also an adjunct pro- f essor at Carleton University in Ottawa. You can reach him at bselic@rational. com. Endnotes 1. One such reason may be that the soft- ware is intended to be physically distrib- uted in some future release. 2. This conceptual model is based on the widely adopted work of Randell et al. [13] 3. The case for synchronous media is somewhat different since we can take advantage of the fact that the transmis- sion time of the messages is constant. 4. The name "Byzantine generals" comes from the analogy of a cabal of generals in Byzantium. in which it is known that some of the generals are likely to be traitors to the common cause, but it is not known which ones. 5. There are also variants of the algorithm that do not require a coordinator. 6. The question of how such timestamps are defined is an entire issue unto itself that we will omit in this short overview. References [1] Burns, A., and A. Wellings. Real-Time Systems and Programming Languages (2nd ed.). Reading, MA: Addison- 144 NOVEMBER 2000 Embedded Systems Programming Wesley, 1997. [2) Fischer, M., N. Lynch, and M. Paterson, "Impossibility of Distributed Consensus with One Faulty Process," Journal of the ACM, April 1985, p. 374. [3) Garcia-Molina, H., "Elections in a Distributed Computing System," IEEE Trans. on Computers, January 1982, p. 48. [4] Goyer, P .. P. Momtahan, and B. Selic, "A Synchronization Service for Locally Distributed Applications," Distributed Processing. North Holland, 1988, p. 3. [5) Goyer, P., P. Momtahan, and B. Selic, "A Fault-Tolerant Strategy for Hierarchical Control in Distributed Computer Systems,'' Proc. 20th IEEE Symp. on Fault- Tolerant Computing Systems (FTCS20), IEEE CS Press, 1990. [6) Hadzilacos, V. and S. Toueg, "Fault- Tolerant Broadcasts and Related Problems," Chapter 5 in S. Mullender (ed.), Distributed Systems (2nd ed.), Reading, MA: Addison-Wesley, 1993, p. 97. [7] Halpern, J. andY. Moses, "Knowledge and Common Knowledge in a Distributed Environment." Proc. of the 3rd ACM Symposium on Principles of Distributed Systems. 1984, pp.50-61. [8] International Standards Organization (ISO), Reference Model of Open Distributed Processing (RM-ODP), Part 1: Overview, ISO/IEC 10746-1, May 1995. (also ITU-T standard X.901). [9] Lamport, L., R. Shostak, and M. Pease, "The Byzantine Generals Problem," ACM Transactions on Programming Languages and Systems. Vol.4, No. 3, July 1982, pp. 382-401. [10] Naiditch. D. Rendezvous with Ada 95, (2nd ed.), New York: John Wiley & Sons, 1995. [11] Object Management Group. The Common Object Request Broker: Architecture and Specification, Revision 2.2, February 1998. [12] Pountain, D. and D. May. A Tutorial Introduction to occam Programming. New York: McGraw-Hill, 1987. [13] Randell, B., P. Lee. and P. Treleaven, "Reliability in Computing System Design," ACM Computing Surveys, Vol. 10, No.2, June 1978, pp. 123-165.

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems November 2000 Vol13_12