[10] WHY USE CORBA
(Part of the CORBA FAQ, Copyright © 1996-99)

[10.1] WHAT IS THE BASIC FUNCTIONALITY PROVIDED BY CORBA?

At the most basic level, CORBA is a standard for distributed objects. CORBA allows an application to request an operation to be performed by a distributed object and for the results of the operation to be returned back to the application making the request. The application communicates with the distributed object that is actually performing the operation. This is basic client/server functionality, where a client issues a request to a server and the server responds back to the client. Data can pass from the client to the server and is associated with a particular operation on a particular object. Data is then returned back to the client in the form of a response.

[ Top | Bottom | Previous section | Next section ]

[10.2] WHAT ADVANTAGES DOES CORBA PROVIDE?

1. CORBA supports many existing languages. CORBA also supports mixing these languages within a single distributed application.
2. CORBA supports both distribution and Object Orientation.
3. CORBA is an industry standard. This creates competition among vendors and ensures that quality implementations exist. The use of the CORBA standard also provides the developer with a certain degree of portability between implementations. Note: application source is not 100% portable between different CORBA products.
4. CORBA provides a high degree of interoperability. This insures that distributed objects built on top of different CORBA products can communicate. Large companies do not need to mandate a single CORBA product for all development.
5. Over 600 companies back CORBA, including hardware companies, software companies, and cable companies, phone companies, banks, etc.

[ Top | Bottom | Previous section | Next section ]

[10.3] WHAT OTHER TYPES OF DISTRIBUTED SYSTEMS DOES CORBA COMPETE WITH?

• DCE
• DCOM
• EJB
• RPC (remote procedure calls)
• Shared memory based interaction
• Named Pipe communication
• Socket level programming
• Message Queuing
• Other IPC (inter-process communication) mechanisms
• Database tables, triggers and polling

[ Top | Bottom | Previous section | Next section ]

[10.4] IS CORBA {BETTER,WORSE} THAN {DCOM,COM+,JAVA RMI,DCE,ETC}?

[Recently created (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]

This is not a wise question, and is an invitation to a flame war. Please don’t ask this question on the newsgroup since it will produce a lot more heat than light. Plus it’s nonsensical since the answer of whether you should use CORBA or Java RMI or ... will depend mostly on peculiarities business and/or technical constraints of your particular team, organization, project, etc.

In any event, please don’t ask this sort of question on comp.object.corba. It’s an invitation to a flame war, since no answer can ever, ever contain enough if’s and’s and but’s to be precisely correct for all situations. For example, to properly answer the question you’d have to factor in many business considerations such as the following:

• what skill sets does your team already have?
• what is your management willing to pay for up-front costs?
• what is your management willing to pay for ongoing maintenance?
• how likely is cross-platform networking in the future? near-term? long-term?
• what happens if your company goes global?
• what happens if your company wants to be acquired by someone else?
• what if your company wants to acquire someone else?
• etc., etc., etc.

Again, please don’t ask this question on comp.object.corba -- it’s flame bait.

[ Top | Bottom | Previous section | Next section ]

[10.5] OKAY, OKAY, BUT NOW TELL THE TRUTH: IS CORBA {BETTER,WORSE} THAN {DCOM,COM+,JAVA RMI,DCE,ETC}?

[Recently created (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]

Note: Please read the previous FAQ before reading this one.

Here’s the truth: Business issues normally dominate technical issues.

In other words, there’s no way to answer the question without knowing the business considerations of the organization that is deciding to use these technologies. There’s no universal notion of better and worse in these things. The vast majority of these decisions are dominated by business considerations, not by technical considerations.

The issues that really end up mattering are things like availability and maturity of a development environment for the development machine, availability of runtime environment(s) for the deployment machine(s), licensing/legal issues of the runtime and/or development environments, availability of trained developers, availability of consulting services, corporate culture/politics, what your company’s customers are using, what your company’s vendors are using, any CEO-level aliances your company has, who is sitting on the Board, etc. These business considerations generally play a much greater role than milliseconds per remote invocation, space overhead per object, etc.

People who argue in favor of one technology over another in a purely technical manner (i.e., who ignore the dominant business issues) damage their own careers. Their management often regards them as techie weenies, and as a result doesn’t listen to them. So do yourself and your company a favor: don’t be a technology bigot. Use the right tool for the job. Recognize that no tool is perfect, and instead figure out what is practical and what your people can be expected to succeed with.

Please note: the issue is not whether life ought to be this way. The issue is merely to recognize and accept that it is this way.

[ Top | Bottom | Previous section | Next section ]

[10.6] IF YOU’RE ONLY GOING TO USE JAVA, IS CORBA EXCESSIVE?

[Recently created (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]

Note: Please read the previous FAQ before reading this one.

The truthful answer is that this question cannot be answered without a lot more information. This is another example of technology decisions being made without knowing the business considerations. For example, consider the following factors:

1. How do you know you’re only going to use Java? You might want to take that position, but how do you know that it is both practical and sustainable in the long run, despite newer technologies, performance problems, product immaturity, etc. It’s rare indeed that you can know that pure Java will be the right decision forever and ever and ever.
2. Is CORBA excessive? Depends on what you want, and what you mean by CORBA. There are a lot of Services coming down the road. What are these worth to you? Which CORBA are we talking about: today’s, tomorrow’s or the big CORBA in the sky with all the Services? How smart are the users, and what are they doing? What other middleware is available, etc?
3. For that matter, which Java are we talking about: the one on the market today or the good stuff coming down the road?
4. Most browsers have CORBA built into them already, excessive or not. Are you sure you want to ignore all that stuff?

[ Top | Bottom | Previous section | Next section ]

 E-mail us