Conference PaperPDF Available

A Software Development Kit to Implement Integration Solutions

Authors:

Abstract and Figures

Typical companies rely on their software ecosystems to support and optimise their business processes. There are a few proposals to help software engineers devise enterprise application integration solutions. Some companies need to adapt these proposals to particular contexts. Unfortunately, our analysis reveals that they are not so easy to maintain as expected. This motivated us to work on a new proposal that has been carefully designed in order to reduce main-tainability efforts.
Content may be subject to copyright.
A Software Development Kit to Implement
Integration Solutions
Rafael Z. Frantz
UNIJUÍ University, Department of Technology
Rua do Comércio, 3000, Ijuí, 98700-000, RS,
Brazil
rzfrantz@unijui.edu.br
Rafael Corchuelo
Universidad de Sevilla, ETSI Informática
Avda. de la Reina Mercedes, s/n, Sevilla 41012,
Spain
corchu@us.es
ABSTRACT
Typical companies rely on their software ecosystems to
support and optimise their business processes. There are a
few proposals to help software engineers devise enterprise
application integration solutions. Some companies need to
adapt these proposals to particular contexts. Unfortunately,
our analysis reveals that they are not so easy to maintain
as expected. This motivated us to work on a new proposal
that has been carefully designed in order to reduce main-
tainability efforts.
Categories and Subject Descriptors
D.2.2 [Design Tools and Techniques]: Software li-
braries; D.2.11 [Software Architectures]: Domain-specific
architectures; D.2.13 [Reusable Software]: Domain engi-
neering
Keywords
Enterprise Application Integration; Business Modelling,
Integration Framework; Domain-Specific Languages.
1. INTRODUCTION
Companies rely on applications to support their business
activities. Frequently, these applications are legacy systems,
packages purchased from third parties, or developed at home
to solve a particular problem. This usually results in hetero-
geneous software ecosystems, which are composed of appli-
cations that were not usually designed taking integration
into account. Integration is necessary, chiefly because it
allows to reuse two or more applications to support new
business processes, or because the current business processes
have to be optimised by interacting with other applications
within the software ecosystem. Enterprise Application In-
tegration (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
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SAC’12 March 25-29, 2012, Riva del Garda, Italy.
Copyright 2011 ACM 978-1-4503-0857-1/12/03 ...$10.00.
develop new functionality on top of them, so that applica-
tions do not have to be changed and are not disturbed by
the EAI solution [9].
In the last years, several tools have emerged to support
the design and implementation of EAI solutions. Hohpe and
Woolf [9] documented many patterns found in the develop-
ment of EAI solutions. Camel and Spring Integration are
two well-known proposals to support these patterns.
We are concerned with maintainability. According to IEEE
[10], maintenance can be classified as corrective, perfective,
and adaptive. Corrective maintenance aims to repair soft-
ware systems to eliminate faults that might cause them to
deviate from their normal processing. Perfective mainte-
nance aims to modify a software system, usually to improve
the performance of current functionalities or even to improve
the maintainability of the overall software system. Adaptive
maintenance focuses on adapting a software system to use
it in new execution environments or business processes.
In this paper, we are interested adaptive maintenance,
which is very important for companies that need to build
their own tools building on existing tools. Many companies
rely on open-source tools that can be adapted to a particular
context within their business domain. For example, a com-
pany that develops EAI solutions may need tools that can
be adapted to particular contexts, e.g., e-commerce (Roset-
taNet [16]), health (HL7 [8]), or insurance (HIPPA [7]).
It is not new that how a software system was designed and
implemented, has an impact on its maintenance costs [1, 4,
11, 17]. In both design and implementation, software engi-
neers need to pay attention to readability, understandability,
and complexity. The resulting models and source code must
be easy to read and understand, because it is very common
that the people who work on them are not involved in main-
tenance tasks. The complexity of the algorithms should be
kept low, not only for performance reasons, but because it
makes it easier for a software engineer to follow execution
flows and debug them. Thus, to reduce the costs involved in
the adaptation of a software system to a particular context,
it is very important that the software system was designed
taking into account properties that have a negative impact
on maintenance.
How costly it is to maintain a tool depends on a variety
of properties. We have calculated these measures on Camel
and Spring Integration, and the results do not seem promis-
ing enough. This motivated us to work on a Software Devel-
opment Kit (SDK) to which we refer to as Guaran´a SDK 1
that provides a well-designed architecture that is intended
1http://www.guarana-project.net
1
to reduce maintainability costs. Guaran´a SDK aims to sup-
port the implementation of EAI solutions. Its design pro-
vides better values for the maintainability measures, which
suggests that Guaran´a SDK is more maintainable and thus
easier to adapt for a particular context than Camel or Spring
Integration.
Guaran´a SDK is composed of two layers, namely: the
framework and the toolkit. The former provides a num-
ber of classes and interfaces that provide the foundation to
implement tasks, adapters, and workflows, as well as a run-
time system. The latter extends the framework to provide
an implementation of tasks and adapters that is intended to
be general purpose; other toolkits for specific contexts are
currently under development.
The rest of the paper is organised as follows: Section §2
presents the related work and compares other proposals to
ours; Section §3 presents the framework layer of Guaran´a
SDK; Section §4, presents the toolkit layer, which extends
the framework layer for a particular context; finally, Sec-
tion §5 reports on our main conclusions.
2. RELATED WORK
The Software Engineering community uses a number of
measures proposed by Chidamber and Kemerer [2], Henderson-
Sellers [6], Martin [13] and McCabe [14] to have an overall
idea of how difficult maintaining a system can be.
Camel and Spring integration are the most closely-related
proposals. They both are based on the catalogue of inte-
gration patters by Hohpe and Woolf [9]. Camel provides a
graphical editor and an API that can be used in Java, Scala,
and Spring configuration files. Spring integration also pro-
vides a graphical editor and an API that can be used in Java
or Spring configuration files.
Since we are interested in how maintainable they are, we
have studied the following maintainability metrics:
NOP: Number of packages that contain at least one class
or interface. This measure can be used as indicator of
how much effort it is required to understand how pack-
ages are organised; note that this provides the overall
picture of the design of a system [3]. The greater this
number, the more effort shall be required.
NOC: Number of classes. This and the following measure
(NOI) can be used as indicators of how much effort
shall be required to understand the source code of a
software system. The grater is this value, the more
difficult it is to understand a software system.
NOI: Number of interfaces.
NOM: Number of methods in classes and interfaces. This
measure can be used as an indicator for the potential
reuse of a class. According to Chidamber and Kemerer
[2], Lorenz and Kidd [12], a large number of methods
may indicate a class is likely to be application specific,
limiting the possibility of reuse.
LOC: Number of lines of code, excluding blank lines and
comments. In general, the greater this value, the more
effort shall be required to maintain a software system.
MLC: Number of lines in methods, excluding blank lines
and comments. According to Henderson-Sellers [6],
this value should not exceed fifty. If it does, the author
suggests to split this method into other methods to
improve readability and maintainability. The greater
this number, the more difficult it is to understand and
maintain the method.
NPM: Number of parameters per method. This measure
can be used as an indicator of how complex it is to un-
derstand and use a method. According to Henderson-
Sellers [6], the number of parameters should not exceed
five. If it does, the author suggest that a new type must
be designed to wrap the parameters into a unique ob-
ject. The greater this number, the more difficult it is
to understand the method.
LCM: Lack of cohesion of methods. In this context, cohe-
sion refers to the number of methods that share com-
mon attributes in a class. It is calculated with the
Henderson-Sellers LCOM* method [6]. A low value
indicates a cohesive class; contrarily, a value close to
one indicates lack of cohesion and suggests the class
might better be split into two or more subclasses be-
cause there can be methods that should probably not
belong to that class.
MCC: The McCabe Cyclomatic complexity. This measure
can be used as an indicator of how complex the algo-
rithm in a method is. According to [14], this value
should not exceed ten. The greater this value, the
more difficult it is to maintain a piece of code.
We have calculated these measures regarding the core im-
plementation of Camel, Spring Integration, and Guaran´a
SDK i.e., we do not take into account the code required to
implement the adapters necessary to interact with the ap-
plications being integrated. We do not considered this code
because it is peripheral to the tools’ main architecture, and
in most cases comes from other open-source projects that
are maintained separately. Table §1 summarises the results.
The architecture of Camel and Spring Integration is or-
ganised in several packages, 54 and 32, respectively. There
are cases in which the maximum number of classes in a pack-
age reaches 96 in Camel and 58 in Spring Integration. These
values show that Camel has almost double as many classes
in a package as Spring Integration. The same happens re-
garding the number of interfaces. Consequently, Camel has
the highest standard deviation and mean values per package
regarding both, classes and interfaces. The highest stan-
dard deviation calculated for Camel, indicates that there
are packages containing many more classes than the average
calculated per package, which may have an impact on the
understandability of the package. Spring Integration has a
low value for the standard deviation regarding the number
of interfaces. The architecture of Guaran´a is organised into
18 packages, and the maximum number of classes in a pack-
age is no more than 11. Furthermore, Guaran´a provides no
more than 9 interfaces distributed in these packages. The
standard deviation calculated for the number of classes and
interfaces per package is very low, 3.09 and 0.76, respec-
tively.
When analysing the methods in classes and interfaces,
we found that Camel has 7,015 methods compared to the
1,431 found for Spring Integration. Most probably the dif-
ference amongst Spring Integration and Camel is because it
has less than a half the number of classes and interfaces of
2
Measure Total Mean Dev. Max Total Mean Dev. Max Total Mean Dev. Max
NOP 54 - - - 32 - - - 18 - - -
NOC 730 13.52 19.55 96 269 8.41 10.52 58 79 4.39 3.09 11
NOI 140 2.59 9.07 58 40 1.25 1.84 9 9 0.50 0.76 2
NOM 7,015 9.61 15.36 192 1,431 5.32 5.60 39 369 4.67 4.61 24
LOC 62,439 - - - 14,929 - - - 2,878 - - -
MLC 34,839 4.52 8.15 141 8,264 5.65 9.59 110 1,748 4.72 6.43 54
NPM - 0.93 1.05 11 - 1.13 0.94 9 - 1.20 1.04 4
LCM - 0.29 0.35 1 - 0.22 0.33 0.94 - 0.14 0.27 0.91
MCC - 1.67 2.06 46 - 1.80 2.04 30 - 1.35 0.91 8
Camel
Spring Integration
Guaraná SDK
NOP = Number of packages; NOC = Number of classes; NOI = Number of interfaces; NOM = Number of methods; LOC =
Number of lines of code; MLC = Number of lines in methods; NPM = Number of parameters per method; LCM = Lack of
cohesion of methods; MCC = McCabe’s Cyclomatic Complexity.
Table 1: Comparison of maintainability measures.
Camel. The values that stand out are the maximum number
of methods per class/interface calculated in Camel, which is
192, against to 39 in Spring Integration. We have analysed
the methods in classes/interfaces and found that Guaran´a
has in total 369 methods, with a maximum number of 24
methods per class/interface.
Other values that are impressive for these tools are re-
garding the total number of lines of code, which is very high,
chiefly for Camel. There are 62,439 lines of code in Camel
and 14,929 in Spring Integration. The implementation of
Guaran´a has a total number of 2,878 lines of code.
Counting the number of lines of code inside methods, we
found Camel has a total number of 34,839, Spring Integra-
tion has 8,264, which if compared to the total number of
lines of code, represents 0.55% and 0.55% of these values,
respectively. It means there are many attributes declared
in classes. The maximum value calculated demonstrate that
there are some methods with up to 141 lines of code in Camel
and 110 in Spring Integration. These values indicate there
may be necessary more effort to maintain and understand
the methods in these tools. Counting the number of lines of
code inside methods, we found Guaran´a has a total number
of 1,748, which, if compared to the total number of lines of
code in Guaran´a, represents 0.61% of this value. Further-
more, there is no method with more than 54 lines of code,
being the average 4.72 lines of code per method. These val-
ues indicate that classes shall be easier to understand and
maintain.
If we look at the maximum number of parameter per
method, it is also impressive how large it is, chiefly in Camel.
This tool has up to 11 and Spring Integration has up to 9
parameters per method. These values indicate some classes
in these tools are likely too application specific, with a lim-
ited possibility to be reused; furthermore, this makes some
of their methods difficult to understand, chiefly in the case
of Camel. Guaran´a has no more than 4 parameters per
method. These values indicate that classes in Guaran´a are
expected to be more reusable and its methods not so difficult
to understand.
The lack of cohesion of methods is similar in every anal-
ysed tool. Camel has 0.29 and 0.35 and Spring Integration
has 0.22 and 0.33. Guaran´a presents a mean of only 0.14.
The values calculated for the McCabe cyclomatic com-
plexity have indicate that there are cases in which they are
extremely high. This is indicated by the maximum values
Figure 1: Message model in the framework.
calculated for the tools, which reaches 46 and 30 in Camel
and Spring Integration, respectively. Consequently, they are
also very complex tools, which may have a serious impact
on their maintenance. The values calculated for the Mc-
Cabe cyclomatic complexity have indicated that the max-
imum value is 8, which indicates the architecture is well
designed and maintenance is expected to be easy.
From the analysis of the maintainability measures, it fol-
lows that the tools we have analysed may have problems re-
garding maintenance, chiefly adaptive maintenance, which
is our main concern in this paper. It is not difficult to see
that the values of these properties are generally significantly
smaller in Guaran´a SDK, which suggests that maintaining
our proposal is easier than maintaining the other technolo-
gies.
3. THE FRAMEWORK LAYER
In the following sections, we describe the packages in the
framework layer.
3.1 Messages
Messages are used to wrap the data that is manipulated in
an EAI solution. They are composed of a header, a body and
one or more attachments, cf. Figure §1. The header holds
several meta-data properties, including: message identifier,
expiration time, and list of parents. The message identifier
is a UUID that uniquely identifies every message; the expi-
ration time allows to set a deadline after which a message is
considered outdated for further processing; the list of par-
ents allows to track which messages originate from which
ones, i.e., it helps find correlated messages. The body holds
3
Figure 2: Task model in the framework.
Figure 3: Port model in the framework.
the payload data. Attachments allow messages to carry ex-
tra pieces of data associated with the payload, e.g., an image
or an e-mail message. Messages implement two interfaces so
that they can be serialised and compared, respectively. Se-
rialisation is required to deep copy, to persist, and to trans-
fer messages, and comparison enables a workflow to process
messages according to their priority.
3.2 Tasks
The task package provides the foundations to implement
domain-specific tasks in specialised toolkits. Figure §2 shows
the task model in our proposal. A task models how a set
of inbound messages must be processed to produce a set
of outbound messages. Tasks communicate indirectly by
means of slots. A slot is an in-memory priority buffer that
helps transfer messages asynchronously so that no task has
to wait until the next one is ready to start working. Tasks
become ready to be executed according to a time criterion or
a slot criterion. In the former case, a task becomes ready to
be executed periodically, after a user-defined period of time
elapses since it became ready for the last time; in the later
case, it becomes ready when the appropriate set of messages
is available in its input slots. For instance, a merger is a
task that reads messages from two or more slots and merges
them into one slot; this task can transfer messages as they
are available. Contrarily, a context-based content enricher
is a task that reads a base message and a context message
from two slots and uses the later to enrich the former; this
task cannot become ready to be executed until two mes-
sages are available in its input slots. Slots and tasks are
both observable objects, which means that they can notify
other objects of changes to their state; in addition, tasks are
observer objects since they monitor slots.
3.3 Ports
Ports abstract away from the communication mechanism
used to interact with the environment, cf. Figure §3. Note
that every port must be associated with a process, and that
we distinguish between one way and two way ports. The for-
mer are unidirectional ports that allow to read/write mes-
Figure 4: Process model in the framework.
sages; the latter are bidirectional ports that allow to either
send a message and wait for the answer (responder ports) or
to receive a message and produce a response message (solic-
itor port). Internally, ports are composed of tasks, namely:
a communicator, a pipeline, and a mapper. Communicators
are the tasks that allow to actually read or write a message,
namely: in communicators are used to read a message in
raw from; contrarily, out communicators are used to write
a message in raw form. By raw form, we mean a stream
of bytes that is understood by the corresponding process or
asset. The pipeline helps pre- or post-process a message in
raw form to decrypt/encrypt, decode/encode, or unzip/zip
it. The pipeline in an input port ends with a mapper task
that transforms the resulting stream of bytes into a text doc-
ument, for instance; the pipeline in an output port begins
with a mapper that transforms the text document into a
stream of bytes. Bidirectional ports can actually be seen as
a combination of an input and an output port.
3.4 Processes
Processes are the central processing units in an integra-
tion solution, cf. Figure §4. They are composed of ports
and tasks, extend class Observable, and implement interface
ITaskContainer. The reason why processes are observable is
that they are just an abstraction that helps organise groups
of tasks that co-operate to achieve a goal; from the point of
view of our proposal, they are just a container that reports
which of their tasks are ready for execution to an external
observer. The ITaskContainer defines the interface to add,
remove, and search for tasks in objects that may contain
tasks. A process may have several observers, e.g., to log or
to monitor its activities; however, the most important one is
a runtime system, which we describe in the following section.
Processes serve two purposes, namely: there are processes
that allow to wrap applications and processes that allow to
orchestrate the workflow. The former are reusable processes
that endow an application with a message-oriented API that
simplifies interacting with it. Implementing such a wrapping
process may range from using a JDBC driver to interact
with a database to implementing a scrapper that emulates
the behaviour of a person who interacts with a user inter-
face. Orchestration processes, on the contrary, are intended
to orchestrate the interactions with a number of services,
wrapping processes, and other orchestration processes. In-
dependently from their role, processes are composed of ports
and tasks.
3.5 Adapters
This package provides the foundations to implement adapters
in specialised toolkits, cf. Figure §5. Adapters are the piece
of software that implements the low-level communication
4
Figure 5: Adapter model
Figure 7: Task model in the toolkit
protocol necessary to interact with the processes or assets
involved in an integration solution. The framework layer
provides four interfaces to describe the operations used by
ports to read, write, solicit, and respond.
3.6 The execution engine
The engine package provides an implementation to the
task-based runtime system on which Guaran´a SDK relies,
cf. Figure §6. Scheduler is the central class in this pack-
age. At run-time, a scheduler owns a work queue, a list of
workers, and three monitors. The work queue is a priority
queue that contains work units to be processed. A work
unit consists of a task to be executed and a deadline. In
most cases, the deadline is set to the current time, which
means that the corresponding task can execute as soon as
possible; there are a few time-dependent tasks for which the
deadline is set to a time in future, e.g., a timer that ticks ev-
ery minute or a communicator that polls a service every ten
minutes. Workers are an extension to the Thread class and
they have a reference to the work unit that they have to ex-
ecute. The monitors are intended to gather statistics about
how memory is used, the time tasks take to complete, and
the size of the work queue. They have been implemented
as independent threads that run at regular intervals, gather
the previous information, dump it to a file, and become idle
the sooner as possible.
4. THE TOOLKIT LAYER
The framework provides two extension points, namely:
Task and Adapter. We have designed a core toolkit that pro-
vides extensions to deal with a variety of tasks that support
the majority of integration patterns in the literature [9], and
provide active and passive adapters that enable the use of
several low-level communication protocols.
Figure §7 presents the extensions to the Task class. Below
we provide an explanation in which term schema is used to
refer to the logical structure of the body of a message. It
may range from a DTD or an XML schema to a Java class.
Router: a router is a task that does not change the
messages it processes at all, but routes them through
a process. This includes filtering out messages that
Figure 8: Adapter model in the toolkit
do not satisfy a condition or replicating a message, to
mention a few tasks in this category.
Modifier: a modifier is a task that adds data to a mes-
sage or removes data from it as long as this does not
result in a message with a different schema. This in-
cludes enriching a message with contextual informa-
tion or promoting some data to its headers, to mention
a few examples in this category.
Transformer: a transformer is a task that translates one
or more messages into a new message with a different
schema. Examples of these tasks include splitting a
message into several ones or aggregating them back.
Timer: a timer is a task that performs a time-related
action, e.g., delaying a message or producing a message
at regular intervals.
StreamDealer: a stream dealer is a task that deals with a
stream of bytes and helps zip/unzip, encrypt/decrypt,
or encode/decode it.
Mapper: a mapper is a task that changes the represen-
tation of the messages it processes, e.g., from a stream
of bytes into an XML document.
Communicator: a communicator is a task that encapsu-
lates an adapter. Communicators serve two purposes:
first, they allow adapters to be exported to a registry so
that they can be accessed remotely; second, a commu-
nicator can be configured to poll periodically a process
or application using an adapter.
There is a package associated with every of the previous
tasks, which provide a variety of specific-purpose implemen-
tations in each integration patten category [5].
Figure §8 shows the extension to the adapters. They can
be either active or passive. An active adapter allows to poll
periodically the process or application with which it inter-
acts; contrarily, a passive adapter is intended to export an
interface to a registry, so that other applications or processes
can interact with it. Note that entry and exit ports can be
implemented using either active or passive adapters.
The active package is divided into two packages to provide
implementations that are based on JBI and RMI protocols,
respectively. Note that supporting JBI adapters allows to
plug Guaran´a SDK into a variety of ESBs; for instance,
our reference implementation is ready to be plugged into
Open ESB [15]. This, in turn, allows Guaran´a SDK pro-
cesses to have access to a variety of applications in current
software ecosystems, including files, databases, web services,
5
Figure 6: Engine model in the toolkit.
RSS feeds, SMTP messaging systems, JMS queues, DCOM
servers, and so on. The rmi package provides several imple-
mentations that are intended to be used to interact with an
RMI-compliant server.
5. CONCLUSIONS
Companies rely on applications to support their business
activities. The integration of these applications is necessary,
chiefly because it allows to reuse applications to support new
business processes or to optimise existing ones. Enterprise
Application Integration (EAI) provides methodologies and
tools to design and implement EAI solutions. Although it is
possible to use current tools to design and implement EAI
solutions, it is still necessary to provide domain-specific tools
that are easy to maintain in order to customise them for a
particular context.
In this paper we have reported on nine maintainability
measures that can be used as an indicator regarding how
expensive a software tool can be to maintain. We have anal-
ysed two widely-used tools in the EAI marked: Camel and
Spring Integration. Our results indicate that these tools are
expected to be more difficult to maintain than our proposal.
We have introduced Guaran´a SDK, which is our soft-
ware tool to design and implement EAI solutions. Guaran´a
SDK is organised in two layers, namely: framework and
toolkit. An abstract implementation of the core concepts in
the domain-specific language introduced in [5] are provided
by the former layer, and, although we also provide a toolkit
implementation, the framework can be reused by engineers
to build other new specialised toolkits. We have also calcu-
lated the values for the maintainability measures regarding
Guaran´a SDK. Our conclusion is that Guaran´a SDK is much
easier to maintain than Camel or Spring Integration.
6. ACKNOWLEDGMENTS
The work in this paper was supported by the Evangelis-
cher Entwicklungsdienst e.V. (EED), the Spanish and the
Andalusian R&D&I programmes (grants: TIN2007-64119,
P07-TIC-2602, P08-TIC-4100, TIN2008-04718-E, TIN2010-
21744, TIN2010-09809-E, TIN2010-10811-E, and TIN2010-
09988-E), and the European Commission (FEDER).
References
[1] S. Bergin and J. Keating. A case study on the adaptive
maintenance of an Internet application. Journal of Software
Maintenance, 15(4):254–264, 2003
[2] S. R. Chidamber and C. F. Kemerer. A metrics suite for
object oriented design. IEEE Trans. Software Eng., 20(6):
476–493, 1994
[3] X. Dong and M. W. Godfrey. Understanding source pack-
age organization using the hybrid model. In International
Conference on Software Maintenance, 2009
[4] A. Epping and C. M. Lott. Does software design complexity
affect maintenance effort? In Goddard Space Flight Center,
pages 297–313, 1994
[5] R. Z. Frantz, A. M. Reina-Quintero, and R. Corchuelo. A
domain-specific language to design enterprise application in-
tegration solutions. International Journal of Cooperative In-
formation Systems, 20(2):143–176, 2011
[6] B. Henderson-Sellers. Object-Oriented Metrics, Measures of
Complexity. Prentice Hall, 1996
[7] Health Insurance Portability and Accountability Act Home,
Oct 2011. Available at http://www.hipaa.com/
[8] Health Level Seven International Home, Oct 2011. Available
at http://www.hl7.org
[9] G. Hohpe and B. Woolf. Enterprise Integration Patterns
- Designing, Building, and Deploying Messaging Solutions.
Addison-Wesley, 2003
[10] IEEE. IEEE Standard Glossary of Software Engineering
Terminology. IEEE Computer Society, 1990
[11] M. Jørgensen. An empirical study of software maintenance
tasks. Journal of Software Maintenance, 7(1):27–48, 1995
[12] M. Lorenz and J. Kidd. Object Oriented Software Metrics.
Prentice Hall, 1994
[13] R. C. Martin. Agile Software Development, Principles, Pat-
terns, and Practices. Prentice Hall, 2002
[14] T. J. McCabe. A complexity measure. IEEE Trans. Software
Eng., 2(4):308–320, 1976
[15] T. Rademakers and J. Dirksen. Open-Source ESBs in Ac-
tion. Manning, 2009
[16] RosettaNet Home, Oct 2011. Available at http://www.
rosettanet.org
[17] N. F. Schneidewind. The state of software maintenance.
IEEE Trans. Software Eng., 13(3):303–310, 1987
6
... Além da linguagem de domínio especifico, a tecnologia Guaraná também possui um Kit de Desenvolvimento de Software (SDK) denominado de Guaraná SDK. De acordo com Frantz e Corchuelo [33], o Guaraná SDK é a implementação java do Guaraná DSL e fornece suporte para a implementação de soluções de integração. ...
... Já o kit de ferramentas estende o framework e proporciona a execução de tarefas e adaptadores que visam atender a um propósito geral. Além disso, Frantz e Corchuelo [33] destacam que outros kits de ferramentas para contextos específicos podem ser desenvolvimentos. ...
... Esta ferramenta utiliza um modelo de execução com base em tarefas para executar as soluções. Esta abordagem difere o Guaraná das outras tecnologias que utilizam um modelo de execução baseado em processos [33]. ...
Thesis
Full-text available
The Information Technology (IT) provides support to business organizations, providing agility and quality to its business processes. This support is provided by applications that composes the software ecosystem that, in general, does not have characteristics required for integration, making it difficult to reuse. In this sense, the Enterprise Application Integration - EAI focuses on the design and implementation of integration solutions. The Guaraná DSL technology is one of the tools that provide this support, but it differs from other proposals to include a monitoring system includes a monitoring system that can be configured using a rule-based language to endow solutions with fault-tolerance. However, Guaraná DSL is not yet formalized, and for this reason, it can not validate the rules written by software engineers using the rule-based language. In addition is not possible automatically generate rules based on the semantics of an integration solution. This research proposes a detailed study of Guaraná DSL technology with emphasis on fault tolerance mechanism in addition to the study and comparison of formal methods: Z notation, B, Alloy, RSL, Petri Nets, taking into account the characteristics of Guaraná. Using the UML metamodel with OCL constraints written in the domain specific language of Guaraná technology found in the literature, we propose a mathematical model with the formal specification of abstract syntax and subsequent validation. For the formal specification and validation was used the Z notation through the Z/EVES tool.
... Thereby, several tools have been released to improve the performance of the applications [22,47,23,7]. Considering this scenario, some integration platforms that support threads creation and management have been developed, such as Mule [10], Camel [20], Spring Integration [13], Petals [42], WSO2 ESB [21] and Guaraná [14,16]. ...
Article
Full-text available
Companies seek technological alternatives that provide competitiveness for their business processes. One of them is integration platforms, software tools that build integration solutions, which allow the different applications that make up the software ecosystem to work synchronously and that new applications or functionality be incorporated with the least impact in the existing ones. The runtime system is the component of the integration platform responsible for managing the computational resources that run the integration solution. Among these resources are the processing units, called threads, or sets of those threads, called thread pools. The performance of the runtime systems is directly related to the number of threads available to run the integration solution, but scaling the number of threads that provide a shorter response time is a challenge for software engineers. If this quantity is undersized, it may cause a delay in the execution; if it is overestimated, it could cause a waste of computational resources. This article presents a mathematical model, defined by differential equations, that establishes the optimum number of threads, which maximizes the expected performance gain by minimizing the execution time of the integration solution. In addition, it presents the mathematical model application, which assists the analysis of the expected gain in different architecture scenarios and quantity of threads.
... Thereby, several tools have been released to improve the performance of the applications [22,47,23,7]. Considering this scenario, some integration platforms that support threads creation and management have been developed, such as Mule [10], Camel [20], Spring Integration [13], Petals [42], WSO2 ESB [21] and Guaraná [14,16]. ...
Article
Full-text available
Companies seek technological alternatives that provide competitiveness for their business processes. One of them is integration platforms, software tools that build integration solutions, which allow the different applications that make up the software ecosystem to work synchronously and that new applications or functionalities be incorporated with the least impact in the existing ones. The runtime system is the component of the integration platform responsible for managing the computational resources that run the integration solution. Among these The performance of the runtime systems is directly related to the number of threads available to run the integration solution, but scaling the number of threads that provide a shorter response time is a challenge for software engineers. If this quantity is undersized, it may cause a delay in the execution; if it is overestimated, it could cause a waste of computational resources. This article presents a mathematical model, defined by differential equations, that establishes the optimum number of threads, which maximizes the expected performance gain by minimizing the execution time of the integration solution. In addition, it presents the mathematical model application, which assists the analysis of the expected gain in different architecture scenarios and quantity of threads.
... Thereby, several tools have been released to improve the performance of the applications [22,47,23,7]. Considering this scenario, some integration platforms that support threads creation and management have been developed, such as Mule [10], Camel [20], Spring Integration [13], Petals [42], WSO2 ESB [21] and Guaraná [14,16]. ...
Preprint
Full-text available
Companies seek technological alternatives that provide competitiveness for their business processes. One of them is integration platforms, software tools that build integration solutions, which allow the different applications that make up the software ecosystem to work synchronously and that new applications or functionality be incorporated with the least impact in the existing ones. The runtime system is the component of the integration platform responsible for managing the computational resources that run the integration solution. Among these resources are the processing units, called threads, or sets of those threads, called thread pools. The performance of the runtime systems is directly related to the number of threads available to run the integration solution, but scaling the number of threads that provide a shorter response time is a challenge for software engineers. If this quantity is undersized, it may cause a delay in the execution; if it is overestimated, it could cause a waste of computational resources. This article presents a mathematical model, defined by differential equations, that establishes the optimum number of threads, which maximizes the expected performance gain by minimizing the execution time of the integration solution. In addition, it presents the mathematical model application, which assists the analysis of the expected gain in different architecture scenarios and quantity of threads.
... A six-page abstract regarding our results was presented in Frantz and Corchuelo (2012); in this article, we extend our preliminary paper as follows: we analyse 16 additional maintainability measures, we analyse an additional wide-spread open-source tool, Mule, we provide a statistical analysis based on Kolmorogov-Smirnov's test, Shapiro-Wilk's test, Iman-Davenport's test, and Bergmann-Hommel's test to confirm our intuitive conclusion from the results obtained with the maintainability measures, we provide a comprehensive description of each layer of Guaraná SDK, and we demonstrate our proposal by means of an industrial experience that has been developed in co-operation with a spin-off company. We have also developed a domain-specific language that is intended to facilitate designing integration solutions at a high level of abstraction (Frantz et al., 2011). ...
Chapter
All over the years, enterprises have been accumulating a variety of applications in their software ecosystem to support their business processes. As a result, a software ecosystem is an heterogeneous set of IT assets (data and functionality) of the enterprise. Enterprise Application Integration (EAI) discipline aims to provide language and tools to support the development of integration solutions. Enterprises are always looking for how to optimise the use of resources, which includes their IT assets. Thus, building EAI solutions that allow to reuse actual data and functionality is mandatory to optimise the current or to provide support for the new business processes that emerge in an enterprise. The need for building EAI solutions has been pushing the development of languages and software tools, which can be used to model, implement, and run integration solutions. In the EAI community, the support for integration patterns is a trend, both in languages and software tools. In this chapter we introduce a software tool to support the realisation of Enterprise Application Integration. This tool is a Java-based software development kit that we provide to implement and run EAI solutions based on integration patterns. We have conducted a series of experiments to evaluate our proposal against real-world integration problems and the results indicate that it is viable and can be used to solve real-world integration problems.
... A six-page abstract regarding our results was presented in Frantz and Corchuelo (2012); in this article, we extend our preliminary paper as follows: we analyse sixteen additional maintainability measures, we analyse an additional wide-spread open-source tool, Mule, we provide a statistical analysis based on Kolmorogov-Smirnov's test, Shapiro-Wilk's test, Iman-Davenport's test, and Bergmann-Hommel's test to confirm our intuitive conclusion from the results obtained with the maintainability measures, we provide a comprehensive description of each layer of Guaraná SDK, and we demonstrate our proposal by means of an industrial experience that has been developed 1 Guaraná technology is available at http://www.guaranasolutions.com. in co-operation with a spin-off company. We have also developed a domainspecific language that is intended to facilitate designing integration solutions at a high level of abstraction (Frantz et al., 2011). ...
Article
Full-text available
Companies typically rely on applications purchased from third parties or developed at home to support their business activities. It is not uncommon that these applications were not designed taking integration into account. Enterprise Application Integration provides methodologies and tools to design and implement integration solutions. Camel, Spring Integration, and Mule range amongst the most popular open-source tools that provide support to implement integration solutions. The adaptive maintenance of a software tool is very important for companies that need to reuse existing tools to build their own. We have analysed twenty five maintainability measures on Camel, Spring Integration, and Mule. We have conducted an statistical analysis to confirm the results obtained with the maintainability measures, and it follows that these tools may have problems regarding maintenance. These problems increase the costs of the adaptation process. This motivated us to work on a new proposal that has been carefully designed in order to reduce maintainability efforts. Guaraná SDK is the software tool that we provide to implement integration solutions. We have also computed the maintainability measures regarding Guaraná SDK and the results suggest that maintaining it is easier than maintaining the others. Furthermore, we have conducted an industrial experience to demonstrate the application of our proposal in industry.
... Amongst the state-of-the-art integration technologies available for enterprises to design and implement integration solutions, there are Camel (Ibsen & Anstey, 2010), Spring Integration (Fisher, Partner, Bogoevici, & Fuld, 2010), Mule (Dossot & D'Emic, 2009), and Guaraná (Frantz & Corchuelo, 2012). These technologies provide a domain-specific language that enables the design of conceptual models for integration solutions. ...
Chapter
Full-text available
It is not difficult to find an enterprise which has a software ecosystem composed of applications that were built using different technologies, data models, operating systems, and most often were not designed to exchange data and share functionalities. Enterprise Application Integration provides methodologies and tools to design and implement integration solutions. The state-of-the-art integration technologies provide a domain-specific language that enables the design of conceptual models for integration solutions. The analysis of integration solutions to predict their behaviour and find possible performance bottlenecks is an important activity that contributes to increase the quality of the delivered solutions, however, software engineers follow a costly, risky, and time-consuming approach. Integration solutions shall be understood as a discrete-event system. This chapter introduces a new approach based on simulation to take advantage of well-established techniques and tools for discrete-event simulation, cutting down cost, risk, and time to deliver better integration solutions.
... Amongst the most recent and important open-source integration frameworks available for companies to design and implement integration solutions, there are Camel (Ibsen and Anstey, 2010), Spring Integration (Fisher et al., 2010), Mule (Dossot and D'Emic, 2009), and Guaraná (Frantz and Corchuelo, 2012). They are based on the catalogue of integration patterns documented by Hohpe and Woolf (2003), which have turned into a cookbook for software engineers to design and implement integration solutions. ...
Article
Full-text available
Consulting companies that specialise in Enterprise Application Integration commonly require adapting existing frameworks to specific domains. Currently, there are many such frameworks available, most of which provide a materialisation of the well-known catalogue of patterns that was devised by Hohpe and Woolf. The decision regarding which framework must be used is critical since adaptation costs are not negligible. In this article, we report on a methodology that helps practitioners make a decision regarding which framework should be selected. To the best of our knowledge, there is not a previous methodology in the literature. Its salient features are that we have assembled a catalogue of measures regarding which there is a consensus in the literature that they are clearly aligned with the effort required to maintain a piece of software and we propose a statistically-sound method to produce a rank. We illustrate our proposal with an industrial case study that we have performed using five open-source frameworks.
Article
‘Software ecosystems’ is argued to first appear as a concept more than 10 years ago and software ecosystem research started to take off in 2010. We conduct a systematic literature study, based on the most extensive literature review in the field up to date, with two primarily aims: (a) to provide an updated overview of the field and (b) to document evolution in the field. In total, we analyze 231 papers from 2007 until 2014 and provide an overview of the research in software ecosystems. Our analysis reveals a field that is rapidly growing, both in volume and empirical focus, while becoming more mature. We identify signs of field maturity from the increase in: (i) the number of journal articles, (ii) the empirical models within the last two years, and (iii) the number of ecosystems studied. However, we note that the field is far from mature and identify a set of challenges that are preventing the field from evolving. We propose means for future research and the community to address them. Finally, our analysis shapes the view of the field having evolved outside the existing definitions of software ecosystems and thus propose the update of the definition of software ecosystems.
Article
Full-text available
We describe an Internet application for providing mobile phone tariff information for Northern Ireland and the Republic of Ireland. Using this application it is possible to accurately and easily determine and compare mobile phone packages offered by different service providers. One of the important features of such an Internet application is the potential for high maintenance associated with the data in the system and more importantly the structure of the system given the inevitable changes in the corresponding mobile phone market. We have identified the maintenance tasks associated with our system to reflect changes in the mobile phone market and outline an evaluation technique for describing the system's ability to cope with change. In particular, we evaluate the actual change required to our software system to implement various maintenance tasks. We have found that there is an upper bound (∼5%) on the maintenance effort associated with the system which is both acceptable and manageable for maintenance purposes. We show that at most the changes required to our system are no greater than 3.07%, when a complete new service provider is added or removed. We conclude that the development of a maintenance model in conjunction with system design is essential for estimating the maintenance effort associated with similar Internet applications.
Article
The Health Insurance Portability and Accountability Act (HIPAA) of 1996 (PL. 104–191) brings the federal government fully into insurance regulation for the first time. Despite the Republican majority's rhetoric about state control, election-year politics trumped federalism. HIPAA's immediate impact oncoverage may be modest, but its ultimate significance is great because it creates a template for more farreaching federal involvement in regulating insurance. HIPAA amends the Employee Retirement Income Security Act (ERISA), the Public Health Service Act, and the Internal Revenue Code, creating a complicatedstructure dictated by efforts to avoid an unfunded mandate. The history of insurance regulation and the activity surrounding the enactment of PL. 104–191 suggest that HIPAA continues an incremental process of transition between state insurance regulation and federal oversight driven by recent and accelerating changes in the structure of the health-care marketplace.
Article
From the Publisher:Best selling author and world-renowned software development expert Robert C. Martin shows how to solve the most challenging problems facing software developers, project managers, and software project leaders today. This comprehensive, pragmatic tutorial on Agile Development and eXtreme programming, written by one of the founding father of Agile Development: Teaches software developers and project managers how to get projects done on time, and on budget using the power of Agile Development. Uses real-world case studies to show how to of plan, test, refactor, and pair program using eXtreme programming. Contains a wealth of reusable C++ and Java code. Focuses on solving customer oriented systems problems using UML and Design Patterns. Robert C. Martin is President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients. He is the author of the best-selling book Designing Object-Oriented C++ Applications Using the Booch Method (Prentice Hall, 1995), Chief Editor of, Pattern Languages of Program Design 3 (Addison Wesley, 1997), Editor of, More C++ Gems (Cambridge, 1999), and co-author of XP in Practice, with James Newkirk (Addison-Wesley, 2001). He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows. Author Biography: ROBERT C. MARTIN is President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients. He is the author of the best-selling book Designing Object-Oriented C++ Applications Using the Booch Method (Prentice Hall, 1995), Chief Editor of, Pattern Languages of Program Design 3 (Addison Wesley, 1997), Editor of, More C++ Gems (Cambridge, 1999), and co-author of XP in Practice, with James Newkirk (Addison-Wesley, 2001). He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.
An empirical study of software maintenance tasks was carried out in a large Norwegian organization in the period 1992–93. More than one hundred randomly selected maintenance tasks were studied through interviews with the maintainers performing the tasks immediately before they started the tasks and immediately after they had completed the tasks. The collected data is used to develop distributions and to test 33 hypotheses about software maintenance. The findings from the study indicate, for example, that Application system documentation plays only a minor role as maintenance information source.The maintenance productivity, measured in LOC/effort, is predicted by the size of the task and type of change in the source code, but seems rather independent of language level, maintainer experience, application age and application size.There is an economy of scale for software maintenance tasks.The type of programming language does not correlate with proportion of unexpected maintenance problems, task complexity or task size.The proportion of corrective maintenance decreases with increasing age of the application.
Conference Paper
Within a large, object-oriented software system it is com- mon to partition the classes into a set of packages, which implicitly serve as a set of coarsely-grained logical design units. However, as such a system evolves and design drift sets in, it becomes increasingly challenging for developers — especially those who are new to the project — to com- prehend the underlying criteria behind the package-level design of the system. This problem is exacerbated by the fact that in most object-oriented programming languages the package (or namespace) construct has little semantics beyond that of a simple container, and so fails to capture the essential properties of the objects that its contained classes represent. In this paper, we propose an approach to uncov- ering package partitioning criteria by analyzing the collab- oration patterns between packages. Our analysis approach is based on the Hybrid Model, a program model that de- scribes the coarsely-grained structure and global behaviour of an object-oriented system. We present an exploratory case study to show how our approach can help maintainers to derive the design criteria related to coupling, cohesion, function reuse, and inheritance reuse.