Trace Link Generation

3.5 Summary . . . . 71

3.1

Motivation

Enterprise Application Integration (EAI) aims to link separate applications into an integrated system driven by business models and the goals they implement. A central problem of application integration is maintaining alignment between the business and technical dimensions involved. Business processes do not map one-to-one to service architecture processes. This gap has turned out to be difficult to approach systematically and to automate [Erl 2004]. Architecture abstractions like patterns and styles capture design knowledge and allow the reuse of successfully applied designs, thus benefitting the quality of software. Abstraction is a central driver in

software engineering approaches. At the business (modelling) level the reuse of successful designs is equally important.

The development of integrated enterprise-wide application architectures is a con- tinuous process. To improve the process and overall quality, the experience of ana- lysts, architects and developers should be captured and reused. Knowledge gained from integration projects can be captured to build a repository of experience-based pattern solutions. A coherence framework able to capture different architecture-level descriptions and abstractions (such as patterns) into an integrated view with busi- ness and software perspectives is required. The problem of process and application integration in terms of modelling aspects, but also architecture issues involve:

• modelling aspects – modelling different views such as information hierarchy, behaviour, and semantics in a coherent framework with interrelated models. • architecture aspects – architecture description and abstractions such as patterns

are central. To benefit from reusable architecture design knowledge captured in the form of patterns, pattern identification and utilisation are basic activities requiring support.

Note that vertical transformations – from business to software architectures – are also important. Elements involved with business operations should be mapped to services. Synchronisation between the two modelling layers is required. Al- though this work does not address this aspect, aiming at completeness, a strategy for pattern-based vertical transformation is introduced in the context of the proposed framework.

The rest of this chapter presents an architectural framework to address the prob- lem of enterprise process and application integration. A layered architecture for service-centric process and application integration is the backbone of the proposed framework. Section 3.2 presents the modelling framework, its layers and involved models. It also describes the role of patterns in the framework, how they can be described by end users and utilised within the framework. Section 3.3 describes the pattern-based techniques that can help analysts and architects during services and service architecture design. Among the techniques, pattern-based service iden- tification (pattern matching and discovery) is developed in detail in this work, but described in the next chapters. Section 3.4 describes a traceability-based approach used to integrate the different modelling layers, including a higher abstraction layer containing patterns. The utility of this approach for change impact analysis is dis- cussed.

3.2. Layered Architecture for Business, Applications and Services

3.2

Layered Architecture for Business, Applications and Ser-

vices

This section presents a framework that integrates different perspectives of the pro- cess and application integration problem. It captures process and architectural mod- els and patterns in an integrated structure. The framework is organised in a layered architecture called LABAS – Layered Architecture for Business, Applications and Services. It layers separate aspects and aid with the maintainability of the architec- ture [Bass 2004].

Two interrelated perspectives of the integration problem, the business and appli- cation view, and two aspect of the solution, services and patterns, are considered in LABAS:

• Business view – two main models describe the business dimension of the EAI problem: process models and domain models. While business process mod- els capture the dynamics of the business, domain models capture structural relations between business concepts.

• Applications view – an application architecture represents a system com- posed of several software applications. Application architectures at enterprise scale normally grow in a decentralised way and involve different technologies, paradigms of development and modelling notations.

• Services view – services organised in an architecture have the potential to bridge the gap between business and technology and to improve the reuse of existing applications and the interoperability with new ones. Software ser- vices are the building blocks of service architectures. They can be composed to provide more complex functionality and to automate business processes. • Patterns – reusing proven solutions reduces costs and development time and

ensures coherently integrated and architected application systems aligned with business processes. Using patterns enables architects to implement successful application integration solutions. Patterns are core and a distinguishing char- acteristic in the LABAS framework.

Moreover, change management and traceability are important aspects of IT sys- tems and business alignment. Consistence between LABAS layers is enhanced through explicitly connecting modelling elements of the EAI problem with elements of the service architecture solution. In order to provide traceability support to el- ements involved in the integration problem across layers, LABAS provides explicit

