PATTERN-BASED BUSINESS-DRIVEN ANALYSIS AND DESIGN OF

SERVICE ARCHITECTURES

Veronica Gacitua-Decar and Claus Pahl

School of Computing, Dublin City University, Glasnevin, Dublin 9, Ireland

Keywords:

Service-oriented architecture, Enterprise application integration, Business patterns, SOA patterns, Architec-

tural analysis, Architectural design, Architecture change.

Abstract:

Service architectures are an increasingly adopted architectural approach for solving the Enterprise Application

Integration (EAI) problem originated by business process automation requirements. In previous work, we

developed a methodological framework for the designing of service architectures for EAI. The framework is

structured in a layered architecture called LABAS, and is distinguished by using architectural abstractions in

different layers. This paper describes the pattern-based techniques used in LABAS for service identiﬁcation,

for transformation from business models to service architectures and for architecture modiﬁcations.

1 INTRODUCTION

Service-oriented Architectures (SOA) have been con-

sidered a promising architectural approach for Enter-

prise Applications Integration (EAI). Software ser-

vices are the building blocks for SOA, and they can

be composed to provide a more coarse grained func-

tionality and to automate business processes. The de-

signing of SOA requires a systematic method in order

to generate quality-aware, modiﬁable and business-

IT aligned service architectures. The development of

service architectures for EAI encompass the analysis

of the involved business processes, business informa-

tion models and applications architecture (Erl, 2004).

Software Patterns are considered in the software

community as architectural abstractions that repre-

sent encapsulated practical knowledge. The instanti-

ation of architectural and design patterns on a partic-

ular architecture design have an impact over the qual-

ity attributes of that architecture (Bass et al., 2004).

At business level, business reference models and pat-

terns also provide encapsulated knowledge,represent-

ing for example best practices, standard business pro-

cesses, standard information models, among others

(Fettke and Loos, 2006).

In previous work (Gacitua-Decar and Pahl, 2008),

we developed a pattern-based and business model-

driven architecture development framework for the

designing of service architectures for EAI. The frame-

work is structured in a layered architecture. The ob-

jective of this paper is to summarise the notations and

techniques required for such a development frame-

work. The contribution of the paper is the pattern-

based techniques for service identiﬁcation, service

architecture development, architecture modiﬁcation,

and transformation from business models to service

architectures used in our framework.

2 LITERATURE REVIEW

Different pattern-based techniques have been pro-

posed for analysis, design and evolution of architec-

tures. In (Zdun, 2007), a systematic method to select

patterns using language grammars and design space

analysis is introduced. Architectural decisions are

triggered by a design problem. In (Kim and Khawand,

), an approach to specify the problem domain of de-

sign patterns is described. The contribution advance

in the direction of automatic evaluation of pattern ap-

plicability. Often, patterns are not used in an iso-

lated way. Sets of patterns are normally part of organ-

ised collections named pattern languages. Pattern lan-

guages allow regulated combinations that extends the

reach of individual patterns (Buschmann et al., 2007).

Architecture transformations are the main architec-

tural concerns after the implementation of a software.

Discovering the instances of architectural and design

patterns, and providing techniques to modify the ar-

252

Gacitua-Decar V. and Pahl C. (2008).

PATTERN-BASED BUSINESS-DRIVEN ANALYSIS AND DESIGN OF SERVICE ARCHITECTURES.

In Proceedings of the Third International Conference on Software and Data Technologies - SE/GSDCA/MUSE, pages 252-257

DOI: 10.5220/0001900802520257

 SciTePress

chitecture in a controlled way, are two important ac-

tivities for software maintenance. Since the nineties,

pattern discovering techniques have been proposed

to recover patterns from source code. Several ap-

proaches start extracting the classes model from the

source code, and subsequently mining the patterns

from that model. A review of pattern discovery tech-

niques can be found in (Dong et al., 2007). Non

controlled changes in the architecture might inter-

fere with the previously applied design patterns. In

(Zhao et al., 2007) a graph-transformation approach

to pattern level design validation and evolution is pre-

sented. In (Gomes et al., 2003) a set of patterns oper-

ators are introduced to design architectures for appli-

cations in grid environments. In (Pahl et al., 2007),

an ontological-based approach for modelling archi-

tecture styles is presented. As such patterns, styles

are architecture abstractions. Style modiﬁcations and

combinations among styles are introduced. Relations

between quality requirements and modelling of styles

are investigated.

3 LAYERED ARCHITECTURE

The integration problem is structured as a layered ar-

chitecture named LABAS (Layered Architecture for

Business, Applications and Services). An incremen-

