The Limitations of the CORBA Object Model

• No standard way to deploy object implementations. CORBA deployment involves distributing object implementations, installing those implementations in their execution contexts, and activating the implementations in an ORB. Developers had to develop ad hoc strategies to instantiate all objects in the system and because objects may depend on one another, implementation is complicated and non-portable.

• Limited standard support for common CORBA server programming patterns.  The CORBA family of specifications provides a rich set of features to implement servers. For example, the CORBA 2.2 specification introduced the Portable Object Adapter (POA), which is the ORB mechanism that forwards client requests to concrete object implementations. In many application domains, however, only a limited subset of these features is ever used repeatedly; yet server developers face a steep learning curve to understand how to configure POA policies selectively to obtain their desired behavior.

• Limited extension of object functionality. In the traditional CORBA object model, objects can only be extended via inheritance. Multiple inheritance in CORBA IDL is fragile because overloading is not supported; therefore, multiple inheritance has limited application.

• Availability of CORBA Object Services not defined in advance.  Developers had to develop adhoc strategies to configure and activate missing runtime services when deploying a system.

• No standard object life cycle management. No standard interface required developers to define auxiliary interfaces to control object life cycles.

 In conclusion, the inadequacies just mentioned led to implementations of objects that are hard to design, reuse, deploy, maintain, and extend. Everything that a reusable component should not be!!!