In-Depth

Web services: Report from the field

• By Johanna Ambrosio
• June 3, 2002

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 can help.

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,'' Park said.

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 software, eventually.

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.

What works
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 tools.

''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 to occur.

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 multiple networks.

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 performance area.''

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,'' he concluded.

For more information, please see the following related articles:
'Starting with Web services' and 'Explaining Java and Web services '