tal transformation from models at business level to a

service architecture is supported by the use of busi-

ness reference models and patterns. Fig.1 depicts the

architecture layers, their elements and involved archi-

tecture abstractions.

3.1 Layers in LABAS

Layers separate aspects of the integration application

problem. Aspects separation improves the architec-

ture maintainability. Explicit connections between

layer elements provide beneﬁcial traceability charac-

teristics, essential for change management.

Business Modelling Layer (BML) is a container for

business elements and provides the process models

and domain models that represent the context of the

business process automation problem. Models in

BML are expressed in an enhanced BPMN notation.

We have developed a UML proﬁle for the BPMN

notation. Most BML constructs are mapped to

UML 2.0 activity diagrams constructs. Additionally,

the BPMN notation is enhanced by domain model

elements.

Figure 1: Layered Architecture (LABAS).

Application Architecture Layer (AAL) is a con-

tainer for applications components supporting the

business processes in BML. AAL is organized in a

process-wide applications architecture. Applications

might be owned by different process roles in BML.

The applications architecture is modelled with AAL

elements of the LABAS proﬁle. AAL constructs are

mapped to UML 2.0 component diagrams constructs.

Business-Applications Intermediate Layer (BAIL)

integrates the elements from BML and AAL in

an enhanced business process model. An explicit

traceability model relates BML and AAL elements.

The traces in BAIL are an integral part of the LABAS

proﬁle and follows the trace-tagged traceability

metamodel from (Baelen and Berbers, 2007).

Service Architecture Layer (SAL) is a container for

software services and is organised in a service archi-

tecture that solves the applications integration prob-

lem. Service architecture models are expressed with

SAL elements of the LABAS proﬁle. The LABAS

metamodel and the LABAS proﬁle for SAL are estab-

lished upon a proposal for a UML Proﬁle and Meta-

model for Services (UPMS) in the OMG

. Services

are categorised in two main types. Business services

abstract activities or business entities from the BML

into the SAL. Technical services abstract functionality

and data provided by the AAL into the SAL, as well

as, functionality required to manage technical issues

such as security, messaging, etc.

3.2 Architectural Abstractions

Domain-Speciﬁc Business Reference Models are

standard decompositions of a business domain. Ref-

erence models arise from experience, and together

with business patterns, they can constitute business

reference architectures.

available at http://www.omg.org/cgi-bin/doc?ad/2007-

11-02

PATTERN-BASED BUSINESS-DRIVEN ANALYSIS AND DESIGN OF SERVICE ARCHITECTURES

253

Business Patterns. They are considered as micro-

models detailing standard decompositions of

reference models. Two types of business patterns are

considered: process patterns and domain patterns.

Note that process and domain patterns have a lin-

guistic and a structural dimension, however process

patterns add a behavioural dimension. In this paper,

we refer only to structural aspects of patterns.

SOA Patterns are software design patterns in

the context of service architectures. They have a

three-part representation with context, problem and

solution descriptions. Well-known design patterns,

such as the GoF patterns (Gamma et al., 1993),

are normally described in a textual form. Formal-

isations of patterns have been introduced to fulﬁl

requirements of pattern recovery and automatic code

generation techniques. In LABAS, SOA patterns

enhance the business-driven service architecture

derived from successive transformations from models

in BML to SAL, into a service architecture that incor-

porates design solutions for technical aspects, such

as service invoking, service composition, security,

among others.

Pattern Catalogues. In LABAS, business and SOA

patterns are implemented and organisedin pattern cat-

alogues. Each pattern in a pattern catalogue contains

information organised in a pattern template. The tem-

plate includes a textual explanation of pattern intent,

motivation, participants, consequences, among oth-

ers, but also models using elements of the LABAS

proﬁle. The latter approach allows the exportation of

the pattern catalogue as a XMI ﬁle, promoting the use

of patterns as tool-supported modelling constructs.

Information of quality attributes associated to patterns

is also included in a section of the pattern template.

4 PATTERN-BASED

TECHNIQUES

This section describes the pattern-based techniques

used in LABAS. The techniques aim to facilitate the

activities performed by business analysts and soft-

ware architects to transform a business model into a

service architecture.

4.1 Business Service Identiﬁcation

Business patterns are utilised to facilitate the recogni-

tion of reusable portions of the business model, set-

ting boundaries for the deﬁnition of reusable business

services. Business patterns from reference models are

Figure 2: Business process patterns in a process model.

a common denominator among organisationsin a spe-

ciﬁc domain, and also within the same organisation

that is changing over time. Changeability is related

to the ease of an architecture to change, but also with