Figure 3.1: Layered Architecture for Business, Applications and Services (LABAS). links between elements from different layers. An explicit traceability model main- tains the dependencies between elements of the integration problem and the service- based solution.

3.2.1 Layers in LABAS

The different layers organised in the LABAS framework capture the problem perspec- tive, considering business and application architecture elements, and the solution perspective, involving elements of the service-based integration solution. From a modelling point of view, a meta-model defines the common constructs among the different layers and provide the modelling support for the transformation from busi- ness to software levels. Figure3.1shows the layers in LABAS.

• Business Modelling Layer. The Business Modelling Layer (BML) represents the business context of the integration problem. BML is a container for elements of the process and domain models. A concrete notation (BPMN [OMG 2008b]) is utilised to implement process modelling support at BML. Process models cap- tures events, activities/tasks and roles involved in actual business processes. The main focus is on behaviour. On the other hand, domain models provide a structural view of business concepts and their relations. Domain modelling is supported through standard UML [OMG 2007] support. A basic ontology to represent domain information model entities can provide extended facilities [Gacitua-Decar 2009b].

• Application Architecture Layer. The Application Architecture Layer (AAL) is a container for the application components supporting the business processes in BML. AAL is organised as a process-wide application architecture. Thus, ap-

3.2. Layered Architecture for Business, Applications and Services

plications can support different tasks and be owned by different roles defined in process models at BML. In order to describe an AAL model in architectural terms, the component and connector view from [Garlan 2006] is adopted. It de- scribes a software system as a set of components, where each component has a set of ports with interfaces that enable the interaction with other components through connectors.

• Business-Application Intermediate Layer. The Business-Application Intermedi- ate Layer (BAIL) provides a consolidated view of the integration problem. The aim behind jointly modelling the business and applications views is to derive an integration solution from BAIL models. The consolidated model integrates the models through trace links (see more details in Section3.4). The integrated models are the business process model, the domain model and the application architecture model. Trace links between process model and domain model ele- ments, and between domain model elements and application components, are the core to consolidate the the integration problem covering elements of the business and application views at BAIL.

• Service Architecture Layer. The Service Architecture Layer (SAL) provides a service-based integration view. It is a container for software services. These services, organised in a service architecture [Alonso 2004] implement the inte- gration solution. A process-centric component and connector view [Allen 1997] to represent AAL elements was used and it follows the recommendations of the Object Management Group (OMG) for service-oriented architecture modelling [OMG 2009b]. Additionally, the LABAS framework proposes a pattern-based service identification technique (see more details in Section3.3) to support the design of service-based solutions for enterprise process and application inte- gration problems. This technique is based on solutions for graph matching and motif discovery which are formalised and described in more details in Chapters5and6.

3.2.1.1 Abstract Syntax for Models in LABAS

Concrete models in the LABAS framework require a modelling infrastructure that defines the abstract syntax to create specific models and trace links connecting mod- els and architecture abstractions. Model-based design provide concepts and tech- niques to define a syntax to create concrete models. A metamodel defines the mod- elling constructs and its relations which are used to create specific models. The Ob- ject Management Group (OMG) is a large standardisation body addressing, among other aspects, the development of modelling standards and guidelines for model-

driven development. Modelling requirements for layers in LABAS can exploit meta- models defined by this organisation. Section 3.2.1 indicated the type of models considered in each LABAS layers. The abstract syntax used for these models is as follow.

• In the BML layer, process model elements follow the recommendations of the BPDM (Business Process Definition Metamodel) [OMG 2008a]. Domain model elements and their organisation follow the UML specifications [OMG 2007] for class diagrams. Only static aspect of classes are considered for domain models in BML.

• In the AAL layer, application architecture models and their elements follow the specifications for UML component diagrams.

• In the SAL layer, service architecture models use modelling constructs rec- ommended in the OMG’s UPMS (UML Profile and Metamodel for Services) [OMG 2006].

