Web services: Report from the field
- By Johanna Ambrosio
The first flush of Web services is upon the IT world, and integration has proved
the first and foremost target. Customers are looking to Web services as a means
to help them finally integrate their diverse applications. Whether the applications
are off-the-shelf, heavily customized or totally homegrown, a Web services approach
Despite what vendors' hype might have us believe, many shops are starting small.
Instead of tackling the all-singing, all-dancing, cross-enterprise kinds of
applications, most are experimenting with using Web services in behind-the-firewall
kinds of projects, where they can control both ends of the equation.
And few of these initial forays qualify as mission-critical.
David Truog, a principal analyst at Forrester Research Inc. in Cambridge, Mass.,
said that in the near to medium term, ''the primary application of Web services
is going to be integration. Web services introduce a layer of industry-wide
agreement on how the applications will interconnect and integrate.'' He
predicts a reduction in the cost of integration as a result -- and a larger
pool of specialists to help implement all this technology. Truog also said that
major application vendors like SAP and PeopleSoft will be bringing out Web services
interfaces to their own software, mostly based on Simple Object Access Protocol
(SOAP), in the next year.
Tyler McDaniel, application strategies director at the Framingham, Mass.-based
Hurwitz Group said that a new study done by his firm confirms the Web-services-as-integration-strategy
trend. Based on a survey of more than 300 IT buyers contacted in February 2002,
almost half said their initial Web services projects would be about internal
integration, while about a quarter of respondents pegged external integration
as their primary focus.
About 10% of companies said they were just about finished with this first project,
while another 20% said they would be done in six months; the same number said
they would be done in about a year. So almost 150 of the 300 respondents said
their first Web services-based application would be done by March 2003.
''I was surprised at how quickly companies are adopting Web services for
integration,'' McDaniel said. ''It's happening faster than I expected.''
Key drivers are the low cost of adopting basic Web services toolkits and the
soft economy, which is placing more value than ever on integrating existing
infrastructure rather than going out and buying more, he explained.
Also, McDaniel said Web services are not all ''that complex compared to
other integration technologies. Most developers can pick this up very quickly
-- wrap components, expose them and then use SOAP calls to connect them. It doesn't
require a big leap [from today's technology] to use these successfully.''
What the users say
Some customers confirm this sentiment, while others say they have run into problems
in the darnedest places. David Park, senior vice president of business and technical
solutions at First-Citizens Bank & Trust in Raleigh, N.C., said that Web
services are 'one piece of our overall strategy.' The Web services
approach is the bank's 'preferred' method of putting a browser-based
front end on many of its legacy mainframe applications, Park explained.
One technical bugaboo they have run into is, of all things, regarding the bank's
standard desktop PC configuration. 'We've locked down our desktops -- we're
using Windows 2000 -- so we can truly control what users can do and so they
can only customize what is safe to customize,' Park said. But the problem
is that Web services require applets to run, and the 'lockdown interferes
with the ability to run any applet any way you want.' So they are currently
using Tivoli's software distribution method to get plug-ins down to workstations.
Still and all, Park is a huge fan of the Web services approach. 'The beauty
is that it's a centralized model, but with the ability to distribute in a decentralized
fashion,' he said. It seems like a combination of the centralized control
of the mainframe, but with a client/server look and feel, he added.
Web services will not become the integration layer at First-Citizens because
the bank has already developed a complex middleware system, called Service Manager,
based on IBM's MQSeries to do that. But Web services will ''fit on top of
the middleware layer, and they'll invoke the Service Manager functions or services,''
One customer who will be experimenting with Web services-based integration
is American Electric Power Company Inc. in Columbus, Ohio. ''We're starting
to do some thinking about it, and we're generating a project to help us understand
Web services and how they can be used here,'' said Ken Foster, manager of
software technology. ''One of the great ways to use them is for integration.''
On tap at the utility will be a project to pull data out of its PeopleSoft
human resources system and turn that information into Web services so that it
is accessible from multiple applications, Foster said.
One of the challenges he faces is trying to avoid vendor lock-in. ''Whatever
I do, I have to do it across all my platforms -- IBM, Sun and HP Unix, IBM mainframes
and lots of Windows 2000 servers,'' Foster said.
He also has to ''develop competencies internally to learn how to do this
-- how to integrate dissimilar software. There's a whole bunch of different
ways to approach this, and we need to learn more,'' he explained.
Indeed, many people are looking at Web services as the next generation of enterprise
application integration (EAI), or even application integration frameworks, which
are just now starting to catch on in some large shops. But while EAI is a way
of connecting one specific piece of software to another specific piece of software,
Web services' allure is that it offers a standardized approach to connect all
Prasad Raje, CEO at Instantis Inc., Sunnyvale, Calif., talked about two types
of Web services integration. One is data delivery -- to grab a customer account
number that can be shared by different applications.
The second, more complex type is what Raje called ''runtime invocation''
integration -- where one Web service combines with others and the results change
depending on the data at hand. One example of this is a credit lookup. Say,
for example, that a customer places an order via a Web site. Before the order
is completed, the system sends out a request to a database, which is essentially
a Web service, that checks in with another database at the credit card issuer
to make sure the credit card is not stolen or maxed out. These are various services
combining to make yet a third, which issues a response to the original Web site.
At the moment, virtually all of Instantis' customers are in the first camp,
Raje said -- using Web services to share data, not to share the underlying logic
of an application. Instantis sells SiteWand, a software-based method that promises
to transform business processes into Web-based applications.
Forrester's Truog said there are three types of tasks that most appropriately
lend themselves to being Web services, and suggests asking the following questions
before deciding whether to use Web services:
Is it done frequently? Checking inventory level is done almost
all the time, while introducing a new product or service is done much more rarely.
Is it dynamic? If the information behind the service changes
frequently, like a price, then it probably is worth turning into a Web service.
Is it something for which you already have a connection? If
you already have an integration piece set up, there is probably no need to redo
it as a Web service, Truog said. 'Let's not go crazy; if you have a link
with technology that works, leave it there.'
Eric Austvold, research director at AMR Research Inc. in Boston, said customers
have some infrastructure work to do before Web services can catch on as integration
''It's a chicken-and-egg problem; you need to have a Web service to use
one. Who creates the first one? You have to have two applications that want
to share information and each application has to expose that as a Web service.
You need the infrastructure to create and share that.''
Then, once the initial service is created, ''who will use it?'' he
asked. It is a situation akin to the first telephone -- until enough people
had them, there was no need to use them.
Still, Austvold agrees that Web services will eventually become very useful
for integration. 'Today we're dealing with hand-coded, point-to-point interfaces
for SAP to Oracle, SAP to PeopleSoft and so on. When you upgrade any of your
software, all bets are off -- that creates a massive retesting problem'
that continues to grow exponentially over time.
With ERP software at about 70% worldwide penetration, supply-chain software
at about 40% and CRM at about 30%, customers are just starting to realize the
extent of their integration woes, Austvold said. Connecting one piece of software
to another is 'not such a big deal' -- but trying to get them all
to play nicely together can be a nightmare.
One of the trends that will help customers make maximum use of Web services
as integration technology is that the traditional middleware vendors are heading
in this direction. WRQ Inc., a Seattle-based leader in the middleware space,
was set to announce Web services interfaces for its wares by the end of April,
said Mike New, the vendor's director of integration strategy.
''The easy part is the standardized interfaces -- UDDI, SOAP, WSDL. That's
fairly trivial,'' New said. ''What's hard is the service part -- providing
some sort of useful business function abstracted enough so that you don't have
to know how the underlying systems work.''
New said that ''in our customer base there have been lots of questions,
but not a single customer has asked to begin implementing Web services yet.''
He does agree that there is a 'tremendous amount of experimenting beginning
Similarly, IBM and Tibco are said to be working on their own Web services connections
for their respective middleware products.
That said, Web services will not cure all integration ills, experts warn. ''Sometimes
you need tightly coupled integration,'' said Hurwitz Group's McDaniel. ''Sometimes
you need to do data transformation to make sure you're transmitting the right
data. Just exposing the interface as a Web service doesn't give you a sense
of the underlying application semantics that you're working with.''
When deciding whether to integrate applications via Web services, McDaniel
suggests thinking about performance, granularity, how big a piece of functionality
you would need to expose as a service, and whether the information or function
is really needed in multiple applications. Most observers say Web services do
not yet lend themselves to huge, transaction-based systems because there is
some delay associated with Web services making requests, particularly across
That performance issue, in fact, is why HSN Inc. opted out of turning the search
engine on its retail-oriented Web site -- HSN.com -- into a Web service, which
was their original plan. The firm, formerly called Home Shopping Network, is
based in St. Petersburg, Fla.
''We did some very early prototype work with the first releases of .NET
to try to figure out this technology and get us familiar with its many pieces,''
explained Gerard Johnson, director of technology at HSN.
The company had originally targeted the site's search engine as an ideal first
project for a Web service, because -- although it is an 'integral'
part of the site -- it is also independent enough so that any changes to it would
not ''translate into ripping out a bunch of code,'' Johnson explained.
But once that decision was made, it 'soon became apparent' that the
Web services approach would not fly, Johnson said. The search engine handles
more than 200,000 requests every day -- and that volume goes up significantly
during the holiday season.
''We just wanted performance,'' Johnson said. ''And as we understood
Web services, its real strength is in the interoperability area, not in the
Although HSN Inc. is a committed -- and very happy -- customer of Microsoft's
.NET environment for application development overall, Web services are not on
the horizon anytime soon, added Stan Antonuk, vice president of technology at
HSN. Perhaps in the next couple of years, as the company gets more into syndicated
commerce, it might make its product descriptions and other pieces of its database
available to off-site partners.
At that point, Web services would be a good fit, Antonuk explained.
When all is said and done, right now customers seem to be looking at Web services
to help replace older integration technology as they have the need to do so.
'RPC is fairly ancient,' said American Electric's Foster. 'I
knew something would have to come along and replace it.'
Not that traditional EAI as we know it will go away anytime soon. ''Let's
not fool ourselves into thinking that Web services are the answer for everything,''
said Hurwitz's McDaniel.
''They do solve some problems, in that they help us more closely align
with business requirements. And if infrastructure software is about anything,
it's about getting IT and business more closely in sync with each other,''
For more information, please see the following related articles:
'Starting with Web services'
and 'Explaining Java and Web