Following the definition of the goals and ques- tions, we can derive the following minimum set of architectural views, which provides the required information for answering the above questions. The views proposed by the UML 2.0 (unified modeling language) specification are used as a reference at this point. However, the selection of the UML as the notation is not binding.
Table 5 contains a column on the tailoring required for explicitly addressing the goals de- fined in the previous sections. This tailoring can be accomplished by using the common UML extensibility mechanisms through special fea- tures of the employed modeling tool or through
the definition of custom views. Furthermore, the column EAI Layers relates the derived views to common EAI realization layers as described in Themistocleous and Irani (2003). Finally, the rightmost column maps the views to each of the EAI viewpoints that we consider. For instance, for the composition viewpoint, the activity view is recommended, while this view is not required in the integration viewpoint.
Planning
In the planning phase, the goals of the EAI project are being refined in terms of scenarios. Here the use-case templates proposed by Cockburn (2001) come into play. For the definition and refinement
View Related Questions Required Tailoring EAI Layer EAI Viewpoint Activity Q2, Q4, Q5, Q7, Q10, Q11, Q12 - Information on the required effort - Information about
the involved devel- opers
Process
automation Composition
Deployment Q5, Q19 None Transportation, Translation Composition, Integration
Structure (class) Interaction Q1, Q3, Q4, Q5, Q6, Q7, Q8, Q9, Q12- Q21 - Information on con- nectors - Information on translation between heterogeneous data schemes - Information on the required effort - Information about
the involved devel- opers
Connectivity Composition,
Integration
of scenarios, the following scheme can be taken into account.
• Data integrationscenarios: Scenarios that
deal with integrating heterogeneous data sources
• Application-logic integration scenarios:
Scenarios that deal with the invocation of external application logic
• Process integration scenarios: Scenarios
that deal with the development of collab- orative business processes (i.e., across the boundaries of a single enterprise)
• Real-time enterprise scenarios: Scenarios
that deal with the synchronization of dif- ferent business processes connected via a collaborative process
• Complex event processing scenarios: Sce-
narios that deal with the handling of multiple event streams arising from the integrated applications
After definition, the scenarios are prioritized and mapped to the iterations that will follow. For prioritizing scenarios, PuLSE™ DSSA provides some common heuristics like the economic value, the typicality, or the required effort. The latter can be supported by the above classification scheme. In general, it makes sense to start with data inte- gration scenarios and to move on toward the more complex event handling scenarios.
Scenarios developed in this phase will even- tually contain variability. In other words, the scenario descriptions can contain optional or parameterized sections that will be selected or set according to the variability decision that will be made for a specific integration solution. Such a variability decision could be, for example, the type of external system to be integrated. Furthermore, all unresolved variability decisions for a scenario are collected in the scenario’s decision model. On the other hand, the set of resolved decisions, which reflect a specific integration solution, are collected in the scenario’s resolution model.
realization
In the realization phase, the requirements posed by the integration scenarios are realized by mak- ing the necessary design decisions. Here the EAI approaches (as described in the introduction), com- mon architectural patterns, and design principles can come into play. The EAI literature provides a great amount of help in this regard. For example Themistocleous and Irani (2003) define the fol- lowing layers, which should be part of every integration solution.
• Process automation: Deals with the busi-
ness processes that consist of activities provisioned by the external system
• Transport: Deals with the transport of
messages between heterogeneous systems • Translation: Deals with the translation
between heterogeneous data models • Connectivity: Deals with the access to
external systems
Regarding EAI design decisions, Keller (2002) proposes the following schema.
• Communication models: Selection of
synchronous or asynchronous communica- tion
• Integration method: Integration over the
data layer, the graphical user interface, the application interfaces, or over application components
• Infrastructure: Selection of a communi-
cation infrastructure (e.g., object brokers, message-oriented middleware, enterprise service bus; Chappell, 2004)
Finally, the literature (e.g., Chappell, 2004; Fowler, 2005; Hohpe & Woolf, 2004) proposes a series of design patterns as well as workflow patterns (Wohed et al., 2003) that are relevant for the realization phase.
152
The realization phase is also responsible for fulfilling the variability, which is eventually con- tained in the scenarios. In this case, the variable sections in the scenarios are to be transformed to variable architectural models. In other words, the resulting models also contain optional or param- eterized sections, which must be set according to the scenario resolution models.
Figure 6 depicts the ordering of activities in the realization process as well as the according patterns and models that can be used as input.
Documentation
In the documentation phase, the design decisions made during the realization are documented according to a documentation scheme, which is derived as shown in Figure 7. The scheme defines the types of documents to be produced as well as their structure and interrelations (cf Bayer, 2004). In other words, the scheme can be seen as a synonym of the view set discussed in the section titled “PuLSE™ DSSA Customization Support.” As shown in Figure 7, one of the inputs Figure 6. Realization phase
Activity View
Structural
View InteractionView
Deployment View Workflow patterns EAI structural patterns EAI deployment patterns EAI design decisions
Figure 7. Documentation process
Analyse existing schemata Existing documentation approaches Available Tools documentation schema Analyze documentation schema Create documentation plan Necessary View s
to the documentation process is the group of views mentioned in “Required Views.”
Since PuLSE™ DSSA is an iterative ap- proach, the documents are to be updated and refined iteratively. For illustrating the variability in the models, special notations can be used, for example, UML stereotypes or special coloring (cf Flege, 2000).
The consistency and correctness of the pro- duced documents can be checked by inspection techniques as proposed, for example, in Software Inspektion (2006). Perspective-based inspections (Laitenberger, 2000) are especially of interest at this point as they can enable the inspection of integration architectures from the special viewpoint of an EAI stakeholder (i.e., composite application developer). In this case, the inspection process defines the different inspection scenarios based on perspectives and provides concrete guidelines. For example, the composite applica- tion developer’s perspective could be described as shown in Box 1.
assessment
In the assessment phase, the integration archi- tecture is being judged against the integration requirements. In other words, the goal is to check to which degree the delivered architecture meets the scenarios of the planning phase as well as additional scenarios that reflect nonfunctional requirements like performance or robustness. The latter can also comprise special interoperability qualities as described, for example, in IEC TC 65/290/DC (2002).
For the assessment, context-based architecture evaluation methods such as SAAM or ATAM are typically used (Clements, Kazman, & Klein, 2002). Furthermore, the GQM method discussed in the section “Quality Model” can come again into play by establishing a measurement program that iteratively measures the satisfaction of the composition or integration goals.
Composite Application Expert Introduction
Imagine you are the expert of the composite application under development. Your interest lies in the efficient reuse of the integrated external applications.
Instructions
For each of the produced architectural documents, do the following. • Determine the integrated external applications.
• Determine the design decisions made for the integration. Identify defects in the architecture using the following questions.
• Are the available interfaces to the external applications fully exploited?
• Is there any customization interface of the external applications that has not been used? • Is the translation between heterogeneous data types being considered?