Composability

Composability, a system design principle, is mainly concerned with the inter-workings and relationships among system components. The keyword "recombinant" is often used to further elucidate composition, and means that a sufficiently composable system allows components to be combined and assembled in varying combinations to satisfy user requirements. Self-containment, the ability of a component to be deployed independently, and statelessness are also key properties of a 'composable' component. Composability thus seems to underlie the concept of ease of integration of systems. An example of a composable product would be an off-the-shelf program that can be integrated into a larger system via a simple configuration file or script [1]. Ideally, in such a case, existing formats would not require vast infrastructure changes to accommodate the new, off-the-shelf component. In many modern cases, however, great reengineering efforts have been required to do just that. Composability therein demonstrates its importance: a truly composable component or system may be integrated fully and seamlessly with another application with minimal reengineering effort.

According to IBM, composability is the "ultimate security goal" for designing cryptographic protocols as they guarantee security even in the event of mixed or arbitrary protocols. Truly composable mixed or arbitrary protocols should integrate seamlessly, allowing a central point of security administration in cryptographic systems. In "Universal Composability," IBM makes the assertion that a general series of steps may be taken to achieve Universal Composability, a proposition that is significant for its boldness. Key however, is the cross-disciplinary implication of the fact that both the cryptographic and systems engineering domains are concerned with composability.

The importance of composability as a practical systems engineering discipline is made evident by examples such as the Defense Modeling and Simulation Office's composability initiative, a sweeping objective with many component actions on the part of the DMSO. In a collaborative modeling and simulation environment, TEAMS, a component of the DMSO, reported findings on a dual spectrum: 1) that composability is a highly feasible goal and 2) that it is (was) achieved only through great difficulty and expense [2]. I.E: groups of subject matter experts, and systems engineers often worked at achieving composition in a modeling and simulation environment with mixed results [2]. Although the DMSO seems to understand how to achieve true composability with respect to modeling and simulation, clearly a standard is needed to militate against extravagant cost and effort going into the process of achieving it. The importance of composability as a systems engineering principle seems to demand it, especially in light of the availability of reusable system components that allow rapid application development (RAD). To summarize, "Composability will be most successful where it produces a significant reduction in development effort and provides formal means to describe the functionality of components."

Composability becomes increasingly important with the proliferation of web services as a means of developing new and interesting applications through hybridization of several composable web services [4]. In fact, in "Composability of Specifications: Patterns and Properties," Jacques Durand of Fujitsu Software touches upon the criticality of composability in both specification and implementation as more combinable web services specifications are being standardized. Durand states that "A secure, reliable SOAP (Simple Object Access Protocol) message exchange that relies on a general addressing support for identifying the endpoints would typically require integrating at least three of such specifications." SOAP (a protocol for exchanging XML-based messages over a computer network) provides a basic messaging framework upon which such services as the Remote Procedure Call (RPC) messaging pattern rely [1]. As this is an infrastructure upon which message exchange is based, it would constitute part of the back-end of a client-server architectural application, a fact which, when considered with the ubiquity of such systems, makes seamless integration of the constituent SOAP specifications even more important, particularly with respect to the security aspect to which Durand refers. Durand agrees that increasing attention to notions of composition has been established in the realm of web services, and that a true in-depth analysis of a truly composable specification has not been accomplished in this realm. This is a direct contrast to the relative ease which IBM seems to equate with establishing composability with their implied notion of a general series of steps to establish it. Here we seem to enter murky waters, perhaps attributable to the various application domains in which composability has importance. However, Durand defines composability of specifications as: "the ability to integrate and jointly operate implementations of these [separate specifications]." The rift between composable specifications and their corresponding implementations is often such that a specification allowing for composability poses no guarantee that the implementation will provide the same flexibility. Durand's exploration of alternatives to true composability, such as the duplication of features as a means of parallel (to the amalgamated object or specification) extension of a specification, and his equating of past notions of composability with reuse - not always the best or most feasible option [5]- further attests to the difficulty in achieving it.

There are, according to Jacques Durand, three general ways in which applications can compose with one another: supportively (supportive composition), constitutively (constitutive composition), and functionally (functional composition). There are also two basic ways in which two specifications can interrelate: in a closed manner, and in an open manner. The notion of closed composability is discovered when specification S1 requires specification S2 in a manner such that any alternatives to S2 are excluded. Open composability involves a specification S1 that explicitly refers to a specification S2 in a non-exclusive manner, requiring only a distinct set of 'bindings' to interrelate the two specifications [5]. In such a case, S2 might be replaced with a specification S3 with a mere introduction of a binding for S3 [5]. Open composability , rudimentarily speaking, appears to be the most flexible means of imposing or enforcing composable specifications. A feature collision or redundancy caveat, or risk, still exists however within the context of the concept of open composability, despite