See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/4000964

Modeling EAI [Enterprise Application Integration]

Conference Paper · February 2002

DOI: 10.1109/SCCC.2002.1173194 · Source: IEEE Xplore

CITATIONS READS
11 1,874

3 authors:

Francisca Losavio Dinarle Ortega

Central University of Venezuela Universidad de Carabobo, UC
115 PUBLICATIONS   691 CITATIONS    12 PUBLICATIONS   62 CITATIONS   

SEE PROFILE SEE PROFILE

Marzio Pérez
University Cesar Vallejo
59 PUBLICATIONS   201 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

fmerchen@iberoamericana.edu.co View project

MODELO DE PROCESO PARA LA INGENIERÍA DE REQUISITOS ORIENTADA A ASPECTOS: UNA APLICACIÓN A SISTEMAS FIABLES View project

All content following this page was uploaded by Francisca Losavio on 29 May 2014.

The user has requested enhancement of the downloaded file.

 Modeling EAI*†
F. Losavio D. Ortega M. Pérez
Centro ISYS, Laboratorio LaTecS, Departamento de Computación, Departamento de Procesos y
Facultad de Ciencias, Universidad de Carabobo, Sistemas,
Universidad Central de Venezuela, Valencia, Venezuela Universidad Simón Bolívar,
Caracas, Venezuela dortega@thor.uc.edu.ve Caracas, Venezuela
flosav@cantv.net movalles@usb.ve

Abstract requirements [17] and the Enterprise Application

Software integration has been a solution to the
problem of connecting dissimilar systems for many
years. This integration is still a challenging issue. EAI
(Enterprise Application Integration) is defined as the
process of integrating enterprise systems with existing
applications. Since software integration research has
yielded a variety of different concepts, we survey and
discuss this terminology. EAI arise as an evolution of
the CASE technology approach. The main goal of this
work is the modeling of EAI in order to obtain a more
organized and unified view of the main aspects
involved. The EAI model presented in this work was
constructed extending the known Brown’s Conceptual
Model of Integration (BCMI). One of the interesting
contributions of this paper are the identification of
architectural styles and patterns and the specification
of a quality model, based on the international
standard ISO 9126-1 for integrated enterprise
systems. This quality model specifies the quality
characteristics that the systems in the EAI domain
should hold.
Keywords: EAI, software architecture, quality model,
middleware, ES, IT
1. Introduction
It is nowadays a normal practice of commercial
organizations to apply information technology to
support their whole work process, trying to solve
complex problems that are common in
increasingly competitive global business
environments. In order to provide a complete,
efficient and reliable support, automated tools
like CASE (Computer Aided Software
Engineering) or complete Information Systems
(IS), must share the common factor of being
integrated. The information must be “shared”
within the organization in order to guarantee a
better planning, control and evaluation of the
work processes, inside and outside of the
organization. In this way, enterprise systems
arise within the organization to fill these
Integration (EAI) arises as an evolution of the
Integrated CASE technology approach. EAI is
defined as the process to integrate Enterprise
Systems (ES) with existing applications.
Historically, in the 90’s decade, the software
engineering community proposed the Integrated
CASE Environments [2], [4], [22], [25]. They were
conceived as a solution to the software integration
problem. These complex software systems integrated
a set of independent CASE tools or other software
tools. The drawbacks of this approach was that only
few software houses fully implemented the
functionality of this conceptual architectural
framework, since the full implementation resulted in
a very huge software system. An example of these
frameworks is the ECMA/PCTE [2]. More recently,
the ES [17] are proposed as integrated IS to cover
most of the enterprise business process. However,
many existing IS are considered “automation
islands”, since they cannot communicate easily with
systems inside the organization and even less outside
it, with external systems of clients and suppliers. One
of the most crucial points of handling software
application integration, is to combine all the
organization assets or expertise, including
information technology such as data base
technology, distributed and real-time computing and
data warehouses, to support the complexity of all the
organizational processes.
Since EAI is a new approach to integration, it lacks
formalization, organization and unification of the
related concepts [6], [11], [14], [17], [20], [23]. The
main goal of this work is the modeling of EAI in
order to obtain a more organized and unified view of
the main aspects involved. The proposed model was
constructed extending the known Brown’s
Conceptual Model of Integration (BCMI) [2]. One of
the interesting contributions are the identification of

