On the Formalisation of an Application Integration Language

Using Z Notation

Mauri J. Klein, Sandro Sawicki, Fabricia Roos-Frantz and Rafael Z. Frantz

UNIJUÍ University, Department of Exact Sciences and Engineering, Bairro Universitário, Ijuí, Brazil

Keywords:

Enterprise Application Integration, Domain-Speciﬁc Language, Formalisation, Z Notation.

Abstract:

Companies rely on applications in their software ecosystem to provide IT support for their business processes.

It is common that these applications were not designed taking integration into account, which makes hard

their reuse. Enterprise Application Integration (EAI) focuses on the design and implementation of integration

solutions. The demand for integration has motivated the rapid growing of tools to support the construction of

EAI solutions. Guaraná is a proposal that can be used to design and implement EAI solutions, and different

from other proposals includes a monitoring system that can be conﬁgured using a rule-based language to

endow solutions with fault-tolerance. Although Guaraná is available, it has not been formalised yet. This is

a limitation since it is not possible to validate the rules written by software engineers, using the rule-based

language, to ensure that all possibilities of failure in a given EAI solution are covered. Besides, it is not

possible to generate automatically these rules based on the semantics of the EAI solution. In this paper we

provide a formal speciﬁcation of the language provided by Guaraná to design EAI solutions, using Z notation.

1 INTRODUCTION

Business processes frequently demand support from

applications. Companies count on software ecosys-

tems (Messerschmitt and Szyperski, 2003) that are

mostly composed of applications that are legacy sys-

tems, packages purchased from third parties, or de-

veloped at home to solve a particular problem. As a

result, these heterogeneous software ecosystems con-

tain applications that were not designed taking inte-

gration into account. Integration is necessary, chieﬂy

because it allows to reuse two or more applications to

support new business processes, or because the cur-

rent business processes have to be optimised by in-

teracting with other applications within the software

ecosystem.

Enterprise Application Integration (EAI) provides

methodologies and tools to design and implement

EAI solutions. The goal of an EAI solution is to keep

a number of applications’ data in synchrony or to de-

velop new functionality on top of them, so that ap-

plications do not have to be changed and are not dis-

turbed by the EAI solution (Hohpe and Woolf, 2003).

Figure 1 illustrates a typical EAI solution, composed

of two processes that contain the integration logic and

ﬁve communication ports that allow for the interac-

tion with applications and between processes.

Sostware

Ecosystem

Integration

Solution

Business Processes

Figure 1: Typical integration solution.

n the last few years, the demand for integra-

tion has motivated the rapid growing of tools to sup-

port the design and the implementation of EAI so-

lutions, such as Camel (Ibsen and Anstey, 2010),

Spring Integration (Fisher et al., 2010), Mule (Dos-

sot and D’Emic, 2009), and Guaraná (Frantz et al.,

2011). As applications, an EAI solution can fail dur-

ing its execution. A desirable feature on integra-

tion tools is fault-tolerance, so that an EAI solution

can keep running despite of the occurrence of fail-

ures. Error monitoring is an important activity in

fault-tolerance, since it enables the detection of er-

rors. Camel, Spring Integration, and Mule provide

an error detection mechanism mostly based on the

widely-used try-catch (Goodenough, 1975). To the

best of our knowledge, Guaraná is the single proposal

314

J. Klein M., Sawicki S., Roos-Frantz F. and Z. Frantz R..

On the Formalisation of an Application Integration Language Using Z Notation.

DOI: 10.5220/0004967003140319

In Proceedings of the 16th International Conference on Enterprise Information Systems (ICEIS-2014), pages 314-319

ISBN: 978-989-758-027-7

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

that provides an error detection mechanism based on

a monitoring system that can be conﬁgured using a

rule-based language to help in the detection of er-

rors (Frantz et al., 2012). Guaraná is composed of

a domain-speciﬁc language (DSL) to design EAI so-

lutions and a framework plus a runtime system that

allows for the implementation and execution of EAI

solutions. By means of the rule-based language soft-

ware engineers can write rules to express the expected

behaviour and then the correct execution of an EAI

solution designed with Guaraná DSL.

The construction of a model that precisely de-