the ability of the architecture to remain invariant after

a change agent acts (Ross et al., 2008). The deﬁnition

of the business services in LABAS takes into account

the latter characteristic.

Business patterns identiﬁcation could be a

human-performed activity, but our aim is to provide

techniques to support business analysts and architects

with algorithms to automate the identiﬁcation of

business patterns in a business model.

Business Pattern Matching. In LABAS, business

models, architectures, business patterns and SOA pat-

terns are represented as graphs. Graphs are a suit-

able formalisation, since they can capture both: struc-

ture and behaviour, and also allow abstractions such

as patterns to be related to architectures. The pattern

matching technique is based on the matching of the

graph (G

PAT

) representing the pattern, over the graph

representing the business model. In order to

identify a business pattern, and consequently a busi-

ness service, an algorithm searches for the sub-graph

PAT

within the graph G

. Fig.2 shows a simpliﬁed

schema of a reference process model (2a) with pro-

cess patterns (2b), and a business model containing

those patterns (2c).

ICSOFT 2008 - International Conference on Software and Data Technologies

254

4.2 Technical Service Identiﬁcation

Identiﬁcation of technical services is slightly differ-

ent to business service identiﬁcation. In this case, the

enhanced process models in BAIL are used to iden-

tify common ﬂowstructures across the process model.

The process model is decomposed until atomic activi-

ties are reached. The atomic activities of interest have

a one-to-one relation with the functionality provided

by applications in AAL. The Fig.3 shows the process

model

of Fig.2c, where the activities are enclosing

sets of application components that provide the func-

tionalities F1 to F17. S1 to S6 correspond to busi-

ness services. S1 and S5 were deﬁned through busi-

ness pattern matching. St1 to St4 are technical ser-

vices that can be reused by business services. Techni-

cal services encapsulate common ﬂow structures with

invocations to functionality provided by application

components in AAL

The identiﬁcation of technical services across pro-

cess models pursue the fundamental concept of reuse

in SOA. The identiﬁcation of the common control

ﬂow structures is support by graph partitioning tech-

niques. Note that the graph representing the enhanced

process model has information about their elements

types, thus control ﬂow structures involving certain

elements types can be further categorised as different

technical services types, for instance: data aggrega-

tion, calculations, among others.

4.3 Pattern-based Architecture

Modelling and Architecture Change

Software patterns have been used to allow reuse of

successfully applied designs, improving the quality

of the software. Analogously, business reference

models and a notion of patterns at business level,

provide a medium to reuse successful business

models. Both, business and software patterns might

be applied in practice, only based on the knowledge

of business analysts and architects. In the LABAS

approach, designers are supported by a repository

of experience-based solutions in the form of pattern

catalogues, and by implemented techniques allowing

the use of those pattern catalogues.

Note that the proper modelling notation for models in

LABAS is not used here because of space considerations.

Examples using the LABAS modelling notation can be ac-

cessed in (Gacitua-Decar and Pahl, 2008)

In order to simplify the illustration of technical ser-

vices in the Fig.3, only simple ﬂow structures are depicted.

More complicate structures involving e.g. decisions, splits,

among other control ﬂow structures, may also be used.

Figure 3: Business and Technical services identiﬁed in a

enhanced business process model.

Pattern Instantiation. Instantiate a pattern in a

model (called here: host model) is a basic task

required in pattern-based architecture modelling. Pat-

tern instantiation allows augmentation of a model or

architecture through the incorporation of that pattern

into the model or architecture. Pattern instantiation

involves the creation of pattern elements and relations

into the host model, and/or the merging of pattern

elements with host model elements. What elements

in the host model are merged can be decided by

the designer or suggested, as is explained below. In

LABAS, patterns can be instantiated at BML and

SAL to augment or to enhance models in these two

layers.

Suggestion of Applicability of a Pattern. Pattern in-

stantiation can be done only after the recognition of

the associated design problem. Inexperienced design-

ers might not be aware that a pattern can be applied

to improve the quality of their designs. If the pattern

problem is expressed in terms of elements and rela-

tions of the host model, the recognition of a pattern

problem could adopt a similar approach as the pat-

tern matching strategy explained in section 4.1. The

pattern problem is formalised as a sub-graph, which

is a subset of the graph that represents the business

model or architecture. Thus, the design problem can

be systematically searched, and once localised, it can

be suggested to the analyst or designer for the subse-

quent instantiation of the associated pattern solution.

Pattern suggestion and pattern instantiation are

geared in a pattern problem-solution pair. The