*
Enterprise Application Integration
†
Co-financed by FONACIT through the S1-2001000792

1
architectural styles/patterns for EAI and the
specification of a quality model for integrated
enterprise systems.
This paper is structured as follows, besides this
introduction and the conclusion: Section 2
presents a brief survey on the antecedents of
software application integration, focusing on the
Brown’s model. Section 3 describes aspects of
EAI, in particular the backward, forward and
upward integration views, which will be used to
“extend” the Brown’s Model. Finally, Section 4
discusses in details the extension of the Brown’s
Model. Each integration view is related with the
process, services and mechanisms levels
proposed by Brown.
2. Antecedents: Integrated
CASE Environments
The integrated CASE environment approach is
briefly illustrated by the integration mechanisms
proposed by Brown, Wasserman, y Thomas y
Nejmeh. Finally the BCMI is discussed. CASE
is an approach aiming to increase the software
engineering process effectiveness through the
automated support to all the software
engineering activities [15]. CASE technology
has evolved into the Integrated CASE Support
Environments (ICSE) [12], offering an
integration framework independent from the
platform (operating system and hardware). The
information is made available to the users
(humans and tools) through a unique data format,
which is the integration unifying concept, such
as the Unix file system, a shared data base or a
common semantics [4]. The following
integration mechanisms have been identified:
• Integration as a set of attributes.
Wasserman [25] proposes five dimensions
platform, presentation, data, control and
process.
• Integration as a relation. Thomas y Nejmeh
[22] extend Wasserman’s analysis with the
specifications of the properties that must be
satisfied by the relations used for tools
integration
• Integration based on repository. Brown [2],
on the basis of the Wasserman’s approach,
improves the definition of the data dimension
defining more deeply the repositories, such as
storage, persistence, data models, rules on the
data operations and integrity.
Table 1 shows the integration dimensions and
mechanisms discussed above, for each approach.
Brown’s Conceptual Model of
Integration
Brown [2] proposes a conceptual model, or three-tier
framework corresponding to different abstraction
levels, to describe the integration of the tools
constituting a CASE environment. The resulting
environment is called a federative environment or a
tools federation. In this model, the process is
included as the abstract notion used to configure the
integrated CASE. The system must be customized to
an organizational process. Three abstraction levels
are distinguished (see Figure 1). The central level
contains the services (functionality of the CASE
environment) offered to the final users. Integration at
this level means to define the relation between the
services of version control and data management.
The third level contains the mechanisms used to
implement the services. It contains the baseline
architecture for the environment and the
technological constraints required to connect the
components (tools) implementing the services. The
first and more abstract level corresponds to the
organizational process providing guidelines (goals in
terms of steps and tasks, constraints) to select the
services offered by the CASE system. The relation
between the service level and the mechanism level is
an implementation relation. A service can be
implemented by several mechanisms. The relation
between the process and service levels is an
adaptation relation. The process constitutes a set of
guidelines and constraints that are used to combine
or select the services in order to satisfy a particular
functionality for the final user. The separation of the
level where the components relations are
implemented, from the level where the services are
provided is crucial. However, the description at the
process level where the environment will operate, is
equally important.
PROCESS
Goals Constraints
Steps
Tasks Politics Schedule
Adaptation
SERVICES
Engineering Management
Design Code Estimations Planning
Implementation
MECHANISMS
Technology
Architecture Client/
PCTE X
Database Server RDBMS
Figure 1. Brown’s Conceptual Model of Integration
[2]
2

