Reading
Common Object Request broker (CORBA)
CORBA is a middleware layer, which, like Java's RMI facility, is designed to support distributed (remote) objects. The key difference between it and Java's RMI facility isn't philosophical -- instead, it is quite practical.Java's RMI facility was designed to be as transparent as possible -- not as interoperable as possible. Although the Java Native Interface does operate with other environments that conform to the JNI spec, a general solution to the general problem was not the concern of the good folks at Sun.
ORBA was developed by the Object Management Group (OMG), and industry group consisting of hundred of companies. For this group, interoperability was the primary concern. Unfortunately, an 800-member group can create quite a large committee -- and CORBA seemingly has a feature for each member!
The CORBA Object Model
As we've already discussed, interoperability was a primary concern during the design of CORBA. As a result, it does not require an object-oriented language to implement a CORBA object, nor does it require one to make use of a CORBA object. Instead, the client envornment must simply be capable of making method calls, and the server must simply be able to implement its own interface specification.CORBA allows for the passing of remote object references to CORBA objects, but does not allow the serialization of other objects. The reason for this is, again, interoperability -- not all languages support objects (but, if they couldn't interface with CORBA, the question would be null).
CORBA methods support three different types of parameters: in, out, and inout. They sound like exactly what they are. in is a copy-by-value parameter. out is basically a return value. And, inout is the combination of the two -- it is copied by value in, and copied by value out. Although, as you know, the semantics are not identical, inout is often used to emulate pass-by-reference.
As was the case with Java, objects that implement IDL interfaces are passed by reference (not copied), others are passed by value.
In CORBA, all object attributes are changed by invoking methods. So, if public attributes are specified for objects, they are implemented as private, but with setter adn getter methods.
CORBA does implement one feature i'd like other environments to consider: read only attributes for objects. In other words, attributes that can be read by anyone, but only changed by the object, itself. These are implemented by creating only getter methods.
CORBA implements an exception model similar to C++ or Java, but the nomenclature is slightly different. In CORBA, exceptions are not thrown, instead, they are raised.
CORBA also supports non-blocking methods, known asoneway methods. These are typically used to implement callbacks, as are common in event-driven programming models.
Servers vs. Servants
The CORBA model involces servers and servants. The server is basically the "main" program that creates the servants and registers them in the repositories (like the Java registry). The servant classes are those that actually implement remote objects by implementing an IDL-described interface.
The IDL, Itself
The IDL specification for the interface of a remote object reads much like C++ or Java. To someone who has worked in either language, the syntax will look familiar, and those things that are represented a bit differently have pretty close analogs in either language.The largest container used in describing remote objects is the module, which is almost exactly like a java package. It is nothing more than a collection of related CORBA objects sharing a namespace. The closest analog it has to C++ is to a C++ namespace. Modules are useful tools, not only because they make for a more organized code base, but also because they prevetn pollution of the global name space.
Interfaces specified in IDL look much like interfaces specified in Java, the biggest differences that catch my mind are similarities with C++: the defintion ends with a semicolon (;) and inheritence uses the C++ colon (:) notation, not the Java "extends". The specification for arrays is also quite different. And, there are plenty of other difference, as well. These are just the ones that grab me off-hand. IDL is niether Java not C++.
The Common Data Representation (CDR)
In implementing Java's RMI, Sun had no concerns about interoperability -- everything as implemented for the Java language on the JVM. This eliminated the typical interoperability concern of data representation. For example, think back to XDR, which was developed by Sun to make RPC interoperably.Well, CORBA has its own analog to XDR, known as CDR. CDR defines all sorts of different types. It implements a handful of simple primitive types: shorts, longs, ints, floats, doubles, and chars (not necessarily 1-byte), booleans, octet (1-byte). CORBA also implements complex types including sequences (like vectors), strings, arrays, structs, unions, and enumerated types. As you might imagine, it does not support pointers.
Interfaces and the Stub Compiler
Again, much as was the case with ONC RPC and Java's RMI, a stub compiler is used to generate the client and server side stubs from this IDL interface. Unlike the two prior single-platform solutions, there are many different stub compilers. Each envornment must have a different stub compiler. This is because the stubs are compiled code that needs to run in a particular environment and interface with a particular language. These stub compilers, along with the Object Request Broker, which we'll discuss shortly, are implemented by the vendors, themselves. This probably would never have reached critical mass -- but for the OMG's large membership, and several key players therein.
The Object Request Broker (ORB)
Another feature of the CORBA model that is environment specific is known as the Object Request broker (ORB). it handles the communication between the client and server hosts. ORBs talk using a protocol standard known as the General Inter-ORB Protocol. The specific version used among Internet hosts is the Internet Inter-ORB Protocol (IIOP)
The Object Adapter
Another component of the CORBA model is the object adapter. It is somewhat of an environment specific glue layer. It is repsonible for maintaining the remote object reference, known as Interoperable Object References (IORs) and dispatching incoming messages from the ORB to the local object via the skeleton. It also handles the activation of non-existant objects. In other words, if a service is registered, and an instance of the class does not yet exist, the object adapter can create one. Although we didn't discuss it, Java RMI now also has the ability to activate objects.
The Implementation Repository
Much like ONC RPC made use of the portmapper and Java 's RMI made use of the RMIregistry, CORBA has an implementation repository, which registers services by their object adapter. An entry in the repository is basically a tuple: <object adapter, pathname for implementation, host:port>The repository can locate running servers, as well as use the object adapter to activate new instances on-demand.
The Interface Repository and Dynamic Stubs and Skeletons
With ONC RPC, a client needed to have all of the necessary stub files at compile time. Java, which is a homogeneous environment supporting dynamic binding, is much more liberal. As we disccused, clients can automatically download the necessary stubs using HTTP.But, CORBA has a tougher problem. Since the environment is heterogenous, and the vendors write the comilers that generate the stubs -- the server might not even possess the right stub. In fact, the client envornment may not even have existed at the time the server's remote objects were compiled.
One solution might be to burden the server-side of things and require that it stay up-to-date and keep a database of these stubs. But, that would be almost impossible -- and some languages don't support dynamic binding, so it couldn't work and be interoperable.
So, instead, CORBA maintains a server-side interface repository and its own dynamic dispatch mechanism. Upon request by a client, the interface repository provides the details of how to marshall a message to the client. The client then, at runtime, constructs the request, sends it to the server, and the reverse happens. It is much slower than a static approach -- but gets the job done. CORBA also maintains a similar mechanism for dynamic skeletons on the server-side. They allow for late-binding (dynamic dispatch) of incoming messages to the appropriate object.
CORBA Services
CORBA objects can make use of several supportive services that are part of the CORBA architecture. The naming service implements a tree structure for finding CORBA objects. It is loosely DNS like in its structure adn function. The CORBA event service allows objects to register, and then get pushed notice of events via oneway methods. Another prominent example is the authentication service which allows for authentication, credential generation, accss controls, auditing, non-repudiation, &c.
"Hello World" CORBA"
Implementing "Hello World" in CORBA is a bit involved, becuase it involves downloading the specific resources for each of the client and server environments. The implementation would also have to be in a specific language.I'm going to assume that you guys can write "Hello World", download the tools and make use of them. So, I'm just going to provide the IDL interface for the program:
module HelloWorldApplication { interface HelloWorld { string sayHello (in personsName); }; };