但传统的Corba有它的缺点：

　　No standard way to deploy object implementations:

　　没有标准的配置对象应用的方式。如：没有标准的方式分布对象应用，在它们的执行上下文安装，或在特定的ORB激活应用。因此，系统设计者必须用ad hoc策略去实例化在系统中的对象。进一步说，因为对象可能要互相依靠，实例化可能在一个大型的系统变得复杂。

　　Lack of support for common programming idioms for CORBA servers:

　　Corba 的说明提供了丰富的应用服务的特性。在某些的应用域，仅仅有限的特性被应用。结果，通过能自动产生应用普通应用实例Corba代码的工具能支持必须的特性，是期望的。如：在Corba 2.2说明中，介绍了POA，它是一个引导客户端的请求到具体的对象应用的机制。POA提供了标准的API去登记对象应用，去活，或激活对象应用。POA是灵活的Corba编程模型模块，并且提供了大量的规则配置它的行为。然而，重要一类应用仅仅用其中的一部分，但是服务开发者不得不去学习如何配置许多的规则，为了得到想要的行为。

　　Difficulty extending object functionalities:

　　传统的Corba对象模型，对象仅能通过继承来扩展它的应用。为了支持新的新的界面，应用开发者必须：1 定义新的，从要求的界面继承，的IDL界面； 2 应用新的界面；3 分配应用到服务器端。然而，多重继承在Corba Idl 是易碎的，因为重载在IDL是不可以的，因为像C的语言缺乏重载。

　　因此，以上的介绍限制了应用。进一步说，应用可以需要暴露相同的IDL界面多次，为了允许开发者多个应用或多个服务的实例，通过一个入口点。相反，多重继承使暴露相同的界面多次或决定哪一个是提供给客户端最原始界面，提供成为不可能。

　　Availability of CORBA Object Services is not defined a priori:

　　Corba说明没用要求在运行时，哪一个对象服务是提供的。结果，对象开发者必须用 ad hoc 策略去配置和激活这些服务。

　　No standard object lifecycle management:

　　虽然Corba对象服务定义了生命周期服务，但它并不是要求的。因此，客户端要明显内容去管理对象的生命周期，以 ad hoc　方式。进一步说，通过生命周期服务控制的Ｃｏｒｂａ对象的开发者必须明白这个事实，和必须定义附加的界面去控制对象生命周期。定义这些的界面使单调的过程，应该自动进行，但较早的Corba说明缺乏。