Object-Based Middleware
8.3.5 Object-Based Middleware
Now let us take a look at a third paradigm. Instead of saying that everything is
a document or everything is a file, we say that everything is an object. An object is a collection of variables that are bundled together with a set of access proce- dures, called methods. Processes are not permitted to access the variables directly. Instead, they are required to invoke the methods.
Some programming languages, such as C++ and Java, are object oriented, but these are language-level objects rather than run-time objects. One well-known sys- tem based on run-time objects is CORBA (Common Object Request Broker Architecture ) (Vinoski, 1997). CORBA is a client-server system, in which client processes on client machines can invoke operations on objects located on (possibly remote) server machines. CORBA was designed for a heterogeneous system run- ning a variety of hardware platforms and operating systems and programmed in a variety of languages. To make it possible for a client on one platform to invoke a server on a different platform, ORBs (Object Request Brokers) are interposed be- tween client and server to allow them to match up. The ORBs play an important role in CORBA, even providing the system with its name.
Each CORBA object is defined by an interface definition in a language called IDL (Interface Definition Language), which tells what methods the object exports and what parameter types each one expects. The IDL specification can be compiled into a client stub procedure and stored in a library. If a client process knows in advance that it will need to access a certain object, it is linked with the object’s client stub code. The IDL specification can also be compiled into a skele- ton procedure that is used on the server side. If it is not known in advance which CORBA objects a process needs to use, dynamic invocation is also possible, but how that works is beyond the scope of our treatment.
SEC. 8.3
DISTRIBUTED SYSTEMS
When a CORBA object is created, a reference to it is also created and returned to the creating process. This reference is how the process identifies the object for subsequent invocations of its methods. The reference can be passed to other proc- esses or stored in an object directory.
To inv oke a method on an object, a client process must first acquire a reference to the object. The reference can come either directly from the creating process or, more likely, by looking it up by name or by function in some kind of directory. Once the object reference is available, the client process marshals the parameters to the method calls into a convenient structure and then contacts the client ORB. In turn, the client ORB sends a message to the server ORB, which actually invokes the method on the object. The whole mechanism is similar to RPC.
The function of the ORBs is to hide all the low-level distribution and commu- nication details from the client and server code. In particular, the ORBs hide from the client the location of the server, whether the server is a binary program or a script, what hardware and operating system the server runs on, whether the object is currently active, and how the two ORBs communicate (e.g., TCP/IP, RPC, shar-
ed memory, etc.). In the first version of CORBA, the protocol between the client ORB and the server ORB was not specified. As a result, every ORB vendor used a different pro- tocol and no two of them could talk to each other. In version 2.0, the protocol was specified. For communication over the Internet, the protocol is called IIOP (Inter- net InterOrb Protocol ).
To make it possible to use objects that were not written for CORBA with CORBA systems, every object can be equipped with an object adapter. This is a wrapper that handles chores such as registering the object, generating object refer- ences, and activating the object if it is invoked when it is not active. The arrange- ment of all these CORBA parts is shown in Fig. 8-36.
Server Client
Client
Client stub
Skeleton
Server code
code
Object
Server ORB Operating system
Client ORB
adapter
Operating system
IIOP protocol
Network
Figure 8-36. The main elements of a distributed system based on CORBA. The CORBA parts are shown in gray.
MULTIPLE PROCESSOR SYSTEMS
CHAP. 8
A serious problem with CORBA is that every object is located on only one ser- ver, which means the performance will be terrible for objects that are heavily used on client machines around the world. In practice, CORBA functions acceptably only in small-scale systems, such as to connect processes on one computer, one LAN, or within a single company.
Parts
» The Second Generation (1955–65): Transistors and Batch Systems
» The Third Generation (1965–1980): ICs and Multiprogramming
» The Fourth Generation (1980–Present): Personal Computers
» System Calls for Process Management
» System Calls for Directory Management
» RESEARCH ON OPERATING SYSTEMS
» Implementing Threads in User Space
» Implementing Threads in the Kernel
» Making Single-Threaded Code Multithreaded
» Mutual Exclusion with Busy Waiting
» Avoiding Locks: Read-Copy-Update
» Scheduling in Interactive Systems
» Scheduling in Real-Time Systems
» The Dining Philosophers Problem
» The Readers and Writers Problem
» The Notion of an Address Space
» Page Tables for Large Memories
» DESIGN ISSUES FOR PAGING SYSTEMS
» Segmentation with Paging: MULTICS
» Segmentation with Paging: The Intel x86
» An Example Program Using File-System Calls
» Device-Independent I/O Software
» Disk Arm Scheduling Algorithms
» Preemptable and Nonpreemptable Resources
» Deadlock Detection with One Resource of Each Type
» Deadlock Detection with Multiple Resources of Each Type
» The Banker’s Algorithm for Multiple Resources
» REQUIREMENTS FOR VIRTUALIZATION
» TYPE 1 AND TYPE 2 HYPERVISORS
» TECHNIQUES FOR EFFICIENT VIRTUALIZATION
» ARE HYPERVISORS MICROKERNELS DONE RIGHT?
» Challenges in Bringing Virtualization to the x86
» VMware Workstation: Solution Overview
» ESX Server: VMware’s type 1 Hypervisor
» Multiprocessor Operating System Types
» Multiprocessor Synchronization
» Low-Level Communication Software
» User-Level Communication Software
» Network Services and Protocols
» File-System-Based Middleware
» Coordination-Based Middleware
» Authentication Using a Physical Object
» Authentication Using Biometrics
» Antivirus and Anti-Antivirus Techniques
» Model-Based Intrusion Detection
» Process-Management System Calls in Linux
» Implementation of Processes and Threads in Linux
» Implementation of the Linux File System
» NFS: The Network File System
» HISTORY OF WINDOWS THROUGH WINDOWS 8.1
» The Native NT Application Programming Interface
» The Win32 Application Programming Interface
» Implementation of the Object Manager
» Subsystems, DLLs, and User-Mode Services
» Job, Process, Thread, and Fiber Management API Calls
» Implementation of Processes and Threads
» Memory-Management System Calls
» Implementation of Memory Management
» Why Is It Hard to Design an Operating System?
» Static vs. Dynamic Structures
» Synchronous vs. Asynchronous Communication
» TRENDS IN OPERATING SYSTEM DESIGN
» SUGGESTIONS FOR FURTHER READING
Show more