Lesson 8

In this module, we walked through the low-level functioning of CORBA clients and servers and checked the major vendors to be sure that their products are compliant with the CORBA specification. As it turned out, they all were, but as we will see in later Modules, this universal support does not continue to be the rule.

• Open Standard
  CORBA is an open standard rather than a proprietary technology. This is important for a variety of reasons.
  1. First, users can choose an implementation from a variety of CORBA vendors or choose one of the freeware implementations.
  2. You might think that switching from one CORBA product to another would involve a lot of work.
  3. The amount of work involved is likely to be much less than you might think, particularly if you follow the practical advice about how to increase the portability of CORBA-based applications.
  In contrast, if you use a proprietary middleware system then switching to another proprietary middleware vendor is much more challenging. The competition between different CORBA vendors helps to keep software prices down.

CORBA (Common Object Request Broker Architecture) is an open standard, which offers several advantages:

1. Vendor Independence: Since CORBA is an open standard defined by the Object Management Group (OMG), it allows users to select from multiple vendors or even opt for open-source implementations. This flexibility can prevent vendor lock-in, where switching providers would otherwise be prohibitively expensive or complex.
2. Interoperability: CORBA's standards ensure that different implementations can communicate with each other. This means that even if you use products from different vendors, they should, in theory, work together seamlessly as long as they comply with the standard specifications.
3. Portability: While switching from one CORBA implementation to another might still require some work, the design of CORBA inherently supports portability. Here are some practical tips to enhance this:
   
   • IDL (Interface Definition Language): By strictly adhering to IDL for defining interfaces, you ensure that the core communication protocols remain consistent across different implementations.
   • Abstraction Layers: Use abstraction layers in your application design. This means keeping CORBA-specific code separate from business logic so that changes in the CORBA environment don't necessitate rewrites of the entire application.
   • Avoid Vendor-Specific Features: Stick to standard features as much as possible to avoid dependency on proprietary extensions which might not be supported by all vendors.
   • Testing for Portability: Regularly test your application with different CORBA ORBs (Object Request Brokers) to ensure it can function across different environments.
   • Documentation and Comments: Maintain good documentation about which parts of your code are CORBA-specific, making future migrations easier.
4. Community and Support: Being an open standard, CORBA benefits from a broad community, which can lead to better support, more development tools, and a wealth of shared knowledge and solutions to common problems.

The work involved in switching might include updating code to ensure it adheres strictly to the standards, handling different CORBA implementations' quirks, and possibly addressing performance optimizations specific to the new ORB. However, with careful design and adherence to the standards, the migration should indeed be less daunting than one might initially assume.

Finally, many proprietary middleware technologies are designed with the assumption that developers will build all their applications using that particular middleware technology, and so they provide only limited support for integration with other technologies. In contrast, CORBA was designed with the goal of making it easy to integrate with other technologies. Indeed, the CORBA specification explicitly tackles integrations with TMN, SOAP, Microsoft's (D)COM and DCE (a middleware standard that was popular before CORBA). Furthermore, many parts of J2EE borrow heavily from concepts in CORBA, which makes it relatively easy to integrate J2EE and CORBA. Some vendors sell gateways between CORBA and J2EE that make such integration even easier. Several CORBA vendors sell COM-to-CORBA and/or .NET-to-CORBA gateways. This provides a very pragmatic solution to organizations that wish to write GUI applications in, say, Visual Basic on Windows that act as clients to server applications on a different type of computer, such as UNIX or a mainframe. The Visual Basic GUI can be written as a COM/.NET client that thinks it is talking to a COM/.NET server, but in fact communicates with a gateway that forwards on requests to a CORBA server.

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.
The next module focuses on interoperability and shows how CORBA is designed to be as interoperable as possible at every level.

Before we move on, take this short quiz about the material we have just covered.
Corba Architecture - Quiz