| GNOME Frequently Asked Questions | ||
|---|---|---|
| <<< Previous | Architecture Components | Next >>> |
Network Objects is GNOME's middle name. This is how they work.
CORBA is the Common Object Request Broker Architecture. From the Open Management Group (OMG, the standards body which controls CORBA) document What is CORBA? comes the following description:
The Common Object Request Broker Architecture (CORBA), is the Object Management Group's answer to the need for inter-operability among the rapidly proliferating number of hardware and software products available today. Simply stated, CORBA allows applications to communicate with one another no matter where they are located or who has designed them(...)
The (ORB) is the middleware that establishes the client-server relationships between objects. Using an ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. The client does not have to be aware of where the object is located, its programming language, its operating system, or any other system aspects that are not part of an object's interface. In so doing, the ORB provides inter-operability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems.
In fielding typical client/server applications, developers use their own design or a recognized standard to define the protocol to be used between the devices. Protocol definition depends on the implementation language, network transport and a dozen other factors. ORBs simplify this process. With an ORB, the protocol is defined through the application interfaces via a single implementation language-independent specification, the IDL (Ed. Interface Description Language). And ORBs provide flexibility. They let programmers choose the most appropriate operating system, execution environment and even programming language to use for each component of a system under construction. More importantly, they allow the integration of existing components. In an ORB-based solution, developers simply model the legacy component using the same IDL they use for creating new objects, then write "wrapper" code that translates between the standardized bus and the legacy interfaces.
OK, enough of that stuff. Here's Todd's explanation:
Do you remember RPC? You know, Remote Procedure Calls? Sun used them as the basis for NFS and NIS. Microsoft used the Distributed Computing Environment's RPC standard as the basis for DCOM.
Well, a remote procedure call is really pretty simple. First, you define the procedure in some standard format. What is there to a procedure definition? Well, you've got the name of the procedure, the arguments which go into it, and the results which come out of it. Then you produce the client side, which tells clients how to feed in arguments and get back results, and then you build the server side, which takes in arguments and gives back results.
You can use this model to build pretty powerful systems. Just take the standard Unix file system interface, convert it to RPC, and bammo, you've got NFS. Note that as long as the inputs and outputs are thrown around in a standard way, the clients calling the procedure and the server servicing the procedure don't have to be written in the same language, running on the same machine, or even running on the same operating system or hardware. This is, truth be told, the killer feature of RPC.
However, as procedural programming (C, Perl) has been superseded by object-oriented programming (Objective C, Java, C++), you really need something more the procedures in RPC. You need something which supports objects: creating objects, accessing object data, accessing object methods, destroying objects. This is where CORBA comes in: think of CORBA as next-generation RPC, just extended to support object-oriented programming. Instead of having under RPC the following:
void foo(int bar); void baz(){return(-1);}you instead have under CORBA the following:
interface bubba{ void foo(in int bar); void baz() raises (InValidContext); }The lesson of all of this? CORBA lets one program language-independent, location-transparent object-oriented interfaces between software components. It' s cool.
I would like to include here definitions of some of the more strange CORBA terminology, so that people can easily get into the groove of what CORBA is and have a good "beck-of-the-envelope" understanding of the components involved. Whenever I refer to a non-obvious CORBA term, I intend to define it here.
Object Request Broker - (or ORB) an ORB is a piece of "middleware", as it's called, which sits between clients and servers and makes easy communication between them possible. The ORB is a conceptual entity, which sometimes takes the form of a shared library and sometimes takes the form of an external program. the ORB is responsible for establishing and destroying sessions between clients and servers and marshaling, unmarshaling, and transporting messages between them during a session.
Object Adaptor - (or OA) an Object Adaptor provides the channel through which an object server (like the gnome panel) communicates with the Object Request Broker (ORBit).
GIOP/IIOP - CORBA takes all of these object-oriented language-isms and handles carrying them between object-oriented software components (marshaling, transporting, and demarshaling). If the two pieces of software are in different locations, then it will use the GIOP protocol to move information between them. IIOP is a specification of GIOP for the Internet protocol suite; theoretically you could run GIOP over something other than IP, in which case it would be called something else. I for one can't figure out why you would want to. 8^) If any version of GIOP other than IIOP ever became important, then I'm sure that ORBit would support it, too. (Think of IIOP as HTML to GIOP's SGML.)
Additionally, there are really two parts to CORBA. There is the part which I've already described, which tells you how to do objectified RPC, how to marshal arguments, how to write IDL files, how GIOP works, etc. and then there are the "CORBA Services". These are services built on top of the basic CORBA infrastructure which make distributed object programming easier.
Perhaps the most important of these is the naming service. E.g., say that you were a program which for some reason needed spell-checking services. One really neat thing that you can do (if your CORBA implementation is nifty enough) is to call up your ORB and say "Hey! I need spell-check service. Go find it for me." The ORB then uses the naming service to see what objects are registered which provide spell-check service. It can then wake up the calling program and say "You can find the spell- check service at #867-5309." You then call up 867-5309 and, lo and behold, there's a spell check service there. Now, that might be a shared library which got mapped into your address space and you are now doing straight function calls into it, or it might be a community spell-check service in Mongolia offered as a public service by the Mongolian FreeBSD users' group over the internet via IIOP. You don't know and, except for maybe a little lag induced by the round-trip to Mongolia, you really don't care. Cool, non?
The naming service, then, allows objects to register themselves for future use. There are other CORBA services, including a transaction service, a security service, a time service, a "relationship service", which might or might not be what you think it is, and more. My copy of the CORBAservices document from March 1997 lists 14 of them.
You can find a copy of the CORBAservices specification at the OMG web page at http://www.omg.org/corba/csindx.htm. If you are interested in implementing any of them, then I'm sure that the ORBit developers would love to talk to you. (See ORBit)
Work is presently underway within the OMG to develop version 3.0, but for now GNOME is using CORBA version 2.2, which is the present standard. I have not heard what GNOME will do when 3.0 comes out.
A good jumping-off page is Linas Vepstas's CORBA page at http://linas.org/linux/corba.html.
Since there seems to be a lot of interest in the difference between CORBA and COM, I'll just mention this one other paper: http://www.research.att.com/~ymwang/papers/HTML/DCOMnCORBA/S.html, DCOM and CORBA Side by Side, Step by Step, and Layer by Layer.
Finally, the TAO project at Washington University in St. Louis has their own ORB, TAO. That group is led by Dr. Douglas Schmidt. You can find a lot of good information on his CORBA page: http://siesta.cs.wustl.edu/~schmidt/corba.html. Be sure to look around at the ACE and TAO pages while you're there; they are very good.
CORBA enables the component architecture of GNOME. It serves a role similar to that of COM/DCOM under win32.
In the beginning, the plan was to use ILU. ILU had a number of benefits, foremost among them that it supports several languages. While ILU was (and is) awfully neat, Xerox's attitude towards it was unclear, and the licensing terms proved to be fatal: ILU is not free software, and the GNOME team proved unable to get Xerox to modify the license. The GNOME project won't adopt technology which is not free software, and that was the end of that.
The project then settled upon MICO. The main attractions of MICO are that it has an Object Adaptor, it is IIOP-compliant, and it is licensed under the terms of the GPL. However, it does not presently support languages other than C++, and it used just an unbelievably amount of memory.
Still dissatisfied, the GNOMErs began work on our own ORB, called ORBit.
ORBit is intended to be multilingual; ILU proves that this is possible. Right now it only supports C, but in the future it will support other languages. (Really, we mean it! It is a very, very new project right now, which is the only reason it is C only.) It also supports GIOP/IIOP, the OMG's CORBA protocol which allows different ORBs to be able to talk to each other.
Finally, ORBit is intended to be high performance. That means low-memory and high-speed. Here, ORBit is taking a lot of cues from Flick. Elliot Lee, the instigator of the ORBit project, thinks that he can, without violating the CORBA spec, get the cost of a CORBA call darn close to that of a standard library call, where a local implementation of the requested service is available. We'll see.
The big reason is that MICO was just unworkable. it took too much memory, it was C++ only, etc. ad naus. With the recent release of the GNOME ORBit, we can start deploying CORBA in the GNOME.
(This section comes pretty much verbatim from Miguel de Icaza, Chief of the GNOMErs.)
CORBA will be used in various contexts. A set of interfaces and library routines called "Bonobo" are used to simplify and integrate applications:
Components: There are pre-packaged libraries/servers that do provide some functionality that can be used by any application like spelling servers, calendaring services and other non-GUI services.
Application embedding and in-place activation: Bonobo is a set of interfaces for providing application embedding and in-place activation which are being defined. The Bonobo interfaces and interactions are modeled after the OLE2 and OpenDoc interfaces.
GNOME Applications as service providers: GNOME applications will export their inner workings through CORBA to allow anyone to reuse their functionality. This allows scripting of the GNOME desktop as any CORBA-aware application or scripting language can invoke methods in a GNOME server (for example, a script in Perl can control remotely invoke a spreadsheet to make a graph or to make a sales report). Some people call this "Automation". Unlike the COM world, the use of CORBA makes this transparent to the implementor of a server.
Reusable controls: Another set of Bonobo interfaces deal with reusable controls. This is similar to Sun's JavaBeans and Microsoft Active-X.
Bonobo doesn't stand for anything. They are Chimpanzees' less grouchy cousins.
| <<< Previous | Home | Next >>> |
| Architecture Components | Up | Graphics in GNOME |