Web Services and EAI - Partners or Rivals?
Reproduced with kind permission of TechMetrix Research
Article written by: JEAN-CHRISTOPHE CIMETIERE - CEO of TechMetrix (firstname.lastname@example.org )
concept of Web Services - now familiar to most companies - is sometimes
positioned as a replacement for EAI (Enterprise Application Integration)
solutions. This confusion is maintained, and even supported by the new
vendors of "pure" Web Services solutions.
us start by looking at the definition of the concepts of Web Services
Services: A Web Service is a modular application which can be accessed
by a network (Internet, Intranet, Extranet) through a standard XML format
(Enterprise Application Integration): EAI is a concept that groups
together a set of methods, technologies and tools used to consolidate
and coordinate different applications, leading to the urbanization of
the enterprise's information system.
reading these definitions, we realize that the functional scope of each
notion is quite different. Web Services pinpoint a specific focus area,
while EAI addresses a much wider range of issues.
composition of Web Services and EAI
us examine the technical components that make up Web Services and EAI.
composition of Web Services
Web Services are made up of a set of standards:
XML: technology used to describe information
used to find required services
used to describe Web services
for remotely executing WEB services
simple set of components has enabled Web Services to build a strong following.
One of the key elements driving Web Services is interoperability. Currently,
interoperability between Web Services (as described above) can be considered
a valid reality because the related technologies are both simple and mature.
diagram illustrates another important point: the standards associated
with Web Services do not attempt to define how to build a service which
is to be published or "Webified". The service may be new or in existence
already, and whatever the implementation technology used, this will not
change the way it is presented in relation to other Web Services. The
"Service Wrapper" is also proprietary, with no link to the Web Services
the initial technical composition of Web Services displays a number of
shortcomings, as it does not cover the following aspects:
over HTTP, it is possible to use SSL to encrypt the channel, and soon
XML Digital Encryption will be available for messages
Authentication: two key standardizations are in progress - SAML
(Security Assertion Markup Language) and XKMS (XML Key Management Specification)
XML Digital Signature looks promising
Transactions: BTP (Business Transaction Protocol), with a first
implementation by HP (HP Web Services Transaction Server 1.0) and XAML
(Transaction Authority Markup Language)
Orchestration: XLANG (Microsoft BizTalk) and WSFL (Web Services
can see, then, that Web Services should be chosen in cases where requirements
match the standards currently available.
composition of EAI
idea of defining the technical makeup of EAI might seem crazy, since EAI
is actually not exclusively based on standards. As we mentioned in the
introduction, EAI groups together a set of methods, technologies and tools
(see our article Which
Technology for Tomorrow's EAI?).
summarize, there are four main types of integration:
Data level: integration is carried out by extraction, and possibly
transformation, routing and injection of data used by applications.
level: integration is carried out directly via application input/output,
for example using messages, APIs, and so on.
logic level: here the information system's business streams are
managed, for example using distributed business objects.
User interface level: the user interface of an application acts
as the input/output point (screen scraping, revamping...). This level
of integration is particularly useful when integrating archaic or dedicated
systems with no other points of access (nonexistent API, inaccessible
data…), which is often the case for mainframe applications.
The ultimate goal is to provide a uniform, standard hub for exchanges
between existing applications, and to open these up to new developments.
The core of an EAI system consists of a set of components which will guarantee
the smooth running of exchanges between sources, which are accessed via
connectors or adapters.
Lastly, the EAI system must be able to provide "standard" entry points,
as shown on the diagram below with the "Public Interfaces." This
is essentially where Web Services will come into play in an EAI solution.
It is also possible for Web Services to be positioned at the level of
Connectors (for example, SAP will provide access to its BAPI integration
interface via Web Services), but in such cases many of the functions offered
by EAI solutions will be lost.
Web Services and EAI are two fully complementary notions: each enriches
the other, but they are not mutually exclusive, since Web Services can
be seen as a technical means of implementing loosely-coupled EAI.
Services are often created from existing company data and processes. The
implementation of Web Services is underpinned by the integration of applications
internally - there are rarely any true Web Services without EAI projects.
conclude, below we set out the procedure generally applied when creating
Building a Web Service
20% time spent considering functional aspects
70% work to integrate applications internally, or set up new systems
The remaining 10%...
Adding a layer for managing inbound/outbound XML calls: SOAP/WSDL,
Managing aspects relating to the process of opening up to the
Authentication, confidentiality, non-repudiation, availability...
more information on this topic, you can consult the following TechMetrix