The following sections are devoted to discuss the
extension of this model with the main concepts
of the EAI approach.
3. The EAI Approach
As we have already appreciated, the integration
problem has not been entirely resolved and the
software application integration is a very
expansive process in terms of human and
technological efforts. However, the importance
of integrating applications is nowadays a main
concern of the software community. The
CORBA framework of the Object Management
Group is only an example [24], [11]. By far, the
largest intangible benefit to enterprise integration
is the recent improved availability of information
that is widely available throughout the
organization using integrated IS and network
communication facilities and the establishment
of enterprise-wide standards for information
resources [17].
According to [17] and the previous sections, IS
integration means to unify independent IS, with
the purpose of providing shared information
and give a valid support to the whole
organizational process. The desired result is an
ES, covering most of the enterprise business
processes. A recent trend is to implement the
Enterprise Resource Planning (ERP) to integrate
all the business aspects, including planning,
manufacturing, sales, finances, for providing a
unique coordination for shared information.
However, ERP is in general not enough, without
taking into account a combination of
innovations: technological, such as database and
communication technology, and organizational,
such as Business Process Reengineering and
Workflow Redesign. Another trend is to
integrate through inter-organizational systems,
such as e-business solutions [23], to automate the
data flow connecting an enterprise with clients
and suppliers. Notice that the integration of IS
uses also more traditional technology like
middleware for databases, user interface
standards and middleware for real-time and
distributed applications, like adapters and
brokers [21]. Actually, one of the goals of this
work is to point out that different software and
technology will be used to integrate, according to
mechanism level, following the Brown’s
integration model.
In order to synthesize these different integration
trends, three integration views are proposed in
[17], to allow software integration in an incremental
way: Backward, Forward and Upward. The
Backward Integration (BI) refers to the integration of
the internal organizational processes. The Forward
Integration (FI) refers to the integration of those
organizational processes related to entities which are
external to the organization, such as clients, partners
and suppliers. The Upward Integration (UI) means
the integration of those organizational processes
related to decision making. These three views will
drive the extension of the BCMI, in the sense that
each model tier will be refined using the three EAI
integration views. The next section presents this
approach.
4. Extension of BCMI with the EAI
Views
The extension of the BCMI is proposed according to
a top-down refinement of each one of the process,
service and mechanism tiers of the Brown’s
framework with the BI, FI and UI views.
The Process Level
In order to refine this level, the most commonly used
organizational processes are described for each
integration view. Notice that each process has its
own goals and constraints, depending directly from
the specific functionality that is required for the
integrated system (see the Process Level in Figure
1).
i. Backward Integration
According to this view, an interesting organizational
process is the Supply Chain Management (SCM)
[11], [23]. ES has been applied to the automation of
this process. SCM consists in the applications of
methods and techniques to integrate internal
processes of sellers, producers and suppliers. SCM
[11], [23] is a collection of physical entities such as,
manufacturers, supply centers, transportation,
delivery centers, online retailing, people and
information, participating in the process of supplying
goods or services from the source to the production
and delivery operations. SCM may be extended to
other external processes such as: flows of materials
and client services. Typically, the following
processes are involved: production and materials
management processes, procurement and order
fulfillment processes. SCM can also be extended to
organizational external processes.
ii. Forward Integration
The extended SCM allows the integration of the
enterprise with its external entities, such as suppliers,
partners and clients [17].
3
iii. Upward Integration
This view is constituted by those processes
integrating vertically the organization. It is
concerned with management decision making,
planning and extend SCM [17]. Table 2 shows
the processes (goals) and examples of sub-
processes for each process [13] in the three
views BI, FI, UI, extending the Process Level of
BCMI (see Figure 1).
The service level
In what follows, the extension of the BCMI is
presented at Service Level, with the three
integration views. Table 3 shows the engineering
and management services, expressed in terms of
the computing systems implementing the
processes shown in Table 2.
i. Backward Integration
In this view, the ERP framework is presented as a
significant example, with the corresponding
implementations. The integration of the internal
organizational processes with the respective
application supporting them is then achieved. If
SCM is automated, obviously it cannot be extended.
It is important to point out that the implementations
of the SCM are considered instances of the ERP
framework, which is also an ES framework.
Moreover, ES represents the integrated IS.
ii. Forward Integration
The scope of ES has to be extended towards the
clients in order to obtain an integrated extended
supply chain. This may be achieved using Database
technology (DataMarts, Data Warehouse, Data
Mining), the Customer Relationship Management
(CRM) and the Customer Experience Management
(CEM), with their respective implementations.

Integration Wasserman Thomas and Nejmeh Brown

