Web services hold the potential to change many things about software, not the least of which is how it is developed.
Despite vendors' claims that Web services are more evolutionary than revolutionary, experts agree that the emerging programming paradigm requires a new mind-set from both the technological and business perspectives.
In addition to creating a need for developers to learn how to use new tools -- be it the new C# or Web services-enabled versions of current languages -- Web services by nature are changing the way applications are built. Instead of traditional, monolithic stovepipe applications, developers must consider how to build more modular components, how to share data across otherwise disparate sources, and ultimately, how to create applications out of those components and data sources. Furthermore, Web services are forcing programmers to consider how the application path they take can have an impact on the business.
The big change that Web services bring, however, is that interoperability becomes a critical aspect that programmers plan for in the design stage rather than as a mere afterthought.
"In the short term, Web services are just another tool -- like Java or COM [Component Object Model] -- in the programmer's toolbox," says Frank Gillett, an analyst at Forrester Research Inc. in Cambridge, Mass. "But in the longer term, people will start thinking from the Web services interfaces in, rather than building from the code out, which is how people do it today. Developers will have to think about the publishing and consuming of Web services from the beginning."
Aside from learning new technologies such as how to implement Web services protocols such as SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery, and Integration), and WSDL (Web Services Description Language) in applications, developers also need to consider how Web services applications will scale.
"Analysis and design hasn't changed much when you develop a Web service app. What has changed severely is the development," says Roberto Torres, CTO and COO of CYDImex in Mexico City. Torres adds that a few years ago developers built systems knowing that a specific number of users would access them; but with Web services' capability of opening systems more smoothly, it is difficult to know exactly how many users will access the software.
Developers also need to plan well for interoperability when building Web services applications, deciding where and when to use Web services instead of, or in combination with, existing EAI (enterprise application integration) or EDI (electronic data interchange) solutions.
The Colorado Department of Agriculture (CDA), for instance, built a Web services architecture based on .Net to make several data sources interoperable with a data warehouse. Data is pulled into the warehouse using SOAP and XML and then is made available through a browser interface or is delivered with Crystal Reports, according to John Picanso, CIO of the CDA in Lakewood, Colo. The resulting Web service and improved information access helps employees better track and manage chronic wasting disease among the state's elk and deer population.
"Web services require more tooling from our developers. It's perhaps a longer process now, but in time it will significantly improve application development," Picanso says, noting that as the CDA gets more practice with Web services, the application-development cycle will shorten.
Indeed, experts say one of the areas where Web services will make application development more efficient is in the reuse of components or entire Web services.
"Web services are reusable by definition. The question then becomes whether they do something people want to be able to reuse," says Rob Perry, an analyst at The Yankee Group in Boston. Perry explains that with Web services reusability extends itself to other areas such as connectors and integration services.
But reuse is not appropriate for all components. "Reuse will come in handy but only in about 40 percent of instances at the most," says Bernhard Borges, managing director of the advanced technology group at PricewaterhouseCoopers (PwC) in New York. "The rest of the situations require too much customization."
Web services require highly componentized applications, so developers need to build those components with reusability in mind. Building Web services components also enables companies to share those services internally and with business partners. Eastman Chemical, for example, is creating a Web services architecture to expose application code and content such as technical catalogs and material-safety data sheets to customer Web sites, says Bill Graham, integration systems solutions manager at the Kingsport, Tenn.-based company.
"Content and services can be exposed from our site and be branded by partners, so it looks to visitors like they are on the customer's site," Graham says. "For exposing our content as a Web service, we're doing the heavy lifting. For the consumer of the Web service, it's more like pointing a network toward a URL."
Graham notes that to achieve its goals, the biggest challenges Eastman has to handle are connecting the various data sources and maintaining security. "We think Web services has a way to go yet," he says.
A fork in the business road
In Eastman's case, embracing Web services allowed the company to leverage its existing infrastructure, but not everyone has found enabling legacy systems for Web services to be as easy as vendors claim.
"We've taken our legacy systems and have thrown them out the window because there was no way we were ever going to integrate them all," says Herman Baumann, executive director of strategic development at the American Hospital Association (AHA) in Chicago. "It would have been a Herculean task to cobble those together, so we decided to start from scratch."
Baumann says that during the process of developing a Web service, which required making data sources from 18 affiliate organizations' various systems available, the biggest stumbling blocks were agreeing on XML definitions, choosing which integration method to use for each particular situation, and getting the different organizations to work together in creating a common hardware and software platform.
"When you're building your strategy around the user, it changes the business imperatives," Baumann explains. "This world of Web services really is not about the technology itself, it's about business. The business issues are so much at play that they are really more important than the technology."
Experts and users agree that the mind-set shift necessary to develop, deploy, and use Web services is at least as significant from a business perspective as it is from an application-development perspective.
"Everybody says Web services is a technology adjustment, but even if the technology didn't move forward today it would still take a long time for business to catch up," says Colin Karsten, e-business manager at Pratt & Whiney (P&W), an airplane engine manufacturer in East Hartford, Conn.
Karsten identifies his biggest hurdle with Web services as figuring out how to get employees, customers, partners, and suppliers to buy into the concept. But by creating Web services, P&W gives those same partners better access to its data, so the benefits are tangible once they're on board.
"Web services enabled us to change the business nature of applications, making them more efficient -- but only when planned properly," Karsten adds. "We have been able to make the data that users want available to them in a custom way rather than forcing every user to learn to be a power-user of our particular homegrown database."
Still, Web services won't solve every application development problem, and they are not without risk. "In a way, Web services is a whole new model. Sometimes it's appropriate for an application to use Web services, and sometimes it's not," says Kathleen Quirk, an analyst at Hurwitz Group in Framingham, Mass.
AHA's Baumann, for instance, says that when choosing how to integrate systems across organizations his team looked at what it needed to accomplish from a business perspective and weighed the resources it had and the cost of new resources.
"In some cases, what makes the most sense is what your IT staff is trained in and comfortable with," Baumann explains.
Furthermore, there are a number of unresolved issues around Web services, namely security, transactional integrity, management, provisioning, and trust. Companies such as Microsoft, IBM, Sun, and BEA are driving technology to solve these problems, in most cases with hopes of standardizing the technology with an independent organization such as the World Wide Web Consortium, but this work is still in a very early stage.
Analysts are predicting that these issues will start to be addressed in a standard way beginning in 2003 and continuing at least through 2005. For developers, a big question remains the possibility of vendor lock-in: Implementations of various Web services protocols such as SOAP are not yet 100 percent interoperable.
In the meantime, however, customers progressing with Web services put their infrastructures in jeopardy of becoming too proprietary, PwC's Borges says. "While the standards are still evolving, you're exposing yourself [to the risk of developing systems that are too proprietary], and you may have to make a significant reinvestment to correct the problems," he adds.
For now, P&W's Karsten says that Web services add an unknown element to the future of applications: "We've just scratched the surface. I don't think anyone understands where this will really go."