Building Secure and Reliable Network Applications phần 3 doc

Kenneth P. Birman - Building Secure and Reliable Network Applications 104 104 6. CORBA and Object-Oriented Environments With the emergence of object-oriented programming languages, such as Modula and C++, came a recognition that object-orientation could play a role similar to that of the OSI hierarchy, but for complex distributed systems. In this view, one would describe a computing system in terms of the set of objects from which it was assembled, together with the rules by which these objects interact with one another. Object oriented system design became a major subject for research, with many of the key ideas pulled together for the first time by a British research effort, called the Advanced Network Systems Architecture group, or ANSA. In this chapter, we will briefly discuss ANSA, and then focus on a more recent standard, called CORBA, which draws on some of the ideas introduced by ANSA, and has emerged as a widely accepted standard for objected oriented distributed computing. 6.1 The ANSA Project The ANSA project, headed by Andrew Herbert, was the first systematic attempt to develop technology for modelling complex distributed systems [ANSA89, ANSA91a, ANSA91b]. ANSA stands for the “Advanced Network Systems Architecture”, and was intended as a technology base for writing down the structure of a complex application or system and then translating the resulting description into a working version of that system in a process of stepwise refinement. Abstractly, ANSA consists of a set of “models” that deal with various aspects of distributed systems design and representation problem. The “enterprise” model is concerned with the overall functions and roles of the organizational structure within which the problem at hand is to be solved. For example, an air-traffic control system would be an application within the air-traffic control organization, an “enterprise”. The “information” model represents the flow of information within the enterprise; in an air-traffic application this model might describe flight-control status records, radar inputs, radio communication to and from pilots, and so forth. The “computation” model is a framework of programming structures and program development tools that are made available to developers. The model deals with such issues as modularity of the application itself, invocation of operations, paramter passing, configuration, concurrency and synchronization, replication, and the extension of existing languages to support distributed computing. The “engineering” and “technology” models reduce these abstractions to practice, poviding the implementation of the ANSA abstractions and mapping these to the underlying runtime environment and its associated technologies. In practical terms, most users viewed ANSA as a a set of rules for system design, whereby system components could be described as “objects” with published interfaces. An application with appropriate permissions could obtain a “handle” on the object and invoke its methods using the procedures and functions defined in this interface. The ANSA environment would automatically and transparently deal with such issues as fetching objects from storage, launching programs when a new instance of an object was requested, implementing the object invocation protocols, etc. Moreover, ANSA explicitly included features for overcoming failures of various kinds, using transactional techniques drawn from the database community and process group techniques in which sets of objects are used to implement a single highly available distributed service. We will consider both types of technology in considerable detail in Part III of the text, hence we will not do so here. Chapter 6: CORBA and Object-Oriented Environments 105 105 ANSA treated the objects that implement a system as the concrete realization of the “enterprise computing model” and the “enterprise information model.” These models captured the essense of of the application as a whole, treating it as a single abstraction even if the distributed system as implemented necessarily contained many components. Thus, the enterprise computing model might support the abstraction of a collision avoidance strategy for use by the air-traffic control enterprise as a whole, and the enterprise data model might define the standard data objects used in support of this service. The actual implementation of the service would be reached by a series of refinements in which increasing levels of detail are added to this basic set of definitions. Thus, one passes from the abstraction of a collision avoidance strategy to the more concrete concept of a collision avoidance subsystem located at each of a set of primary sites and linked to one-another to coordinate their actions, and from this notion to one with further refinements that define the standard services composing the collision avoidance system as used on a single air-traffic control workstation, and then still further to a description of how those services could be implemented. In very concrete terms, the ANSA approach required the designer to write down the sort of knowlege of distributed system structure that, for many systems, is implicit but never encoded in a machine-readable form. The argument was that by writing down these system descriptions, a better system would emerge: one in which the rationale for the structure used was self-documenting, in which detailed information would be preserved about the design choices and objectives that the system carries out, and in this manner the mechanisms for future evolution could be made a part of the system itself. Such a design promotes extensibility and interoperability, and offers a path to system management and control. Moreover, ANSA designs were expressed in terms of objects, whose locations could be anywhere in the network (Figure 6-1), with actual issues of location entering only the design was further elaborated, or in specific situations where location of an object might matter (Figure 6-2). This type of object- oriented, location-transparent design has proved very popular with distributed systems designers. Figure 6-1: Distributed objects abstraction. Objects are linked by object references and the distributed nature of the environment is hidden from users. Access is uniform even if objects are implemented to have special properties or internal structure, such as replication for increased availability or transactional support for persistence. Objects can be implemented in different programming languages but this is invisible to users Kenneth P. Birman - Building Secure and Reliable Network Applications 106 106 6.2 Beyond ANSA to CORBA While the ANSA technology per se has not gained a wide following, these ideas have had a huge impact on the view of system design and function adopted by modern developers. In particular, as the initial stages of the ANSA project ended, a new project was started by a consortium of computer vendors. Called the Common Object Request Broker Architecture, CORBA undertakes to advance standards permiting interoperation between complex object-oriented systems potentially built by diverse vendors [OMG91]. Although CORBA undoubtedly drew on the ANSA work, the architecture represents a consensus developed within an industry standards organization called the Object Management Group, or OMG, and differs from the ANSA architecture in many respects. The mission of OMG was to develop architecture standards promoting interoperability between systems developed using object-oriented technologies. In some ways, this represents a less ambitious objective than the task with which ANSA was charged, since ANSA set out both to develop an all-encompassing architectural vision for building enterprise-wide distributed computing systems, and to encorporate reliability technologies into its solutions. However, as CORBA has evolved, it has begun to tackle many of the same issues. Moreover, CORBA reaches well beyond ANSA by defining a very large collection of what are called “services”, which are CORBA-based subsystems that have responsibility for specific tasks, such as storing objects or providing reliability, and that have specific interfaces. ANSA began to take on this problem late in the project and did not go as far as CORBA. At the time of this writing, CORBA was basically a framework for building DCE-like computing environments, but with the priviso that different vendors might offer their own CORBA solutions with differing properties. In principle, adherence to the CORBA guidelines should permit such solutions to interoperate  e.g. a distributed system programmed using a CORBA product from Hewlett Packard should be useful from within an application developed using CORBA products from SUN Microsystems, IBM, or some other CORBA-compliant vendor. Interoperability of this sort, however, is planned for late in 1996, and hence there has been little experience with this specific feature. Figure 6-2: In practice, the objects in a distributed system execute on machines or reside in storage servers. The runtime environment works to conceal movement of objects from location to location, activation of servers when they are initially referenced after having been passively stored, fault-tolerance issues, garbage collection, and other issues that span multiple objects or sites. Chapter 6: CORBA and Object-Oriented Environments 107 107 6.3 OLE-2 and Network OLE As this book was bring written Microsoft Corporation had just launched a major drive to extend its proprietary object-oriented computing standard, OLE-2, into a distributed object-oriented standard aimed squarely at the internet. The network OLE-2 specification, when it emerges, is likely to have at least as big an impact on the community of PC users as Corba is having on the UNIX community. However, until the standard is actually released, it is impossible to comment upon it. Experts with whom the author has spoken predict that network OLE will be generally similar to Corba, but with a set of system services more closely parallel to the ones offered by Microsoft in its major network products: NT/Server and NT/Exchange. Presumably, these would include integrated messaging, email, and conferencing tools, system-wide security through encryption technologies, and comprehensive support for communicating using multi-media objects. One can only speculate as to more advanced features, such as the group computing technologies and reliability treated in Part III of this text. 6.4 The CORBA Reference Model The key to understanding the structure of a CORBA environment is the Reference Model [OMG91], which consists of a set of components that a CORBA platform should typically provide. These components are fully described by the CORBA architecture, but only to the level of interfaces used by application developers and functionality. Individual vendors are responsible for deciding how to implement these interfaces and how to obtain the best possible performance; moreover, individual products may offer solutions that differ in offering optional properties such as security, high availability, or special guarantees of behavior that go beyond the basics required by the model. At a minimum, a CORBA implementation must supply an Object Request Broker, or ORB, which is responsible for matching a requestor with an object that will perform its request, using the object reference to locate an appropriate target object. The implementation will also contain translation programs, responsible for mapping implementations of system components (and their IDL’s) to programs that can be linked with a runtime library and executed. A set of Object Services provide the basic functionality needed to create and use objects: these include such functions as creating, deleting, copying, or moving objects, giving them names that other objects can use to bind to them, and providing security. An interesting service about which we will have more to say below is the Event Noticication Service or ENS: this allows a program to register its interest in a class of events. All events in that class are then reported to the program. It thus represents a communication technology different from the usual RPC- style or stream-style of connection. A set of Common Faciities contains a collection of standardized applications that most CORBA implementations are expected to support, but that are ultimately optional: these include, for example, standards for system management and for electronic mail that may contain objects. And finally, of course, there are Application Objects developed by the CORBA user to solve a particular problem. Kenneth P. Birman - Building Secure and Reliable Network Applications 108 108 In many respects the Object Request Broker is the core of a CORBA implementation. Similar to the function of a communications network or switching system, the ORB is responsible for delivering object invocations that originate in a client program to the appropriate server program, and routing the reply back to the client. The ability to invoke an object, of course, does not imply that the object that was invoked is being used correctly, has a consistent state, or is even the most appropriate object for the application to use. These broader properties fall back upon the basic technologies of distributed computing that are the general topic of this textbook; as we will see, CORBA is a way of talking about solutions but not a specific set of prebuilt solutions. Indeed, one could say that because CORBA worries about syntax but not semantics, the technology is largely superficial: a veneer around a set of technologies. However, this particular veneer is an important and sophisticated one, and also creates a context within which a principled and standardized approach to distributed systems reliability becomes possible. For many users, object-oriented computing means programming in C++, although SmallTalk and Ada are also object-oriented languages, and one can develop object-interfaces to other languages like Fortran and Cobol. Nonetheless, C++ is the most widely used language, and is the one we focus on in the examples presented in the remainder of this chapter. Our examples are drawn directly from the “programmer’s guide” for Orbix, an extremely popular CORBA technology at the time of this writing. An example of a CORBA object interface, coded in the Orbix interface defintion language (IDL), is shown in Figure 6-4. This interface publishes the services available from a “grid” server, which is intended to manage two-dimensional tables such as are used in spread-sheets or relational databases. The server exports two read-only values, width and height, which can be used to query the size of a grid object. There are also two operations which can be reference reference reference DII interface instance instance instance interface stub stub interface ORB Figure 6-3: The conceptual architecture of CORBA uses an object request broker as an intermediary that directs object invocations to the appropriate object instances. There are two cases of invocations: the static one, which we focus on in the text, and the dynamic invocation interface (DII), which is more complex to use and hence not discussed here. (Source: Shapiro) // grid server example for Orbix // IDL in file grid.idl interface grid { readonly attribute short height; readonly attribute short width; void set(in short n, in short m, in long value); void get(in short n, in short m); }; Figure 6-4: IDL interface to a server for a "grid" object coded in Orbix, a popular CORBA-compliant technology. Chapter 6: CORBA and Object-Oriented Environments 109 109 performed upon the object: “set”, which sets the value of an element, and “get” which fetches the value. Set is of type “void”, meaning that it does not return a result; get, on the other hand, returns a long integer. To build a grid server, the user would need to write a C++ program that implements this interface. To do this, the IDL compiler is first used to transform the IDL file into a standard C++ header file in which Orbix defines the information it will need to implement remote invocations on behalf of the client. The IDL compiler also produces two forms of “stub” files, one of which implements the client side of the “get” and “set” operations; the other implements the “server” side. These stub files must be compiled and linked to the respective programs. If one were to look at the contents of the header file produced for the grid IDL file, one would discover that “width” and “height” have been transformed into functions. That is, when the C++ programmer references an attribute of a grid object, a function call will actually occur into the client-side stub procedures, which can perform an RPC to the grid server to obtain the current value of the attribute. We say RPC here, but in fact a feature of CORBA is that it provides very efficient support for invocations of local objects, which are defined in the same address space as the invoking program. The significance of this is that although the CORBA IDL shown could be used to access a remote server that handles one or more grid objects, it can also be used to communicate to a completely local instantiation of a grid object, contained entirely in the address space of the calling program. Indeed, the concept goes even further: in Orbix+Isis, a variation of Orbix, the grid server could be replicated using an object group for high availability. And in the most general case, the grid object’s clients could be implemented by a server running under some other CORBA-based environment, such as IBM’s DSOM product, HP’s DOMF, SUN’s DOE, Digital Equipment’s ObjectBroker, or other object-oriented environments with which CORBA can communicate using an “adapter”, such as Microsoft’s OLE. CORBA implementations thus have the property that object location, the technology or programming language used to build an object, and even the ORB under which it is running can be almost completely transparent to the user. N ode 1 Node 2 server p roxy client function call function return function call forwarded by proxy return value forwarded to proxy server Figure 6-5: Orbix conceals the location of objects by converting remote operations into operations on local proxy objects, mediated by stubs. However, remote access is not completely transparent in standard CORBA applications if an application is designed for reliability. For example, error conditions differ for local and remote objects. Such issues can be concealed by integrating a reliability technology into the CORBA environment, but transparent reliability is not a standard part of CORBA, and solutions vary widely from vendor to vendor. Kenneth P. Birman - Building Secure and Reliable Network Applications 110 110 What exactly would a grid server look like? If we are working in C++, grid would be a C++ program that includes an “implementation class” for grid objects. Such a class is illustrated in Figure 6-6, again drawing on Orbix as a source for our example. The “Environment” parameter is used for error handling with the client. The BOAImpl extention (“gridBOAImpl”) designates that this is a Basic Object Adaptor Implementation for the “grid” interface. Figure 6-7 shows the code that might be used to implement this abstract data type. Finally, our server needs an enclosing framework: the program itself that will execute this code. The code in Figure 6-8 provides this; it implements a single grid object and declares itself to be ready to accept object invocations. The grid object is not named in this example, although it could have been, and indeed the server could be designed to create and destroy grid objects dynamically at runtime. // C++ code fragment for grid implementation class #include “grid.hh” // generated from IDL class grid_i: public gridBOAImpl { short m_height; short m_width; long **m_a; public: grid_i(short h, short w); // Constructor virtual ~grid_i(); // Destructor virtual short width(CORBA::Environment &); virtual short height(CORBA::Environment &); virtual void set(short n, short m, long value, CORBA::Environment &); virtual long get(short n, short m, CORBA::Environment &); }; Figure 6-6: Orbix example of a grid implementation class corresponding to grid IDL. Chapter 6: CORBA and Object-Oriented Environments 111 111 The user can now declare to Orbix that the grid server is available by giving it a name and storing the binary of the server in a file, the pathname of which is also provided to Orbix. The Orbix “life cycle service” will automatically start the grid server if an attempt is made to access it when it is not running. // Implementation of grid class #include “grid_i.h” grid_i::grid_i(short h, short w) { m_height = h; m_width = w; m_a = new long* [h]; for(inti=0;i<h;i++) m_a[i] = new long [w]; } grid_i::~grid_i() { for(inti=0;i<m_height;i++) delete[ ] m_a[i]; delete[ ] m_a; } short grid_i::width(CORBA::Environment &) { return m_width; } short grid_i::height(CORBA::Environment &) { return m_height; } void grid_i::set(short n, short m, long value, CORBA::Environment &) { m_a[n][m] = value; } void grid_i::get(short n, short m, CORBA::Environment &) { return m_a[n][m]; } Figure 6-7: Server code to implement the grid_i class in Orbix. #include “grid_i.h” #include <iostream.h> void main() { grid_i myGrid(100,100); // Orbix objects can be named but this is not // needed for this example CORBA::Orbix.impl_is_ready(); cout <<“server terminating” << endl; } Figure 6-8: Enclosing program to declare a grid object and accept requests upon it. Kenneth P. Birman - Building Secure and Reliable Network Applications 112 112 CORBA supports several notions of reliability. One is concerned with recovering from failures, for example when invoking a remote server. A second reliability mechanism is provided for purposes of reliable interactions with persistent objects, and is based upon what is called a “transactional” architecture. We discuss transactions elsewhere in this text and will not digress onto that subject at this time. However, the basic purpose of a transactional architecture is to provide a way for applications to perform operations on complex persistent data structures without interfering with other concurrently active but independent operations, and in a manner that will leave the structure intact even if the application program or server fails while it is running. Unfortunately, as we will see in Chapter 21, transactions are primarily useful in applications that are structured as database systems on which programs operate using read and update requests. Such structures are important in distributed systems, but there are many distributed applications that match the model poorly, and for them, transactional reliability is not a good approach. #include “grid.hh” #include <iostream.h> void main() { grid *p; p = grid::_bind(“:gridSrv”); cout << “height is “ << p->height() << endl; cout << “width is “ << p->width() << endl; p->set(2, 4, 123); cout << “grid(2, 4) is “ << p->get(2, 4) << endl; p->release(); } Figure 6-9: Client program for the grid object; assumes that the grid was "registered" under the server name "gridSrv". This example lacks error handling; an elaborated version with error handling appears in Figure 6-10. Chapter 6: CORBA and Object-Oriented Environments 113 113 Outside of its transactional mechanisms, however, CORBA offers relatively little help to the programmer. For example, Orbix can be notified that a server application can be run on one of a number of machines. When a client application attempts to use the remote application, Orbix will automatically attempt to bind to each machine in turn, selecting at random the first machine which confirms that the server application is operational. However, Orbix does not provide any form of automatic mechanisms for recovering from the failure of such a server after the binding is completed. The reason for this is that a client process that is already communicating with a server may have a complex state that reflects information specific to that server, such as cached records with record identifiers that came from the server, or other forms of data that differ in specific ways even among servers that are, broadly speaking, able to provide the same functionality. To rebind the client to a new server, one would somehow need to refresh, rebuild, or roll back this server-dependent state. And doing so is potentially very hard; at a minimum, considerable detailed knowledge of the application will be required. The same problems can also arise in the server itself. For example, consider a financial trading service, in which the prices of various stocks are presented, and which is extremely dynamic due to rapidly changing market data. The server may need to have some form of setup that it uses to establish a client profile, and may have an internal state that reflects the events that have occured since the client first bound to it. Even if some other copy of the server is available and can provide the same services, there could be a substantial time lag when rebinding and there may be a noticable discontinuity if the new server, lacking this “state of the session”, starts its financial computations from the current stream of #include “grid.hh” #include <iostream.h> void main() { grid *p; TRY { p = grid::_bind(“:gridSrv”); } CATCHANY { cerr << “bind to object failed” << endl; cerror << “Fatal exception “ << IT_X << endl; exit(1); } TRY { cout << “height is “ << p->height() << endl; } CATCHANY { cerr << “call to height failed” << endl; cerror << “Fatal exception “ << IT_X << endl; exit(1); } etc } Figure 6-10: Illustration of Orbix error handling facility. Macros are used to catch errors; if one occurs, the error can be caught and potentially worked around. Notice that each remote operation can potentially fail, hence exception handling would normally be more standardized. A handler for a high availability application would operate by rebinding to some other server capable of providing the same functionality. This can be concealed from the user, which is the approach used in systems like Orbix+Isis or Electra, a CORBA technology layered over the Horus distributed system. [...]... mechanisms and, because few applications actually use the optional locking interfaces, on greater attention to cache validation protocols In this section, we briefly survey some of the best known stateful file systems Our treatment is brief because of the 129 130 Kenneth P Birman - Building Secure and Reliable Network Applications The Andrew File System was developed at Carnegie Mellon University and subsequently... between the disconnected computer and the main file system server is reestablished Much of the sophistication of Coda is concerned with tracking the appropriate sets of files to cache in this manner, and with optimizing the merge mechanisms so that user intervention can be avoided when possible 133 Kenneth P Birman - Building Secure and Reliable Network Applications 134 The challenge faced by Coda is... are really not all that frequent in modern computing systems, and that most applications are not particularly critical! In a world where hardware was less reliable or the applications were more critical, protocols such as the NFS protocol might be considerably less attractive 127 128 Kenneth P Birman - Building Secure and Reliable Network Applications Our discussion is for the case of a normal NFS server... real-time applications, such as computer assisted conferencing systems and multimedia playback systems In these cases one might be willing to accept additional mechanism (and hence complexity) as a way of gaining a desired property A stateless architecture will be much simpler, but cached data may be stale and hence cannot be used in the same ways 1 23 124 Kenneth P Birman - Building Secure and Reliable Network. .. protocol, and usable by the server to rapidly validate access and locate the corresponding inode 125 126 Kenneth P Birman - Building Secure and Reliable Network Applications On the server side, the file system is conventionally structured, but is accessed by messages containing a vnode identifier and an offset into the file, rather than block by block The vnode identifier is termed a file handle whereas... Birman - Building Secure and Reliable Network Applications The Lotus Notes system is a commercial database product that uses a client-server model to manage collections of documents, which can draw upon a great variety of applications (word-processing, spreadsheets, financial analysis packages, and so forth) The system is widely popular because of the extremely simple sharing model that it supports and. ..114 Kenneth P Birman - Building Secure and Reliable Network Applications incoming data Such events will not be transparent to the client using the server and it is unrealistic to try and hide them The integration of of a wider spectrum of reliability enhancing technologies with CORBA represents an important area for research and commercial development, particularly if reliability... Most of the protocols and techniques discussed in the remainder of this textbook are compatible with CORBA in the sense that they could be used to implement standard CORBA reliability services, such as its replication service or the event notification service 119 120 Kenneth P Birman - Building Secure and Reliable Network Applications 6.16 Related Readings On the ANSA project and architecture: [ANSA89,... location; the request can then be reissued and should now reach the correct server This is illustrated in Figure 7-1 Notice that the use of cached data is transparent to (concealed from) the 121 Kenneth P Birman - Building Secure and Reliable Network Applications 122 client system name service (2) cached record accurate record accurate record accurate record (3) accurate record (1) original server new... In Sprite, network partition failures are considered unlikely because the physical network used at Berkeley is quite robust, and in any case, network partitions cause the client workstations to initiate a recovery protocol Information concerning the precise handling of network partitions, or about methods for replicating AFS servers, was not available to the author at the time of this 135 136 Kenneth . Birman - Building Secure and Reliable Network Applications 104 104 6. CORBA and Object-Oriented Environments With the emergence of object-oriented programming languages, such as Modula and C++,. transparent reliability is not a standard part of CORBA, and solutions vary widely from vendor to vendor. Kenneth P. Birman - Building Secure and Reliable Network Applications 110 110 What exactly. P. Birman - Building Secure and Reliable Network Applications 114 114 incoming data. Such events will not be transparent to the client using the server and it is unrealistic to try and hide them. The