Does web services threaten the livelihood of EAI vendors? They insist that if you think web services means free integration, then you're sorely mistaken.

	express delivery
	• print  • comment
	EAI software vendors are repositioning their offerings to adjust to web services standardization, but their ultimate role is unclear: Integration is simpler and cheaper using web services Tools are still needed for transformation, routing, messaging and management Some customers are using EAI platforms alongside web services Core elements are becoming commodotized Vendors seek to offer value elsewhere
	Glossary terms: EAI, BPM, XML, publish-subscribe, WS-I, lookup tool Sponsored links: your text link here

The gloves are off in the scrap between the prophets of web services integration and the supporters of conventional enterprise application integration (EAI). Last month, the Gartner conference on web services and application integration skirted timidly around the contentious issue of where the two meet, leaving delegates wondering whether they were actually attending two separate events. Upstart analyst rival ZapThink pulled no punches in its report last month on Service-oriented consulting, which suggested professional services revenues from traditional systems integration will be overshadowed by the value of service-oriented projects by 2006.

So is conventional EAI doomed? EAI vendors are adamant that customers will still have to mix and match web services and EAI in today's environment, and any attempt to pursue one to the exclusion of the other is to miss out on a crucial resource. Wolfgang Gebhard, EMEA product marketing manager at Palo Alto, CA-based integration vendor Tibco, says: "A couple of months ago people were saying web services standardization would replace EAI products, but that's definitely not true.

"How we see it is that standardization provides advantages and makes integration interoperable. It also simplifies dedicated projects. Core web services standards like WSDL, SOAP and BPEL4WS make integration solutions simpler, cheaper and easier to implement and they will grow the market to companies who were previously not integrated, because it was too complex or too expensive. But they will never surpass EAI."

Andy Astor, vice president of web services at Fairfax, VA-based webMethods, adds: "If you start off with the assumption that web services-based infrastructure makes integration free and take your line of questioning from there, then you are starting off on the wrong foot.

"Integration is not free with web services technologies. You still require tools to do data transformation [and] routing, and you need to have a publish-and-subscribe messaging infrastructure in place."

EAI vendors also claim service monitoring and management issues need to be solved, as well as security, business process management and transactionality, which refers to the need to ensure a transaction is completed or have it rolled back. "Without the infrastructure, you have to build it all yourself," says Astor. "Interoperability between applications is only one layer in the complete integration stack and until they move all the way up the stack, web services will remain an immature technology."

Proving credentials

Nonetheless, EAI vendors are keen to play up their web services credentials. Astor points out that webMethods was a co-developer of SOAP with Microsoft back in 1997, while he himself recently took up a place on the board of the Web Services Interoperability organization (WS-I). Tibco explains how it integrated market-leading XML management products after its acquisition three years ago of Extensibility, which had developed what it claims is the only fully standards-based XML schema management system, essential for XML-based transformation and routing. SeeBeyond's recent release of its ICAN product, meanwhile, heavily emphasized web services and the BPM-related concept of business activity monitoring.

But more importantly, these vendors are keen to cite examples of where customers are using web services standards in their own EAI projects.

Two-year-old Infinity Pharmaceuticals, based in Cambridge, Massachusetts, saw web services as the solution to its integration challenges, and thus a way to achieve a competitive edge in developing new drugs. As a greenfield site, it opted for web services in preference to vendor-specific solutions such as EAI or .NET, and uses webMethods to power web services-based integration within its InfiNet Knowledge Platform. The webMethods infrastructure connects automated data feeds from lab equipment and external third-party applications into the platform, which brings together its R&D and database systems in a collaborative environment through a single browser interface.

In other cases, EAI vendors get involved because of a requirement for high throughput and data integrity. Canadian electronic components distribution giant Future Electronics has been using webMethods to deliver web services feeds from two of its back-end systems into browser-based applications. One project has made technical product detail available to sales and marketing staff, by feeding it via a web service from the company's i2 product discovery application.

A second data synchronization project at Future provides wider access to up-to-the-minute inventory and product detail data, by connecting the company's Tandem mainframe system with an internal browser-based application. Previously, staff had to ring a dedicated helpdesk to get at the product information stored on the mainframe. In a tightly-coupled environment, widespread direct access to a highly fault-tolerant, mission-critical mainframe system has always been unthinkable, but web services coupled with an EAI platform have made it possible.

In a quandary

The quandary for EAI vendors is that they want to be seen embracing the new world order — after all, integration standards are the holy grail — but they also have to talk up the benefits of their traditional sweetspot: the small percentage of projects that require their proprietary messaging hubs.

So Astor, for example, takes pains to argue that there are cases where tight coupling is still appropriate: "If you want to decrement an inventory when you take an order — and you never want to decrement except in the case of taking an order — then you may not want the inventory decrementing to be separate to the order-taking service, [to make sure that] you don't decrement inventory without taking an order." But having cited this as an example of the sort of tightly coupled process at which EAI excels, he goes on to insist that webMethods is "not at all tightly coupled. Any webMethods service can be called as a web service and that has been true for years."

EAI vendors all play up the virtues of their platforms in enterprise situations where generic web services, with their lower performance threshold, may not hold up to rigorous requirements. However, there certainly are elements of the EAI stack that will be "standardized out" of the equation.

The adapters that EAI vendors provide to plug specific applications and platforms into their products, for example, will become redundant as vendors such as SAP start using web services as a standardized way of enabling access to application resources. The messaging hubs that form the next layer of an EAI platform are also becoming less and less important as web services standards begin to add the interoperability that was always missing.

Transferring value

EAI vendors may need to drop their prices for these newly commoditized functions, while moving their remaining value proposition into other areas. And they are first to admit it. "What customers are paying for are not just transport mechanisms," says Astor. "There a sizeable R&D investment which people who are too web services-centric often overlook."

They are therefore looking for new areas of value — often centered around business process management (BPM). Tibco points to a large European carrier which calculated it was losing around $100m per year through misplacing cargo. Multiple applications were involved and while each of these could be exposed as a web service, some overarching business process management was required — and this is where Tibco came in.

But EAI vendors are not the only sources of BPM skills, and many rivals in this field are smaller specialists with a leaner cost base. In the past, the complexity of high-end application integration has always discouraged customers from attempting their own solutions. Today, web services gives customers a new way of building integrations piecemeal from point to point, safe in the knowledge that, because they are standards-based and service-oriented, they will be reusable in future integrations. The greatest fear of EAI vendors in the web services world is quite simply that, in the end, their customers won't need them any more.

More on this topic