scribes an EAI solution and allows for an analysable

model depends on formality. Although Guaraná DSL

is available, it has not been formalised yet. Its meta-

model is expressed using the Uniﬁed Modeling Lan-

guage (UML) notation (OMG, 2011) and constrained

using the Object Constraint Language (OCL) (OMG,

2012). Thus, it is not possible to reason about EAI

solutions designed using Guaraná DSL. Reasoning

would allow us not only to validate whether the rules

written by software engineers to detect errors cover

all possibilities of failure in a given EAI solution, but

also build the foundations to generate in an automated

fashion these rules based on the semantics of the EAI

solution.

According to van Lamsweerde (2000), a formal

speciﬁcation must be expressed in a language made

of three components: syntax, semantics, and rules for

reasoning on the speciﬁcation. The latter component

enable analysis on the speciﬁcation in an automated

fashion. Therefore, in this paper, we start the formali-

sation of Guaraná DSL by providing a formal speciﬁ-

cation of its abstract syntax using Z notation (Spivey,

1992).

Formal Speciﬁcation has been studied since of the

principles of Computer Science (Floyd, 1967; Dijk-

stra, 1975; Wing et al., 1999). The interest on for-

mality, mainly concerning language deﬁnition, has

been growing continually since that point (Bowen and

Hinchey, 2006; Harel and Rumpe, 2004; Shroff and

France, 1997). In Harel and Rumpe (2004), the au-

thors argue that any language, no matter how it is,

whether textual or visual, for programming or design,

it must be complete, with clear syntactic rules and

rigid description of their meaning. A sound language

deﬁnition must rigorously deﬁne the mapping of each

syntactic element to its meaning. Often, language de-

signers make such mapping informally. According to

the same authors, providing a formal semantics for the

languages, together with tools for analysing and exe-

cuting their behaviour and for consistency checking,

is crucial (Harel and Rumpe, 2004).

In the literature, there are a number of works pro-

viding formal speciﬁcations for modelling languages,

likewise we propose in this paper. In Mostafa et al.

(2007); Shroff and France (1997); Kim and Carring-

ton (1999), the authors formalise UML diagrams us-

ing Z notation. Hong and Mannino (1995) provide

a denotational semantics for UML. Kaliappan and

König (2012) give formal semantics to UML activ-

ity diagrams using the compositional Temporal Logic

of Actions. In another work, Vidal et al. (2012) for-

malise the semantics of OWL-S services choreogra-

phy using Petri nets. As argued by van Lamsweerde

(2000), the major contribution of a formal speciﬁca-

tion is that it can be automatically manipulated by

tools for a wide variety of purposes, such as anima-

tions of the speciﬁcation in order to check its ade-

quacy, generation of test cases and counterexamples.

The rest of this paper is organised as follows: Sec-

tion 2 gives an overviewof the metamodel of Guaraná

DSL; Section 3 presents the formal speciﬁcation of

the abstract syntax of Guaraná DSL; Section 4 dis-

cusses challenges and future work; and, ﬁnally, Sec-

tion 5 presents our conclusions.

2 Guaraná DSL

In this section, we provide an overview of the abstract

syntax of Guaraná DSL. Figure 2 depicts the UML-

based metamodel as introduced by authors in Frantz

et al. (2011).

In this metamodel, Solution is the root class and

it represents an EAI solution. A Solution has a name

property, which is used for documentation purposes

only, and consists of one or more Processes, one or

more Applications, and one or more Links. Class Pro-

cess contains the integration logic necessary to inter-

act with applications within the software ecosystem

and to process data that ﬂows in the EAI solution.

A Process is composed of at least one EntryPort, at

least one ExitPort, at least one Task, and at least two

Slots. Ports are composed of tasks and slots, that get

connected by Links; these, in turn, can be either Ap-

plicationLinks, which connect Applications to Ports,

or IntegrationLinks, which connect EntryPorts to Ex-

itPorts. Every task has a name, a set of inputs, a set

of outputs, and an executionBody. Both inputs and

outputs are connected to slots at run time and hold

messages; the execution body is a piece of Java code

that implements the atomic activity that must be car-

ried out by the task. Inside the execution body, a soft-

