Enterprise application integration (EAI) and Web services technologies solve integration problems in different
ways. Find out how these two technologies differ and how to determine the right approach to your integration problem.
Integration is an age-old problem for IT, probably going back to when the second application was installed in the first computer shop. Indeed the more information that is produced, the more complex the issues of integration become.
The essential questions are what needs to be shared or accessed, and by whom, and where the end-users or systems are located -- within or outside of the company.
Over time, different approaches have emerged -- data adapters, message brokering and other types of middleware, and others. These different technologies have collectively become known as enterprise application integration (EAI).
Enter Web services. These basically use object-oriented technology to "wrap" data and programming elements to be accessed by different Web-based applications. The typical example is a price-lookup request by a customer. Using Web services like Simple Object Access Protocol (SOAP), the browser can check out prices at different SOAP-based sites and then deliver a price comparison to the customer.
The system provides the service behind the scenes by invoking different behavior and information from the various target systems. SOAP and other Web services make use of remote procedure calls and other so-called legacy technology. SOAP is also based on XML.
One essential difference between Web services and earlier EAI efforts is this: Web services provide a standardized means of dealing with integration, where EAI has traditionally been driven by one or two vendors or is product-specific. In other words, a software bridge of sorts may exist to connect a PeopleSoft human-resources package to SAP's R/3 system, but that same EAI bridge won't work for other human-resources packages trying to connect to SAP.
On the other hand, SOAP, for one, is a standard backed by the World Wide Web Consortium. Also, where Web services are meant from the get-go to be used in a distributed fashion, that's not always the case with EAI technologies.
But Web services don't come cheaply. Legacy data or information has to be "wrapped" to become a Web service, which can require a fair bit of custom programming work. And Web services don't yet have a lot of infrastructure around them because they're still pretty new, says Beth Gold-Bernstein, a vice president at ebizQ, an integration consultancy and portal in White Plains, N.Y.
"Web services don't yet have that level of maturity around them, especially for things like business-process management," she explains. Although EAI is more proprietary, she contends that as an overall technology it's "more functional" because it's been around longer. She concedes that it is rapidly changing, but believes that EAI and Web services will co-exist "for quite some time."
David Linthicum, chief technology officer at Mercator Software Inc. in Reston, Va., breaks the integration problem down to two major types of approaches. The first is exchanging simple data between systems, such as when one application pulls a customer name or ID number from another application. This is where traditional EAI technologies have performed -- translating and moving data from one type of software to another.
The second level is integrating applications on a service level. The latter is what Web services do -- they essentially create a composite application out of many applications, Linthicum explains. In this scenario, "you're invoking behavior, not just moving information," he says.
A big danger is applying the wrong approach to the problem, Linthicum says. "Web services may be overused. Probably only about 20% of integration projects need service-level integration." The rest are straight data exchanges.
It's critical to keep in mind that integration "is a very complex thing, and you need different types of technologies to solve different problems. Web services is one part of the suite; it serves a purpose but it's not the only way to do application integration," Linthicum says. Customers need to beware of vendor hype, he suggests.
Overall, Charles Goldfarb, the creator of XML technology and co-author of "The XML Handbook," says that Web services and traditional EAI are different points on the same integration continuum. He explains that EAI approaches are often specific, more tightly-coupled, solutions, where Web services is a more generalized, loosely-coupled approach to an integration problem. The trade-offs are similar to those in other aspects of system design.
"Specialized solutions require more original development and maintenance, whereas a generalized solution tends to be less efficient in execution," he says. "You're trading the overall resource drain on the organization -- the resources needed for developing the specific solution -- for a resource drain on a computer that may not run as efficiently." The best approach to take, he says, depends on the individual situation.
"If the volumes are high, and the job is well-defined, then it may pay to optimize the runtime" by creating a tightly-coupled customized solution, Goldfarb suggests. But if flexibility is required "in a world where, day to day and hour to hour, what you're doing and who you're doing it with can change," then the Web services approach may be more beneficial.
Visit searchWebServices for more information on Web services.
SPONSORED BY: EMC
EMC CLARiiON and AutoIS: Solutions for leaving the competition behind
See how these EMC customers are using EMC CLARiiON to take advantage of new business opportunities and change direction fast -- and affordably. Learn about AutoIS -- EMC's answer to open storage management and the new products and technologies that enable you to automate storage across multivendor environments.