Web services and EAI -- Partners or rivals?

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. This article by TechMetrix takes a look at at the definition of the concepts of Web services and EAI and examines the technical components that make up each.

This Content Component encountered an error


Market Analysis
Web Services and EAI - Partners or Rivals?

Introduction
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 EAI:

Web services: A Web service is a modular application which can be accessed by a network (Internet, Intranet, Extranet) through a standard XML format interface.

EAI (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.

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 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 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 Markup Language)

Orchestration: XLANG (Microsoft BizTalk) and WSFL (Web Services Flow Language)

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 Which Technology for Tomorrow's 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 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.

Conclusion
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 Web services.

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, XML-RPC, etc.
    • Managing aspects relating to the process of opening up to the outside: Authentication, confidentiality, non-repudiation, availability...

For more information on this topic, you can consult the following TechMetrix resources:

Web Services Solutions Directory
B2B Directory


Copyright 2002 TechMetrix Research. TechMetrix is a technology-oriented analyst firm focused on e-business application development needs. TechMetrix is also backed by its parent company, a European global system integrator - SQLI - with more than 800 developers in the field.

For More Information:

Dig deeper on Service-oriented architecture (SOA) implementations

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close