|
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).
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:
com.sun.star.lang.XServiceInfo.getImplemenationName
). Second,
the services.rdb
registry associates each implementation name
with an activator (e.g., com.sun.star.loader.SharedLibrary
) and
an activator-dependent location (e.g., a platform-dependent shared library
pathname, in case of the com.sun.star.loader.SharedLibrary
loader).services.rdb
registry, by associating each
implementation name with one or more UNOIDL service description names.service-dependency
elements. Each
service-dependency
element contains the name of a UNOIDL
service description, serving as both the component instantiation name and
the component client interface name.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:
com.sun.star.uno.XWeak
,
com.sun.star.lang.XTypeProvider
, and
com.sun.star.lang.XServiceInfo
to the set of interface types,
with respective constraints on their functionality (e.g.,
com.sun.star.lang.XTypeProvider.getTypes
must return all the
mandatory interface types covered by the service description).com.sun.star.beans.XPropertySet
. For
example, if a UNOIDL service description contains the property declaration
[property] long P
, and exports the mandatory interface type
com.sun.star.beans.XPropertySet
, then there is the functional
constraint that a call to XPropertySet.getPropertyValue("P")
returns an ANY
value of type LONG
.com.sun.star.lang.XTypeProvider.getTypes
at runtime must return
either both of them or neither of them).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. |