Download (direct link):
The separation of the access model from its implementation permits us to develop long-lived, reusable models independent of the underlying technology and the life cycle of the implementation technology. This separation allows developers to effectively reuse accessor components at the level of UML models, thus promoting the advantages of model-driven, component-based development into the important field of system access and system integration. In addition, the clean separation of the accessor component layer from the business component layers of the architecture permits different development tasks and roles to be carried out independently: Business-model design, application development, and B2C or B2B design now can be performed by different, specifically trained specialists using specialized tools. This improves flexible adaptation, reuse, and maintenance at many points in the system life cycle. For example, with this separation of concerns, it is possible to redesign the type of user access or external system access at the UML level without touching the business component behind the scenes. By the same token, new use cases can be realized and new user interface technologies can be leveraged with little or no change to existing accessor models.
To date, the IT industry has been slow to address model-driven development in this area of user and system access—the terrain covered by accessors. This has not been due to neglect; it is simply because the IT industry at large has been more focused on improving the central, server-side aspects of system design.
There is nothing amiss here; it just means that the accessor components have less standard infrastructure on which we can base their modeling style and its model-driven technology projection. Although the accessor design leverages the standards available in this space, they must currently define more of the model-driven infrastructure than the other convergent components. For this reason, the accessor metamodel and the runtime environment, which will be introduced in the following sections, are the most extensive parts of the Convergent Architecture.
The Accessor Framework
Figure 4.13 illustrates the use of accessor components to support different channels of access to a software system. It shows that an accessor component actually consists of several separate parts. Many of these parts are modeled separately in the interest of the clear separation of concerns. However, they are interrelated as parts within a system of patterns. Together they form what is called the accessor framework.
Chapter 4: The Convergent Component Metamodel
! [ZEE. M'.k'pri n: L.n * i r-:■ i■ n■ n:
Figure 4.13: The model-driven parts of the accessor framework.
This figure manifests some additional separation of concerns that has not been mentioned yet. First, beginning at the top of the figure, the accessor framework recognizes that various forms of access may differ only at the level of their external representation; all other aspects, such as information content, information flow, and event flow, remain equivalent across the various representations. In addition, new forms of access may arise at any time, while other existing forms may be deprecated over time. Thus, the modeling and production of these various representation channels are encapsulated by so-called representers. These representers run in so-called representer containers. A representer container is another important abstraction: It encapsulates a specific runtime environment for a group of interrelated representers. For example, an HTML browser is a representer container that may manage one representer per HTML frame. This level of model-driven granularity is required by modern Internet portals. Nothing less will suffice for a model-driven production of such systems. Another important advantage to this constellation is that it permits representers to be reused in different accessor models.
A single accessor may support any number of representers. Figure 4.13 shows three representer channels being supported by a single UI-accessor. It also shows a single representer being supported by the SI-accessor. Similar to representer containers, accessors are also housed in accessor containers. An example of an accessor container is a servlet engine or a Java/Swing framework. Based on this separation of concerns in both modeling and runtime environments, a single, reusable accessor may serve significant functionality to multiple representation channels, that is, to multiple representers. This is called multichannel access to a single accessor. Moreover, new channels may be added or existing ones removed at any time via the UML model without having to circumvent, and compromise, the model-centric architecture.
The following sections provide more detail on each part of the accessor framework.
Chapter 4: The Convergent Component Metamodel