Approach
Dimensions Platform: a common framework for
Services
Presentation: usability standards
Data: consistency
Control: communication and
interoperability
Process: roles of the tools
Mechanisms Platform: hardware/software
Presentation: look and feel, toolkit,
window manager
Data: shared files
Control: daemons, triggers, message
server
Process: functionality
Table 1. Integration mechanisms
Platform: is not considered
Presentation: usability standards
Data: interoperability, no-
redundancy, consistency,
exchange formats,
synchronization
Control: provision and use to
achieve functionality
Process: step, event, constraints
Mechanisms are not relevant
Platform: is not considered
Presentation: usability standards
Data: persistency and common
semantics
Control: tools offer services
Process: is not considered
Platform: is not relevant
Presentation: look and feel, toolkit,
window manager
Data: repository and common access
mechanism
Control: message passing
Process: is not considered

Level Integration views

Backward
Process • Sales and marketing: order
processing, order tracking
• Manufacturing/production:
inventory management,
purchasing, shipping, plant and
equipment maintenance
• Financial and accounting: account
payable, account receivable, cash
management, forecasting, product-
cost accounting
• Human resources: personal
administration, personal planning,
benefit accounting, training
• Development and research: design
and testing virtual prototyping of
products, ergonomic analysis,
simulation of assembly.
Table 2. Extension of the Process Level of BCMI with internal, external and management organizational
processes.
Forward Upward
• Telemarketing • Sales: sales management,
• Web sales sales planning
• Retail sales • Manufacturing/production:
production planning, material
• Customer service
requirement planning,
inventory management
• Financial and accounting:
product-cost accounting, cost-
center accounting, asset
accounting, general ledger,
financial report.
• Human resources: applicant
tracking, contract cost
analysis.

4
iii. Upward Integration
This view is characterized by the Executive
Information System (EIS). They support
managers in decision making and in the
communications of these decisions to the
corresponding responsible persons.
The components proposed by Brown
(engineering and management) for the service
level do not fit into the classification of systems
adopted here, which is based on the
technological evolution of the IS (example:
legacy systems based on languages, B2C systems
based on platform client/server based on layers).
Table 3 summarizes the above discussion.
Services are presented in terms of the typical IS
supporting the processes, according to the
respective integration view. Among the modules
of the CRM systems, the Sales Force
Automation (SFA) is taken as an example. The
workflow systems are considered among the
collaborative systems.
The Mechanism Level
According to Brown, two types of components
are taken into account at this level: architecture
and technology. Hence, a brief survey on
software architecture and information technology
used for integration will be given before
presenting the extension of the mechanism level.
i. Architecture
An architecture (components and connectors
with a behavior [19]) is the main mechanism
required in order to articulate the services
supporting the organizational processes,
according to BCMI. The architecture is the
baseline on which services are branched. The
services correspond to the ES functionality, such
as the SCM and ERP implementations. The
activities (tasks and constraints) required by the
organizational processes (goals) are then
satisfied (see Tables 2 and 3). Moreover, Brown
considers technological constraints, which may
affect the proposed architecture.
One of the goals of this work is the identification
of the architectural styles [19] and patterns [3],
with their corresponding quality properties,
suitable for the ES applications, extending in this
way the BCMI to the EAI context. Notice that
the identification of the quality characteristics
required to build the EAI framework constitutes a
quality model for ES applications [9].
According to [17], EAI is defined as the process to
integrate ES with existing applications, such as ERP,
maintenance management, inventory management
and cost-accounting systems, including web-based
interfaces and middleware components to achieve
integration. EAI is associated with system
integration within a business entity. However, it can
also be associated to enterprise systems of different
corporations, called Business to Business (B2B) and
different clients, called Business to Consumer (B2C)
[8], [7].
The basic notions about software architecture can be
seen in [19]. The architecture term conveys several
meanings, sometimes contradictory. Architecture is
considered here as the structure of the components of
a system, their interrelationships and guidelines
governing their design and evolution over time. The
architectural model of a system provides a high level
syntactic and semantic description that enables
compositional design and analysis of component-
based systems. The architecture becomes the basis of
systematic development and evolution of software
systems [16], in particular, this applies to EAI
applications. The description of the architecture is
composed of identifiable components of various
types. Components interact in identifiable distinct
ways. Connectors mediate interactions among
components, they establish the rules that govern
components interaction and specify any particular
mechanism required. Components and connectors
have interfaces. A component’s interface is defined
as a set of ports, which determines the component’s
points of interaction. A connector’s interface is
defined as a set of roles, which identifies the
participants of an interaction. A configuration
defines topologies of components and connectors.
The architecture is composed also of other
constituents: constraint, style [19], pattern [3] and
rationale. In particular, an architectural style defines
a family of software systems meeting the
requirements imposed by the architectural definition
given above.
5
 Level Integration views
