Component Architectures
Where do frameworks, peer-to-peer networks and infrastructure fit in?

To assemble independently designed components, we must standardize their interactions, making them both interoperable (able to share data and participate in protocols) and complementary (their functionality complements one another, making the whole greater than the sum of the parts). The latter quality, being more context-specific, is trickier, but it can be addressed by domain-specific reference models and architectures. Reference architectures devise a standard way to divide and conquer a particular problem domain, predefining roles that contributing technologies can play. Components that cover such specified roles are then naturally complementary.

Explaining Frameworks

Reusability or multiple use can focus on two levels of design: architecture and individual modules. In software, a multi-use architecture is called a reference architecture, a multi-use architecture cast to use specific technology is called a framework and a multiple-use module is called a component. In all cases, the target of use is typically a narrowed range of applications, not all applications. One reason is that, in practice, both the architecture and the complementarity required for component composition demand some narrowing of application domain. In contrast, infrastructure software targets multiple-use opportunities for a wide range of applications.

For example, enterprise resource–planning applications target standard business processes in large corporations. ERP vendors such as SAP, Baan, PeopleSoft and Oracle use a framework and component methodology to provide some flexibility to meet varying end-user needs. Organizations can choose a subset of available components, and mix and match them within an overall framework defined by the supplier. The customization process, however, tends to be so complex that it’s commonly outsourced to business consultants.

In essence, a framework is a preplan for the decomposition of an application, including interface specifications. You can customize it by substituting different functionality in constituent modules, and extend it by adding other modules through defined gateways. A framework may be highly dynamic, subject to wide variations in configuration at execution time. The application scope of a framework is necessarily limited: No single architecture will be suitable for a wide range of applications. Thus, frameworks typically address either a narrower application domain or particular vertical industry.

Why OO Isn’t a Component Methodology

Component methodologies require discipline, standards and a supporting infrastructure to be successful. Object-oriented programming, for example, emphasizes modularity through supporting languages and tools, but it hasn’t achieved component assembly. Why? OOP lacks discipline (such as encapsulation) enforced by compilers and runtime environment, standards for interoperability (such as remote invocation and event protocols) and a supporting infrastructure (such as instantiation, configuration and version control).

The P2P Problem

Constructing an application from components by configuring them all against one another, in what’s known as a peer-to-peer architecture, doesn’t scale beyond simple configurations because of the combinatorial explosion of created dependencies, all of which may need to be managed during the application evolution. A framework can be used to bundle all relevant component connections and partial configurations, hierarchically creating a coarser-grained module. A component may “plug into” multiple places in a component framework, if that component is relevant to multiple aspects of the system.

About Infrastructure

Components and infrastructure share some common elements. Like components, infrastructure (such as operating system, DBMS or middleware) is typically intended for multiple uses, licensed from another company, used as is and encapsulated. Infrastructure (as seen by the application developer and operator) is large-grained, while components are typically much smaller-grained. The primary distinction between components and infrastructure lies in composability. Infrastructure is designed to be extended by adding applications. This is a weak form of composability, because it requires that the infrastructure predate the applications, and the applications are developed specifically to match the capabilities of an existing infrastructure. Similarly, an application is typically designed for a specific infrastructure context, and thus lacks the non-context-specific property. Components, on the other hand, embody a strong form of composability in that the goal is to enable the composability of two (or more) components that are developed completely independently, neither with prior knowledge of the other. Achieving this, however, is a difficult technical challenge.

—C. Szyperski and D. Messerschmitt