ware engineer may reference the messages held in the

inputs and outputs.

OntheFormalisationofanApplicationIntegrationLanguageUsingZNotation

315

name : Name

Solution

name : Name

Process

outputs : Name[0..*]

inputs : Name[0..*]

executionBody : EString

name : Name

Task

name : Name

Application

ApplicationLink

name : Name

Link

name : Name

Port

ExitPortEntryPort

relatedOutput : Name

relatedInput : Name

name : Name

Slot

IntegrationLink

links

1..*

applications

1..*

processes

1..*

slots

2..*

tasks

process

1..*

0..1

entryPorts

process

1..*

exitPorts

process

1..*

sourceoutputSlots

10..*

target

inputSlots

0..*

application

port

target

source

link

tasks

port

1..*

0..1

slots

1..*

Figure 2: Guaraná DSL Metamodel from Frantz et al. (2011).

3 FORMALISATION

In this section we formalise the abstract syntax of

Guaraná DSL using Z schemas, describing its classes

and relationships.

3.1 Types and Constraints

In an EAI solution designed with Guaraná DSL, sev-

eral building blocks are identiﬁed by names. For this

purpose, we introduce the set of all names as basic

type of the speciﬁcation. Similarly, we introduce a

basic type for the set of all scripts, which are a piece

of source code that implements the business logic of

tasks, cf. expression (1).

[Name, Script] (1)

The free type deﬁned in expression (2) deﬁnes

Type to be a set containing the main building blocks

of Guaraná DSL.

Type ::= Task|Slot|Process|Application|Link (2)

In order to ensure that all building blocks have

a unique name, we write out explicitly a constraint

denoted by expression (3). Two variables type1 and

type2 should not have the same name; therefore,

if type1.name equals type2.name, then type1 equals

type2.

∀ type1, type2 : Type • (3)

type1.name = type2.name ⇔ type1 = type2

We deﬁned the remaining sets using Z schemas,

which are composed of two parts: declarative and

predicative. In order to keep the formalisation com-

prehensive and facilitate initial understanding of our

proposal, only Process, Port and Solution schemas are

composed of predicative parts.

3.2 Schemas Deﬁnition

In Z notation, a state schema that formalises the static

aspect of a class is called Class Schema. It consists

of a declarative part in which variables are declared

and a predicative part that contains a predicate (ex-

pressed as a list of conjuncts) constraining variable

values. The variables in a class schema represent at-

tributes and object identiﬁers of a class.

The Task schema describes the building block

Task, in which four variables are declared: name,

inputs, outputs, and executionBody. We deﬁne the

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

316

declarative part of the Task schema using variables

without any relationship between others Z schemas.

The sets Name and Script were declared in expres-

sion (1), and variable name is restricted by expression

(3).

We identiﬁed sets EntryPort and ExitPort with a

name and a type of Task. The set Port is composed of

the union of EntryPort and ExitPort. The intersection

of EntryPort and ExitPort forms an empty set. This

can be observed at Port schema deﬁnition.

In Guaraná DSL, a Slot can connect two tasks or

a task with a port. Thus, in the speciﬁcation, the Slot

schema describes the building block Slot, in which

three variables are declared: name, slots, and inter-

slots. The Slot that connects two tasks is modelled

as a set of binary relations between the sets Task and

Task, while connections between Task and Port is

modelled as a set of binary relations between the sets

Task and Port.

A process of a Guaraná solution is identiﬁed by

a name and composed of slots, tasks, and ports (en-

tryPorts and exitPorts). A process is speciﬁed as a

schema, where the main predicates (constraints) and

declarations of subsets of its composition are deﬁned.

In its predicative part, the slot deﬁnition has relation

with two distinct tasks. In other words, for all s1 from

set Slot, where t1, t2 belonging to set Task, the term

s1.slots relates task t1 with task t2. The deﬁnition in-

terslot relates bilaterally Task with Port. Thus, for all

s1 from set Slot, where t1 belongs to set Task and pt1

belongs to set Port, the term s1.interslot relates task

t1 with port pt1.

After the declarations of sub-sets of a process and

the deﬁnition of some predicates, we declare the other

