Web cannot replace integration
Growth in the use of Web services has highlighted their impact on enterprise application integration, but it would be a mistake to assume that one technology replaces the other

Recent spin from software suppliers appears to claim that Web services technology will oust the complex, expensive and proprietary enterprise application integration (EAI) which currently dominates the market.

With simple, cheap standards-based Web services integration platforms, there is certainly major potential in this new technology. It can be used within companies across all industries to build new applications which are easier to integrate with existing ones and to integrate existing applications.

But the idea that Web services technology is set to take over the software world is complete tosh. And dangerous tosh at that. In the world of software infrastructure (of which EAI is a part) the crude association of proprietary technology with "bad" while standards-based technology is seen as "good" is not a sound idea. Proprietary technology generally works better, runs faster, and is more efficient.

Web services technologies prescribe a new way of deploying software in order to make it available for direct program-to-program access across the Internet. They also provide an independent mechanism through which applications can interact. The software that sits "behind" a Web service could be an enterprise Java application or component; a Cobol transaction; a Visual Basic program; or a common object request broker architecture (Corba)-based application - an attempted technology standard for application server products. Or it could be something else.

This concept is not new. Microsoft's component object model (Com), for example, was founded on the same principles - the ability to build and integrate its own software products, and for third parties to use it to link their software programs together with others, on the Windows platform. It is a Windows-only technology, and continues to play a major part of underpinning .net.

There is also Object Management Group's Corba. However, both Com and Corba required suppliers to swear allegiance to their particular camp in the "Microsoft versus everyone else" war. The difference with Web services - and the exciting bit - is the use of open standard Internet and Web technologies to expose interfaces. This makes it easier for different supplier communities to work together. The war may finally be coming to a close - in this area at least - and Web services are the peacemakers.

Universal backing for Web services technology from suppliers means that there are a lot of people interested in using it to ease the complexity of integrating packaged and custom-built applications. This problem area has most recently been the domain of EAI products from suppliers such as webMethods, Vitria, SeeBeyond and IBM.

Web services technology is a potential substitute for proprietary EAI technologies in some instances, but not in the majority. In other cases it will play a part in overall integration solutions, providing just the basic communications infrastructure.

But today, Web service-based middleware technologies are not capable of driving serious EAI solutions. The uncomfortable truth for many software infrastructure suppliers is that EAI is "heavy-lifting" work.

Users need technology stability and maturity when pushing thousands of messages or function calls through an integration system every hour. Web services today do not provide for many of the advanced features required by such scenarios.

Moreover, there is a whole range of EAI scenarios where the focus of Web services is not really relevant. Ovum calls these scenarios data migration and reconciliation scenarios, where integration work is required to homogenise information stored in a number of applications whose functions and information overlap.

Examples of this would be where two companies merge or where a company wants to migrate an old system to a new platform.

In these scenarios, integration technology needs to focus on two issues, which Web services technology is not designed to address. The first is making it easy for developers to understand the structure of existing databases and other data sources. The second is performing highly complex transformations on that data, very quickly.

The XML-based technologies XSL and XSLT are often pitched as part of solutions, but they are not powerful enough, and their implementations are not efficient to support such serious EAI scenarios.

Web services technology will affect the EAI landscape - but in most cases it will not remove the need for proprietary EAI technology. Anyone who tells you otherwise is probably trying to sell you something that you should not buy.

Neil Ward-Dutton is director of e-infrastructure, Ovum


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in November 2001

 

COMMENTS powered by Disqus  //  Commenting policy