The 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.
Let us start by looking at the definition of the concepts of Web services and
Web services: A Web service is a modular application that can be accessed
by a network (Internet, intranet, extranet) through a standard XML format interface.
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 enterprises
On 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.
Technical Composition of Web Services and EAI
Let us examine the technical components that make up Web services and EAI.
Technical Composition of Web Services
Web services are made up of a set of standards:
XML: technology used to describe information
UDDI: used to find required services
WSDL: used to describe Web services
SOAP: for remotely executing Web services
This 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.
The diagram illustrates another important point: the standards associated with
Web services do not attempt to define how to build a service that 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 standards.
However, the initial technical composition of Web services displays a number
of shortcomings, as it does not cover the following aspects:
Encryption: 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).
Signature: 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
Orchestration: XLANG (Microsoft BizTalk) and WSFL (Web Services Flow
We can see, then, that Web services should be chosen in cases where requirements
match the standards currently available.
Technical Composition of EAI
The 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
Technology for Tomorrows EAI?).
To 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.
Application level: Integration is carried out directly via application
input/output; for example, using messages, APIs and so on.
Business logic level: Here the information systems 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, etc.). This level of integration
is particularly useful when integrating archaic or dedicated systems with
no other points of access (e.g., 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 that 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 in 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.
Web 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.
To conclude, below we set out the procedure generally applied when creating
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, XML-RPC,
Managing aspects relating to the process of opening up to the outside:
authentication, confidentiality, nonrepudiation, availability
TechMetrix Research is a technically-oriented analyst firm focused on e-business application development needs. It has developed a unique evaluation approach to provide accurate information on software. The firm publishes comparison reports and product reviews.