Backward Forward Upward
Services • CASE tools • CRM (Customer • EIS (Executive
• Legacy Systems Relationship Management) Information Systems)
• TPS (Transaction Processing
systems • ESS (Executive
Systems) • CEM (Customer Experience Support Systems)
• ERP (Enterprise Resource
Management) systems • MIS (Management
Planning ) • B2C (Business to Consumer) Information Systems)
systems • DSS (Decision
• B2B (Business to Business) Support Systems)
systems • KMS (Knowledge
Management Systems)
Table 3. Extension of the service level of the BCMI with the services supported by the internal, external
and management organizational processes.

The architectural styles considered here for EAI
will be briefly introduced, in order to abridge
this presentation. The details can be seen in [3]
and [19], however we have given the quality
characteristic favored by each style and pattern,
taking the ISO 9126-1 definition [9], in order to
illustrate the nonfunctional requirements that the
final system built with the style should meet.
reflecting the actual state and an independent set
of components operating on the central memory.
In general, components only communicate
through the central memory. Examples are many
integrated support environments. There are also
middleware-based repository [1]. It favors
maintainability (changeability) and reliability
(fault-tolerance).

• Event-based and implicit invocation.
Components are modules whose interfaces
provide procedures and events. The
procedure invocation for handling the event
is the connector. When an event is
generated, the event generator mechanism
does not know the event handler (the
component’s module affected by it).
Middleware applications [20] deal with
event-based systems, in particular, with
distributed evolutionary applications.
Examples are process control systems and
stock tracking. It mostly favors the
maintainability (changeability), portability
(reuse, in terms of adaptability) and
functionality (interoperability) quality
characteristics.
• Layers. The components are the layers
hierarchically organized. Each layer offers
services to the immediate superior layer and
it is client of the immediate inferior layer.
Connectors are defined by the protocols
specifying the interaction between the
layers. Examples are the TCP/IP protocols,
operating systems, some programming
support environments, interactive systems,
IS and database systems. It mostly favors
maintainability (changeability) and
portability (adaptability) quality
characteristics. Notice that the client/server
architecture is a variant of the layers style.
• Repository. It has two types of components:
a central data structure or central memory
Notice that ISO 9126-1 [9] gives the following
definitions for the quality characteristics mentioned
above: Adaptability is the capability of the software
product to be adapted to different specified
environments using only its own functionality. This
property indicats also a type of reuse. Changeability
is the capability of the software product to enable a
specified modification to be implemented. It includes
the properties usually known as extensibility and
flexibility. Interoperability is the capability of the
software product to interact with on or more
specified systems. It can be used in place of
compatibility. Fault-tolerance is the capability of the
software product to maintain a specified level of
performance in case of software fault or of
infringement of its specified interface. It is used here
mostly for robustness.
However, the majority of software systems use a
combination of styles. A style is always placed at a
high abstraction level. Architectural patterns are
placed at a lower abstraction level according to [3].
A style may be composed of architectural patterns. In
turn, architectural patterns may be composed of
design patterns. In what follows, the more interesting
architectural patterns and design patterns [3], [18]
that can be used to structure EAI applications, will
be presented. They are broadly grouped in three
categories, according to their main usage.
Distributed systems
• Broker: can be used to structure distributed
applications with decoupled components that

6
 interact by remote service invocations. The
