Back to Articles Page      

Web Services and EAI - Partners or Rivals?  Reproduced with kind permission of TechMetrix Research   Article written by: JEAN-CHRISTOPHE CIMETIERE - CEO of TechMetrix (  )

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.

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

• Web Services Solutions Directory
• B2B Directory