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.
MORE ON THIS TOPIC
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.
See EMC Customer Focus magazine
