CORBA (Common Object Request Broker Architecture)

Common Object Request Broker Architecture

The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together. General overview
CORBA is a mechanism in software for normalizing the method-call semantics between application objects that reside either in the same address space (application) or remote address space (same host, or remote host on a network).
CORBA uses an interface description language (IDL) to specify the interfaces that objects will present to the outside world. CORBA then specifies a “mapping” from IDL to a specific implementation language like C++ or Java. Standard mappings exist for Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I and Python. There are also non-standard mappings for Perl, Visual Basic, Ruby, Erlang, and Tcl implemented by object request brokers (ORBs) written for those languages.
The CORBA specification dictates that there shall be an ORB through which the application interacts with other objects. In practice, the application simply initializes the ORB, and accesses an internal Object Adapter which maintains such issues as reference counting, object (& reference) instantiation policies, object lifetime policies, etc. The Object Adapter is used to register instances of the generated code classes. Generated Code Classes are the result of compiling the user IDL code which translates the high-level interface definition into an OS- and language-specific class base for use by the user application. This step is necessary in order to enforce the CORBA semantics and provide a clean user processes for interfacing with the CORBA infrastructure.
Some IDL language mappings are more hostile than others. For example, due to the very nature of Java, the IDL-Java Mapping is rather trivial and makes usage of CORBA very simple in a Java application. The C++ mapping is not trivial but accounts for all the features of CORBA, e.g. exception handling. The C-mapping is even more strange (since it's not an OO language) but it does make sense and handles the RPC semantics just fine. (Red Hat Linux delivers with the GNOME UI system, which has its IPC built on CORBA.)
A "language mapping" requires that the developer ("user" in this case) create some IDL code representing the interfaces to his objects. Typically a CORBA implementation (either an Open Source or commercial product) comes with a tool called an IDL compiler. This compiler will convert the user's IDL code into some language-specific generated code. The generated code is then compiled using a traditional compiler to create the linkable-object files required by the application. This diagram illustrates how the generated code is used within the CORBA infrastructure:

This figure illustrates the high-level paradigm for remote interprocess communications using CORBA. Issues not addressed here, but that are accounted-for in the CORBA specification include: data typing, exceptions, network protocol, communication timeouts, etc. For example: Normally the server side has the Portable Object Adapter (POA) that redirects calls either to the local servants or (to balance the load) to the other servers. Also, both server and client parts often have interceptors that are described below. Issues CORBA (and thus this figure) does not address, but that all distributed systems must address: object lifetimes, redundancy/fail-over, naming semantics (beyond a simple name), memory management, dynamic load balancing, separation of model between display/data/control semantics, etc.
In addition to providing users with a language and a platform-neutral remote procedure call specification, CORBA defines commonly needed services such as transactions and security, events, time, and other domain-specific interface models.
Key features
Objects By Reference
Objects are used in an application "by reference". This reference is either acquired though a "stringified" URI string, NameService lookup (similar to DNS), or passed-in as a method parameter during a call.
Object references are "lightweight" objects matching the interface of the "real object" (remote or local). Method calls on the reference result in subsequent calls to the ORB and blocking on the thread while waiting for a reply, success or failure. The parameters, return data (if any) , and exception data are marshaled internally by the ORB according the local language/OS mapping.
Data By Value
The CORBA Interface Definition Language provides the language/OS-neutral inter-object communication definition. CORBA Objects are passed by reference, while data (integers, doubles, structs, enums, etc) are passed by value. The combination of Objects by reference and data-by-value provides the means to enforce strong data typing while compiling clients and servers, yet preserve the flexibility inherent in the CORBA problem-space.
Objects by Value (OBV)
Apart from remote objects, the CORBA and RMI-IIOP define the concept of the OBV. The code inside the methods of these objects is executed locally by default. If the OBV has been received from the remote side, the needed code must be either a priori known for both sides or dynamically downloaded from the sender. To make this possible, the record, defining OBV, contains the Code Base that is a space separated list of URLs from where this code should be downloaded. The OBV can also have the remote methods.
The OBV's may have fields that are transferred when the OBV is transferred. These fields can be OBV's themselves, forming lists, trees or arbitrary graphs. The OBV's have a class hierarchy, including multiple inheritance and abstract classes.
CORBA Component Model (CCM)
CORBA Component Model (CCM) is an addition to the family of CORBA definitions. It was introduced with CORBA 3 and it describes a standard application framework for CORBA components. Though not dependent on "language independent Enterprise Java Beans (EJB)", it is a more general form of EJB, providing 4 component types instead of the 2 that EJB defines. It provides an abstraction of entities that can provide and accept services through well-defined named interfaces called ports.
The CCM has a component container, where software components can be deployed. The container offers a set of services that the components can use. These services include (but are not limited to) notification, authentication, persistence and transaction management. These are the most-used services any distributed system requires, and, by moving the implementation of these services from the software components to the component container, the complexity of the components is dramatically reduced.

What is DDE and why is it totally different from COM?
DDE stands for Dynamic Data Exchange. That's exactly what it does, and nothing more. It sends data between applications using Windows messages according to a documented protocol. Saying that DDE is old-fashioned and is being replaced by COM is something you see repeated parrot fashion over and over again. DDE and COM do not work in the same way and they solve different problems. Here are some points of difference:
COM is synchronous, one party makes subroutine calls into the other and must wait until the call returns. If the called component is busy the caller is blocked until it becomes free. DDE is asynchronous, a well-programmed client sends a Windows message to the server and carries on processing. Windows holds the message and sends it to the server when the server is ready to process it.
COM is complex to program but powerful. The client can manipulate objects within the server as if they belonged to the client. DDE is straightforward to implement but all it can do is transmit data. It can only control another application because the recipient can treat data as a command.
COM works well when the client creates an instance of a server object or application for its own use. Programming a continuously running server, to which clients can attach when they wish, is possible but tricky. DDE of itself is incapable of creating objects (although OLE1 used it as a transport mechanism). The essence of DDE is that clients attach to an already running server.
Applications using COM almost always need support DLLs such as the VB runtimes or MFC. Programs using DDE can be mean and lean and do not need extra support DLLs.
COM interfaces are tightly specified and contained within the software component. Some documentation is normally built into the interface. The user of a COM component knows exactly which methods are available and how to call them. DDE interfaces are specified only in external documentation.
Because of the tight interface specification, upgrading COM components can be a nightmare. With DDE the server or client can be changed independently.
COM is frequently used to communicate with a DLL in the same process space (called an in-process server). Such as server is often termed an ActiveX control and has the extension OCX. Our DDClient and DDServer Visual Basic components are in-process servers. Using DDE to communicate between components of the same application is possible but has no benefits.
COM communication with a remote machine is called DCOM (Distributed COM). If you make a DCOM call to a remote machine which does not respond, your program (or at least the thread making the call) is stuck. DCOM has a fixed built-in timeout which you cannot change. DDE with a remote machine is called NETDDE, it is used by the Hearts game and Chat which come with Windows. Timeout is controlled by the program.
Under Windows 3.1 and 9x it is possible to crash the system by badly programmed DDE, because the message queue can be filled. NT does not crash in this way, COM does not suffer from the problem at all.
DDE is totally "Bit blind", neither the client nor server can tell whether the other application is 16-bit or 32-bit. Indeed, the server cannot know whether the client is on the same computer or not. Connecting 16 to 32 bit COM components is not usually possible.
It is easy to see from the above points why a DDE server is the most widely used way of providing data obtained from any form of hardware interface. In particular:
The server can run continuously.
It will probably serve a wide range of clients but can be updated without requiring them all to be recompiled.
It is immune from the problems associated with different versions of the system DLLs on different machines.
It can be small and self-contained.
Clients cannot interfere with the running of the server by being slow or busy
DDE mechanism overview
Making the connection between a DDE server and a DDE client
DDE uses a hierarchy of three names, the SERVICE, the TOPIC and the ITEM. A DDE CONVERSATION is established using the service and topic names as a pair. It is convenient to name the pair a CHANNEL. It is roughly the equivalent of a telephone number. The item part of the name is used to identify the particular data or command being requested by the client once a conversation is established.
To establish a conversation a DDE client specifies the service/topic name pair (channel) it wishes to connect to. Windows broadcasts the request to all top level windows. The first server to accept is connected to the client and so a conversation is established.
The client may leave either the topic or the service name unspecified, or both. This is known as a WILDCONNECT. For example, if the topic name is not specified conversations may be established on all the topics supported by a server. If both are unspecified conversations may be established on all topics with all servers. It is up to the server whether to accept such a connection, and if so on what topics.
Unlike a telephone connection, any number of quite separate conversations may be in progress on the same channel, even between the same two applications. This is often done so that only one item of information or one type of command is handled by each conversation. There is no interaction at all between different conversations using the same pair of service and topic names.
Transactions within a DDE conversation
Just as the client application initiates the establishment of a conversation, it also initiates all the transactions. It can request data from the server as a once off (a REQUEST transaction), request being kept up to date about an item of data (an ADVISE or NOTIFY transaction), give commands to the server (an EXECUTE transaction) and send unsolicited data to the server (a POKE transaction). The client associates with all these transactions the item part of the identification. It informs the server of the data required by the client in a request transaction, the action to be taken by the server in an execute transaction or the data being passed to the server in a poke transaction.
It is also possible to use the item part of the name as the data itself, with the topic name indicating the context in which the data is to be used.
Raw DDE has no timing constraints except the order in which messages are sent. At the Windows message level, there is no distinction between synchronous and asynchronous transactions. Synchronous and asynchronous operation is a feature of the DDE management library, or DDEML.
To find out more go to How to get further information
Question and topic list DDE Software downloads Home page