Three Waves of Web Services Deployment
Industry analyst Forrester Research, Inc., expects three waves of deployment. The first wave will be "partner" Web services to help cement complex supply chains. This initial deployment phase, based on Web services-friendly standards like RosettaNet and ebXML, already has some support in cooperative transaction-oriented industries such as electronics. Our earlier example of a credit card authorization service is a very simple case of this, in which the bank is the Web site owner's "partner."

The next wave will be what Forrester calls "private" Web services. These will essentially use Web services protocols to extend internal enterprise application integration efforts. This will appeal especially to organizations that have complex internal structures, many packaged and custom applications, a wide geographical spread, and a high level of local autonomy for their operational and IT departments.

An informal Giga Group survey published in December 2001 stated that 60% of the respondents (120 IT executives attending Giga's "Emerging Technology Scene" conference in December 2001) saw Web services as a strategic component of their internal integration strategy, rather than specifically for interbusiness use. This approach is seen as more immediately useful; after all, the business can be sure that the service will be used and will lower risk. In a large retailer, for example, a bank-provided Web service for credit card authorization might interface with an internal credit card-processing application on the retailer's side.

Gartner sees Web services becoming "the dominant mode of deployment for new application solutions for Fortune 2000 companies" over the next couple of years. Gartner also believes that most large organizations will have mixed J2EE and .NET infrastructures, which will reinforce the need for Web services-based interoperability of these platforms.

Finally, all the analysts seem to agree that a third wave of deployment - the widespread use of "public" Web services and the full-blown adoption of the entire Web services stack, including registries and the automated discovery of services - will be delayed until standards are finalized. In the case of our example, we may want to choose a replacement bank with the lowest processing charges. We can do this by searching a UDDI registry to find an alternate service with the same WSDL specification, but only if the registrations include pricing, and only if the service interface is standardized. Otherwise, we end up having to recode our own application.

A Slow, But Steady, Adoption Curve
The low-level components of Web services - the plumbing, if you like - will make a useful contribution to interplatform interoperability as a lowest common denominator lingua franca. This will help to isolate business relationships (within and between companies) from technology decisions by providing a vendor- and architecture-neutral point of integration.

In particular, we can expect to see a Web services "skin" being used to cover platform-specific components such as J2EE Connector Architecture-based adaptors. This will meet the needs of internal application construction and integration as well as B2B projects.

Behind the Web services facade, we'll still see the same old applications, and developers will still have to deal with the age-old problems of application construction, application integration, and component reuse. Applications (whether designed to offer a Web service or constructed by aggregating a number of Web services) still need to offer the appropriate levels of reliability, availability, performance, scalability, and security. Under the counter, what may look to the outside world like a single Web service will actually require complex integration with existing enterprise applications. Developers will see the Web services interface as yet another feature to add to their EAI landscape.

Gradually, we can expect to see packaged applications delivered with predefined Web services interfaces. This will replace existing proprietary interfaces, such as SAP's RFC (Remote Function Call), or add standards-based functional interfaces where none existed before. EAI vendors will become more tightly focused on business process management, data mapping, and transformation - based on a general purpose J2EE- or .NET-based application server platform and Web services standards - rather than having to invest in different physical connectors for each application vendor.

At SpiritSoft, we don't really think large corporations are going to fall for the "discovery" aspect of Web services anytime soon. Would you want to conduct business with partners selected from the Web services equivalent of a Google search, without any human checking of the partner's reliability (or even existence)? Would you trust your entire business to an anonymous search engine? That seems to be one of the more extravagant premises on which UDDI is being promoted.

It seems more likely that industry communities, all with their own memberships, will develop rules and regulations. This may sound a lot like the trading hub model, which was somewhat deflated last year. In fact, the communities are more likely to gather under the wing of a dominant member (suppliers to a food retailer or car manufacturer, for example) or be policed by an existing industry body or consortium (RosettaNet, ebXML, Microsoft's Passport) that can add value and trust to the basic Web services framework.

Government will also be a strong market for Web services - national governments in particular will be able to mandate use and prescribe specific approaches to interoperability. Web services represent a more convenient interface for G2B (government-to-business) integration than either proprietary tools or manual interactions via HTML. Think of the possible reporting benefits for the IRS!

Most promising, Web services will be offered either to fulfill common point functionality requirements (like access control, wallet management, or credit card authorization) or to provide syndicated interactive content suitable for inclusion in a Web site. There will certainly be a competitive market for Web services - provided by your parcel service, your travel provider, your self-service HR department, and so on - that will be integrated into your corporate portal. Because Web services offers a very granular approach to application integration, it provides an attractive alternative to companies that want to outsource a few functions, but not an entire system. No CIO wants to be forced to outsource everything, and with Web services, he or she can control just how much is outsourced (or "insourced" to autonomous departments), and in what size application "chunks." Meanwhile, subsidiaries and departments will be able to mix and match their own Web service providers.

Conclusion
To answer the question most people have - "Will Web services be a hot trend in 2002?" - I make these predictions:

Forward-looking developers will welcome the ability to expose internal application components on the Internet or intranet. They will look for infrastructure vendors who provide open, standards-based technology components that can easily be slotted together so users are not locked into vendor-specific, proprietary frameworks. This will help to limit the cost of adopting the technology and will ensure that your architecture can be extended to meet new challenges as they arise.

Related Links