Previous Up Next

Chapter 19  Other CORBA Infrastructure

This chapter briefly mentions some other optional parts of CORBA infrastructure that have not been discussed in this book. Interested readers can find details in the CORBA specification (available from www.omg.org) and in manuals for products that support these capabilities.

19.1  Real-time CORBA

As its name suggests, the Real-time CORBA specification is CORBA with several extensions that make it suitable for use in real-time applications. The author is not aware of any books that specifically address real-time CORBA programming. There is, of course, the specification document for Real-time CORBA, which is available from the OMG web site, and any CORBA product that implements this standard is likely to have additional information in its manual.

19.2  CORBA for Embedded Systems

The core part of CORBA has so many capabilities that an implementation of CORBA is likely to occupy several megabytes of memory. While modern desktop computers have sufficient RAM to run CORBA-based applications, many embedded systems have much smaller amounts of memory. In order to tailor CORBA for the constrained RAM of embedded devices, several CORBA vendors offer the ability to “subset” CORBA functionality so that if an CORBA-based application uses just a subset of CORBA’s functionality then the application can be linked with a proportionally smaller CORBA library. Some vendors have managed to squeeze a useful subset of CORBA into less than 100KB.

The Minimum CORBA specification is an OMG-standardized subset of CORBA functionality that is thought to be useful in embedded systems. The intention of defining a standardized subset of CORBA functionality is that it provides source-code portability for applications that use a subset of CORBA. However, the Minimum CORBA specification has received criticism, as some feel that the subset it defines is still too large for many embedded systems. For this reason, CORBA vendors who specialize in embedded systems usually offer their own proprietary subsets of CORBA functionality in order to minimize memory requirements.

19.3  CORBA Component Model (CCM)

In recent years, there has been a growing realization that many applications contain not just “business logic” code but also a lot of “infrastructure code” to perform tasks such as security, transactions and persistence of data. In fact, the amount of infrastructure code in an application often outweighs the amount of business-logic code. Needless to say, this is an unfortunate imbalance because the need to write vast quantities of infrastructure code increases the cost of application development.

One of the important capabilities of J2EE (Java 2, Enterprise Edition) is an application server: this specializes in providing infrastructure services that are commonly used with business-logic code. The intention is that developers can focus their efforts on writing business-logic code without having to worry about the supporting infrastructure code. The business-logic code is packaged into a JavaBean1 and this can then be deployed into a J2EE application server. The deployment is achieved by having the J2EE application server read a deployment descriptor, which is an XML document that specifies which JavaBean class should be dynamically loaded, and which infrastructure services (such as transactions or security) should be applied to it.

The CORBA Component Model (CCM) is a generalization of the concept of a J2EE application server. It is a generalization because CCM aims to provide application server functionality for business-logic code that is written in an arbitrary language, not just Java. CCM is part of the newest CORBA specification (3.0). There are several implementations of CCM available—some from CORBA vendors and some from third-party companies—but it is still too early to predict whether CCM will achieve a lot of popularity or if it is destined to be a niche product area. A very readable and detailed overview of CCM can be found in the Pure CORBA book [Bol01].


Previous Up Next