A FRAMEWORK FOR IDENTIFYING ARCHITECTURAL

PATTERNS FOR E-BUSINESS APPLICATIONS

Feras T. Dabous

, Fethi A. Rabhi

and Tariq Al-Naeem

School of Information Systems, Technology and Management

School of Computer Science and Engineering

The University of New South Wales, 2052 Sydney NSW, Australia

Keywords:

Patterns, e-Business Applications, Architectural Design, Legacy Systems, e-Finance.

Abstract:

The success of today’s enterprises is critically dependant on their ability to automate the way they conduct

business with customers and other enterprises by means of e-business applications. Legacy systems are valu-

able assets that must play an important role in this process. Selecting the most appropriate architectural design

for an e-business application would have critical impact on participating enterprises. This paper discusses

an initiative towards a systematic framework that would assist in identifying a range of possible alternative

architectural designs for such applications and how some of these alternatives can evolve into formal archi-

tectural patterns or anti-patterns. This paper focuses on e-business applications with some requirements and

assumptions that are often presented in a few speciﬁc domains such as e-ﬁnance. The concepts presented in

this paper are demonstrated using a real life case study in the domain of e-ﬁnance and in particular capital

markets trading.

1 INTRODUCTION

The concept of e-business applications has been used

extensively in the literature to refer to a range of ap-

plications. This range encompasses B2C interactions

(e.g. simple Web-based client/server applications)

and B2B interactions either as a workﬂow by means

of workﬂow technology or as a distributed application

by means of middleware technologies. In this paper,

we consider an e-business application domain that can

be improved by developing or utilising corresponding

business logic and functionality that can span differ-

ent organisational legacy systems.

In previous work, we identiﬁed and formalised a

number of architectural patterns based on practical

experience in the domain of e-ﬁnance. These patterns

address a similar problem context and therefore con-

stitute alternative architectures where the selection of

the most appropriate pattern is based on the prob-

lem context speciﬁcation. In (Dabous et al., 2005),

we presented models for patterns qualities estimations

that can be used in the selection process for a given

problem context, whereas in (Al-Naeem et al., 2005b)

we utilised AHP (Anderson et al., 2002) method for

this selection process that is extended in (Dabous,

2005) to encompass estimations provided by the qual-

ity models.

This paper extends upon the previous work by

proposing a framework for identifying patterns that

can be used in the architectural design of e-business

applications. We consider e-business domains that

have special requirements and assumptions mainly re-

lated to the existence of legacy functionality. These

domains, such as e-ﬁnance, consist of applications

that are business process intensive and therefore we

alternatively use the term Business Process (BP) to

refer to an e-business application.

This paper is organised as follows. Section 2

presents the basic assumptions made in this research

and formalises the concepts used. It also presents e-

ﬁnance particularly capital markets as a real-life ap-

plication domain. Section 3 discusses a common ar-

chitectural description that forms the basis of the pat-

terns identiﬁcation framework. Section 4 discusses

the two major phases in the proposed patterns identi-

ﬁcation framework. Section 5 presents and discusses

ﬁve design strategies that ingrain the basic input for

the framework. Section 6 presents ﬁve candidate pat-

terns that are the outcome of the ﬁrst phase in the

proposed framework together with the instantiation of

each pattern on the selected application domain. Fi-

nally, section 7 concludes this paper.

T. Dabous F., A. Rabhi F. and Al-Naeem T. (2005).

A FRAMEWORK FOR IDENTIFYING ARCHITECTURAL PATTERNS FOR E-BUSINESS APPLICATIONS.

In Proceedings of the First International Conference on Web Information Systems and Technologies, pages 88-95

DOI: 10.5220/0001234000880095

 SciTePress

2 BASIC ASSUMPTIONS AND

CONCEPTS

This section presents the basic assumptions made in

this paper and introduces the different concepts used

such as functionality, legacy systems and BPs to-

gether with a selected application domain. The as-

sumptions and concepts discussed are based on sev-

eral architectural analysis, benchmarking studies, and

e-business applications development such as (Rabhi

et al., 2003) that have been conducted on a number of

legacy systems.

2.1 Review of notation

A functionality in the context of this research refers to

an identiﬁed autonomous task that resides within an

“encapsulating entity”. A functionality corresponds

to an activity within a BP which performs a speciﬁc

job (i.e. in part of the business logic). A functionality

can be either automated or new (i.e. non-automated).

If it is automated then the encapsulating entity can

be a legacy system. On the other hand, if it is new

functionality then the encapsulating entity can be a

human process. We use the notion F

all

= {f

: 1 ≤

i ≤ |F

all

|} to represent the set of all functionalities

(automated and not automated) that belong to a par-

ticular domain. The deﬁnition of the set F

all

does not

tell anything about the automation of any function-

ality. We also use the concept of “equivalent func-

tionalities” to refer to a group of functionalities that

have similar business logic each of which resides in

a different encapsulating entity. We use the notion

Q = {q

: 1 ≤ i ≤ |Q|} to represent the set of all

groups of equivalent functionalities. Each q

⊆ F

all

is the ı

set of a number of equivalent functionali-

ties such that |q

| ≥ 1 and q

∩ q

= φ : a 6= b and

i=1

= F

all

Two assumptions related to the legacy systems are

made. The ﬁrst one is that each legacy system is

owned by one company within the domain of study

and their development teams are not related to the

BPs development team. The second one is that the

development team for the BPs can only interact with

these legacy systems through their deﬁned interfaces

(e.g. in the form of APIs) and has no access permis-

sion to the corresponding source code. Therefore, we

assume that different functionalities within the same

legacy system have similar interfacing mechanism.

We use the notation F

⊆ F

all

to represent the

set of all automated functionalities contained in the

legacy systems of a particular domain. Let LG = {l

1 ≤ i ≤ |LG|} be the set of key legacy systems iden-

tiﬁed in that particular domain. Every l

⊆ F

and

∩ l

= φ when a 6= b . It is also important to note

that in practice there is no instance of two equivalent

functionalities within the same legacy system mean-

ing that if f

∈ l

and, f

∈ l

then {f

, f

} * q∀q ∈ Q.

We also consider a ﬁxed number of BPs in a par-

ticular domain referred to by the set BP = {bp

: 1 ≤

i ≤ |BP |}. We assume that these BPs may have ac-

tivities that correspond to existing functionalities in

the legacy systems. The business logic of each bp

is expressed in terms of an activity diagram whose

nodes are the activities (i.e. functionalities) and the

arcs determines the execution ﬂow between the func-

tionalities. We use the function activ ities(bp) ⊆ F

all

to identify the set of functionalities that are required

by the BP bp (i.e. it returns the set of all nodes in a

bp’s activity diagram).

In the context of this research we assume that

every f ∈ F

all

has at least one corresponding bp ∈

BP such that f ∈ activities(bp). In other words,

i=1

activities(bp

) = F

all

2.2 Selected application domain

Within the e-ﬁnance domain, we focus on capital

markets which are places where ﬁnancial instruments

such as equities, options and futures are traded (Har-

ris, 2003). The trading cycle in capital markets com-

prises a a number of phases which are: pre- trade an-

alytics, trading, post-trade analytics, settlement and

registry. At each phase of this cycle, one or more

legacy systems may be involved. Therefore, a vast

number of BPs exist within this domain involving a

number of activities that span through different stages

of the trading cycle. Many of these activities can

be automated by utilising functionalities of existing

legacy systems. The automation of these BPs is chal-

lenging for two reasons. The ﬁrst one is that it may

involve a number of legacy systems that are owned by

different companies. The latter one is that these BPs

are normally used by business users who are not tied

to any of these companies (e.g. ﬁnance researchers).

The application domain presented in this paper cor-

responds to one problem context that comprises four

legacy systems encapsulating 12 automated function-

alities, ﬁve non-automated functionalities and ﬁve

BPs that leverages the 17 functionalities in conduct-

ing the business logic. We focus on four legacy sys-

tems that have been customised around Australian

Stock Exchange (ASX) practices. Theses systems are

FATE, SMARTS, XSTREAM, and AUDIT Explorer.

Each of these systems supports a number of func-

tionalities accessible through APIs. In this paper, we

consider a few functionalities in each system that are

shown in ﬁgure 1. These functionalities have been re-

ported in (Yu et al., 2004; Dabous et al., 2003). We

also consider ﬁve BPs in this paper which are: ASX

trading data processing, visualisation of ASX trad-

ing data, reporting surveillance alerts, trading strategy

formalisation, and trading strategy execution. Figure

A FRAMEWORK FOR IDENTIFYING ARCHITECTURAL PATTERNS FOR E-BUSINESS APPLICATIONS

LG

F

all

F

au

Q2

RealTimeSim1

RealTime3

BAnalytic

Analytic2

Q4

TeSim1

TE3

Q3

TeSim1

FATE

RealTimeSim1

CurrDaySim1

XSTREAM

Realtime3

TE3

CurrDay3

AUDIT

VisualModel4

Q1

IntraDay2

CurrDay3

CurrDaySim1

SMARTS

CalibRun2

RealTimeAlerts2

IntraDay2

InterDay2

Analytic2

Q5

Q8

Q7

Q6

CalibRun2

RealTimeAlerts2

VisualModel4

InterDay2

Q12

Regulator

Q11

StrategyCnrl

Q10

OrderExeMgt

Q9

MktEventDetect

Figure 1: Selected application domain

IntraDay2

CurrDay3

Analytics2

VisualModel

BP2: Visualization

Today in Days

Mkt=asxMkt=asx

Old in Days

BP5: Trade Strategy exection

MktEventDetect

Event detected

StrategyCtrl

Ctrl msg

OrderExcMgt

RealTimeSim1 RealTime3

Subscriber event

triggered

Subscriber event

triggered

TE3

Order

palcement

Event=trade

else

Mkt= ASX-sim Mkt= ASX

TeSim1

CurrDay3

InterDay2

IntraDay2

Mkt =sim-ASX

Analytics2

BAnalytics

Metrics=smarts

Metrics=Beta

BP1: ASX Trading Data Processing

Mkt =rASX

Old in Days

Note: BP1 forms a sub-BP of BP2

CurrDaySim1

Today in Days

BP3: Surveillance

CalibRun2

RealTimeAlerts2

Regulator

Alert raised

BP4: Trade Strategy

formalisation

MktEventDetect

Event detected

StrategyCtrl

Ctrl msg

OrderExcMgt

Event=trade

else

Figure 2: Activity diagrams of the BPs

2 illustrates the workﬂow for each of these BPs as ac-

tivity diagrams. More details about the functionali-

ties, legacy systems, and the BPs that are used in this

application domain are discussed in (Dabous, 2005).

3 COMMON ARCHITECTURAL

DESCRIPTION

We propose a common architectural description with

the main motivation of facilitating a uniﬁed system-

atic architectural presentation. It describes each iden-

tiﬁed pattern in terms of a set of architectural compo-

nents Comp = {X

: 1 ≤ i ≤ |Comp|} which commu-

nicate with each other according to the BP descrip-

tion. A component X

∈ Comp is described accord-

ing to four essential features: denoted by the tuple

< tasks(X

), conT o(X

), invBy(X

), access(X

) >

where:

1. tasks(X

): is a function that identiﬁes the set of

tasks that are encapsulated in the component X

These tasks can be one of three types. The ﬁrst one

isthe implementation of a functionality f ∈ F

all

that is denoted by C(f ) and is used in three differ-

ent cases. The ﬁrst is when f ∈ F

refers to an

existing legacy functionality within a legacy sys-

tem. The second is when f ∈ F

refers to rede-

veloping (i.e. reengineering) an existing function-

ality. The third is when f ∈ (F

all

− F

) which

is not implemented in any of the legacy systems.

The second one is he implementation of a wrapper

for a functionality f that is denoted by CW (f). It

is used when X

makes it possible to invoke the

functionality f from other components. The third

one is the implementing of the business logic of a

business process bp denoted by CBL(bp). We will

use the term ‘business process enactment’ to refer

to the implementation code of the business logic.

Note that these three tasks functions return the im-

plementation code resulted from applying the re-

spective task on its parameters. For example C(f )

returns the implementation code when applying the

‘create’ task on f (i.e. the code that implements f).

2. conT o(X

) ⊂ Comp: is a function that returns the

set of components that X

invokes while executing

its business logic.

3. invBy(X

) ⊂ Comp: is a function that returns the

set of components that invoke X

4. access(X

): a function that returns the access

method that is used by all X

∈ invBy(X

) to in-

voke X

. There are three main categories of access

methods that we consider. The ﬁrst one is service-

oriented (SO) that presumes the existence of acces-

sible interfaces by means of a remote invocation us-

ing XML based protocols such as SOAP. The sec-

ond one is legacy-oriented that presumes the exis-

tence of APIs for local invocations whereas extra

code is required to make these APIs available for

remote invocations by means of binary protocols

that ranges from TCP/IP to RPC based protocols.

For this access method we used a function denoted

by api(l) : l ∈ LG that returns the API name of

the legacy system l that we also use as the access

method for the same legacy system. The third one

is ‘nil’ that is used when X

is not required for in-

vocation by any other X

∈ Comp. We denote the

set of all available access methods by the set AC

and therefore access(X

) ∈ AC ∀X

∈ Comp.

WEBIST 2005 - INTERNET COMPUTING

r1

r2

r3

d1

d4d3

d2

DS

For every  c in P(DS)

Rules

Step 2 :generate architectural

construction algorithm by

combining all  ds in c

validate

dispose

Step 4 :apply

pattern ranking/

selection method

Estimations

Ranked patterns

Preferences

Phase #1Phase #2

S

u

c

e

s

f

u

l

s

t

o

r

i

e

s

U

n

s

u

c

e

s

f

u

l

s

t

o

r

i

e

s

Pt

anti

Pt

cndt

Valid match

Not a valid match

Step 1 :instantiated

architectures for all

candidate patterns in Pt

cndt

Problem context

specification

Pt

frml

d1 d2 d3 d4

d4

d3

d4

d2

d3

d2d1

d4

d1

d3

d1

d2

d1

d3

d2

d1

d4

d2 d1

d4

d3

d4

d3d2

d1

d4d3

d2

Step 1 :generate  P(DS)

Step 2 : apply

conseq. models

Step 3 : consult

stakeholders

Step 5 :Long-

term evolution

Figure 3: Framework for the patterns identiﬁcation

4 PATTERNS IDENTIFICATION

FRAMEWORK

This section presents an extensible systematic frame-

work for identifying domain-speciﬁc architectural

patterns for e-business applications. As illustrated in

ﬁgure 3,this framework comprises two phases: candi-

date patterns identiﬁcation phase followed by the evo-

lution phase into formal patterns.

Phase #1: candidate patterns identiﬁcation

This stage considers the identiﬁcation of architec-

tural descriptions that correspond to candidate pat-

terns. This phase consists of two main steps:

1. Given a set of design strategies denoted by the DS

(see section 5) such that each strategy is formalised

using the common architectural description that is

discussed in section 3, generate the power set of all

subsets denoted by P(DS) that contains 2

|DS|

el-

ements. Each c ∈ P(DS) corresponds to a unique

possible combination of design strategies.

2. For each c ∈ P(DS) do the following: Firstly, let

arch

be the combined architectural construction

algorithms ∀d ∈ c. Secondly, having a set of com-

bining rules denoted by Rules (see section 5.2),

check arch

against all combining rules. If arch

is validated ∀r ∈ Rules, then arch

is added to

the set of candidate patterns denoted by P t

cndt

(i.e.

P t

cndt

= P t

cndt

∪ {arch

}), otherwise discard

arch

Phase #2: evolution into formal patterns

This stage considers the evolution opportunities for

the candidate patterns in P t

cndt

into either formal pat-

terns denoted by the set P t

frml

or anti-patterns de-

noted by the set P t

anti

. Theoretically, this evolution

process would result in P t

cndt

= P t

frml

∪ P t

anti

However, in reality, the evolutionary process for any

candidate pattern may take several years and depends

mostly on frequent use for that candidate pattern in

practice with different problems to generate either

successful solutions that push forward into formal

pattern or unsuccessful solutions that push forward

into anti-pattern. This phase consists of the ﬁve main

steps:

1. Instantiate the architectural description for each

identiﬁed candidate pattern in P t

cndt

on a given

application domain problem that is formalised with

accordance to the notations in section 2.1. Section

6 discusses the candidate patterns instantiations on

the application domain that is illustrated in section

2.2.

2. Apply the consequences estimation models, which

are discussed in (Dabous et al., 2005; Dabous,

2005), on the given application domain speciﬁca-

tions so that estimation per model for each pattern

architecture is generated.

3. Investigate the stakeholders’ preferences on the re-

quired quality attributes that correspond to the pat-

terns’ consequences.

4. Apply a pattern selection algorithm based on steps

1, 2, and 3 using common MADM methods such

AHP which is discussed in (Al-Naeem et al.,

2005b). The outcome of such a selection method

is a rank for each pattern architecture in P t

cndt

5. The last step is to investigate possibilities of the

evolution of each candidate pattern. A candidate

pattern would gradually evolve into a formal pat-

tern in P t

frml

if it has been occupying one of

the higher ranks and successful stories have been

reported about its usage in practice. Otherwise,

such candidate pattern would gradually evolve into

an anti-pattern in Pt

anti

if it has been occupy-

ing lower ranks and/or unsuccessful stories have

been reported about its usage in practice. While

evolving, each candidate pattern documentation in

P t

cndt

would also be enriched with all experiences

with different problems context together with the

ranks, successful and unsuccessful stories.

Therefore, this framework is extensible because the

incorporation of one extra design strategy generates

A FRAMEWORK FOR IDENTIFYING ARCHITECTURAL PATTERNS FOR E-BUSINESS APPLICATIONS

extra |DS| combinations, and therefore possibly mo-

tivates extra candidate patterns wherever a valid com-

bination is generated. The framework is also system-

atic since all design strategies, candidate patterns, and

consequences models are deﬁned around one com-

mon architectural description (the section 5), and

therefore a tool can be developed in order to navigate

through the steps of this framework. Due to space

limitations, this paper extends only to the ﬁrst phase

of demonstrating the identiﬁcation of a few candidate

patterns and step 1 in the second phase by applying

a realistic application from the domain of e-ﬁnance.

Indeed, related work to step 2 is reported in (Dabous

et al., 2005) and related work to steps 3 and 4 is re-

ported in (Al-Naeem et al., 2005b; Al-Naeem et al.,

2005a). Step 5 of phase 2, which requires long term

validation, is not yet addressed thoroughly in this re-

search.

5 DESIGN STRATEGIES AND

COMBINATION RULES

In this framework, we use the concept of ‘de-

sign strategy’ as a basic architectural construct

into the pattern identiﬁcation process. Each de-

sign strategy is described using the common

architectural description. We use the notion

DS = {Reuse,Automate,Wrap,Migrate,MinCoordinate}

as the set of design strategies used in this paper. We

denote a set XLG to represent the architecture by

creating a component for every legacy system. This

set of components is presumed to exist. This set is

constructed using the following algorithm:

ConstructXLG (LG)

• For each l

∈ LG Do:

1. X

= createNew(); /* creates and initialises a new

component*/

2. access(X

) = api(l

);

3. tasks(X

) = {C(f

) : f

∈ l

};

4. XLG = XLG ∪ {X

} /* add X

to XLG */

Where createNew() function would create a compo-

nent X

of the same type as the components of Comp

and initialise its four features to nil (i.e. access()=

tasks()= conTo()= invBy()= nil). Whereas api(l

)

functions returns the access method that is supported

by the legacy system l

5.1 Design strategies

Reuse This design strategy considers the existing

legacy systems and the functionalities they embed

as existing assets that should be utilised immedi-

ately. Based on the proposed generic architecture,

this design strategy corresponds to creating |LG|

entries in Comp which have been already declared

as the content of the set XLG ⊂ Comp. The non-

automated functionalities (i.e. ∀f ∈ (F

all

− F

))

are not addressed in this design strategy. Its corre-

sponding algorithm is:

REUSE()

• For each X

∈ XLG

∈ XLG:

– Comp = Comp ∪ {X

};

Automate This design strategy creates |F

all

− F

components each of which supports a new func-

tionality that does not exist in any of existing legacy

systems. This strategy implements a uniﬁed ac-

cess type for these new functionalities (i.e. ∀f ∈

all

− F

)). This is accomplished using the fol-

lowing algorithm:

AUTOMATE(ac) /*ac is the access method used*/

• For each f

∈ (F

all

− F

)

∈ (F

all

− F

)

