The Common Object Request Broker (CORBA) is the response to the need for interoperability among the number of hardware and software products available today. It allows applications to communicate with one another no matter where they are located or who has designed them. What follows is a look at the architecture and specifications of this technology.
The rapid growth of internets/intranets, the advances in high speed networks, the increasing complexities in new system requirements and the movement towards componentization along with re-use, and hence lowering software development cost, are among the reasons for the increasing demand on distributed computing, and CORBA in particular.
Distributed object application development enables the re-use of existing functionality, promoting Rapid Application Development (RAD) with plug-and-play-type interaction of distributed objects. It also enables isolated development and implementation of objects without adversely affecting other components. Further, effective code maintenance, including code augmentation and systematic distribution of updates, can be achieved. In addition, thin client interfaces that connect to comprehensive server applications and data repositories in multiple locations can be implemented.
CORBA is a distributed object framework proposed by a consortium of more than 760 companies called the Object Management Group (OMG). The core of the CORBA architecture is the Object Request Broker (ORB), which acts as the object bus over which objects interact with other objects located locally or remotely. CORBA enables invocations of methods on distributed objects residing anywhere on a network as if they were local objects. CORBA employs ORBs, located on both the client and the server, to create and manage client/server communications between objects. ORBs allow objects on the client side to make requests of objects on the server side without any prior knowledge of where those objects exist, what language they are in or what operating system they are running on.
To facilitate these requests and provide ORB interoperability, OMG came up with the CORBA 2.0 specification that outlines a protocol named Internet Inter-ORB Protocol. CORBA objects are created in a specific programming language; then proxy objects called "stubs" and "skeletons" are created. A stub is compiled into the language of the client application. It contains the interface for a remote object, but not the behavior. The skeleton is compiled in the language of the target application and is installed on a server.
For example, a Java applet for banking application on the Internet might send a "pay $1,000 on mortgage" message to a stub representing the bank's application. The message then goes from the stub to an ORB running on the client to an ORB on the server. If the bank's application is written in C++, the server ORB would call a C++ skeleton, which would pass it to the C++ object responsible for executing bill payments.
A CORBA object is represented to the outside world by an interface with a set of methods. A particular instance of an object is identified by an object reference. The client of a CORBA object acquires its object reference and uses it as a handle to make method calls, as if the object is located in the client's address space. The ORB is responsible for all the mechanisms required to find the object's implementation, prepare it to receive the request, communicate the request to it, and carry the reply (if any) back to the client. The object implementation interacts with the ORB through either an Object Adapter or through the ORB interface.
Dynamic Invocation Interface enables the client to detect and invoke server objects at runtime. No IDL Stub is necessary for this type of object invocation. IDL Stubs, on the other hand, define how clients invoke server objects. ORB Interfaces are defined as general services for both the clients and server. In addition, IDL Skeleton provides static interfaces to objects of a specific type. However, Dynamic Skeleton Interface defines a generic interface for objects, regardless of type, that are not specified in the IDL Skeleton. Object Adapter handles communication between an object and the ORB. The Interface is a named collection of abstract operations or methods that represent one functionality.
There are several pros and cons to CORBA that need to be looked at before taking the step of downloading CORBA onto your system.
CORBA Pros
As far as the pros of CORBA, it offers local/remote transparency, which means that objects can invoke other services without needing location details. Also, CORBA offers strong programming language and broad platform support. CORBA gives the client static or dynamic method invocation and implementation inheritance. Lastly, it offers the client strong security, meaning that authentication, authorization, encryption, security domains and audit services are supported at the specifications level.
CORBA Cons
One disadvantage of CORBA is that there are proprietary extensions to CORBA where vendors may add nonstandard features that may sacrifice interoperability and portability. Another drawback to CORBA is that there is a lack of full specification support where products could go further to supply CORBA-specified services. CORBA also has large command sets, which will make learning an ORB vendor's particular commands a serious investment of time. Lastly, CORBA has a lack of development tools, which don't provide productivity tools for building components.
CORBA gives clients interoperability without the need to have the same operating system as a company or person that you are trying to communicate with through the Internet. There are hundreds of CORBA users all the way from major corporations to personal users. It is this diversity that makes CORBA unique
