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 mindset 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 their 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 affect 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 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,” said 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.”
Streamlining development
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 services app. What has changed severely is the development,” said Roberto Torres, CTO and COO of CYDImex in Mexico City. Torres added 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 said, 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,” said Rob Perry, an analyst at The Yankee Group in Boston. Perry explained 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 per cent of instances at the most,” said 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 catalogues and material-safety data sheets to customer Web sites, said 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 said. “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 said.
Unexplored trails
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,” said Kathleen Quirk, an analyst at Hurwitz Group in Framingham, Mass.
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 per cent interoperable.
In the meantime, however, customers progressing with Web services put their infrastructures in jeopardy of becoming too proprietary, PwC’s Borges said. “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 said 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.”
