6.1 The Ericsson Component Model

The object model of ECM is based on that of COM (Ghosh et al. 2005). ECM defines instantiable classes, which can implement an arbitrary number of interfaces, and when instantiated form objects.¹ The memory layout of interfaces is almost identical to that used by COM—the binary standard of the ECM object model is thus concerned with the in-memory representation of interfaces, which use dispatch tables to realize late binding. Figure 6.1 depicts the memory layout of ECM interfaces. Very late binding is not supported, and only minimal runtime type information is kept (enabling interface navigation).

Interfaces and classes are assigned runtime names in the form of UUIDs. Interfaces may extend one other interface, with the exception of IRoot, which is the root of the interface hierarchy.² IRoot is identical to COM’s IUnknown, and ECM thus uses reference counting to manage the lifetime of objects and supports interface navigation. Errors are signaled through return values—the equivalent to COM’s HRESULT return type is the RVoid type, which contains 16 bits of error information divided into a number of fields. The remaining 16 bits may be used to transmit actual return values in addition to the error information—the RSel type is used to return integer values and the RBool type is used to return boolean values. Return values are typically transmitted using output arguments, though.

ECM uses factories to instantiate objects, which are always allocated on the heap. A mapping between class UUIDs and addresses of factory functions is maintained by a data store, which is consulted when objects are instantiated. (ECM also supports “private” classes, whose factories are not registered with the data store, and are instantiated by directly calling the factory function of the class.) The ECM runtime system is accessed through a standard ECM interface, IShell, an implementation of which is available at all times. IShell is most commonly used to instantiate objects, through IShell::CreateInstance().

ECM comes with an interface description language, known as EIDL, whose syntax is similar to the IDL dialect used with COM, but with ECM-specific keywords. EIDL defines a number of standard types that can be used with ECM classes. ST-Ericsson’s software development kit ships with an IDL compiler that for a particular interface can be used to generate C bindings and a “skeleton” C implementation. The latter is a generated class with empty operation bodies, which developers can use as a convenient starting-point when authoring new classes. ECM’s C binding is similar to the code presented in Chapter 4.

Classes and arbitrary resource files may be part of application suites, which can be built and deployed separately from other suites. They may be installed and uninstalled at runtime, and are made part of a running system through dynamic linking. Application suites are packaged as Native Archive (NAR) files.

From a technical perspective, application suites are in some respects the software components of the ST-Ericsson platform. However, they were not built to support a thriving component ecosystem of third-party components that are composed to build component-based software. Rather, application suites serve as the shared library mechanism of the platform, enabling short build times and a way of preventing unwanted dependencies between suites.

ST-Ericsson offers its customers a choice between linking their application suites dynamically with the platform, as described above, and of linking statically to form a monolith containing both the customer code and the platform. If the latter option is used, ECM is effectively reduced from a combined component and object model to only an object model.

Figure 6.1: Memory layout of ECM/ECMX interfaces

Footnotes

1. ST-Ericsson refers to classes as “components,” and to objects as “component instances,” but acknowledges in the platform documentation that “components facilitate an object-based development paradigm.” Also, the OPA documentation occasionally refers to “component instances” as “objects.” For consistency, this thesis refers to these ECM entities as classes and objects, reserving the “component” word for entities that are in most respects compatible with the definitions of Chapter 1.
2. ECM also includes IStaticRoot, which is the root interface of an alternative interface hierarchy. IStaticRoot interfaces essentially group together procedural operations, as these interfaces can only have one implementation.