Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

convergent architecture Building model driven J2EE Systems with UML - Hubert R.

Hubert R. convergent architecture Building model driven J2EE Systems with UML - Wiley publishing , 2002. - 289 p.
ISBN: 0-471-10560-0
Download (direct link): convergentarchitecturebu2002.pdf
Previous << 1 .. 53 54 55 56 57 58 < 59 > 60 61 62 63 64 65 .. 142 >> Next

-102-
Convergent Architecture Chapter 4: The Convergent Component Metamodel
personality simply serves to encapsulate database access and legacy ESQL code and make these available to one or more fat client personalities.
We now move to the next level of detail for each type of convergent component, one section for each of the four architectural layers.
[5]In
current OMG/MDA terminology, the TPC constitutes the core UML models (UML profiles) and the standard mappings plus additional stylistic guidelines and the respective automation levels of the technology projection.
[6]Which in theory is always a good idea, but is not always practical.
Assembly Components
Assembly components (assemblies) actively coordinate constellations of reusable components in both the development and deployment phases of the component life cycle. These constellations often correspond to traditional applications. The coordination provided by an assembly also extends into the operational phases of the life cycle. As shown in Figure 4.12, assemblies constitute the top-level, macro unit of system packaging and deployment. As the macro units of a system, they also drive the macro planning and development process.
^ i ^
Assembly 1 , / Assembly 2 \
- =■ ApflLifjtichn ^ — = AppIlLüti.L'll'l l
Figure 4.12: Assemblies as macro units.
Assemblies are convergent components that exist to manage and package other convergent components. Normally, assemblies are the only convergent
-103-
Convergent Architecture
Chapter 4: The Convergent Component Metamodel
components deployed alone as units. All other convergent components are deployed in the context of an assembly. During the deployment phase, the assembly component helps manage the installation process. This concept of an assembly component corresponds to the CORBA components' (CCM) definition of an assembly. In the J2EE technology projection, an assembly maps to a J2EE EAR. Convergent components can be reused by several assemblies. In Figure 4.12, Assembly 2 uses components B and C from Assembly 1. Thus, an assembly can be referred to and used by other assemblies at the level of its convergent components. However, a convergent component is always owned and managed by a single assembly. Assembly 1 owns components B and C. Using a term explained in more detail in Chapter 5, every convergent component has a single resource owner.
These reuse relationships are tracked and managed by the assembly development team (also defined in Chapter 5) during system development. This explicit ownership ensures that the reuse is managed throughout the entire life cycle of a component in the context of a single assembly. This means that although individual convergent components are still installable units, they are always installed in the context of an assembly. The assembly is responsible for the integrity of the overall system. For example, to update a single resource component in an assembly, a new version of its assembly is installed. The assembly may in fact only update this single resource component, but the assembly also must guarantee the continued integrity of its entire development and runtime environment. Guaranteeing such integrity is no small task. This is one reason why this task is clearly assigned to a component, the assembly component, and to its corresponding team, the assembly development team (for details, see Chapter 5) in the Convergent Architecture.
Accessor Components
As indicated by their name, accessor components (accessors) provide access to and from external entities. The definition of an external entity is very simple: It is anything that is not installed as part of an assembly or part of its direct runtime platform.
At the highest level, it is possible to distinguish between two basic types of accessor components. The similarities between these two types actually outnumber their differences, as will be seen:
1. User interface accessors (UI-accessors and UI-ACCs). These are the mediators between an IT system A and a human user B. These user interfaces are not limited to graphical user interfaces (GUI); they can also be voice-based, text-based, and so on.
2. System interface accessors (SI-accessors and SI-ACCs). These are the mediators between two systems A and B. They can be used to integrate different architectures (system integration) or different installations (an interface between the installations of the same system in different organizations).
Accessors serve two important purposes. First, they delimit and defend the architectural boundaries throughout the system life cycle. They are used to coerce and convert things external to the architecture into things that conform to the architectural style. This is the best way—and probably the only way—to ensure
-104-
Convergent Architecture
Chapter 4: The Convergent Component Metamodel
long-term architectural integrity no matter how many external entities are involved in an integrated system. Second, they separate the modeling of system access from the particular implementation of the access to provide developers with a clean separation of concerns.
Previous << 1 .. 53 54 55 56 57 58 < 59 > 60 61 62 63 64 65 .. 142 >> Next