COBRA Primer
COMMON OBJECT REQUEST BROKER ARCHITECTURE (CORBA) PRIMER
PREFACE
Purpose of this document: This document intends to introduce CORBA to a beginner. It examines the requirements for a Distributed Object Management technology and explains how CORBA fulfills these requirements. Some readers may find certain sections of this document overly simplified. But, this document introduces the concepts of CORBA at a basic technological level, which, in the author’s experience, is the best approach towards understanding CORBA. Intended Audience: This document is targeted at software engineers, programmers, and analysts, who have at least an intermediate programming experience. Some familiarity with Object Oriented languages, such as C++ and Java, is a prerequisite for understanding the CORBA technology. Experience with development of large software systems is advantageous, but not necessary. Author’s qualification: Over the last few months, as a systems analyst with a financial services firm and a telecommunications company, the author’s job has involved prototyping and studying the development and performance issues related to the usage of CORBA in distributed applications. The application units were distributed across Windows95, AIX and DEC platforms. The CORBA products used were Inprise’s Visibroker and Iona’s Orbix. The languages of implementation were C++ and Java.
Purpose of this document: This document intends to introduce CORBA to a beginner. It examines the requirements for a Distributed Object Management technology and explains how CORBA fulfills these requirements. Some readers may find certain sections of this document overly simplified. But, this document introduces the concepts of CORBA at a basic technological level, which, in the author’s experience, is the best approach towards understanding CORBA. Intended Audience: This document is targeted at software engineers, programmers, and analysts, who have at least an intermediate programming experience. Some familiarity with Object Oriented languages, such as C++ and Java, is a prerequisite for understanding the CORBA technology. Experience with development of large software systems is advantageous, but not necessary. Author’s qualification: Over the last few months, as a systems analyst with a financial services firm and a telecommunications company, the author’s job has involved prototyping and studying the development and performance issues related to the usage of CORBA in distributed applications. The application units were distributed across Windows95, AIX and DEC platforms. The CORBA products used were Inprise’s Visibroker and Iona’s Orbix. The languages of implementation were C++ and Java.
INTRODUCTION
While distributing the functionality of an application across sub-systems seem to be the logical way to design a software system today, it was not too long ago that these systems tended to be monolithic. Though the drawbacks with monolithic systems were well understood, development of distributed applications proved tedious and quite unattractive until more recently, mostly due to the lack of infrastructure to aid the development of such systems. Among the reasons often cited for moving from monolithic to distributed-systems are improved usage of resources and increased ease of enhancement and maintenance. A number of products and technologies have appeared in the market in the last few years to facilitate what is known as Distributed Object Management (DOM). DOM provides for the distribution of components, or objects, in a system across multiple hardware resources and platforms, which would then communicate with each other over well-defined interfaces. DOM products attempt to address the heterogeneous nature of resources, and provide a simple and robust communication mechanism that insulates the developer from the complexities of the underlying network communication. Distributed Component Object Model (DCOM), from Microsoft, and Common Object Request Broker Architecture (CORBA), from the Object Management Group (OMG), have popularized the DOM technology. This document attempts to introduce CORBA to a beginner. In doing so, this document will examine some of the predecessors of CORBA that were used to solve the problems with the development of distributed applications, and study the advantages that CORBA has to offer over these mechanisms.
While distributing the functionality of an application across sub-systems seem to be the logical way to design a software system today, it was not too long ago that these systems tended to be monolithic. Though the drawbacks with monolithic systems were well understood, development of distributed applications proved tedious and quite unattractive until more recently, mostly due to the lack of infrastructure to aid the development of such systems. Among the reasons often cited for moving from monolithic to distributed-systems are improved usage of resources and increased ease of enhancement and maintenance. A number of products and technologies have appeared in the market in the last few years to facilitate what is known as Distributed Object Management (DOM). DOM provides for the distribution of components, or objects, in a system across multiple hardware resources and platforms, which would then communicate with each other over well-defined interfaces. DOM products attempt to address the heterogeneous nature of resources, and provide a simple and robust communication mechanism that insulates the developer from the complexities of the underlying network communication. Distributed Component Object Model (DCOM), from Microsoft, and Common Object Request Broker Architecture (CORBA), from the Object Management Group (OMG), have popularized the DOM technology. This document attempts to introduce CORBA to a beginner. In doing so, this document will examine some of the predecessors of CORBA that were used to solve the problems with the development of distributed applications, and study the advantages that CORBA has to offer over these mechanisms.