Language:

The Free and Open Productivity Suite
Apache OpenOffice 4.1.6 released

OpenOffice.orgUNO Component Model


Conceptual Model

We use the term “component” here in a very limited, well defined sense. Unfortunately, within the broader field, and even within UNO itself, the term is also used with other meanings, typically to mean some form of collection of what is here called components.

A UNO component is the smallest unit in the UNO component model. A UNO component is a software artifact that has the following properties:

A component client interface is a set of UNO interface types (referenced by their—globally unique—names), together with a marker for each interface type, denoting it as either mandatory or optional, and semantic constraints on the functionality of those interface types and the runtime presence of any optional interface types. There is one constraint on the set of interface types: no optional interface type from the set may be an (indirect) base type of any mandatory interface type from the set.

Each component client interfaces is associated with a globally unique component client interface name. This association must be globally unique; otherwise, clients of a component (who describe their expectations of the component by means of a component client interface name) could not be sure that, at runtime, they receive a component instance that meets their expectations. (This requirement of globally unique names for component client interfaces is the same as for named UNO types.)

At runtime, instances of UNO components can be obtained from a component manager. The component instances are UNO objects that behave according to their respective component client interfaces. A component manager works based on component instantiation names. Each code that uses a component manager must document what component instances (adhering to which component client interfaces) it expects to obtain from the component manager, with which component instantiation names. Throughout the lifetime of a component instance, that instance has access to a certain component manager; what other component instances the instance itself expects to obtain from that component manager is documented by the component's component dependencies (but note that this only covers the component's static dependencies).

How UNO Implements the Conceptual Model

Components are often also called services in UNO. The conceptual component client interfaces are implemented as UNOIDL service descriptions, whose names serve as the conceptual component client interface names. The conceptual properties of components are represented in UNO as follows:

A UNOIDL service description appears to be richer than a corresponding conceptual component client interface (which, after all, is little more than a set of UNO interface types with associated semantic constraints). But all of this additional richness can be reduced to syntactic sugar:

In UNO, the conceptual component managers are instances of com.sun.star.lang.ServiceManager. UNO does not distinguish between the conceptional component client interface names and component instantiation names—the names of UNOIDL service descriptions are used for both cases.

When a component instance is created at runtime, it is passed a com.sun.star.uno.XComponentContext, through which it has access to a com.sun.star.lang.ServiceManager. The guarantee that this ServiceManager fulfils the component's component dependencies is indirect and weak: since component instantiation names are (globally unique) names of UNOIDL service descriptions, which in turn are the same as component client interface names, it is guaranteed that if a ServiceManager returns any component instance at all for a given component instantiation name from the component dependencies, then that instance will adhere to the corresponding component client interface from the component dependencies. However, there is no guarantee that the ServiceManager does not return null instead. Also, there is no way to guarantee that a component's dynamic dependencies are satisfied.

Author: Stephan Bergmann (last modification $Date: 2004/10/28 14:58:24 $). Copyright 2004 OpenOffice.org Foundation. All rights reserved.

Apache Software Foundation

Copyright & License | Privacy | Contact Us | Donate | Thanks

Apache and the Apache feather logo are trademarks of The Apache Software Foundation. OpenOffice, OpenOffice.org and the seagull logo are registered trademarks of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners.