DYNAMIC INTERACTION OF INFORMATION SYSTEMS

Weaving Architectural Connectors on Component Petri Nets

∗

Nasreddine Aoumeur, Gunter Saake

ITI, FIN, Otto-von-Guericke-Universit

at Magdeburg, Postfach 4120, D–39016 Magdeburg, Germany

Kamel Barkaoui

Laboratoire CEDRIC, CNAM, 292 Saint Martin, 75003 Paris - France

Keywords:

High-Level Nets, rewriting logic, speciﬁcation/validation, architectural techniques, dynamic evolution.

Abstract:

Advances in networking over heterogenous infrastructures are boosting market globalization and thereby forc-

ing most software-intensive information systems to be fully distributed, cooperating and evolving to stay com-

petitive. The emerging composed behaviour in such interacting components evolve dynamically/rapidly and

unpredictably as market laws and users/application requirements change on-the-ﬂy both at the coarse- type

and ﬁne-grained instance levels.

Despite signiﬁcant proposals for promoting interactions and adaptivity using mainly architectural techniques

(e.g. components and connectors), rigorously specifying / validating / verifying and dynamically adapting

complex communicating information systems both at type and instance levels still remains challenging. In

this contribution, we present a component-based Petri nets governed by a true-concurrent rewriting-logic based

semantics for specifying and validating interacting distributed information systems. For runtime adaptivity,

we enhance this proposal with (ECA-business) rules Petri nets-driven behavioral connectors, and demonstrate

how to dynamically weaving them on running components to reﬂect any emerging behavior.

1 INTRODUCTION

Advances in networking over heterogenous infras-

tructures are forcing most software-intensive systems

to be fully distributed, cooperating and evolving in

facing the ﬁerce struggle to stay competitive. This

situation is more acute for contemporary informa-

tion systems where market globalization and volatil-

ity are pressing business laws, policies (makers) and

users requirements to adapt/evolve on-the-ﬂy, unpre-

dictably and rapidly. These facts have been urging

organizations to shift from their traditional integrated

form with centralized control to loosely-coupled net-

worked applications owned and managed by diverse

business partners.

With the huge difﬁculties of directly and sat-

isfactory implementing such complex communicat-

ing systems even with the availability of advanced

networked infrastructures and standards (e.g. Web-

Services and Service-oriented computing), more re-

∗

This research is partially supported by a DFG (German

Science Foundation) Project Under Contract SA 465/31-1.

search efforts are nowadays devoted to foundational

early phases of speciﬁcation, validation and veriﬁca-

tion. Additionally, the tedious challenges of adaptiv-

ity must be tackled at these requirement early phases;

otherwise any initial certiﬁed speciﬁcation becomes

rapidly outdated and useless, where afterwards the

standing-alone programmers will be on charge of un-

controlled/unwished/untractable maintenance.

Architectural techniques over component-

orientation belong to the mostly investigated and

appropriate software-engineering conceptual means

to address the adaptivity through their ﬁrst-class

explicit connectors (Cheng and Garlan, 2001;

Szyperski, 1998) and their reconﬁgurations. Never-

theless, due to the growing complexity and volatility

of such complex interacting software-intensive

systems, it seems we are still far from a satisfactory

architectural-based proposal. Indeed, existing pro-

posals either focus on the coarse-grained component

level (adding/removing/replacing components) while

ignoring the component instance level (e.g. internal

statefull functionalities) or vice-versa. As will be

152

Aoumeur N., Saake G. and Barkaoui K. (2007).

DYNAMIC INTERACTION OF INFORMATION SYSTEMS - Weaving Architectural Connectors on Component Petri Nets.

In Proceedings of the Ninth International Conference on Enter prise Information Systems - ISAS, pages 152-158

DOI: 10.5220/0002402501520158

 SciTePress

demonstrated in this paper both levels are vital for

expressing dynamic change and evolution.

With respect to information systems, the authors

are not aware of any approach that handles dynamic

adaptivity by respecting cross-organizational business

rules (Wan-Kadir and Loucopoulos, 2003) at the ar-

chitectural level at both the type and instance levels.

Business rules are the main driving force for reshap-

ing inter-organizations goals, policies and function-

ing/regulations and are therefore rapidly evolving to

enhance the competitiveness.

This paper puts forwards a (business-) rule-based

architectural approach for specifying / validating and

dynamically adapting complex gross-organizational

information systems. Methodologically, given a

(UML-based) semi-formal description of the applica-

tions, we ﬁrst propose a formal speciﬁcation based

on a variant of component-based Petri nets, we in-

troduced in (Aoumeur and Saake, 2002). In this

so-called CO-NETS framework, IS components are

conceived as a hierarchy of modular classes we ex-

plicit observed interfaces. For validating such com-

ponents, a true-concurrent rewriting logic-based is

proposed for governing different transitions behav-

ior. We further enrich CO-NETS with the concept

of rule-driven architectural connector behavior. Such

architectural connectors reﬂect different ubiquitous

cross-organizational and thus inter-component do-

main business rules. As we separately and explic-

itly specify such connectors, we are able to dynam-

ically weaving the right rules when required to reﬂect

the enforcement of new/modiﬁed policies, laws and

other requirements. Crucial to point out is that the

proposed dynamic weaving is non-intrusive, that is,

we do not delve inside component functionalities or

change/adapt any existing component internal behav-

ior.

The rest of the paper is organized as follows.

In the second section we review the main CO-NETS

features and illustrate them with a simpliﬁed bank-

ing system. The third section introduce the concept

of (business) rule-based architectural connectors at a

semi-formal level. The fourth main section focuses on

the modeling of such connectors within CO-NETS and

how they are dynamically woven on interacting com-

ponents. This paper is closed by some remarks and

insights about future extensions. We should note that

the paper’s presentation is kept at an informal level

with some hints when required to the formal counter-

part.

2 CO-NETS COMPONENTS:

OVERVIEW WITH

ILLUSTRATIONS

2.1 CO-NETS Component Structure

The component structure deﬁnes the structure of ob-

ject states and operations to be accepted by such

states. The CO-NETS signature that we are propos-

ing can be informally described as follows:

• Object states are algebraic terms of the form:

hId|l

, ..l

, f

(Id), .., f

(Id), s

′

, .., s

′

Where Id represents an observed object iden-

tity. l

, .., l

denotes local attributes with re-

spective current values v

, .., v

. The attributes

(Id), .., f

(Id) are considered as hidden (deﬁned

in a co-algebraic way). Observed attributes can be

also be deﬁned such as s

, ..., s

• To separate at any time local attributes from ob-

served ones and exhibit intra-concurrency, we in-

troduce a simple deduction rule we call ‘object-

state splitting / merging’ rule that permits to split

(resp. recombine) the object state as required.

• We also make an explicit distinction between in-

ternal messages and external as imported / ex-

ported messages.

With respect to this perception each template signa-

ture is henceforth endowed with an explicit interface

composed of observed attributes and messages, and

that we subsequently refer to as (basic) component

signature.

2.1.1 The Account and Customer Components

We assume having accounts and customers that we

naturally regarded as two separate yet interacting

components. For instance, for the account compo-

nent signature, each (current) account is composed

of: a balance (shortly

bal

) as observed, and a min-

imal limit (

lmt

), a boolean value (

Red

) valuated to

true when below limit.

obj

account

extending

object-state .

protecting

Account-data .

sorts

Acnt .

subsort

Id.Acnt

OId .

subsort

DEB CRD TRS

Obs Msg.

subsort

ChgL

Loc Msg.

subsort

loc Acnt obs Acnt

Acnt

object .

(* attributes as functions*)

Pin : Id.Acnt

→

string .

(* Local attributes *)

op h | Bal : , Lmt : , Hs : i

: Id.Acnt

DYNAMIC INTERACTION OF INFORMATION SYSTEMS - Weaving Architectural Connectors on Component Petri

Nets

153

Money Money History

→

loc Acnt.

(* observed attributes *)

op h | Hd : i

: Id.Acnt OId

→

obs Emp .

(* Local messages *)

Chgl : Id.Acnt Money

→

ChgLm .

(* observed messages *)

Deb : Id.Acnt Money Date

→

DEB.

Crd : Id.Acnt Money Date

→

CRD.

Trs : Id.Acnt Id.Acnt Money Date

→

TRS.

vars

B, L, W, D : Money ; C : Id.Acnt .

endo



2.2 CO-NETS Component Behaviors

On the basis of a given component structure, we de-

ﬁne the notion of component speciﬁcation as a CO-

NET in the following straightforward way.

• CO-NETS places are precisely deﬁned by associ-

ating with each message declaration or method

one (message) place, that is, such messages places

contain associated message instances sent or re-

ceived by objects but not yet performed. Also,

with each object sort a (object) place is associated.

• CO-NETS transitions reﬂect the effect of messages

on object states they are addressed to. Conditions

may be associated to them restricting their appli-

cation.

Application to the Account and Customer Com-

ponents. The associated CO-NETS account compo-

nent is depicted in the left-hand side of Figure 1. This

component is composed of current accounts as a su-

perclass and saving accounts as a subclass (where the

interest could be increased through

Tinc

and money

be moved from a saving account to a current account

using

Tmvt

). The right-side of this ﬁgure represents

the customer component. As described above, in this

net in addition to the object place

ACNT

that contains

all account instances three message places namely

ChgL

DEB

and

CRD

have been conceived.

2.3 CO-NETS Component Interactions

By taking beneﬁt of explicit component interfaces

(i.e. observed attributes and import / export mes-

sages), we present how interacting behaviorally dif-

ferent components, leading to cooperative informa-

tion systems composed of several truly distributed and

independent yet cooperating CO-NETS components.

As depicted in Figure 2, the general schema of ’ex-

ternal’ transitions reﬂect this communication where

Just relevant external parts of component states enter

into contacts with observed messages and resulting

(under conditions) in: (1) the messages ms

, .., ms

being consumed; (2) states of some external parts

of objects participating in the communication being

changed; and (3) new external messages (that may in-

volve deletion/creation ones) being sent to objects at

different components, namely ms

, .., ms

. . . .

Condition

. .

hId

|bs

: v

, ...i

hId

|bs

: v

, ...i

Bs(obj

)

Bs(obj

)

Mes

⊕

hId

|bss

⊕

hId

|bss

⊕

hId

bss

′

⊕

hId

|bss

′

Figure 2: The Inter-component interaction pattern.

Application to the Running Example. In Figure 3

the interaction of the two components is described us-

ing exclusively their observed features. We note here

that besides those explicitly deﬁned as observed fea-

tures, attributes as functions are also observed, but

their contents cannot be accessed either at local or at

this interaction level. This concerns in particular the

Pin attribute as function. Here are some comments

on this observed interaction behaviour. The transition

Twrd

, for instance, captures the sending of a withdraw

order from the customer, namely

C-Deb(C,A,M)

, that

have to be received by the withdraw message in the

concerned account (i.e. the account of this customer

as account hold). This means that we have to select

from the observed account attribute through the read-

arc the inscription:hA|Hd : Ci.

2.4 Animating and Validating CO-NETS

Speciﬁcations

One of the most advantage of the CO-NETS approach

is its operational semantics expressed in rewriting

logic; moreover, by introducing the state splitting /

recombining axiom there is a natural exhibition of

intra-object concurrency. More precisely, each tran-

sition is governed by a corresponding rewrite rule in-

terpreted in rewrite logic (Meseguer, 1992) (or more

precisely an instantiation of this logic we refer to as

CO-NETS rewrite theory. The main ideas consist in:

(1) associating with each marking mt its correspond-

ing place p as a pair (p, mt); (2) introducing a new

multiset generated by a union operator we denote by

⊗ for reﬂecting CO-NETS states as multisets over dif-

ferent pairs (p

, mt

), , that is, a CO-NETS state is de-

scribed as (p

, mt

) ⊗ (p

, mt

) ⊗ ...; (3) allowing the

distributivity of ⊗ over ⊕ for exhibiting a maximal

of concurrency, that is, if mt

and mt

are two mark-

ing multisets then we always have: (p, mt

⊕ mt

) =

(p, mt

) ⊗ (p, mt

); (4) enabling object states’ split-

ICEIS 2007 - International Conference on Enterprise Information Systems

154

. . . .

. . .

Trs(a1,a2,M)

Inc(s,0.3)

ChgA(c2,..)

Mv(s,a,78)

Deb(a1,45)

Crd(a2,78)

C−Deb(c1,4)

C−Crd(c4,5)

. . . . .

Customer

. . . . .

Sav_acnt

Incr

ChgA

C−Deb

C−Crd

The Account Component

The customer Component

Ttrs

ACNT

MVT

Tdeb

Tcrd

DEB

CRD

Tinc

Tmvt

|Bal : 45, Hs : [],Hd : Annai

|Bal : 15, Hs : [1.1.01, +48], Hd : Alexi

Deb(A,W)

hA|Bal : Bi

hA|Bal : B−Wi

True

Crd(A, D)

hA|Bal : Bi

hA|Bal : B+ Di

Trs(A1, A2, M)

True

Dep(A2, M)

Wrd(A1, M)

True

hS|Int : 0.2, Dinc : 1.1.03i

Inc(S, Ir)

Ir > I

hS|Int : I, Dinc : Di

hS|Int : Ir, Dinc : Dci

Mv(S, A, M)

True

∼

hA|Hd : DihS|Hd : Di

Trs(S, A, M)

Ch(C, Adr)

True

hC|Adr : Di

hC|Adr : Dri

|Cust : elan, Adr : Bonn,...i

Figure 1: A Simpliﬁed Banking speciﬁcation within CO-NETS.

ting and recombining at a need for exhibiting intra-

object concurrency.

Application to the Account Component. By ap-

plying the afore-described general form of rewrite

rules, it is not difﬁcult to generate the transition rules

associated with the CO-NETS speciﬁcation of the

banking example. The rewrite rule associated with

the debit transition

Tdeb

is:

Tdeb :(DEB, Deb(C,W)) ⊗ (ACNT, hC|Bal : Bi)

⇒ (ACNT, hC|Bal : B−Wi)

3 ECA-RULE BASED

ARCHITECTURAL

CONNECTORS

Architectural connectors must generally endowed

with: (1) roles expressing functional requirements

from candidate components to interact; and (2) glues

for expressing the behavior governing such inter-

component interaction. As we are targeting com-

plex information systems are main domain applica-

tion, instead of just exchanging and ordering mes-

sages at this interaction level we propose a more

knowledge-intensive behavioral interaction patterns

expressed in terms of business rules. For such cross-

organisations business rules, we propose the most

adopted form which the Event-Conditions-Actions

(ECA) paradigm. More precisely the general pattern,

we decide to follow for expressing inter-component

interactions is as follows:

ECA-behavioral glue <glue-Identity>

interface participants <list-of-participants>

invariant <possible interaction constraints to respect>

constants/attributes/operations

<extra-required elements for the interaction>

interaction rules: <Rule-Name>

at-trigger <

(set-of-)events

under <

conditions

reacting <

set-of-actions

This behavioral rule requires of course from dif-

ferent participating entities explicit interfaces includ-

ing different events, messages and other properties

(such as constants, variables ,etc). When needed, we

explicitly specify such interfaces before giving this

glue.

3.1 ECA Behavioral Glues: Illustration

To stay competitive banking systems are offering dif-

ferent incitive packages for their customers, rang-

ing from simple agreed-on contracts (e.g. different

formulas for withdrawing / transferring moneys) to

highly sophisticated complex offers (i.e. staged hous-

DYNAMIC INTERACTION OF INFORMATION SYSTEMS - Weaving Architectural Connectors on Component Petri

Nets

155

. . . .

Customer

Cwdri3

Account

TRS

CRD

Twdr

Tdep

Ttrfs

DEB

C−DEB

C−CRD

C−TRS

Observed Customer Component

Observed Account Component

C− Deb(C, A, M)

hA|Hd : Ci

Deb(A, M)

True

C−Crd(C, A, M)

hCi

hA|Hd : Ci

Crd(A, M)

True

|Hd : Anna, Pin(a

|Name : Alexi

C− Trs(C1,C2, A1, A2, M)

hC1ihC2i

hA1|Hd : C1ihA2|Hd : C2i

Trs(A1, A2, M)

True

Figure 3: The Customer account CO-NETS components interaction.

ing loans, mortgages, etc.) depending on their pro-

ﬁles, trust, experiences, etc.

Let us illustrate simple cases of customer-bank

agreements using our running example, through two

customer-tailored variants of withdrawals. The usual

case for any ordinary customer is to check what is

called standard withdrawal, where the customer has

to be the owner of a corresponding account and the

withdrawal amount should not go beyond the current

balance.

ECA-behavioral glue

Std-Withdraw

participants Acnt: Account; Cust: Customer

invariants Cust.own(Acnt) = True

interaction rule : Standard

at-trigger

Cust.withdraw(M)

under

(Acnt.bal()

≥

acting

Acnt.Debit(M)

end Std-withdraw

A more ﬂexible withdrawal for moderately pre-

vileged customers is to endow them with a credit

those amount depends on proﬁle and trust. Customers

enjoying such agreements can now withdraw amounts

going beyond the current balance. The modelling of

such ﬂexible agreed-on withdrawal takes the follow-

ing slightly modiﬁed behavioral glue.

ECA-behavioral glue

VIP-Withdraw

participants Acnt: Account; Cust: Customer

attribute Cust.credit : Money

invariants Cust.own(Acnt) = True

interaction rule : VIP

at-trigger

Cust.withdraw(M)

under

(Acnt.bal() +Cust.credit

≥

acting

Acnt.Debit(M)

end VIP-withdraw

4 MODELLING ECA

BEHAVIORAL CONNECTORS

AS EXTENDED CO-NETS

With CO-NETS capabilities in capturing statefull

components behavior, we present in the following

how ECA-driven architectural connectors enhance

these potentials towards more dynamic adaptivity

and evolution. Following the same intuitive guide-

lines for constructing CO-NETS components from in-

formal component-based applications, the modelling

steps for integrating such architectural connectors

into already speciﬁed CO-NETS components could

sketched in the following. First, we have derive from

a given ECA-based architectural connector descrip-

tion, a more precise corresponding component signa-

ture speciﬁcation by algebraically specifying different

properties (attributes, messages, events, etc.). Sec-

ondly, by gathering different connector attributes and

participants into states, we then associate such each

state type a corresponding place and with each mes-

sages and operations also a place. This results in the

skeleton of the Petri net for such architectural con-

nectors. Finally, we have to inject the rules into such

skeleton by assigning conditions to transition condi-

tions, events as input arc-inscriptions and actions as

output ones. In a more detail, these translating steps

could be explained as follows:

1. Deﬁne architectural connector structure alge-

braically using the CO-NETS component signa-

ture pattern. That is, ﬁrst, gather all compo-

nent participants interface identities with possible

other attributes into a glue state type-as-tuple.

2. Specify all involved messages, events, constants

ICEIS 2007 - International Conference on Enterprise Information Systems

156

. . . .

VIP−Package

. . . .

C_Wdr

C−Dep

C−Trs

Trd−Package

. . . .

DEB

. . . .

CRD

. . . .

REG−Ctr

TRS

The observed part of the regulator component

Obs(Customer)

Obs(Account)

Obs(Regulator)

The observed part of the Account component

The observed part of the customer component

The inter−component coordination contracts

REST

contr3i4

Tvip

Ttrd

Tinhb

hA|Bal(A), Hd : Ci

hT|Acnt : A,Cust : Ci

Wrd(C, A, M)

Bal(A) ≥ M

Deb(A, M)

|Bal(a

), Pin(a

hcs

|Cs

N : Annai

hct

|Ac : a

,Cs : c

hA|Bal(A), Hd : Ci

hT|Ac :,Cs :C, Crd : Di

Wdr(A, C, M)

(Bal(A) > Cst VIP) ∧ (Bal(A) + D > M)

Deb(A, M)

hct

|Ac : a

,Cs : c

,Crd : d

hCt

|Reg : r

, Acnt : a

hrg

|big : nil, small : nili

Deb(A, M)

hA|Bal(A)i

hCt|Reg : R, Acnt : Ai

hR|big : nil, small : nili

big ≥ small

big ←− bal(A) small ←− M

Deb(A, M)

hR|big : bal(A), small : Mi

Figure 4: ECA-Architectural connectors woven on the CO-NETS banking system.

and invariants in a given architectural connector

using a precise algebraic setting.

3. Associate with each state type a given ”glue-state”

place, and with each local messages and events a

given place.

4. The transitions for architectural connectors have

to be constructed for reﬂecting the different ECA-

rules. The general pattern for such interacting

transitions is to be conceived following now the

new general pattern we depict in Figure 4. This

pattern expresses the idea of dynamically weaving

exogenous behavior of interacting components.

Thats is: (1) Involved component interfaces in a

given ECA architectural behavior are captured us-

ing observed state parts (places) from such CO-

NETS components and imported/exported mes-

sages (places); (2) These interface elements (e.g.

observed states and messages) enter into contact

to reﬂect the ECA-rule in question; (3) To al-

low renaming and reﬁnement while weaving such

architectural behavior, we add in the interaction

transition new boxes for eventual term assign-

ments.

4.1 Illustration Using the Running

Example

We approach the two already conceived architectural

within the CO-NETS framework following the above

steps. That is, as shown below ﬁrst their algebraic

signatures are derived—the ECA-rule themselves are

skipped and replaced by just informal text as they are

to be speciﬁed through the architectural Petri net af-

terwards.

obj

Std-Withdrawal .

extending

object-state .

using

Id.Acnt Id.Cust .

subsort

StdGlue

object .

(* StdGlue state *)

op h | Acnt : ,Cust : i

: Id.StdGlue

Id.Acnt Id.Custm

→

StdGlue.

vars

Z : Money ; H : Id.Cust .

vars

A : Id.Acnt, C: Id.Cust, Gl : Id.StdGlue .

endContract



obj

VIP-Withdraw .

extending

object-state .

using

Id.Acnt Id.Cust .

subsort

VIPglue

object .

(* VIPGlue state *)

CST VIP :

→

Nat

op h | Acnt : ,Cust : ,Crd( ) : i

: Id.VIPGlue

Id.Acnt Id.Custm Real

→

VIPGlue.

vars

Z : Money ; H : Id.Custm .

vars

A : Id.Acnt, C: Id.Cust, Ct : Id.VIPGlue .

DYNAMIC INTERACTION OF INFORMATION SYSTEMS - Weaving Architectural Connectors on Component Petri

Nets

157

CST VIP = Nat Value

endContract



5 CONCLUSIONS

For reliably developing complex concurrent and dy-

namically evolving information systems, we extended

component-based Petri nets with ECA-compliant be-

havioral architectural connectors. We shown how to

incrementally incorporate different state-full connec-

tors those behaviors being extracted from externalized

cross-organizational business rules. Both graphical

animations and concurrent symbolic computations us-

ing soundly enriched rewriting logic are possible for

validating the conceived evolving conceptual model.

This ﬁrst step towards enhancing component-

based formalisms with dynamic inter-component ex-

plicit and state-full interactions in true-concurrent dis-

tributed environments has to be further worked out for

resulting in a complete methodology with adequate

software tools supporting it.

ACKNOWLEDGEMENTS

The authors are grateful to the insightful comments

and suggestions of the reviewers.

REFERENCES

Aoumeur, N. and Saake, G. (2002). A Component-Based

Petri Net Model for Specifying and Validating Coop-

erative Information Systems. Data and Knowledge

Engineering, 42(2):143–187.

Cheng, S. and Garlan, D. (2001). Mapping architectural

concepts to uml-rt. In Proc. of the International Con-

ference on Parallel and Distributed Processing Tech-

niques and Applications (PDPTA’2001).

Meseguer, J. (1992). Conditional rewriting logic as a uni-

ﬁed model for concurrency. Theoretical Computer

Science, 96:73–155.

Szyperski, C. (1998). Component Software : Beyond

Object-Oriented Programming. Addision-Wesley.

Wan-Kadir, W. and Loucopoulos, P. (2003). Relating

Evolving Business Rules to Software Design. Jour-

nal of Systems Architecture.

ICEIS 2007 - International Conference on Enterprise Information Systems

158