AVAILABLE: 5
As previously explained, the architecture of distributed systems requires middleware (Object Request Broker) to handle communication between objects. Essentially, objects in the system can be implemented in different programming languages, run on different platforms, and do not need to know the names of all other objects in the system.
Currently, there are two main middleware standards supporting distributed object computing:
CORBA (Common Object Request Broker Architecture): A set of middleware standards issued by the OMG (Object Management Group). CORBA defines a machine-independent and generic approach to distributed object computing. Various implementations are available for UNIX and Microsoft operating system applications.
DCOM (Distributed Component Object Model): Developed by Microsoft. Its distributed computing model is less common than CORBA, and DCOM provides limited support for interoperability.
RMI (Remote Method Invocation): Developed by Java.
CORBA, developed by OMG, plays a role in defining standards for object-oriented development but does not provide implementations for these standards. The OMG vision for distributed systems, as illustrated in Figure 10.7, proposes that distributed applications are made up of several components, including:
- Application Objects: Designed and implemented specifically for the application.
- Standard Objects: Defined by OMG for specific domains, such as financial services, e-commerce, healthcare, etc.
- CORBA Services: Fundamental services providing basic distributed computing capabilities, such as directories, security management, etc.
- CORBA Horizontal Facilities: Generic facilities applicable across many application domains, such as user interface management and system management.
CORBA Standards and Key Elements
The CORBA standard encompasses all aspects of this vision and consists of four main elements:
- CORBA Object Model: Encapsulates the state with a defined interface described in IDL (Interface Definition Language).
- Object Request Broker (ORB): Manages requests for object services. The ORB locates objects providing the requested services, facilitates the request, and returns the results to the requester.
- A Set of Object Services: Provides general services potentially required by many distributed applications, such as directory services and transaction services.
- A Set of Common Components: Built on fundamental services that applications might need.
CORBA objects have a unique identifier called the Interoperable Object Reference (IOR), used when one object requests services from another.
Object Request Broker (ORB) Functionality
The ORB is aware of objects requesting services and their interfaces. It handles communication between objects. Communicating objects do not need to know each other's location or implementation details, as the interface isolates objects from the ORB. Therefore, changes to an object's implementation are transparent. The object's location can change between invocations without affecting the system.
Figure 10.8 illustrates how two objects, O1 and O2, communicate via the ORB. The calling object (O1) uses an IDL stub associated with the interface of the object providing the needed service. The implementation of O1 integrates calls to this stub when services are required.
IDL (Interface Definition Language) is a superset of C++, making it easy to access. Mappings to IDL have also been defined for other languages, such as Ada and COBOL, to support linking with IDL. Objects providing services have an IDL skeleton connected to the service application's interface. When a service is called through the interface, the IDL skeleton translates the call into the implementation language of the object providing the service. After execution, the IDL skeleton translates the results back into IDL, making them accessible to the calling object.
Objects providing services to other objects while utilizing services from elsewhere require both an IDL skeleton and an IDL stub. Each object being utilized must have its own IDL stub.