Object Management Architecture Functional View

While the Object Management Architecture (OMA) itself isn't actively used in its original form, its key concepts and principles have been incorporated into various modern technologies and standards. Here's a breakdown of its status and influence:

• CORBA: The Common Object Request Broker Architecture (CORBA), which OMA was a part of, has seen a decline in popularity in recent years. However, it's still used in specific industries and legacy systems.
• OMG: The Object Management Group (OMG), which developed OMA and CORBA, continues to play a significant role in enterprise software. It has shifted its focus to newer standards like:
  • UML (Unified Modeling Language) for visual modeling
  • BPMN (Business Process Model and Notation) for business process modeling
  • MDA (Model-Driven Architecture) for model-driven development
• Influence on Modern Systems: OMA's core concepts, such as:
  1. Object-oriented modeling
  2. Distributed object communication
  3. Interoperability
  4. Component-based development have had a lasting impact on software engineering and influenced:
     • Service-oriented architecture (SOA)
     • Microservices
     • Cloud computing
     • Enterprise application integration (EAI)

In summary, while OMA itself might not be actively used, its legacy has shaped the evolution of software development and continues to influence modern technologies.

Understand how the components of the OMA commonly function. The OMA is designed to reuse functionality wherever possible. This is most obvious at the fundamental ORB level, where the ORB is used by all components as a communications mechanism. In addition, since the CORBAservices provide fundamental object-level functionality, components of the CORBAservices are reused in much of the CORBAfacilities specifications and even frequently reused within the CORBAservices specifications themselves. In fact, there are no usage restrictions and any part of the OMA may make use of existing OMA components.

The diagram above roughly depicts how specific portions of the OMA commonly function. Even though there are no component usage restrictions, reuse usually takes place at successively higher levels.
What this means architecturally is that CORBA applications developers will make use of both CORBAfacilities and CORBAservices, while the CORBAfacilities will make use of many of the CORBAservices, and all of the components will make use of the ORB to provide CORBA communication. The bulk of the remaining concepts that make up the CORBA specification are based upon the simple but powerful Object Management Architecture (OMA) and the fundamental request/reply services provided by the ORB. But before we begin looking deeper into CORBA, we will take an opportunity in the next lesson to analyze our fundamental understanding of CORBA.

CORBA provides platform-independent programming interfaces and models for portable distributed object-oriented computing applications. Its independence from programming languages, computing platforms, and networking protocols makes it highly suitable for the development of new applications and their integration into existing distributed systems. Like all technologies, CORBA has unique terminology associated with it. Although some of the concepts and terms are borrowed from similar technologies, others are new or different. Understanding these terms and the concepts behind them is key to having a firm grasp of CORBA itself. The most important terms in CORBA are explained in the following list. A CORBA object is a "virtual" entity capable of being located by an ORB and having client requests invoked on it. It is virtual in the sense that it does not really exist unless it is made concrete by an implementation written in a programming language. The realization of a CORBA object by programming language constructs is analogous to the way virtual memory does not exist in an operating system but is simulated using physical memory. A target object, within the context of a CORBA request invocation, is the CORBA object that is the target of that request. The CORBA object model is a single-dispatching model in which the target object for a request is determined solely by the object reference used to invoke the request.
A client is an entity that invokes a request on a CORBA object. A client may exist in an address space that is completely separate from the CORBA object, or the client and the CORBA object may exist within the same application. The term client is meaningful only within the context of a particular request because the application that is the client for one request may be the server for another request.
A server is an application in which one or more CORBA objects exist. As with clients, this term is meaningful only in the context of a particular request. A request is an invocation of an operation on a CORBA object by a client. Requests flow from a client to the target object in the server, and the target object sends the results back in a response if the request requires one.
An object reference is a handle used to identify, locate, and address a CORBA object. To clients, object references are opaque entities. Clients use object references to direct requests to objects, but they cannot create object references from their constituent parts, nor can they access or modify the contents of an object reference. An object reference refers only to a single CORBA object.
A servant is a programming language entity that implements one or more CORBA objects. Servants are said to incarnate CORBA objects because they provide bodies, or implementations, for those objects. Servants exist within the context of a server application. In C++, servants are object instances of a particular class. The definitions of these terms will be refined in later chapters, but these definitions will be sufficient for understanding the CORBA features described in the next section.