Web services and EAI -- Partners or rivals?

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

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:

• Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
• Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
• For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
• Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.

• Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
• Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
• Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.