With a slight modification of the COM object model, the disadvantages of that object model can be avoided. Let us call this new object model RCOM after Robust-Component-Object-Model. The difference with COM is that the AddRef and Release routines are removed. Their functionality is replaced by functions of the Instance Manager that is a part of the infrastructure. The Infrastructure reacts on requests to connect source instances with target instances. The establishment of a connection may involve the dynamic creation of a new instance and it will always increase the reference count of the target. The release of a connection will decrease the reference count of the target. When the reference count reaches zero, it causes the deletion of the dynamically generated target or the reset and cleanup of a fixed target. The fact that the infrastructure handles all creation and deletion processes makes it possible to introduce reliable garbage collection. In order to avoid confusion the navigation support routine gets a different name. In order to support instance reset and cleanup, a ResetInstance routine is added in the top of every interface. The combination of the two standard routines is given a name: IAccessor. This replaces the IUnknown base interface of the COM model.
The RCOM component model inherits all of the nice features of the COM object model and avoids all nasty features of the COM object model. The ResetInstance routine can be used to repair an instance after it is obstructed by a halted task. This makes the RCOM model extra interesting for application in real-time applications.
In order to support the configuration of component-based systems the RCOM component model contains extra features such as RequireInterfaces and ConnectionRequest fields. Both are implemented by reserved places in the data structure that contains the assets of the instance. RequireInterfaces are used by the infrastructure to provide the instance with a direct link to a connected target instance. ConnectionRequests are used by the instances to request to be connected to a new or a different target. These features are not so much a characteristic of the binary structure of the component model. They result from the way that the infrastructure handles the component model.
In embedded applications, a software component must not restrict to software-software components. It must also be able to support software-hardware interfaces and streaming interfaces. Again, these features have little to do with the binary representation of the component model. However, they are depending on the way that classes of component instances are implemented.