Container-Component Architectures

Container-Component Architectures are examples of open architectures because they allow users to extend an application's functionality by adding new components created by third party developers. Components have to be added without modifying the code of the original application since users don't have access to the application's source code. The Container-Component Architecture is a good example of the Open-Closed Principle.

A component (also called a plugin) consists of one or more collaborating objects, implements some interfaces, and requires interfaces to be implemented. The detailed definition of a component can be found here.

Components provide system functionality. The container's job is to manage the lifecycle of its components (create, suspend, resume, destroy) and also to provide infrastructure services to the components such as communication, persistence, security, execution environment (a VM for example), synchronization, white and yellow page directories, etc.

Examples of applications that follow the Container-Component Architecture include:

Browsers containing Applets

Web Containers containing Sevelets

EJB Containers containing EJB Beans

The Eclipse platform containing plugins

The Visual Basic IDE containing VB controls

The PC Motherboard and PCI or ISA expansion cards

Economically, the availability of numerous, competitively priced components that extend the functionality of the original container application, make it more attractive to potential customers.

The Meta Object Protocol (MOP)

But how can the container developers anticipate the functionality of third party components? Surely they will need to know about the required and implemented interfaces of these components.

One idea is to require that all components implement some sort of Meta-Object Protocol (MOP) interface. The MOP interface might require all components to be able to "tell" the container about the interfaces they implement and require. This will allow developers to automate the process of managing new components:

Note that the MOP assumes objects exist that represent interfaces, operations, and parameters:

An object/class that represents or manipulates another program component, such as an interface or an operation, is called a meta-object/meta-class.

Components that can describe themselves in this way are said to be reflective. Reflection is discussed further here.