sets that compose an integration solution. Therefore,

we describe at this stage, the Application and Link

schemas. Application is composed of a name, which

uniquely identiﬁes the application and two sets of

ports: entryPorts and exitPorts. Link is composed

of a name which uniquely identiﬁes the Link, and

two other sets of relationships: integrationLink and

applicationLink. The former contains relationships

between EntryPorts and ExitPorts, and the latter re-

lationships between Application and Port. With the

declaration of these two schemas, we can represent

the general formalisation of the EAI solution, which

is composed of Process, Application, Link and Port.

Finally, we specify an EAI solution. To this

end, we deﬁne the Solution schema, which has two

constraints. The ﬁrst constraint introduces integra-

tionLink as the relation between EntryPort of process

p1 and ExitPort of process p2, where p1 must be dif-

ferent from p2. For all l1 in set Link and p1, p2 in

set Process, where l1.integrationLink relates Entry-

Port from process p1, with ExitPort from process p2,

such as p1 and p2 must be different. The second con-

straint represents the applicationLink as the relation-

ship between an Application and a Port ensuring that

two different Applications will never be connected to

OntheFormalisationofanApplicationIntegrationLanguageUsingZNotation

317

the same port. Thus, for all l1, l2 from set Link, and

app1, app2 from set Application, and pt1 from set

Port, where l1.applicationLink relates app1 with pt1

and l2.applicationLink relates app2 with pt1, if and

only if, application app1 is equals to app2.

4 CHALLENGES AND FUTURE

WORK

There is a long way to go before Guaraná DSL can

have a well-deﬁned semantics. To the best of our

knowledge, this is the ﬁrst proposal addressing for-

malisation of this language. Amongst the challenges

raised, we are aware of the limitations of tool support

for Z speciﬁcations. Although Z notation has been

widely used to provide formal speciﬁcation, there are

few tool support to assist in the detection of seman-

tic errors, which makes difﬁcult the validation of the

speciﬁcation. We have to investigate which technique

can be combined with Z to cope with this limitation.

The main goals in our ongoing research are: i) for-

malise the semantics and the rules for reasoning on

the domain-speciﬁc language of Guaraná proposal; ii)

validate the rules for error detection, so that we can

ensure they cover every possibility of failure in an

EAI solution designed with Guaraná DSL; iii auto-

matically generate these rules based on the semantics

of an EAI solution; and, iv) generate test cases from

the EAI solution speciﬁcation.

5 CONCLUSIONS

Currently, the lack of formal semantics on Guaraná

DSL prevents the automated reasoning of the EAI so-

lutions designed with this language. In this paper, we

presented a formal speciﬁcation of the abstract syntax

of Guaraná DSL using Z notation. This is a ﬁrst step

towards the formalisation of the language.

We seek, with the use of formalism, to eliminate

ambiguities and inconsistencies that would only be

detected during development and testing phases. Fur-

thermore, the correction of the speciﬁcation in a pre-

liminary stage of the development process avoids er-

rors that can occur later, resulting in more onerous

problems. In this context, we know that a key chal-

lenge for software engineers is to ensure the reliability

of designed EAI solutions. For this reason, the current

paper addressed the formal speciﬁcation of the ab-

stract syntax of Guaraná DSL, an initial step towards

the formalisation of the whole language, with that we

want to ensure that an EAI solution is in accordance

with what was speciﬁed.

Using the mathematical basis of a formal spec-

iﬁcation technique, such as Z notation, it became

possible to explore the abstract syntax of Guaraná

DSL with precision and rigour. For that, we used

Z schemas to describe the Uniﬁed Modeling Lan-

guage classes and the Object Constraint Language

constraints of the Guaraná DSL metamodel. Thus,

the formalisation of Guaraná DSL would contribute

to the validation of an EAI solution, allowing to check

that its speciﬁcation meets the integration solution re-

quirements. Besides, we believe that our work on the

formalisation of Guaraná DSL shall contribute to the

improvement and adoption of this proposal.

ACKNOWLEDGEMENTS

The research work on which we report in this paper

was supported by CAPES, FAPERGS, and the inter-

nal Research Programme 2013/14 at UNIJUI Univer-