PATTERN-BASED BUSINESS-DRIVEN ANALYSIS AND DESIGN OF SERVICE ARCHITECTURES

255

instantiation of the pattern solution into a model with

a design problem (pattern-problem), is formalised

as a graph transformation rule. The transformation

rule allows the transformation from a graph that

represents the model or architecture with a design

problem, into a graph that represents the model or

architecture with the instantiated pattern-solution.

Note that the modelling of the pattern problem

is a key issue for the automatic suggestion of the

applicability of a pattern (Kim and Khawand, ).

Pattern Comparison. A design problem could have

more than one pattern solution associated. In this

case, two or more patterns require a comparison. The

comparison is supported in LABAS with information

about quality attributes associated to the pattern.

This information is encapsulated in the pattern

consequences section of the pattern template.

Pattern Modiﬁcation. The description of a pattern

solution is a generic description. The instantiation

of a pattern might require the modiﬁcation of the

generic pattern solution into one that adjust to the

actual model. The adjustments should not interfere

with the objectives and consequences of the pattern.

The preservation of the pattern properties requires

that only allowed modiﬁcations can be done. Thus,

allowed modiﬁcations over patterns make use of a set

of pattern modiﬁcation techniques. Basic techniques

involve for example, the increasing or decreasing of

the instances of pattern elements, and the increasing

or decreasing of pattern elements. After modiﬁcation

of the pattern, validation techniques are applied.

Pattern Combination. Often, patterns are not

applied in a isolated way. They are combined to

reach a larger scope. Different types of pattern

combinations might occurs. For instance, patterns

can be uniﬁed or embedded. In the latter case, one

or more patterns are subsets of the pattern with

larger scope. Combination of two patterns could

interfere with the expected contributions that each

pattern provide separately. An important issue in

pattern combination is to verify that the individual

pattern consequences are preserved after the patterns

combination. This is difﬁcult to ensure before

implementation, but some indication at design-time

can be provided with the analysis of possible inter-

ferences between associated pattern quality attributes.

Discussion. Requirements for combining patterns

could exceed the capabilities of simple techniques

such as the union or the embedding techniques men-

tioned above. Only as an illustration, we use an

analogy with relational algebra. Basic operations as

projection and selection in relational algebra are not

enough in some practical uses for data base queries.

Composition of operators is a solution to the restric-

tions of the basic operations. Analogously, combina-

tion of pattern techniques provides a medium to sat-

isfy more complex requirements imposed by architec-

ture modelling and modiﬁcations.

Several issues can also be discussed from a prac-

tical point of view. For instance, available business

models, architecture designs and patterns might have

different levels of details. However, the increasing

use of enterprise architecture frameworks, such as the

well-known Zachman framework (Sowa and Zach-

man, 1992), have encouraged the development and

maintenance of business and software architecture

models, together with associated reference architec-

tures and reference models. We can assume that mod-

els, architectures and their associated patterns exist,

and with same level of granularity. Note that this pa-

per leaves out of its scope, process simulation and lin-

guistics considerations for pattern matching and pat-

tern identiﬁcation techniques. However, the integra-

tion of the behavioral and linguistic dimensions could

follow similar directions as in (Ehrig et al., 2007) and

(Martens, 2005).

4.4 Transformations

The methodological framework based on LABAS

(section 3) explains how to systematically transform

a business model into a service architecture. Pat-

terns are actively involved during this transformation.

Since a one-to-one transformation from business pro-

cesses into services is not realistic, a multi-step trans-

formation approach is adopted. Firstly, pattern-based

identiﬁed business services, which are documented

in the enhanced business process model of BAIL by

means of tagged values, are transformed into service

elements in SAL. Relations among BAIL elements

are preserved after the transformation, providing in

this manner, information about the ﬂow dependen-

cies between business services. Subsequently, tech-

nical services, also documented with tagged values in

BAIL elements, are transformed into service elements

in SAL. Technical services also have ﬂow dependen-

cies inherited from the BAIL model.

5 CONCLUSIONS

In this paper we have outlined the necessary nota-

tional elements and pattern-based techniques used in

our methodologicalframework for developing service

ICSOFT 2008 - International Conference on Software and Data Technologies

256

architectures for EAI. Traditionally, the creation of ar-

chitectures have only focused on structural descrip-

tions. Instead, the focus in this paper has been on pro-

cesses and constrained architectural descriptions. The

continual rise of abstraction in software engineering

approaches was a central driver, placing the notion of

patterns at business domain level and focusing on its

subsequent transformation to a service architecture.

The LABAS architecture and its associated method-

ological framework have as an ultimate goal, the cre-

ation of service architecture solutions for EAI with