• A traceability metamodel adds to the LABAS modelling infrastructure facilities to manage explicit trace links between elements in different layers and between model elements and pattern elements. More details are provided in Section3.4. A LABAS profile was developed to create concrete LABAS’s models using a stan- dard UML tool. Section 7.3.1refer to profile used in the proposed framework and support for pattern documentation.

3.2.2 Patterns in LABAS

Architectural abstractions such as patterns have diverse definitions in the software and business communities. Section 2.3.2 refers to different notions of architectural abstractions, in particular, Section2.3.2.2focuses on diverse definitions for process- oriented patterns. Figure3.2 illustrates different levels of abstraction where the pat- tern concept can be positioned. At the concrete pattern level, pattern users can document patterns associated to a specific application domain and utilise them in that context. The focus in subsequent chapters is on process patterns at the concrete pattern level. Once a pattern is selected at this level, it can be instantiated in a con- crete model, i.e., at the model level. More abstract patterns, which are independent of the application domain are expressed with an abstract syntax that is located at a metamodel level. Examples of process patterns in the abstract level are the pro- cess patterns defined in [WP 1999], [Aalst 2009b], [Weber 2008], [Lanz 2009]. They define control flow constraints for executable processes, however they are indepen- dent of the applications where they are involved in. Only recently, except for a few exceptions, such as in [Malone 2003], [Barros 2007], [Thom 2009], [Smirnov 2009],

3.2. Layered Architecture for Business, Applications and Services

Figure 3.2: Abstraction levels and types of patterns.

knowledge from process designs created for common business operations is being documented and reutilized in a similar way to design patterns in software engineer- ing. In this work, process patterns are addressed in this sense, i.e., in an analogous manner to patterns for software architectures.

The authors in [Buschmann 2007] suggest that the use of (software) patterns is not possible to be fully tool-based or automated. Although the proposed LABAS framework considers the notion of patterns similarly to the authors in [Buschmann 2007], this work emphasises on automation and therefore, pattern de- scriptions that make machine readability possible are encouraged. The aim is to help pattern users to automate tasks which are repetitive, time consuming and diffi- cult to manage due to size complexity.

Subsequent chapters explain how the automated use of patterns in the context of LABAS is explored, in particular, the application domain of patterns in this work is focused on the business process level. However the techniques developed in next chapters can be applicable to any graph-based representation of software level pat- terns. The reason to focus on process patterns at business level is that design and ar- chitectural patterns at software level have been widely studied and exploited within the software community, however patterns and their use at a more business op- eration level are less investigated. Moreover, since service-based architectures are closely related to both the business operation and software perspectives, the LABAS framework should not only look at patterns from the software development perspec- tive, but also from the business process design and integration perspective.

Business- and architecture-level patterns are the two main kinds of patterns dis- tinguished in LABAS. Process patterns falling in the first category are central in the

next chapters:

• Business-level patterns identify the interaction and structure between users, busi- ness processes and data. Process-oriented patterns within this category capture common process designs providing a solution to frequent problems associated to business operations. Thus, not only structure but also behaviour are central to process-oriented patterns.

• Architecture-level patterns – at a more technical level – address enterprise appli- cation integration problems and capture reliable architecture solutions. In con- trast to business-level patterns, architecture-level patterns shift the focus into more structural software component and service connectivity aspects. They can also have a direct link to quality attributes.

Process Pattern. In particular, this work associates a business process pattern to a description of a reoccurring design problem with regard to an organisation’s opera- tion in a specific business domain, and a generic process representation explaining a solution to the operational problem. Beside the problem-solution pair description, the constraints to the problem and the solution space are also explained. A generic solution to a process-centric problem is specified describing the constituent elements of the solution process, their responsibilities and relations. Processes are mainly fo- cused on behaviour and; therefore, relations in a process pattern description are mainly associated to that aspect. A more formal (and graph-based) definition for process patterns is provided in Chapter4.

3.2.3 Pattern Description for End Users

