What are the advantages and disadvantage OF CORBA?

Answer 1

Advantages:

1.Maturity

The original version of the CORBA standard was defined in 1991. This first version of the specification was deliberately limited in scope. The OMG's philosophy was to define a small standard, let implementors gain experience and then slowly expand the standard to incorporate more and more capabilities. This "slow but sure" approach has been remarkably successful. In particular, there have been few backwards-incompatible changes to the CORBA specification. Instead, new versions of the specification have tended to add new functionality rather than modify existing functionality. Today, CORBA is extremely feature-rich, supporting numerous programming languages, operating systems, and a diverse range of capabilities-such as transactions, security, Naming and Trading services, messaging and publish-subscribe services-that are essential for many enterprise-level applications. Many newer middleware technologies claim to be superior to CORBA but actually have to do a lot of "catching up" just to match some of the capabilities that CORBA has had for a long time.

2.Open standard

CORBA is an open standard rather than a proprietary technology. This is important for a variety of reasons.

First, users can choose an implementation from a variety of CORBA vendors (or choose one of the freeware implementations). You might think that switching from one CORBA product to another would involve a lot of work. However, the amount of work involved is likely to be much less than you might think. In contrast, if you use a proprietary middleware system then switching to another proprietary middleware vendor is much more challenging.

Second, the competition between different CORBA vendors helps to keep software prices down.

3.Wide platform support

CORBA implementations are available for a wide variety of computers, including IBM OS/390 and Fujitsu GlobalServer mainframes, numerous variants of UNIX (including Linux), Windows, AS/400, Open VMS, Apple's OS X and several embedded operating systems. There are very few other middleware technologies that are available on such a wide range of computers.

4.Wide language support

CORBA defines standardized language mappings for a wide variety of programming languages, such as C, C++, Java, Smalltalk, Ada, COBOL, PL/I, LISP, Python and IDLScript. Some small organizations might use a single programming language for all their projects, but as an organization increases in size, it becomes increasingly likely that the organization will make use of several programming languages. Likewise, the older an organization is, the higher the likelihood becomes that some of its "legacy" (older) applications are implemented in one programming language and newer applications are implemented in a different programming language. For these organizational reasons, it is important for a middleware system to support many programming languages; unfortunately, not all middleware systems do so. One extreme case of this is J2EE, which supports only Java. Another extreme case is the SOAP middleware standard. SOAP applications can be built with a variety of programming languages but, at the time of writing, the SOAP standard defines only one language mapping (for Java). There may be several vendors who support, say, C++ development of SOAP applications, but each of those vendors provides their own proprietary C++ APIs. This means that there is no source-code portability of non-Java SOAP applications across different vendor products.

5.Efficiency

The on-the-wire protocol infrastructure of CORBA ensures that messages between clients and servers are transmitted in a compact representation. Also, most CORBA implementations marshal data (that is, convert data from programming-language types into a binary buffer that can be transmitted) efficiently. Many other middleware technologies also use a similarly compact format for transmitting data and have efficient marshaling infrastructure. However, there are some notable exceptions, as I now discuss.

SOAP uses XML to represent data that is to be transmitted. The verbosity of XML results in SOAP using much more network bandwidth than CORBA.1 SOAP-based applications also incur considerable CPU overhead involved in formatting programming-language types into XML format and later parsing the XML to extract the embedded programming-languages types.

Some other middleware technologies, such as IBM MQ Series, transmit only binary data, which is efficient. However, this requires that developers write the marshaling code that copies programming-language types into the binary buffers prior to transmission, and the unmarshaling code to extract the programming-language types from a binary buffer. In contrast, a CORBA IDL compiler generates the marshaling and unmarshaling code, so that developers do not need to write (and maintain) such low-level code.

6.Scalability

The flexible, server-side infrastructure of CORBA makes it feasible to develop servers that can scale from handling a small number of objects up to handling a virtually unlimited number of objects. Obviously, scalability varies from one CORBA implementation to another but, time and time again, real-world projects have demonstrated that a CORBA server can scale to handle not just a huge amount of server-side data, but also high communication loads from thousands of client applications. Most CORBA vendors will likely know of customers who have tried a different middleware technology, found that it could not scale sufficiently well and then switched to CORBA.

Disadvantages:

1. Firewall unfriendly. There's no real CORBA standard to bind an ORB and it's clients to a port or a port range, there are (only) vendor specific options.

2. Regarded as complicated. This is in some parts a prejudice, in some parts justificated: remote invocation of CORBA interfaces is at least as simple as over XMLRPC (which is regarded as easy), but the C++ language mapping predates the STL and features three different storage classes and clumsy handling of sequences - there are other examples.

3. No standard to get the initial reference for the naming service. I don't know why, but there never has been an OMG blessed standard to get an initial reference for the naming service over the network. Of course, this results in different solutions from different vendors, all using some kind of broadcast request.

4. No official perl mapping. There are at least two perl ORBs available as open source, but neither the mapping is official, nor the implementations are complete. Others may count this as an advantage, take your pick. There are a couple of other script language ORBs, though, but perl is still the favourite of sysadmins here in Europe, it seems.