∈ (F

all

− F

1. X

= createNew ();

2. access(X

) = ac;

3. tasks(X

) = {C(f

)};

4. Comp = Comp ∪ {X

};

Wrap This design strategy considers a uniﬁed access

method for all functionalities identiﬁed in the set

of legacy systems (i.e. ∀f

∈ F

). It creates a

total of |F

| components in Comp each of which

corresponds to a wrapper component (i.e. for every

functionality that resides in a legacy system) . This

is accomplished using the following algorithm:

WRAP (ac)

• For each X

∈ XLG such that X

∈ Comp

∈ XLG such that X

∈ Comp

∈ XLG such that X

∈ Comp do:

– For each C(f

) ∈ tasks(X

1. X

= createNew();

2. access(X

) = ac;

3. tasks(X

) = {CW (f

)};

4. invBy(X

) = X

5. conT o(X

) = X

6. Comp = Comp ∪ {X

}

Migrate This design strategy ignores existing legacy

systems and therefore redevelops the functionali-

ties ∀f ∈ F

all

with a uniﬁed access method. This

strategy groups each set of equivalent functionali-

ties q ∈ Q in one component. Therefore, it cre-

ates a total of |Q| new components in Comp where

each new component corresponds to one q ∈ Q

and contains a task C(f

) for each f

∈ q. This is

accomplished using the following algorithm:

MIGRATE(ac) /*ac is the access method used*/

• For each q

∈ Q

∈ Q:

1. X

= createNew ();

2. access(X

) =ac;

3. tasks(X

) = {C(f

) : f

∈ q

};

4. Comp = Comp ∪ {X

}

WEBIST 2005 - INTERNET COMPUTING

MinCoordinate Minimum Coordinate (MinCoordi-

nate) design strategy relates to the implementation

of every bp

∈ BP enactment as an autonomous

component that depends directly on the activities

denoted by activities(bp). This design strategy

mandates that any bp ∈ BP should implement

its own private copy of any required functional-

ity that is not supported in any other component

in Comp. Meaning that an f ∈ F

all

such that

C(f) /∈ tasks(X

)∀X

∈ Comp should imple-

ment an instance of f that is accessed only by X

and therefore tasks(X

) = tasks(X

) ∪ {C(f)}.

This design strategy is accomplished using the fol-

lowing algorithm:

MINCOORDINATE()

1. Let BpComp =φ /* An empty set of same type as

Comp*/

2. For each bp

∈ BP

∈ BP :

(a) X

= createNew ();

(b) access(X

) = φ;

) = {CBL(bp

)};

(d) For each f

∈ activities(bp

) DO:

• IF (∃X

: C(f

) ∈ tasks(X

))

– conT o(X

) = conT o(X

) ∪ {X

};

– invBy(X

) = invBy(X

) ∪ {X

};

• ELSE tasks(X

) = tasks(X

) ∪ {C(f

)};

(e) BpComp = BpComp ∪ {X

};

3. Comp = Comp ∪ BpComp;

5.2 Design strategies combination

rules

The design strategies are combined by linearly apply-

ing their corresponding construction algorithms. The

order in which the participating design strategies are

combined with the aim of generating a ‘valid’ combi-

nation is signiﬁcant. This order is based on associated

rank for each strategy. The ﬁrst rank is for ‘Reuse and

‘Migrate’, the second is for ‘Automate’ and ‘Wrap’,

the third is for ‘MinCoordinate’ design strategy. The

naming convention for the patterns that we consider

shows the participating design strategies in the cor-

rect combining order.

We have investigated the major combining rules

that are applied to any possible design strategies com-

bination and therefore considering this combination

as either valid or invalid. The main idea for such rules

is to make sure that the combined design strategies

algorithms can form a neat architecture when applied

on any problem context speciﬁcation. A neat architec-

ture would guarantee that Comp architecture facili-

tates the connectivity from any business process to all

of its required functionalities without redundancies.

The following rules are the major ones that should ap-

ply in order to consider a valid design strategies com-

bination and therefore a candidate pattern:

1. Existence of tasks that implements all BPs logic:

For every bp ∈ BP, ∃X

: CBL(bp) ∈ tasks(X

2. Existence of tasks that implement all functionalities

in F

all

For every f ∈ F

all

, ∃X

: C(f) ∈ tasks(X

3. A functionality can have one and only one wrapper

component:

If CW (f) ∈ tasks(X

) and CW (f ) ∈ tasks(X

)

such that access(X

) = access(X

) then X

= X

4. Non-redundancy of a BP logic implementation task:

If CBL(bp) ∈ tasks(X

) and CBL(bp) ∈ tasks(X

)

then X

= X

5. Redundancy of a functionality implementation can be

found locally in any BP that requires it if that func-

tionalities is not created publicly elsewhere:

If C(f ) ∈ tasks(X

) and C(f ) ∈ tasks(X

) : X

then CBL(bp

) ∈ X

and CBL(bp

) ∈ X

: a 6=

Otherwise, the generated combination will be ‘in-

valid’ and therefore it is not considered as a candidate

pattern. For instance, such invalid combinations may

generate the following cases:

I The existence of redundancy across the tasks of the

matched design strategies (e.g. ∃C(f ) : C(f) ∈

tasks(X

) and ∈ tasks(X

) where X

and X

are in different design strategies).

II The existence of missing tasks that one of the par-

ticipant design strategies should contain (e.g. For

any f ∈ F

all

∄X

: C(f ) ∈ tasks(X

)).

By applying these rules, we obtained seven valid com-

binations each of which constitutes candidate pat-

tern. The ﬁrst ﬁve patterns are more likely to evolve

into formal patterns because they are initially iden-

tiﬁed based on practical experience and reported in

(Dabous, 2005) whereas the other two are expected

to evolve into anti- patterns because they promote the

isolation of standalone BP implementation that is ob-

solete and does not correspond to current practices.

6 CANDIDATE PATTERNS

Now we brieﬂy discuss the architectural descrip-

tion of the ﬁve candidate patterns. Details of their

forces and consequences are discussed thoroughly in

(Dabous, 2005). We also show the architecture gen-

erated when instantiating each candidate pattern on

the selected application domain (i.e. the contents of

the set Comp). Figures 4-8 illustrate visually the con-

tents of the set Comp for these ﬁve architectures. In

these ﬁgures, each box (i.e. component) corresponds

to an X

∈ Comp showing its tasks as ovals and ac-

cess method on the top of the box whereas each arrow

(i.e. link) from X

to X

means that X

∈ conT o(X

)

and X

∈ invBy(X

). The patterns instantiations of

A FRAMEWORK FOR IDENTIFYING ARCHITECTURAL PATTERNS FOR E-BUSINESS APPLICATIONS

XLG

Access() = nil

CBL(BP5)

C(MktEventDetect)

C(OrderExeMgt)

C(StrategyCnrl)

Access() = nil

CBL(BP4)

C(MktEventDetect)

C(OrderExeMgt)

C(StrategyCnrl)

Access() = nil

CBL(BP3)

C(Regulator )

Access() =nil

CBL(BP2)

Access() = nil

CBL(BP1)

C(BAnalytics )

Access() = API1

C(TeSim1)

C(RealTimesim1)

C(CurrDaySim1)

Access() = API3

C(RealTime3)

C(CurrDay3)

C(TE3)

Access() = API4

C(VisualModel4)

Access() = API2

C(CalibRun2)

C(RealTimeAlerts2)

C(IntraDay2)

C(InterDay2)

C(Analytic2)

Figure 4: Pt1 applied on the application domain

XLG

SO

C(MktEventDetect)

SO

C(OrderExeMgt)

SO

C(StrategyCnrl)

SO

C(Regulator)

SO

C(BAnalytics)

Access() = API3

C(RealTime3)

C(CurrDay3)

C(TE3)

Access() = API4

C(VisualModel4)

Access() = API1

C(TeSim1)

C(RealTimesim1)

C(CurrDaySim1)

Access() = API2

C(CalibRun2)

C(RealTimeAlerts2)

C(IntraDay2)

C(InterDay2)

C(Analytic2)

Access() = nil

CBL(BP1)

Access() =nil

CBL(BP2)

Access() = nil

CBL(BP3)

Access() = nil

CBL(BP4)

Access() = nil

CBL(BP5)

Figure 5: Pt2 applied on the application domain

the application domain correspond to the second step

of the second phase in the proposed framework. We

provide our naming convention for each pattern as fol-

lows:

Reuse+MinCoordinate (Pt1) This pattern considers

generating invocations to the required functional-

ities across legacy system by direct invocations

through the APIs of these systems. On the other

hand, each BP implements its local program code

for each of its activities that have no corresponding

functionality in any of the legacy systems. Figure

4 shows the architecture of Pt1 instantiation on the

selected application domain.

Reuse+Automate+MinCoordinate (Pt2) This pat-

tern considers generating an invocation to the re-

quired functionalities across legacy system by di-

rect invocation through the APIs of these sys-

tems. It also considers implementing all activities

of BPs that have no correspondence in any of the

legacy systems as global e-services with advertised

service-based interface. Figure 5 shows the archi-

tecture of Pt2 instantiation on the selected applica-

tion domain.

Reuse+Wrap+Automate+MinCoordinate (Pt3)

This pattern considers providing a uniﬁed service-

based interface to every particular functionality

across legacy systems. This provision is achieved

by developing service-based Wraps. It also con-

siders implementing all activities of BPs that have

no correspondence in any of the legacy systems

XLG

Access() = nil

CBL(BP5)

Access() = nil

CBL(BP3)

Access() =nil

CBL(BP2)

Access() = nil

CBL(BP1)

SO

C(MktEventDetect)

SO

C(OrderExeMgt)

SO

C(StrategyCnrl)

SO

C(Regulator)

SO

C(BAnalytics)

SO

CW(RealTimeSim1)

SO

CW(CurrDaySim1)

SO

CW(TeSim1)

SO

CW(VisualModel4)

SO

CW(TE3)

SO

CW(CurrDay3)

SO

CW(RealTime3)

SO

CW(Analytic2)

SO

CW(InterDay2)

SO

CW(IntraDay2)

SO

CW(RealTimeAlerts2)

SO

CW(Calibrun2)

Access() = API1

C(TeSim1)

C(RealTimeSim1)

C(CurrDaySim1)

Access() = API3

C(RealTime3)

C(CurrDay3)

C(TE3)

Access() = API4

C(VisualModel4)

Access() = API2

C(CalibRun2)

C(RealTimeAlerts2)

C(IntraDay2)

C(InterDay2)

C(Analytic2)

Access() = SO

CBL(BP4)

Figure 6: Pt3 applied on the application domain

XLG

SO

CW(RealTimeSim1)

SO

CW(CurrDaySim1)

SO

CW(TeSim1)

SO

CW(VisualModel4)

SO

CW(TE3)

SO

CW(CurrDay3)

SO

CW(RealTime3)

SO

CW(Analytic2)

SO

CW(InterDay2)

SO

CW(IntraDay2)

SO

CW(RealTimeAlerts2)

SO

CW(Calibrun2)

Access() = API1

C(TeSim1)

C(RealTimeSim1)

C(CurrDaySim1)

Access() = API3

C(RealTime3)

C(CurrDay3)

C(TE3)

Access() = API4

C(VisualModel4)

Access() = nil

CBL(BP1)

C(BAnalytics )

Access() =nil

CBL(BP2)

Access() = nil

CBL(BP3)

C(Regulator )

Access() = nil

CBL(BP4)

C(MktEventDetect)

C(OrderExeMgt)

C(StrategyCnrl)

Access() = nil

CBL(BP5)

C(MktEventDetect)

C(OrderExeMgt)

C(StrategyCnr)l

Access() = API2

C(CalibRun2)

C(RealTimeAlerts2)

C(IntraDay2)

C(InterDay2)

C(Analytic2)

Figure 7: Pt4 applied on the application domain

as global e- services with advertised service-based

interface. Figure 6 shows the architecture of Pt3

instantiation on the selected application domain.

Reuse+Wrap+MinCoordinate (Pt4) This pattern

considers providing a uniﬁed service-based inter-

face to every particular required function- ality

across legacy systems. This provision is achieved

by developing service-based Wraps. On the other

hand, each BP implements its local program code

for each of its activities that have no corresponding

functionality in any of the legacy systems. Figure

7 shows the architecture of Pt4 instantiation on the

selected application domain.

Migrate+MinCoordinate (Pt5) This pattern con-

siders the disposal or abandoning existing legacy

systems. Therefore, starting from scratch, this pat-

tern migrates the implementation of required func-

tionalities through a re-engineering/automation

process into global e-services with advertised

service-based interface. In this process, each

group of equivalent functionalities are reengineered

within a single program that supports one interface.

WEBIST 2005 - INTERNET COMPUTING

SO

C(InterDay2)

SO

C(VisualModel4)

SO

C(RealTimeAlerts2)

SO

C(CalbRun2)

SO

C(MktEventDetect)

SO

C(OrderExeMgm)

SO

C(StrategyCnrl)

SO

C(Regulator)

Access= SO

C(Banalytic)

C(Analytic2)

Access= SO

C(TeSim1)

C(TE3)

Access= SO

C(RealTimeSim1)

C(RealTime3)

Access= SO

C(CurrDaySim1)

C(IntraDay2)

C(CurrDay3)

Access() = nil

CBL(BP1)

Access() =nil

CBL(BP2)

Access() = nil

CBL(BP3)

Access() = nil

CBL(BP4)

Access() = nil

CBL(BP5)

Figure 8: Pt5 applied on the application domain

Figure 8 shows the architecture of Pt5 instantiation

on the selected application domain.

MinCoordinate (Pt6) and Automate+MinCo. (Pt7)

are more likely to evolve into anti-patterns because

they promote the isolation and standalone BP

implementation that is obsolete and does not

correspond to current practices.

7 CONCLUSION

In this paper, we presented and discussed the basic

components of a systematic extensible framework for

identifying patterns for the architectural design of a

category of applications in the e-business domain.

This work is motivated by three factors. The ﬁrst one

is the availability of ﬁve architectural patterns that are

identiﬁed and formalised in (Dabous, 2005) based on

practical experience in developing e-business appli-

cations that utilise legacy functionality in the domain

of e-ﬁnance. The second one is the quality models

reported in (Dabous, 2005; Dabous et al., 2005) that

estimate the patterns consequences for a given appli-

cation domain speciﬁcation. The third one is the ar-

chitectural patterns selection method based on AHP

that is reported in (Al-Naeem et al., 2005b; Al-Naeem

et al., 2005a).

The proposed framework is systematic and extensi-

ble. It is systematic since the formalisation of the de-

sign strategies, the candidate patterns and the quality

models uses the same common architectural descrip-

tion. It is also extensible since the identiﬁcation of

each extra design strategy would duplicate the number

of strategies combinations and therefore possibly trig-

gers extra candidate patterns. In (Dabous, 2005), we

illustrated the impact of introducing additional two

strategies on identifying more candidate patterns.

Current work focuses on providing tool support for

automatic generation of the candidate patterns archi-

tectures for a given application domain speciﬁcation

and for ranking the architectures generated by instan-

tiating these patterns with accordance to their appro-

priateness based on both the estimations provided by

the quality models and the preferences for such qual-

ity provided by stakeholders.

REFERENCES

Al-Naeem, T., Dabous, F. T., Rabhi, F. A., and Beatallah,

B. (2005a). Formulating the architectural design of

enterprise applications as a search problem. In Aus-

tralian Software Engineering Conference (ASWEC

2005), Australia. Computer society Press.

Al-Naeem, T., Dabous, F. T., Rabhi, F. A., and Benatal-

lah, B. (2005b). Quantitative evaluation of enterprise

integration patterns. In 7th Int. Conf. on Enterprise

Information Systems (ICEIS05), Miami, USA.

Anderson, D., Sweeny, D., and Williams, T. (2002). An In-

troduction to management Science: Quantitative Ap-

proaches to Decision Amking. South-Western Educa-

tional Publishing.

Dabous, F. T. (2005). Pattern-Based Approach for the Ar-

chitectural Design of e-Business Applications. Phd

thesis, School of Information Systems, Technology

and Management, The University of New South

Wales, Australia. (to be submitted in Apr 2005).

Dabous, F. T., Rabhi, F. A., and Yu, H. (2003). Perfor-

mance issues in integrating a capital market surveil-

lance system. In Proceedings of the 4th International

Conference on Web Information Systems engineering

(WISE03), Rome, Italy.

Dabous, F. T., Rabhi, F. A., Yu, H., and Al-Naeem, T.

(2005). Estimating patterns consequences for the

architectural design of e-business applications. In

7th Int. Conf. on Enterprise Information Systems

(ICEIS05), Miami, USA.

Harris, L. (2003). Trading and Exchanges: Market Mi-

crostructure for Practitioners. Oxford University

Press.

Rabhi, F. A., Dabous, F. T., Chu, R. Y., and Tan, G. E.

(2003). SMARTS benchmarking, prototyping & per-

formance prediction. Technical Report CRCPA5005,

Capital Market Cooperative Research Center (CM-

CRC).

Yu, H., Rabhi, F. A., and Dabous, F. T. (2004). An ex-

change service for ﬁnancial markets. In 6th Interna-

tional Conference on Enterprise Information Systems

(ICEIS04), Porto, Portugal.

A FRAMEWORK FOR IDENTIFYING ARCHITECTURAL PATTERNS FOR E-BUSINESS APPLICATIONS