One important aspect facilitating the use of patterns is how they are described. There are several approaches to describe patterns, from natural language and more infor- mal graphical representations such as the pattern descriptions in [Buschmann 2007], to more formal descriptions such as those based on role concepts [Kim 2008], graphs [Bottoni 2009] or with an ontological base [Pahl 2007] and [Kampffmeyer 2007]. The first type of descriptions are easily understood by humans but hardly readable for machines. More formal and precise descriptions benefit automation, but they might be difficult to use among pattern users.

A common and widely accepted medium to describe patterns is by means of pattern templates. A pattern template is a predefined structure to organise the main elements describing a pattern. This structure often involves an evocative pattern name, a concrete and precise description of the context, problem statement, con- straints limiting the solution space and a solution that solves the problem within the

3.2. Layered Architecture for Business, Applications and Services

constrained solution space. Additional elements of a pattern template can include related patterns, pattern variants and examples where the pattern has been applied. LABAS is a framework oriented to support the design of service-based solutions for enterprise process and application integration. Regarding the use of patterns in LABAS, a balance between facility of use among end users and formalisation to facil- itate automation is considered. Thus, patterns are described using a pattern template. The template has parts oriented towards pattern users and others designated to be more easily processes by machines. The sections oriented to pattern users involve textual descriptions that use a vocabulary familiar to pattern users. As emphasised in [Rising 2007], a vocabulary and concepts familiar to pattern users are key to fa- cilitate the use of patterns. On the other hand, one of the aims of this work is to automate some tasks related to the use of patterns. Automation is facilitated by pro- viding a section in the pattern template – referred to as pattern configuration – that contains a graph-based representation of the pattern elements’ configuration. 3.2.3.1 Pattern Template

Pattern templates in LABAS organise the set of patterns used during the design of service-based solutions for enterprise application and process integration. A pattern template includes the following sections:

Name. The name should be recognizable and useful to facilitate its searching and communication among pattern users. The name provides a reference to users familiar with the pattern to immediately bring to mind the problem and solution addressed by the pattern.

Problem. The problem section describes a recurrent design problem addressed by the pattern. A description of the problem also contains its context. The problem description and its context have a textual explanation targeting pattern users. The pattern context might contain a machine readable section. That section uses a pre- defined categorisation of the specific domain addressed in the problem. Constraints are described for concepts in that domain. Categories and constraints can be defined in a domain specific ontology that helps to divide, organise and explain the problem space and support automation during the utilisation of patterns.

• Context. The context defines a set of conditions in which the pattern prob- lem occurs. It can be thought as a constrained problem space, similar to the constrained solution space described by the Forces section in the Solution. In one extreme, a problem space without constraints cover an universal problem. This extreme is not desirable since, as explained in [Buschmann 2003], a pat-

tern can become all things for all people, each person with their different – perhaps incompatible – view, potentially damaging pattern utilization. The more constraints are defined for the problem space, the more precise the con- text description. However, if the context is significantly restricted, the problem addressed by a pattern can lose recurrence and; therefore, dilute the utility of the pattern.

Solution. The solution identifies the configuration of elements balancing the con- straints within the context of the problem. Elements of a pattern solution are generic and often named pattern roles. Simple pattern role descriptions are composed of an evocative name, a textual description for pattern users and possibly a category from a domain specific ontology. If a category is not assigned, the pattern role name is used as a more informal medium of identification.

Pattern roles are connected to each other in a pattern configuration. Connections represent either static or dynamic relations among pattern roles. Comprehensive pattern role descriptions contain a set of attributes describing them. In order to support automated mechanisms to compare pattern roles, a threshold value can be assigned to each attribute. This value represents a quantitative indication for the minimum similarity value between two attributes being compared. Section5.5

explains the use of these attributes and threshold values in more details.

Specific types of pattern involve different types of pattern roles. Architecture patterns in LABAS consider the component and connector view from [Garlan 2006] to represent pattern configurations. Components, connectors, interfaces and ports are the types involved. Process patterns on the other hand refer to configurations that relate pattern roles from a control flow perspective, reflecting the abstract behaviour of a number of process instances. Process participants (or process pattern roles) are involved with or in activities, decisions, events and domain entities that together define a process pattern configuration.

• Forces. Forces define the influential factors restricting the possible solutions to