sity.

REFERENCES

Bowen, J. P. and Hinchey, M. G. (2006). Ten Command-

ments of Formal Methods ...Ten Years Later. IEEE Com-

puter, 39(1):40–48.

Dijkstra, E. W. (1975). Guarded Commands, Nondeter-

minacy and Formal Derivation of Programs. Commun.

ACM, 18(8):453–457.

Dossot, D. and D’Emic, J. (2009). Mule in Action. Man-

ning.

Fisher, M., Partner, J., Bogoevici, M., and Fuld, I. (2010).

Spring Integration in Action. Manning.

Floyd, R. W. (1967). Assigning meanings to programs. In

Proceedings of a Symposium on Applied Mathematics,

volume 19 of Mathematical Aspects of Computer Sci-

ence, pages 19–31.

Frantz, R. Z., Corchuelo, R., and Molina-Jiménez, C.

(2012). A proposal to detect errors in Enterprise Ap-

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

318

plication Integration solutions. Journal of Systems and

Software, 85(3):480–497.

Frantz, R. Z., Quintero, A. M. R., and Corchuelo, R. (2011).

A Domain-Speciﬁc Language to Design Enterprise Ap-

plication Integration Solutions. Int. J. Cooperative Inf.

Syst., 20(2):143–176.

Goodenough, J. B. (1975). Exception handling: Issues

and proposed notation. Communications of the ACM,

18(12):683–696.

Harel, D. and Rumpe, B. (2004). Meaningful Model-

ing: What’s the Semantics of "Semantics"? Computer,

37(10):64–72.

Hohpe, G. and Woolf, B. (2003). Enterprise Integration

Patterns - Designing, Building, and Deploying Messag-

ing Solutions. Addison-Wesley.

Hong, S. N. and Mannino, M. V. (1995). Formal seman-

tics of the uniﬁed modeling language {LU} . Decision

Support Systems, 13(3-4):263–293.

Ibsen, C. and Anstey, J. (2010). Camel in Action. Manning.

Kaliappan, P. S. and König, H. (2012). On the Formaliza-

tion of UML Activities for Component-based Protocol

Design Speciﬁcations. In Proceedings of the 38th In-

ternational Conference on Current Trends in Theory and

Practice of Computer Science, SOFSEM’12, pages 479–

491.

Kim, S.-K. and Carrington, D. (1999). Formalizing the

UML Class Diagram Using object-Z. In Proceedings of

the 2Nd International Conference on The Uniﬁed Mod-

eling Language: Beyond the Standard, UML’99, pages

83–98.

Messerschmitt, D. and Szyperski, C. A. (2003). Software

Ecosystem: Understanding an Indispensable Technology

and Industry. MIT Press.

Mostafa, A. M., Ismail, M. A., Bolok, H. E., and Saad,

E. M. (2007). Toward a Formalization of UML2.0

Metamodel using Z Speciﬁcations. In Software Engi-

neering, Artiﬁcial Intelligence, Networking, and Paral-

lel/Distributed Computing, 2007. SNPD 2007. Eighth

ACIS International Conference on, volume 1, pages 694–

701.

OMG (2011). UML 2.4 Superstructure Speciﬁcation.

OMG (2012). OCL 2.3.1 Object Constraint Language.

Shroff, M. and France, R. B. (1997). Towards a formaliza-

tion of UML class structures in Z. In COMPSAC, pages

646–651. IEEE Computer Society.

Spivey, J. M. (1992). The Z Notation: A Reference Manual.

Prentice Hall.

van Lamsweerde, A. (2000). Formal speciﬁcation: a

roadmap. In ICSE - Future of SE Track, pages 147–159.

Vidal, J. C., Lama, M., and BugarÃn, A. (2012). Toward

the use of Petri nets for the formalization of OWL-S

choreographies. Knowledge and Information Systems,

32(3):629–665.

Wing, J., Woodcock, J., and Davies, J. (1999). In FM’99 -

Formal Methods: World Congress on Formal Methods in

the Development of Computing Systems, volume 1708–

1709 of LNCS. Springer-Verlag.

OntheFormalisationofanApplicationIntegrationLanguageUsingZNotation

319