Lecture notes on Distributed Systems pdf

how does a distributed system enhance resource sharing and how to distributed file system and How distributed systems are used in organizations pdf free download
OliviaCutts Profile Pic
OliviaCutts,France,Teacher
Published Date:01-08-2017
Your Website URL(Optional)
Comment
Chapter 14 Distributed systems 14.1 Distributed system definition 14.6 Distributed algorithms 14.2 Overview of issues 14.7 Deadline scheduling in a 14.3 Language support distributed environment 14.4 Distributed programming Summary systems and environments Further reading 14.5 Reliability Exercises Over the last thirty years, the cost of microprocessors and communications technology has continually decreased in real terms. This has made distributed computer systems a viable alternative to uniprocessor and centralized systems in many embedded application areas. The potential advantages of distribution include: improved performance through the exploitation of parallelism, increased availability and reliability through the exploitation of redundancy, dispersion of computing power to the locations in which it is used, the facility for incremental growth through the addition or enhancement of processors and communications links. This chapter discusses some of the problems that are introduced when real-time systems are implemented on more than one processor. 14.1 Distributed system definition For the purposes of this chapter, a distributed computer system is defined to be a system of multiple autonomous processing elements cooperating in a common purpose or to achieve a common goal. This definition is wide enough to satisfy most intuitive notions, without descending to details of physical dispersion, means of communication, and so on. The definition excludes pipeline and array processors, whose elements are not autonomous; it also excludes those computer networks (for example, the Internet) 523524 DISTRIBUTED SYSTEMS Machine tools Manipulator Conveyor belt Processor element Processor element Processor element Manipulator Machine tools Local area network Processor Processor element element Main computer Conveyor belt Processor element Figure 14.1 A manufacturing distributed embedded system. 1 where nodes work to no common purpose . The majority of applications one might sensibly embed on multiprocessor architectures – for example command and control, banking (and other transaction-oriented commercial applications), and data acquisition – fall within the definition. A distributed manufacturing-based system is shown in Figure 14.1. Even modern aircraft designs (both civil and military) have embedded distributed systems. For example, Integrated Modular Avionics (AEEC, 1991) allows more than one processing modules to be interconnected via an ARINC 629 bus, as illustrated in Figure 14.2. It is useful to classify distributed systems as either tightly coupled, meaning that the processing elements, or nodes, have access to a common memory, and loosely 1 However, as communication technology continues to improve, more and more internet-working will fit this definition of a distributed system.ARINC 629 databus OVERVIEW OF ISSUES 525 Processing resource Sensor/ actuator Figure 14.2 A civil avionics distributed embedded system. coupled, meaning that they do not. The significance of this classification is that syn- chronization and communication in a tightly coupled system can be effected through techniques based on the use of shared variables, whereas in a loosely coupled system some form of message passing is ultimately required. It is possible for a loosely coupled system to contain nodes which are themselves tightly coupled systems. This chapter will use the term ‘distributed system’ to refer to loosely coupled architectures. Also, in general, full connectivity will be assumed between processors – issues associated with the routing of messages and so on will not be considered. For a full discussion on these topics, see Tanenbaum (1998). Furthermore, it will be assumed that each processor will have access to its own clock and that these clocks are loosely synchronized (that is, there is a bound by which they can differ). A separate classification can be based on the variety of processors in the sys- tem. A homogeneous system is one in which all processors are of the same type; a heterogeneous system contains processors of different types. Heterogeneous sys- tems pose problems of differing representations of program and data; these problems, while significant, are not considered here. This chapter assumes that all processors are homogeneous. 14.2 Overview of issues So far in this book, the phrase concurrent programming has been used to discuss com- munication, synchronization and reliability without getting too involved with how pro- cesses are implemented. However, some of the issues which arise when distributed applications are considered raise fundamental questions that go beyond mere imple- mentation details. The purpose of this chapter is to consider these issues and their526 DISTRIBUTED SYSTEMS implications for real-time applications. They are: Language support – The process of writing a distributed program is made much easier if the language and its programming environment support the partitioning, configuration, allocation and reconfiguration of the distributed application, along with location-independent access to remote resources. Reliability – The availability of multiple processors enables the application to become tolerant of processor failure – the application should be able to exploit this redundancy. Although the availability of multiple processors enables the ap- plication to become tolerant of processor failure, it also introduces the possibility of more faults occurring in the system which would not occur in a centralized single-processor system. These faults are associated with partial system failure and the application program must either be shielded from them, or be able to tolerate them. Distributed control algorithms – The presence of true parallelism in an appli- cation, physically distributed processors, and the possibility that processors and communication links may fail, means that many new algorithms are required for resource control. For example, it may be necessary to access files and data which are stored on other machines; furthermore, machine or network failure must not compromise the availability or consistency of those files or data. Also, as there is often no common time reference in a distributed system, each node having its own local notion of time, it is very difficult to obtain a consistent view of the overall system. This can cause problems when trying to provide mutual exclusion over distributed data. Deadline scheduling – In Chapter 13, the problems of scheduling processes to meet deadlines in a single processor system were discussed. When the processes are distributed, the optimal single processor algorithms are no longer optimal. New algorithms are needed. These issues are now discussed in turn. However, in one chapter it is difficult to do justice to all the new activities in these areas. 14.3 Language support The production of a distributed software system to execute on a distributed hardware system involves several steps which are not required when programs are produced for a single processor: Partitioning is the process of dividing the system into parts (units of distribution) suitable for placement onto the processing elements of the target system. Configuration takes place when the partitioned parts of the program are associ- ated with particular processing elements in the target system.LANGUAGE SUPPORT 527 Allocation covers the actual process of turning the configured system into a col- lection of executable modules and downloading these to the processing elements of the target system. Transparent execution is the execution of the distributed software so that remote resources can be accessed in a manner which is independent of their location. Reconfiguration is the dynamic change to the location of a software component or resource. Most languages which have been designed explicitly to address distributed program- ming will provide linguistic support for at least the partitioning stage of system devel- opment. For example, processes, objects, partitions, agents and guardians have all been proposed as units of distribution. All these constructs provide well-defined interfaces which allow them to encapsulate local resources and provide remote access. Some ap- proaches will allow configuration information to be included in the program source, whereas others will provide a separate configuration language. Allocation and reconfiguration, typically, require support from the programming support environment and operating system. It is, perhaps, in the area of transparent execution where most efforts have been made to achieve a level of standardization across the various approaches. The goal is to make communication between distributed processes as easy and reliable as possible. Unfortunately, in reality, communication often takes places between heterogeneous pro- cessors across an unreliable network, and in practice complex communication protocols are required (see Section 14.5). What is needed is to provide mechanisms whereby: Processes do not have to deal with the underlying form of messages. For example, they do not need to translate data into bit strings suitable for transmission or to break up the message into packets. All messages received by user processes can be assumed to be intact and in good condition. For example, if messages are broken into packets, the run-time system will only deliver them when all packets have arrived at the receiving node and can be properly reassembled. Furthermore, if the bits in a message have been scrambled, the message either is not delivered or is reconstructed before delivery; clearly some redundant information is required for error checking and correction. Messages received by a process are the kind that the process expects. The process does not need to perform run-time checks. Processes are not restricted to communication only in terms of a predefined built- in set of types. Instead, processes can communicate in terms of values of interest to the application. Ideally, if the application is defined using abstract data types, then values of these types can be communicated in messages. It is possible to identify three main de facto standards by which distributed programs can communicate with each other: by using an application programmers interface (API), such as sockets,tonetwork transport protocols528 DISTRIBUTED SYSTEMS Server Client 43 1 6 Network 5 Server Client stub 2 stub skeleton Figure 14.3 The relationship between client and server in an RPC. by using the remote procedure call (RPC) paradigm by using the distributed object paradigm. The issue of network protocols will be discussed in Section 14.5 and a Java in- terface for sockets will be briefly considered in Section 14.4.3. The remainder of this subsection will consider RPC and distributed objects including the Common Object Request Broker Architecture (CORBA). 14.3.1 Remote procedure call The overriding goal behind the remote procedure call paradigm is to make distributed communication as simply as possible. Typically, RPCs are used for communication be- tween programs written in the same language, for example, Ada or Java. A procedure (server) is identified as being one that can be called remotely. From the server speci- fication, it is possible to generate automatically two further procedures: a client stub and a server stub. The client stub is used in place of the server at the site on which the remote procedure call originates. The server stub is used on the same site as the server procedure. The purpose of these two procedures is to provide the link between the client and the server in a transparent way (and thereby meet all the requirements laid out in the previous section). Figure 14.3 illustrates the sequence of events in a RPC between a client and a server via the two stub procedures. The stubs are sometimes called middleware as they sit between the application and the operating system. The role of the client stub is to: identify the address of the server (stub) procedure;LANGUAGE SUPPORT 529 convert the parameters of the remote call into a block of bytes suitable for trans- mission across the network – this activity is often call parameter marshalling; send the request to execute the procedure to the server (stub); wait for the reply from the server (stub) and unmarshal the parameters or any exceptions propagated; return control to the client procedure along with the returned parameters, or raise an exception in the client procedure. The goal of the server stub is to: receive requests from client (stub) procedures; unmarshal the parameters; call the server; catch any exceptions that are raised by the server; marshal the return parameters (or exceptions) suitable for transmission across the network; send the reply to the client (stub). Where the client and server procedures are written in different languages or are on different machine architectures, the parameter marshalling and unmarshalling mech- anisms will convert the data into a machine- and language-independent format (see Section 14.4.4). 14.3.2 The Distributed Object Model The term distributed objects (or remote objects) has been used over the last few year in a variety of contexts. In its most general sense, the distributed object model allows: the dynamic creation of an object (in any language) on a remote machine; the identification of an object to be determined and held on any machine; the transparent invocation of a remote method in an object as if it were a local method and irrespective of the language in which the object is written; the transparent run-time dispatching of a method call across the network. Not all systems which support distributed objects provide mechanisms to support all this functionality. As will be shown in the following subsections: Ada supports the static allocation of objects, allows the identification of remote Ada objects, facilitates the transparent execution of remote methods, and supports dis- tributed run-time dispatching of method calls;530 DISTRIBUTED SYSTEMS Java allows the code of a Java object to be sent across the network and instances to be created remotely, the remote naming of a Java object, the transparent invocation of its methods, and distributed run-time dispatching; CORBA allows objects to be created in different languages on different machines, facilitates the transparent execution of remote methods, and supports distributed run-time dispatching of method calls. 14.4 Distributed programming systems and environments The number of distributed applications is vast, ranging from simple embedded control systems to large complex multi-language generic information processing platforms. It is beyond the scope of this book to discuss fully how these systems can be designed and implemented. However, four approaches will be considered: (1) occam2 – for simple embedded control systems (2) Ada – for more complex distributed real-time applications (3) Java – for single-language Internet-type applications (4) CORBA – for multi-language multi-platform applications 14.4.1 Occam2 Occam2 has been specifically designed so that programs can be executed in a distributed environment, that of a multi-transputer network. In general, occam2’s processes do not share variables so the unit of partitioning is the process itself. Configuration is achieved by thePLACED PAR construct. A program constructed as a top-levelPAR,suchas: PAR p1 p2 p3 p4 p5 can be distributed, for example as follows: PLACED PAR PROCESSOR 1 p1 PROCESSOR 2 PAR p2 p3 PROCESSOR 3 PAR p4 p5DISTRIBUTED PROGRAMMING SYSTEMS AND ENVIRONMENTS 531 P3 C2 C3 P2 P4 C1 C4 P1 C5 P5 Figure 14.4 Five occam2 processes connected by five channels. It is important to note that the transformation of the program from one that has a simple PAR to one that uses a PLACED PAR will not invalidate the program. However, oc- cam2 does allow variables to be read by more than one process on the same processor. Therefore, a transformation may not be possible if the programmer has used this facility. For the transputers, it is also necessary to associate each external channel with an appropriate transputer link. This is achieved by using the PLACE AT construct. For example, consider the above example with the following integer channels shown in Figure 14.4. The program for execution on a single transputer is: CHAN OF INT c1, c2, c3, c4, c5: PAR p1 p2 p3 p4 p5 If the program is configured to three transputers, as illustrated in Figure 14.5, the occam2 program becomes:532 DISTRIBUTED SYSTEMS Processor 1 Processor 2 L0 L0 L2 c1 c1 c2 p2 p3 p1 c3 c5 L1 L1 Processor 3 L2 c5 c4 c3 L0 p5 p4 Figure 14.5 Five occam2 processes configured for three transputers. CHAN OF INT c1, c3, c5: PLACED PAR PROCESSOR 1 PLACE c1 at 0: PLACE c5 at 1: p1 PROCESSOR 2 PLACE c1 at 2: PLACE c3 at 1: CHAN OF INT c2: PAR p2 p3 PROCESSOR 3 PLACE c3 at 0: PLACE c5 at 2: CHAN OF INT c4: PAR p4 p5 The ease with which occam2 programs can be configured for execution on a dis- tributed system is one of the main attractions of occam2. Allocation is not defined by the occam2 language nor are there any facilities for reconfiguration. Further, access to resources is not transparent.DISTRIBUTED PROGRAMMING SYSTEMS AND ENVIRONMENTS 533 Real-time perspective The occam2 support for real-time is limited. However, within these limitations, the distributed system model is consistent. 14.4.2 Ada 95 Ada defines a distributed system as an interconnection of one or more processing nodes (a system resource that has both computational and storage capabilities), and zero or more storage nodes (a system resource that has only storage capabilities, with the storage addressable by more than one processing nodes). The Ada model for programming distributed systems specifies a partition as the unit of distribution. Partitions comprised aggregations of library units (separately com- piled library packages or subprograms) that collectively may execute in a distributed target execution environment. The configuration of library units into partitions is not defined by the language; it is assumed that an implementation will provide this, along with facilities for allocation and, if necessary, reconfiguration. Each partition resides at a single execution site where all its library units occupy the same logical address space. More than one partition may, however, reside on the same execution site. Figure 14.6 illustrates one possible structure of a partition. The arrows represent the dependencies between library units. The principal interface be- tween partitions consists of one or more package specifications (each labelled ‘partition interface library unit’ in Figure 14.6). Partitions may be either active or passive. The library units comprising an active partition reside and execute upon the same processing element. In contrast, library units comprising a passive partition reside at a storage element that is directly accessible to the nodes of different active partitions that reference them. This model ensures that active partitions cannot directly access variables in other active partitions. Variables can only be shared directly between active partitions by encapsulating them in a passive partition. Communication between active partitions is defined in the language to be via remote subprogram calls (however, an implementation may provide other communica- tion mechanisms). Categorization pragmas To aid the construction of distributed programs, Ada distinguishes between different categories of library units, and imposes restrictions on these categories to maintain type consistency across the distributed program. The categories (some of these are useful in their own right, irrespective of whether the program is to be distributed) are designated by the following pragmas:534 DISTRIBUTED SYSTEMS LU LU LU LU LU LU LU LU Partition interface library unit LU Library unit Depends relationship (with clauses) External requests for services Figure 14.6 The structure of a partition. Preelaborate A preelaborable library unit is one that can be elaborated without execution of code at run-time. Pure Pure packages are preelaboratable packages with further restrictions which enable them to be freely replicated in different active or passive partitions without introducing any type inconsistencies. These restrictions concern the declaration of objects and types; in particular, variables and named access types are not allowed unless they are within a subprogram, task unit or protected unit.DISTRIBUTED PROGRAMMING SYSTEMS AND ENVIRONMENTS 535 Remote Types A Remote Types package is a preelaboratable package that must not contain any variable declarations within the visible part. Shared Passive Shared Passive library units are used for managing global data shared between active partitions. They are, therefore, configured on storage nodes in the distributed system. Remote Call Interface A Remote Call Interface package defines the interface between active parti- tions. Its body exists only within a single partition. All other occurrences will have library stubs allocated. The specification of a Remote Call Interface package must be preelab- orable; in addition other restrictions apply, for example it must not contain the definition of a variable (to ensure no remote data access). A package which is not categorized by any categorization pragma is called a normal library package. If it is included in more than one partition, then it is replicated and all types and objects are viewed as distinct. For example, theCalendar package is, in this regard, normal. The above pragmas facilitate the distribution of an Ada program and ensure that illegal partitionings (which allow direct remote variable access between partitions) are easily identifiable. Remote communication The only predefined way in which active partitions can communicate directly is via remote subprogram calls. They can also communicate indirectly via data structures in passive partitions. There are three different ways in which a calling partition can issue a remote subprogram call: by calling a subprogram which has been declared in a remote call interface pack- age of another partition directly; by dereferencing a pointer to a remote subprogram; by using run-time dispatching to a method of a remote object. It is important to note that, in the first type of communication, the calling and the called partitions are statically bound at compile time. However, in the latter two, the parti- tions are dynamically bound at run-time. Hence Ada can support transparent access to resources.536 DISTRIBUTED SYSTEMS Program 14.1 The AdaSystem.RPC package. with Ada.Streams; package System.RPC is type Partition_ID is range0.. implementation defined; Communication_Error : exception; type Params_Stream_Type ... Synchronous call procedure Do_RPC( Partition : in Partition_ID; Params : access Params_Stream_Type; Result : access Params_Stream_Type); Asynchronous call procedure Do_APC( Partition : in Partition_ID; Params : access Params_Stream_Type); The handler for incoming RPCs type RPC_Receiver is access procedure( Params : access Params_Stream_Type; Result : access Params_Stream_Type); procedure Establish_RPC_Receiver(Partition : Partition_ID; Receiver : in RPC_Receiver); private ... end System.RPC; Many remote calls contain only ‘in’ or ‘access’ parameters (that is, data that is being passed in the same direction as the call) and a caller may wish to continue its execution as soon as possible. In these situations it is sometimes appropriate to designate the call as an asynchronous call. Whether a procedure is to be called synchronously or asynchronously is considered by Ada to be a property of the procedure and not of the call. This is indicated by using a pragma Asynchronous when the procedure is declared. Ada has defined how distributed programs can be partitioned and what forms of remote communication must be supported. However, the language designers were keen not to overspecify the language and not to prescribe a distributed run-time support system for Ada programs. They wanted to allow implementors to provide their own network communication protocols and, where appropriate, allow other ISO standardsDISTRIBUTED PROGRAMMING SYSTEMS AND ENVIRONMENTS 537 to be used; for example the ISO Remote Procedure Call standard. To achieve these aims, the Ada language assumes the existence of a standard implementation-provided subsystem for handling all remote communication (the Partition Communication Sub- system, PCS). This allows compilers to generate calls to a standard interface without being concerned with the underlying implementation. The package defined in Program 14.1 illustrates the interface to the remote pro- cedure (subprogram) call (RPC) support system which is part of the PCS. The type Partition Id is used to identify partitions. For any library-level declaration, D, D’Partition Id yields the identifier of the partition in which the declaration was elaborated. The exceptionCommunication Error is raised when an error is detected by System.RPC during a remote procedure call. An object of stream typeParams Stream Type is used for marshalling (translating data into an appropriate stream-oriented form) and unmarshalling the parameters or results of a re- mote subprogram call, for the purposes of sending them between partitions. The object is also used to identify the particular subprogram in the called partition. The procedureDo RPC is invoked by the calling stub after the parameters are flat- tened into the message. After sending the message to the remote partition, it suspends the calling task until a reply arrives. The procedureDo APC acts likeDo RPC except that it returns immediately after sending the message to the remote partition. It is called whenever theAsynchronous pragma is specified for the remotely called procedure. Establish RPC Receiver is called immediately after elaborating an active par- tition, but prior to invoking the main subprogram, if any. TheReceiver parameter designates an implementation-provided procedure that receives a message and calls the appropriate remote call interface package and subprogram. Real-time perspective Although Ada defines a coherent real-time model for single and multiprocessor sys- tems, it has very limited support for distributed real-time systems. There is no integra- tion between the Distributed Systems Annex and the Real-Time Annex. Arguably, the technology of language support in this area is not sufficiently widely accepted to merit standardization. 14.4.3 Java There are essentially two ways in which to construct distributed Java applications: (1) execute Java programs on separate machines and use the Java networking facili- ties; (2) use remote objects.538 DISTRIBUTED SYSTEMS Java networking In Section 14.5, two network communication protocols will be introduced: UDP and TCP. These are the prominent communication protocols in use today and the Java envi- ronment provide classes (in thejava.net package) which allow easy access to them. The API to these protocols is via theSocket class (for the reliable TCP protocol) and the DatagramSocket class (for the UDP protocol). It is beyond the scope of this book to consider this approach in detail – see the Further Reading section at the end of this chapter for alternative sources of information. Remote objects Although Java provides a convenient way of accessing network protocols, these pro- tocols are still complex and are a deterrent to writing distributed applications. Conse- quently, Java supports the distributed object communication model through the notion of remote objects. The Java model is centred on the use of thejava.rmi package which builds on top of the TCP protocol. In this package is theRemote interface: public interface Remote ; This is the starting point for writing distributed Java applications. Extensions of this interface are written to provide the link between the clients and servers. For example, consider a server which wishes to return details of the local weather forecast for its location. An appropriate interface might be: public interface WeatherForecast extends java.rmi.Remote // shared between clients and server public Forecast getForecast() throws RemoteException; The methodgetForecast must have aRemoteException class in its throws list so that the underlying implementation can indicate that the remote call has failed. Forecast is an object which has details of today’s forecast. As the object will 2 be copied across the network, it must implement theSerializable interface public class Forecast implements java.io.Serializable public String Today() String today = "Wet"; return today ; 2 Like theRemote interface, theSerializable interface is empty. In both cases it acts as a tag to give information to the compiler. For theSerializable interface, it indicates that the object can be converted into a stream of bytes suitable for I/O.DISTRIBUTED PROGRAMMING SYSTEMS AND ENVIRONMENTS 539 Once the appropriate remote interface has been defined, a server class can be declared. Again, it is usual to indicate that objects of the class can potentially be called remotely by extending one of the predefined classes in the packagejava.rmi.server.Cur- rently, there are two classes: RemoteServer (which is an abstract class derived from the Remote class) and UnicastRemoteObject which is a concrete extension of RemoteServer. The latter provides the class for servers which are non-replicated and have a point-to-point connection to each client using the TCP protocol. It is an- ticipated that future extension to Java might provide other classes such as a replicated server using a multicast communication protocol. The following examples shows a server class which provides the weather forecast for the county of Yorkshire in the UK. public class YorkshireWeatherForecast extends UnicastRemoteObject implements WeatherForecast public YorkshireWeatherForecast() throws RemoteException super(); // call parent constructor public Forecast getForecast() throws RemoteException ... Once the server class has been written, it is necessary to generate the server and client stubs for each of the methods that can be called remotely. Note that Java uses the term skeleton for the server stub. The Java programming environment provides a tool called ‘rmic’ which will take a server class and automatically generate the appropriate client stub and server skeleton. All that is now required is for the client to be able to acquire a client stub which accesses the server object. This is achieved via a registry. The registry is a separate Java program which executes on each host machine which has server objects. It listens on a standard TCP port and provides an object of the classNaming extracted in Program 14.2. Each server object can use theNaming class to bind its remote object to a name. Clients then can access a remote registry to acquire a reference to the remote object. Of course, this is a reference to a client stub object for the server. The client stub is loaded into the client’s machine. Once the reference has been obtained, the server’s methods can be invoked. Real-time perspective The facilities described above are those of Standard Java which is not intended to operate within real-time constraints. Real-Time Java is currently silent on the issue of distributed540 DISTRIBUTED SYSTEMS Program 14.2 An extract of the Java Naming class. public final class Naming public static void bind(String name, Remote obj) throws AlreadyBoundException, java.net.MalformedURLException, UnknownHostException, RemoteException; // bind the name to the obj // name takes the form of a URL such as // rmi://remoteHost:pot/objectName public static Remote lookup (String name) throws NotBoundException, java.net.MalformedURLException, UnknownHostException, RemoteException; // looks up the name in the registry and returns a remote object ... real-time programming. However, this is a topic which will be addressed within the next few years. 14.4.4 CORBA The Common Object Request Broker Architecture (CORBA) provides the most general distributed object model. Its goal is to facilitate interoperability between applications written in different languages, for different platforms supported by middleware software from different vendors. It was designed by the Object Management Group (OMG) – a consortium of software vendors, software developers and end users – according to the Object Management Architectural Model, which is depicted in Figure 14.7. At the heart of the architecture is the Object Request Broker (ORB). Thisisa software communication bus that provides the main infrastructure that facilitates inter- operability between heterogeneous applications. The term CORBA often refers to the ORB. The other components of the architecture are: Object Services – a collection of basic services which support the ORB; for example, support for object creation, naming and access control, and tracking relocated objects. Common Facilities – a set of functions which is common across a wide range of ap- plication domains; for example, user interfaces, document and database manage- ment. Domain Interfaces – a group of interfaces which support particular application do- mains such as banking and finance or telecommunications. Application Interfaces – the end users’ specific application interfaces.DISTRIBUTED PROGRAMMING SYSTEMS AND ENVIRONMENTS 541 Application Domain Common interfaces interfaces interfaces Object request broker Object services Figure 14.7 The Object Management Architecture Model. To ensure interoperability between ORBs from different vendors, CORBA defines a General Inter-ORB Protocol which sits on top of TCP/IP (see section 14.5.2). Central to writing CORBA applications is the Interface Definition Language (IDL) . A CORBA interface is similar in concept to the Java remote interface discussed in the previous section. The IDL (which is like the C++ language) is used to describe the facilities to be provided by an application object, the parameters to be passed with a given method and its return values, along with any object attributes. An example interface for the weather forecast application given in the previous section is shown below. interface WeatherForecast void GetForecast(out Forecast today); Once the IDL for the application is defined, tools are used to ‘compile’ it. The IDL com- piler generates several new files in one of a number of existing programming languages such as Java or Ada. The files include: client stubs that provide a communication channel between the client and the ORB; and a server skeleton which enables the ORB to call functions on the server. The code for the server and clients can now be written. The server consists of two parts: the code for the application object itself and the code for the server process. The application object has to be associated with the server skeleton. The way this is achieved is dependent on the target language. For example in Java, it can be done by producing a class which is a subclass of the generated server skeleton. The methods for the application objects are then completed. The server process itself can be written as a main program which creates the application object and initializes the ORB and tells it that the object is ready to receive client requests. The structure of the client is similar.542 DISTRIBUTED SYSTEMS In reality, CORBA provides many more facilities than those described above. As well as the static association between client and server, CORBA clients can dynamically discover a server’s IDL interface without prior knowledge of the server details. Further- more, the services that support the ORB allow for a wide range of functionality such as an event service, transaction and concurrency control, persistent objects and trading services. Applications access these services via the Portable Object Adapter (POA). This is a library which provides the run-time environment for a server object. Real-time perspective Although, in general, CORBA provides comprehensive support for distributed objects, from this book’s perspective, one of the main limitation of CORBA has been its lack of support for real-time applications. The ORBs were not designed to operate within time constraints and the result is that many are inappropriate for soft real-time systems, let alone systems which have to operate within stringent timing constraints. Furthermore, the basic communication models provided by CORBA are: a synchronous RPC where the client must wait for the server to reply, and a deferred synchronous RPC where the client thread continues and subsequently polls for the reply. As was illustrated in Chapter 13, synchronous communication models are more difficult to analyze for their timing properties than asynchronous models and the results are more pessimistic. For these reasons and the increasing use of CORBA in real-time applications, the OMG have set out over the last few years to address the performance problems associated with the main CORBA standard. They have tackled the problems from three perspectives: (1) Minimum CORBA (2) CORBA Messaging (3) Real-Time CORBA Minimum CORBA is a subset of the CORBA 2.2 specification which omits many services including all those associated with dynamic configurations between client and server objects. The subset is targeted at embedded systems with limited resources. CORBA Messaging is an extension to the CORBA standard to support asyn- chronous message passing and quality of service parameters. The Real-Time CORBA (RT CORBA) (Object Management Group, 1999) spec- ification defines mechanisms that support predictability of distributed CORBA appli- cations. It assumes that real-time behaviour is obtained by using fixed-priority based scheduling and is, therefore, compatible with most real-time operating systems – espe- cially those supporting the Real-Time POSIX interfaces. The key aspect of RT CORBA is that it allows applications to configure and control both processor and communication resources. These facilities will now be briefly described.

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.