components are broker, client, server, proxy
and bridge. Examples are CORBA and its
implementations [24], e-commerce
applications. It favors modifiability
(changeability), portability (adaptability)
and functionality (interoperability)
Adaptable and configurable systems
• Microkernel: it applies to systems that
must be able to adapt to changing systems
requirements. The components are:
microkernel, external and internal server,
adapter, client. An example is Windows NT.
It favors maintainability (changeability) and
portability (adaptability).
• Reflection: it provides a mechanism for
observing a component’s state for changing
structure and behavior of software systems
dynamically. The components are basically
two levels: a metalevel providing
information about selected systems
properties. A base level with the application
logic. Its implementation builds on the
metalevel. Connectors are the protocol
communicating the levels. Examples are
CLOS [10] and Java [24]. It favors
maintainability (changeabilty) and
portability (adaptability).
• Wrapper Façade: encapsulates the
functions and data provided by existing non-
object-oriented APIs within more concise,
robust, portable and maintainable and
cohesive object-oriented class interfaces.
Components: application, Wrapper Façade,
API Functions. Examples: Java Virtual
Machine, Java class libraries (AWT, Swing),
Microsoft Foundation Classes (MFC). It
favor maintainability, portability and
reliability (fault-tolerance).
• Component Configurator: allows an
application to link and unlink its
components implementations at run-time
without having to modify, recompile or
statically relink the application. It supports
reconfiguration of components into different
application processes without having to shut
down and re-start running processes.
Components: component reconfigurator,
component repository, component, concrete
component. Examples: Windows NT
service control manager, Java applets,
reflective ORB. It favors maintainability
(modularity for testability) and portability
(adaptability).
• Interceptor: allows services to be added
transparently to a framework and triggered
automatically when certain events occur.
Variants of this pattern are Chain-of-
responsibility, Publisher/subscriber and
Subject/observer. Components: context,
concrete framework dispatcher, application,
interceptor, concrete interceptor. Examples:
Component-based application servers, CORBA
implementations (COM), Web browsers,
reflective ORB. It favors modifiability
(changeability).
• Extension Interface: allows multiple interfaces
to be exported by a component to prevent
bloating of interfaces and breaking of client
code when developers extend or modify the
functionality of the component. Components:
root interface, extension interface, component,
component factory, client. Examples are
CORBA implementations such as COM/COM+,
CCM, Enterprise Java Beans (EJB). It favors
modifiability (changeability).
Notice that Interceptor and Extension Interface
can use the Component configurator pattern to
re(configure) various service roles into
components in application processes without
having to shut down and restart running
application processes
Interactive systems
• MVC, PAC: for interactive systems to separate
concerns, presentation aspects from the
semantics of application. The Model, View,
Controller (MVC) pattern is also known as
Subject/Observer or Publisher/Subscriber. The
Presentation, Abstraction, Control (PAC)
pattern is represented by the Mediator pattern.
The components are colleagues that
communicate between each other through a
distinguished colleague (intermediary). The
main difference between MVC and PAC is that,
in PAC, colleagues only communicate through
the Control and not directly to the Model as in
MVC. Examples are interactive systems with
graphic user interface. It favors modifiability
(changeability).
Notice that the above architectural patterns belong
basically to the layers style. They can be modified
(reused or extended) and adapted to different
contexts, to support interoperability for the
integration of software applications. For example, to
define the architecture of a client/server application
based on distributed, flexible and evolutionary
components, with an adaptable and extensible user
7
interface, all the above architectural and design
patterns can be found in the commercial
available software components that will be used
to design the application.
On the basis of the analysis of the architectural
and design patterns involved in the EAI
framework, a possible ES quality model can be
formulated, selecting the common characteristics
present: maintainability (changeability,
modularity), portability (adaptability),
functionality (interoperability) and reliability
(fault-tolerance).
In consequence, ES built following the EAI
framework should meet the required
characteristics listed in the quality model, in
order to be considered “quality systems”. An ES
should then be reusable, modular, adaptable
and interoperable. Moreover in cases of critical
real-time systems, fault-tolerance is also
required. Notice that a middleware application
also fulfill this quality model, since it is built
using the above architectural patterns.
Continuing with the extension of the BCMI, the
technology related with the mechanisms used to
implement the services supporting the
organizational process will be described in what
follows.
ii. Technology
Information Technology (IT) is defined as a set
of resources available to manage changes and
give support to people in the development of the
activities related to an organization [5], [6], [11],
[14], [17]. The following resources are
considered:
• Hardware: it is constituted by the physical
components of the computer equipment used
for the following activities: data input
(keyboard, mouse, monitor, multimedia
facility, etc.), data processing (Central
Processing Unit) and data output (monitor,
printer, multimedia facility, etc.).
• Software: it corresponds to the
programming instructions controlling and
coordinating the hardware components or
computing applications. Examples:
middleware applications (defined as an
intermediary layer allowing interoperability
of different software applications through
the network). It provides services such as
data exchange, identification, authorization,
directories and security. They use
communication protocols like TCP/IP [20]),
Graphical User Interface, groupware and
multimedia.
• Database technology: it uses hardware and
software, being conformed by the data
storage/retrieval and the software controlling the
data organization on the physical components.
Examples: Data Warehouse, Data Mining, Data
Mart, etc. Some less traditional techniques for
knowledge capture are genetic algorithms,
neural networks, fuzzy logic, intelligent agents.
• Communication technology: it uses hardware
and software, including the network physical
equipments and the software, to transfer data
from one physical location to another different
physical location. Examples are Internet,
intranet, extranet. The network connection
(LAN, WAN) to the computers and the
communication equipment required to share
usual data and multimedia data, is performed
through different media (telephone, wireless
technology like cellular phone, microwave,
satellite, WAP). With respect to the
communication applications, it can be
mentioned: fax, HTML, XML, Electronic Data
Interchange (EDI), EDI based Internet,
Electronic Fund Transfer (EFT), groupware,
workflow and e-mail.
• Human resources: they are required to operate
the above technologies.
The Mechanism Level of the BMCI with the three
integration views is discussed below.
i. Backward Integration
The database and communication technologies are
mostly related with middleware applications, which
are used to integrate the applications implementing
the internal services in the BI view (see Table 3).
GUI software is also used.
ii. Forward Integration
The same argument used for BI applies for FI.
iii. Upward Integration
The same argument used for BI applies for UI.
Moreover, notice that all the architectural styles and
patterns discussed for EAI can be applied indistinctly
to the three views. Now at this level, middleware
software on one hand uses the proposed architectural
patterns for EAI, fulfilling the required quality
characteristics. On the other hand, it uses database
and communication technologies. GUI and
multimedia facility software uses event-based style,
8
and pattern based on decoupling, favoring Mechanism Level, since it is the lowest abstraction
changeability. In consequence, they are natural level, holds the general styles and mechanisms which
mechanisms to be used to integrate ES, will be used to implement all the services
according to the EAI framework [11]. So, the corresponding to the three views of EAI.
three views have the same mechanisms. In
consequence, the BI, FI and UI views are not 5. Conclusion
relevant at the BCMI Mechanism Level. Table 4 This work takes the integrated CASE technology as
summarizes these results. the basis to model and unify the recent EAI
approach. The Brown’s Conceptual Model of
Level Components EAI Integration is extended with the EAI views of
Mechanism Architecture • Styles: integration. Brown’s three abstraction levels of
Layers, repository, event-
based, implicit invocation
Process, Service and Mechanism are customized to
• Patterns: the EAI organizational processes, services
distributed, adaptable, supporting the processes and mechanisms to
interactive and reconfigurable implement the services. This model is also used to
Technology • Hardware structure and unify EAI terminology. Moreover,
• Software: architectural styles and patterns for EAI applications
middleware, GUI and are identified, with the corresponding quality
multimedia facility requirements. This allows the definition of a standard
• Database technology quality model, in the sense of ISO 9126-1, specifying
• Communication the quality characteristics that an integrated
technology
enterprise system should hold. The more formal
Table 4. Mechanism Level of the BCMI for EAI
specification of an integration model for software
applications is an ongoing research.
Figure 2 shows the BCMI (see Figure 1)
extended with the EAI views. Notice that the

