| Lesson 4 | The distributed computing view |
| Objective | Conceptual layers of core CORBA architecture |
Fundamental CORBA Architecture - Distributed Computing View
What are the conceptual layers of the core CORBA architecture?
At its heart, the CORBA model is based upon the concept of distributed services and service users.
This simple model is repeated many times in the CORBA architecture so that distributed application objects that provide services play the role of CORBA server,
while the application objects that make use of the services play the role of CORBA client.
The SlideShow below graphically displays this relationship.
At its heart, the CORBA model is based upon the concept of distributed services and service users.
This simple model is repeated many times in the CORBA architecture so that distributed application objects that provide services play the role of CORBA server,
while the application objects that make use of the services play the role of CORBA client.
The SlideShow below graphically displays this relationship.
Conceptual Layers of core CORBA Architecture Version 3.4
The Common Object Request Broker Architecture (CORBA), in its version 3.4, is designed with a multi-layered approach that facilitates communication between various computer systems irrespective of their underlying hardware, operating systems, and programming languages. This architecture is maintained by the Object Management Group (OMG). Here are the conceptual layers of the core CORBA 3.4 architecture:
In summary, the core architecture of CORBA 3.4 is designed to provide a robust framework for the development and deployment of distributed, interoperable, multi-language applications. It achieves this through its layered approach, encompassing everything from basic communication (ORB) and interface definition (IDL) to high-level services and component models.
- Object Request Broker (ORB) Core: At the heart of CORBA is the ORB, which is responsible for establishing the client-server relationships and managing the communication between them. The ORB handles request and response messages, locates the appropriate object implementations, and marshals and unmarshals data.
- IDL (Interface Definition Language) and IDL Compiler: CORBA uses IDL to define the interfaces that objects present to the outside world. IDL is language-neutral, allowing for the definition of services and interfaces independent of the programming language used to implement them. The IDL compiler generates client and server stubs in various programming languages.
- Dynamic Invocation Interface (DII) and Dynamic Skeleton Interface (DSI): These interfaces allow for dynamic creation and invocation of requests and responses. DII is used by clients to construct requests dynamically at runtime, whereas DSI allows servers to handle requests without compile-time knowledge of the interface.
- Portable Object Adapter (POA): The POA is responsible for managing the lifecycle of CORBA objects, their references, and their request servicing policies. It decouples the client-side implementation from the server-side implementation, making it easier to manage objects.
- Services: CORBA defines a set of services that provide essential functionalities for distributed objects, such as Naming Service, Transaction Service, Security Service, and more. These services are reusable components that enhance the capabilities of the ORB.
- CORBA Component Model (CCM): Introduced in CORBA 3, CCM is a model for creating and deploying components in a CORBA environment. It builds on the basic object model of CORBA and provides additional features for component packaging, deployment, and management.
- Messaging: This layer includes support for asynchronous communication, Quality of Service (QoS) configurations, and reliable messaging, enhancing the robustness and flexibility of CORBA-based systems.
- Interoperability Protocols: These protocols, such as General Inter-ORB Protocol (GIOP) and Internet Inter-ORB Protocol (IIOP), enable interoperability among different ORB implementations, ensuring that systems can communicate regardless of their underlying ORB technology.
In summary, the core architecture of CORBA 3.4 is designed to provide a robust framework for the development and deployment of distributed, interoperable, multi-language applications. It achieves this through its layered approach, encompassing everything from basic communication (ORB) and interface definition (IDL) to high-level services and component models.
Computer Networks are Heterogeneous
Computer networks typically are heterogeneous. For example, the internal network of a small software company might be made up of multiple computing platforms. There might be
Small sections of a given network may be homogeneous, but the larger a network is, the more varied and diverse its composition is likely to be. There are several reasons for this heterogeneity. One obvious reason is that technology changes over time. Because networks tend to evolve rather than being built all at once, the best technologies from different time periods end up coexisting on the network. In this context, "best" may refer to qualities such as the lowest cost, the highest performance, the least expensive mass storage, the most transactions per minute, the tightest security, the flashiest graphics, or other qualities deemed important at the time of purchase. Another reason for network heterogeneity is that one size does not fit all. Any given combination of computer, operating system, and networking platform will work best for only a subset of the computing activities performed within a network. Still another reason is that diversity within a network can make it more resilient because any problems in a given machine type, operating system, or application are unlikely to affect other networked systems running different operating systems and applications.
The factors that lead to heterogeneous computer networks are largely inevitable; thus, developers of practical distributed systems, whether they like it or not, must cope with heterogeneity. Whereas developing software for any distributed system is difficult, developing software for a heterogeneous distributed system sometimes borders on the impossible. Such software must deal with all the problems normally encountered in distributed systems programming, such as the failure of some of the systems in the network, partitioning of the network, problems associated with resource contention and sharing, and security-related risks. If you add heterogeneity to the picture, some of these problems become more acute, and new ones crop up.
The next lesson highlights the central role that the ORB plays in CORBA.
- a mainframe that handles transactional database access for order entry,
- UNIX workstations that supply hardware simulation environments and
- a software development backbone,
- personal computers that run Windows and provide desktop office automation tools, and
- other specialized systems such as network computers, telephony systems, routers, and measurement equipment.
Small sections of a given network may be homogeneous, but the larger a network is, the more varied and diverse its composition is likely to be. There are several reasons for this heterogeneity. One obvious reason is that technology changes over time. Because networks tend to evolve rather than being built all at once, the best technologies from different time periods end up coexisting on the network. In this context, "best" may refer to qualities such as the lowest cost, the highest performance, the least expensive mass storage, the most transactions per minute, the tightest security, the flashiest graphics, or other qualities deemed important at the time of purchase. Another reason for network heterogeneity is that one size does not fit all. Any given combination of computer, operating system, and networking platform will work best for only a subset of the computing activities performed within a network. Still another reason is that diversity within a network can make it more resilient because any problems in a given machine type, operating system, or application are unlikely to affect other networked systems running different operating systems and applications.
The factors that lead to heterogeneous computer networks are largely inevitable; thus, developers of practical distributed systems, whether they like it or not, must cope with heterogeneity. Whereas developing software for any distributed system is difficult, developing software for a heterogeneous distributed system sometimes borders on the impossible. Such software must deal with all the problems normally encountered in distributed systems programming, such as the failure of some of the systems in the network, partitioning of the network, problems associated with resource contention and sharing, and security-related risks. If you add heterogeneity to the picture, some of these problems become more acute, and new ones crop up.
The next lesson highlights the central role that the ORB plays in CORBA.