improved changeability characteristics, while main-

taining coherence between the business model and the

software architecture. Explicit traceability between

elements of different layer in LABAS contribute to

the coherence between the business and the software

levels. The improved changeability characteristics of

the architecture solutions are achieved by using ar-

chitectural abstractions. Their use is enabled through

the pattern-based techniques described in this paper.

The techniques are utilised for software service iden-

tiﬁcation, for business model to service architecture

transformations and for architecture modiﬁcations.

Our future plans include the use of the

Architecture-Level Modiﬁability Analysis (ALMA)

method (Bengtsson et al., 2004) to evaluate the archi-

tecture solutions created with LABAS. In (Gacitua-

Decar and Pahl, 2008) we demonstrate the use of

LABAS and discuss the use of ALMA. We also con-

sider the formalisation and implementation of the

pattern-based techniques described in this paper. We

will investigate sematic and behavioral aspects in pat-

terns. The implementation of techniques is planned

to be part of a plug-in for a standard UML modelling

tool. The plug-in is complemented with a LABAS

proﬁle, compliant with the LABAS metamodel. Ad-

ditionally, a simpliﬁed pattern catalogue at business

level, and a SOA pattern catalogue will be developed

for evaluation purposes.

REFERENCES

Baelen, V. v. and Berbers, J. (2007). Traceability as input

for model transformations. In ECMDA Traceability

Workshop (ECMDA-TW), Haifa, Israel.

Bass, L., Clements, P., and Kazman, R. (2004). Soft-

ware Architecture in Practice. Addison-Wesley Pro-

fessional, second edition.

Bengtsson, P., Lassing, N., Bosch, J., and van Vliet,

H. (2004). Architecture-level modiﬁability analy-

sis (alma). Journal of Systems and Software, 69(1-

2):129–147.

Buschmann, F., Henney, K., and Schmidt, D. C. (2007).

Pattern-Oriented Software Architecture: On Patterns

and Pattern Languages. Wiley and Sons.

Dong, J., Zhao, Y., and Peng, T. (2007). Architecture and

design pattern discovery techniques - a review. In In-

ternational Conference on Software Engineering Re-

search and Practice (SERP), pages 621–627, USA.

Ehrig, M., Koschmider, A., and Oberweis, A. (2007). Mea-

suring similarity between semantic business process

models. In APCCM2007, volume 67, pages 71–80,

Australia.

Erl, T. (2004). Service-oriented architecture: Concepts,

Technology, and Design. Prentice Hall.

Fettke, P. and Loos, P. (2006). Reference Modeling for Busi-

ness Systems Analysis. IGI Publishing.

Gacitua-Decar, V. and Pahl, C. (2008). Business model

driven service architecture design for enterprise appli-

cation integration. In ICBIIT2008.

Gamma, E., Helm, R., Johnson, R. E., and Vlissides, J. M.

(1993). Design patterns: Abstraction and reuse of

object-oriented design. In ECOOP93, volume 707 of

LNCS, pages 406 – 431. Springer.

Gomes, M. C., Rana, O. F., and Cunha, J. C. (2003). Pat-

tern operators for grid environments. Sci. Program.,

11(3):237–261.

Kim, D.-K. and Khawand, C. E. An approach to precisely

specifying the problem domain of design patterns. J.

of Visual Languages and Computing, 18(6):560–591.

Martens, A. (2005). Simulation and equivalence between

bpel process models. In Proc. of the Design, Analy-

sis, and Simulation of Distributed Systems Symposium

(DASD05).

Pahl, C., Giesecke, S., and Hasselbring, W. (2007). An

ontology-based approach for modelling architectural

styles. In ECSA 2007.

Ross, A., Rhodes, D., and Hastings, D. (accepted 2008).

Deﬁning changeability: Reconciling ﬂexibility, adapt-

ability, scalability, modiﬁability, and robustness for

maintaining system lifecycle value. Journal of Sys-

tems Engineering.

Sowa, J. F. and Zachman, J. A. (1992). Extending and for-

malizing the framework for information systems ar-

chitecture. IBM Syst. J., 31(3):590–616.

Zdun, U. (2007). Systematic pattern selection using pattern

language grammars and design space analysis. Soft-

ware Practice and Experience, 37(9):983–1016.

Zhao, C., Kong, J., Dong, J., and Zhang, K. (2007). Pattern-

based design evolution using graph transformation. J.

of Visual Languages and Computing, 18(4):378–398.

PATTERN-BASED BUSINESS-DRIVEN ANALYSIS AND DESIGN OF SERVICE ARCHITECTURES

257