No standard way to deploy object implementations:

The CORBA specification does not define a standard way to deploy object implementations in server processes, i.e., there is no standard way to distribute object implementations, install those implementations in their execution context, or activate the implementation in a particular ORB. Thus, system designers must use adhoc strategies to instantiate all objects in a system. Moreover, since objects may depend on one another, instantiating objects in a large-scale distributed system can become complicated.

Lack of support for common programming idioms for CORBA servers:

The CORBA family of specifications provides a rich set of features to implement servers. In many application domains, however, only a limited subset of those features are ever used. Consequently, it is desirable to support subsets of necessary features via tools that can generate CORBA code automatically to implement common application use-cases. 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. The POA specification provides standard APIs to register object implementations with the ORB, to deactivate those objects, or to activate object implementations on-demand. The POA is a flexible component of the CORBA programming model and provides numerous policies to configure its behaviour. However, an important class of applications only use a subset of the possible configurations of a POA, yet server developers must learn how to configure many POA policies to obtain their desired behaviour.

Difficulty extending object functionalities:

In the traditional CORBA object model, objects can be extended only via inheritance. To support new interfaces, therefore, application developers must:

1) Define a new IDL interface that inherits from all the require interfaces,
2) Implement the new interface,
3) Deploy the new implementation across all their servers.

However, multiple inheritance in CORBA IDL is fragile since overloading is not allowed in IDL due to languages like C that lack overloading. Therefore, the techniques described above have only limited applicability. Moreover, applications may need to expose the same IDL interface multiple times to allow developers to either provide multiple implementations or multiple instances of the service through a single access point. In contrast, multiple inheritance makes it impossible to expose the same interface more than once, or to determine which is the most derived interface available to clients.

Availability of CORBA Object Services is not defined a prior:

The CORBA specification does not mandate what Object Services are available at run-time. As a consequence, object developers must use adhoc strategies to configure and activate these services when planning a system.

No standard object lifecycle management:

Although the CORBA Object Service defines a Lifecycle Services, its use is not mandated. Therefore, clients often require explicit knowledge to manage the lifecycle of an object in adhoc ways. Moreover, the developers of CORBA objects controlled through the LifeCycle service must be aware of this fact, and must define auxiliary interfaces to control the object life cycle. Defining these interfaces is a tedious process, and should be automated when possible, but the earlier CORBA specifications lacked the features required to implement such automation.