Middleware Technologies [MCA II Yr, Anna University] by Roy Antony Arnold

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.

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.

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

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

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.

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.