Component Architecture

The component architecture covers three principal areas ... 

A component architecture defines a kit by establishing the conventions of interoperation, which are represented by connectors (see Section 1.9.3). 

Chapter 10, Components and Connectors, describes the richness of component-based developmemt and explains how it raises the level at which implementation units can be connected to build larger systems. Because there is no single answer to what constitutes useful component and connection mechanisms, we use frameworks (see Chapter 9, Model Frameworks and Template Packages) to define the generic building blocks of different component architectures. 

Rather than limit ourselves to a specific component technology, we then introduce the port-connector model of component architectures. We discuss a typical example of such an architecture and show how to specify and design with components in this architecture. Then we show how even ad hoc and heterogenous component systems are amenable to systematic development in Catalysis. 

As with packaging, the exact form of component composition varies across different component technologies and tools. The key point is that the composition can be done by a different party, and at a different time, from the building of the components themselves. Section 10.7, Component Architecture, discusses a component-port-connector model for describing compositions in a simple way. Ports are the access points in a component where its services can be accessed or where it can access another s services connectors couple ports. The kinds of compositions supported by a particular technology or style can be described by its connector kinds. 

When you build a design from components, you don t need to know how they are represented as objects or as instances of a classes or know how the connectors between components work.2 In federated systems, just as in 00 programs, each component is a collection of software it is chosen for the support it provides of the corresponding business function and uses local data representations best suited to the software. Just as in OO programs, objects must access the information held by other objects, so in a component architecture, components intercommunicate through well-defined interfaces so as to preserve mutual encapsulation. 

The first APIs were sets of functions that an external component could invoke. If there was ary notion of an object receiving the function calls, it was the entire running executable itself. But the most recent developments in this field have put the executable program into the background (see Figure 10.2). The objects are the spreadsheet cells, the paragraphs in the document, the points on the graph the application software is only the context in which those objects execute. The component architecture determines what kinds of object interactions are allowed. 

To us, a component architecture defines the schemes of how components can be plugged together and interact. This definition may vary from one project or component library to another and includes schemes such as CORBA, DCOM, JavaBeans, database interface protocols such as ODBC, and lower-level protocols such as TCP/IP as well as simpler sets of conventions and rules created for specific projects. 

Component models are specifications of what a component does—based on a particular component architecture, including the characteristics of its connectors—and descriptions of connections between components to realize a larger design. 

The answers to these questions are common across any set of components that can work together (see Section 10.2.2, Components and Standardization). Together, they form a set of definitions and rules called a component architecture. Microsoft s DCOM, the Object Management Group s CORBA, and Sun s JavaBeans are examples. Project teams often devise their own component architecture either independently or (more sensibly) as specializations of these types. Highly generalized architectures cannot provide, for example, a common model of a Bank Customer, but this would be a sensible extension within a bank. 

A design described using connectors doesn t depend on a particular way of implementing each category of connector. What s important is that the designer know what each one achieves. We can distinguish the component architecture model (which connectors can be used) from the component architecture implementation (how they work). 

There can be many different implementations of a given architecture model, and the same architecture model can be applied to many different applications. A given component architecture describes its type, or style, and its implementation. 

If you have a simple component architecture, it could minimally define operating system and language or clarify how to couple components working in different contexts. If it defines no notion such as our transfer connector, you must define all the messages you expect to send and receive. 

Component architecture A component architecture is a choice of categories of connectors. They are specified first by what they achieve (signaling an event, updating values, transferring objects, and so on) and secondarily by how they are implemented (COM operation, e-mail, carrier pigeon, and so on). 

Most categories of port have a gender (such as input and output ) and a type of value that is transmitted, from simple numbers to complex objects such as reservations or stock dealings. These elements also are defined by the specific component architecture, which also must define the rules whereby the ports can be connected (for example, an input always to an output). 

We could use explicit stereotypes to indicate the component frameworks being applied instead, we assume that a distinguished connector and arrow notation has the same semantics within a particular component architecture. Also, the semantics work equally for types and instances. 

An output property is an attribute that the component architecture specifically allows to be visible to other components. A chosen component architecture provides a pattern for implementing attributes tagged with the output property stereotype.12... 

An input property is an attribute exposed according to a component architecture so that it can be controlled by the output of another component. It can be linked with invariants to other attributes. There is an implied invariant that an input property will be equal to whatever output (of some other component) it may be coupled to. Therefore, although an input property can be used in a postcondition, it doesn t make sense to imply that it is changed by the action ... 

Pictorially, input and output properties can be shown with solid arrows, as distinguished from the open arrows of events. (The shadow emphasizes that this is a component—that is, something intended to be implemented according to a component architecture. But it s only for dramatic effect and can be omitted.)... 

Different component architectures treat constraints differently. The simplest approach is to treat the constraint as a form of require condition the user must ensure that it is not violated. 

A particular component architecture (such as COM+) might intercept the instantiation and connection operations. (Remember, many of them need to be a part of the standard infrastructure services see Section 10.2.2, Components and Standardization.) That component infrastructure can monitor the known components and their connections to provide richer extensions of behavior. 

Available connectors are defined in framework packages for the component architecture. 

Design rules for technical architecture This defines the elements used and patterns followed systemwide for dealing with the computing infrastructure aspects of the design. It includes hardware and software platforms and tools, middleware and databases, and the choice of API standards and component architecture, such as JavaBeans or COM. These rules emerge in parallel with the activities in items 11 and 12 architecture models and implementations. 

In this case study we have not adopted any particular component architecture such as Cat One (see Section 10.8.1, Cat One An Example Component Architecture). So our connectors have been limited to standard requests or responses between large-grained components rather than higher-level facilities such as events, properties, and workflow transfers. 

Figure 16.18 Retrieval of component architecture to store specification. 

UML offers one notation to define the interface of a component (the lollipop notation). Catalysis recognizes that component technology is about the connecting together of encapsulated units. The types of these connections will vary a given component architecture will define its own types. You can define a component architecture using frameworks and then use those frameworks to compose components as diverse as workflow, event-property-method connections, and traditional objects. 

Figure 2.14 shows the components of the photosystems residing along the thylakoid membranes. Insights into the structure of the membrane and component architecture has recently been obtained by atomic force microscopy (Bahatyrova et ah, 2004). The space inside the membranes is called the lumen,... 

This dual-component architecture allows the PCMCIA architecture to be used in different types of computer systems (that is, not just Intel s). For example, the Apple laptop computers currently use PC cards for modems and LAN interface cards, and they are based on Motorola processors. 

A component-based prototype for intrusion detection and response has been realized. It is based on Microsoft s component architecture, the Component Object Model (COM) and its extension, the Distributed Component Object Model (DCOM). 

---