Backward Forward Upward

PROCESS PROCESS
PROCESS
Manufacturing Telemarketing
Sales and Human Web Retail Sales
resources sales Production management Applicant
marketing Financial and sales Customer planning Financial tracking
Accounting service
report
Adaptation
SERVICES SERVICES SERVICES MIS
Legacy TPS B2B CRM ESS
Systems ERP CEM EIS KMS
B2C DSS

Implementation
MECHANISMS
Broker MVC
Microkernel Reflection

Figure 2. Graphical representation of the BCMI extended to EAI

References [2] Brown A., Carnery D., Morris E., Smith D.,
[1] Blair G., Blair L., Issarny V., Tuma P., Zarrella P. "Principles of Case Tool
Zarras A. "The Role of Software Integration". Software Engineering Institute,
Architecture in Constraining Adaptation in Oxford University Press, 1994.
Component-Based Middleware Platforms". [3] Buschmann F., Meunier R.;,Rohnert H., Peter
IFIP/ACM International Conference on S., Michael S. "A System of Patterns". John
Distributed Systems Platforms. Wiley & Sons Ltd. 1996.
Proceedings. Lecture Notes in Computer [4] Chen M., Norman R. "A Framework for
Science. New York, NY, USA. April 2000. Integrated CASE". IEEE Software, March,
1992.

