Techne.CM

Owned by Former user (Deleted)
Last updated: May 20, 2007Version comment
2 min read

Purpose and Scope

Techne.CM (Component Manager) implements the assembly of components into any of the three component types: fragment, feature, and feature set. The concept of "weaving an application" from fragments, features and feature sets is what this module is all about. Based on this simple component "universe", CM maintains the "application model" of Techne.

In order to understand the differences of these types, let's start by defining what a feature is. A feature takes on the common definition of "a set of functionality" that contributes something useful to an application. A feature may be equated to a service or group of services, but it is not a strict correlation. In fact, a feature may not be a service at all, e.g. a UI feature. On the other hand, a fragment is a "dead piece of something" (that something is the feature). Fragments are like gems hidden inside a bundle or jar file that lie dormant. Hence, it is an element of the feature that is inactive and only becomes active when it becomes a part of the latter. Finally, a feature set is an assembly of features that ultimately functions as an application system or sub-system. To describe the benefits that Techne.CM provides to the table, here are some of its capabilities:

  • Manages a registry of components.
  • Defines and maintains the component hierarchy. A snapshot of this hierarchy can be viewed on demand.
  • Provides an alternative to "glueing" components via services. A service sometimes does not fit the bill (not intuitive). For example, a DAO (data access object) is not a service but it must be exposed. Also, the concept of "waiting for a service to arrive" not only is counter-intuitive, it also wastes time and depending on its nature, could be difficult to implement.
  • Enables fragments to be composable to other types. In a manner of speaking, CM "changes" the scope of a fragment. However, scope (i.e. visibility) is not considered a significant issue for containerization. Rather, it is an either/or proposition - the fragment is either part of the app or it is not part of the app.