CORBA (Common Object Request Broker Architecture) is a set of standards which define what is called a distributed object system. These standards were written by the OMG (Object Management Group). The OMG is made up of more than 700 firms who are pursuing common agreement on standard protocols. CORBA defines the protocol for interaction between objects. As stated, these object may be written in different programming languages, run on different operating systems, live on different machines.
For example, let's imagine I have an Apple object with the eat_me method. This object was coded into some library written in C which lives on mathieu.rezel.enst.fr, an old 486 running Windows, with support for CORBA. Now, if I wish, I can ask the Apple Object for its eat_me method from a C++ program from anywhere on the network. For example, from calisson.enst.fr, an ULTRA 5 workstation, I can get the result of the eat_me method executed on the mathieu PC.
The nice thing about all this is that the programmer doesn't have to care whether the method was executed on a local machine or remote. All of this is taken care of by CORBA. The object itself could have been on the same machine I made the call from: no one needs to know. Furthermore, such objects could be written in any language and calls to them may be done with any other language (provided the language has CORBA-support).
To achieve all of this, CORBA defines a set of communication protocols between objects. The communication medium is the ORB (Object Request Broker). The ORB will take care of sending the messages between objects: objects may be on the same machine the call is made or on another machine on the network. In the first case, the ORB will optimize the message exchange. In the second case, calls will be made using the IIOP or the GIOP protocols on top of the existing network layers.
The ORB is specific to the CORBA implementation (ORBit has its own ORB), but ORBs from different firms will communicate transparently, thanks to the common protocol. This means that you may use some ORB and build objects with it and later, if you decide that this ORB sucks (e.g. it is too slow), you may use another one and have the same objects interact.
Here is a diagram which explains these mechanisms:
Figure 1. ORB communication
When you make your call to the object, you must create the correct messages: this is what the stub is used for. The skeleton is responsible for translating these messages to the correct calls to the objects. The programmer is responsible for writing the stub and skeleton, but some tools are there to help you, as we will see later. The stub acts a a local 'representative' or proxy of the remote object, thus enabling working with a remote object as if it were local. The skeleton does the exactly the opposite thing. Note for COM-programmers: a CORBA-stub is what's called a proxy in COM-lingo, while a skeleton plays roughly the same role a COM stub does.
This is the basic CORBA-architecture, but CORBA is much more: CORBA's aim is to create a distributed object system. The ORB is the framework for the objects, but CORBA also defines a rich set of objects and pseudo-objects (object facades provided by the ORB) to deal with various issues programmers face when working with distributed objects:
First, we have CORBA Services, which allow you to have, for example, naming services, security services (object authentication, communication encryption...), and license services (to control the users use of the software). There are 16 services nowadays, but very few are implemented in ORBit (which is the CORBA implementation we will use).
Next, the CORBA facilities are build on top of the CORBA services. CORBA facilities are a set of objects specific to industry branches: medical, law,..