Lesson 1

In this Module, we will look deeper into CORBA's core functionality and begin to uncover the details of how things work.
In this module, you will learn:

1. How CORBA clients and CORBA servers function
2. More about the key functionality of the ORB
3. CORBA interfaces and how they tie things together from end to end
4. Where the vendors stand in regards to the CORBA specification

At the end of this module, we will have explored the fundamental structure of CORBA.

The Common Object Request Broker Architecture (CORBA) is a middleware standard developed by the Object Management Group (OMG) to enable interoperability between applications running on different platforms, programming languages, and hardware. CORBA achieves this by defining a standardized communication model for distributed objects.
At its core, CORBA provides:

1. Language and Platform Independence – Applications written in different languages can communicate using CORBA.
2. Location Transparency – CORBA objects can reside anywhere on a network.
3. Standardized Communication – Uses an Object Request Broker (ORB) to mediate client-server interactions.

How CORBA Clients and Servers Function In a CORBA-based system, interaction happens through a client-server model where distributed objects communicate via stubs, skeletons, and an ORB.
1. Server-Side (Object Implementation) A CORBA server implements an object that provides services. These steps outline how a CORBA server works:

1. Define the Object Interface – Using IDL (Interface Definition Language), a developer defines the methods that the CORBA object provides.
2. Generate Stubs and Skeletons – The IDL compiler generates:
   • Client Stub (for the client-side proxy).
   • Server Skeleton (to handle method calls on the server side).
3. Implement the Object – The server provides an implementation of the object methods.
4. Register the Object with the ORB – The object is registered with the ORB, making it available to clients.

2. Client-Side (Object Invocation) A CORBA client interacts with a CORBA server by calling remote methods. The process includes:

1. Obtain the Object Reference – The client gets a reference to the CORBA object (e.g., through a Naming Service or a stringified object reference).
2. Call Methods on the Object Stub – The client makes method calls on the local stub, which acts as a proxy for the remote object.
3. ORB Handles the Communication – The ORB transparently sends the request to the server-side skeleton.
4. Server Processes the Request and Returns Data – The server executes the method and returns the result back to the client.

Key Components of CORBA

• IDL (Interface Definition Language) – Defines object interfaces independent of programming languages.
• ORB (Object Request Broker) – The middleware that manages communication between distributed objects.
• Stub and Skeleton – Auto-generated components that handle method calls transparently.
• Naming and Trading Services – Allow clients to locate and bind to CORBA objects.

Example: CORBA in Action

1. The server registers an object with the ORB.
2. A client queries the ORB (or Naming Service) for the object reference.
3. The client calls a method on the local stub.
4. The ORB routes the request to the server-side skeleton.
5. The server executes the requested method and returns the response.

Final Thoughts While CORBA has largely been replaced by modern alternatives like gRPC, RESTful APIs, and microservices architectures, it still exists in legacy enterprise applications due to its robustness in heterogeneous distributed systems.

In addition to the CORBA basics of allowing objects to communicate with each other, recall that the OMA (of which CORBA is a part) also provides additional capabilities in the form of CORBAservices and CORBAfacilities. As you'll find out, CORBAservices and CORBAfacilities provide both h horizontal (generally useful to all industries) and vertical (designed for specific industries) services and facilities.

• Build on CORBA Concepts
  The design of each Object Service uses and builds on CORBA concepts:
  1. Separation of interface and implementation
  2. Object references are typed by interfaces
  3. Clients depend on interfaces, not implementations
  4. Use of multiple inheritance of interfaces
  5. Use of subtyping to extend, evolve and specialize functionality
  Other related principles that the designs adhere to include:
  1. Assume good ORB and Object Services implementations. Specifically, it is assumed that CORBA-compliant ORB implementations are being built that support efficient local and remote access to "fine-grain" objects and have performance characteristics that place no major barriers to the pervasive use of distributed objects for virtually all service and application elements.
  2. Do not build non-type properties into interfaces A discussion and rationale for the design of object services was included in the HPSunSoft response to the OMG Object Services RFI