9
 [5] Collins E. "Charting the impacts of
Information Technology". Division of
Science Resources Studies National
Science Foundation. Presented at the
“Workshop on Science, Engineering and
Quality of life: Research outcome Models.
12-14 Dec 1997.
http://www.nsf.gov/sbe/srs/infotech/chartin
g/htmstart.htm
[6] Gupta U. "Information Systems. Success in
the 21st Century". Prentice Hall. 2000.
[7] ILUMA Technologies, Inc. Copyright ©
2001. "Enterprise Application Integration
(EAI)".
http://www.iluma.com/solutions_eai.asp
[8] Information Technology Toolbox, Inc.
Copyright © 1998-2002. "EAI overview".
http://eai.ittoolbox.com/browse.asp?c=EAI
PeerPublishing&r=%2Fpub%2Feai%5Fove
rview%2Ehtm
[9] ISO/IEC, 1998. FCD 9126-1.2: Information
Technology - Software Product Quality.
Part 1: Quality Model.
[10] Keene S. E. "Object-Oriented Programming
in Common Lisp – A Programmer’s Guide
to CLOS". Addison Wesley, 1989.
[11] Laudon K., Laudon J. "Management
Information Systems". Sixth edition.
Prentice Hall. 2000.
[12] Losavio F., Matteo, A., Pérez M. "CASE
Integration Approaches and a Proposal for
an Object Oriented CASE Environment".
Proceedings of International Conference on
Information Systems Analysis and
Synthesis. ISAS'96, Orlando USA, July,
1996.
[13] Mendoza M. "Sistemas y Procedimientos.
Nuevas Tendencias en la Contaduría".
Caracas, 1996. Universidad Católica
Andrés Bello.
[14] O'Brien J. "Introduction to Information
Systems Essentials for the Internet Worked
Enterprise". Ninth Edition. Mc Graw-Hill.
2000.
[15] Pérez M. "Arquitectura para Ambientes
Case Integrados. Tesis Doctoral en Ciencias
de la Computación de la UCV. Febrero
1999.
[16] Ramdane-Cherif A, Lévy N., Losavio F.
“Dynamic Reconfigurable Software
Architecture: analysis and evaluation” to
appear in proceedings of WICSA 2002,
August 2002, Montreal, Canada
View publication stats
[17] Sandoe K., Corbitt G., Boykin R. "Enterprise
Integration". California State University, Chico.
John Wiley & Sons, Inc.2001.
[18] Schmidt D., Stal M., Rhonert H., Buschmann F.
“Pattern-Oriented Software Architecture”, Vol.
2, John Wiley & Sons, Ltd., 2001.
[19] Shaw M., Garlan D. "Software Architecture -
Perspectives on an Emerging Discipline".
Prentice Hall. 1996.
[20] Slater D. "Middleware demystified". Special
report. CIO Magazine. May 15, 2000.
http://www.cio.com/archive/051500_middle.ht
ml
[21] Themistocleous M., Irani Z. "Evaluating
Application Integration: an Exploratory Case
Study". Seventh Americas Conference on
Information Systems. 2001.
[22] Thomas I., Nejmeh B. "Definitions of Tool
Integration for Environments". IEEE Software.
March, 1992
[23] Turban E., Rainer K., Potter R. "Introduction to
Information Technology". John Wiley & Sons,
Inc. 2001.
[24] Wallnau K., Foreman J. "Object Request
Broker". Carnegie Mellon Software
Engineering Institute.
http://www.sei.cmu.edu/str/descriptions/orb_bo
dy.html
[25] Wasserman, A. "Tool Integration in Software
Engineering Environments". Proceeding of Int.
Workshop of Environment. Berlin. Germany.
1990.
10