The ZapThink Web Services Roadmap: It’s Going to be a Bumpy Ride

Today’s Web Services story is all about integration. Enterprises are taking advantage of the open standards-based protocols underlying Web Services to integrate systems quickly and inexpensively, compared to the more complex, difficult technologies that are currently in widespread use. Several years from now, however, we at ZapThink envision a global environment of widely available, loosely coupled Web Services provided by Service-oriented architectures across multiple enterprises. However, this Web Service nirvana is by no means assured. There are many roadblocks in the way of Web Services adoption, and each one threatens to slow down or even stop the progress toward the global Service-oriented vision.

ZapThink’s roadmap to Web Services adoption–roadblocks and all–appears in the figure below. The top band illustrates the invocation style, or how companies will most commonly connect to Web Services. The first arrow represents the current environment, where companies use Web Services primarily for integration. Developers create static Web Services, either as stand-alone components or by wrapping some kind of existing functionality. Then they create a Web Service consumer that talks to the Web Service. Both sides of the conversation–Web Service and consumer–are static; that is, the developer fixes them when creating the system.

The second invocation style phases in around 2003-2004, as companies begin to take advantage of the dynamic description capabilities of Web Services. Developers still create Web Services as before, but now the consumers are able to query the Web Services in order to connect, or bind, to them dynamically at runtime. When developers follow this style, therefore, the Web Service consumers they create need not be aware of the Web Services they will connect to when the developer creates them.

The final arrow represents the full vision of dynamically described and discovered Web Services, when Web Services consumers both discover and bind to the Services at runtime. ZapThink calls this invocation style “Just-in-Time” or JIT integration. In this scenario, Web Service consumers look in a registry, find the Web Service they need, and bind to it, all at runtime. The developer who builds the Web Service doesn’t need any knowledge of the consumers that will connect to their Service, and likewise, the developer who writes the consumer doesn’t need to have any knowledge of the Web Services the consumer will invoke. The integration happens automatically as the software is running.

Primary Use of Web Services

Through 2003 and into 2004, ZapThink believes that companies will continue to use Web Services primarily for internal integration projects. The business story now is about reducing the cost of integration–a bottom line ROI approach that is appropriate during the recovery from an economic downturn.

Many companies will also begin to set up business-to-business (B2B) links with Web Services, primarily starting in 2003 (although there are some bold examples of B2B uses of Web Services today). By 2004-2005, the primary use of Web Services will be for B2B. B2B eCommerce got a bad name during the dot.com boom, both because the technology wasn’t ready and the business models were mostly irrational. Nevertheless, there is no question that there is enormous pent up demand for logical, inexpensive, flexible ways to conduct electronic business between companies.

As time goes on, software vendors will continue to embed Web Services in most of the software they create, so that by 2005, Web Services will essentially be taken for granted. Just as no one talks about “TCP/IP-enabled software” today, the same will happen with Web Services (as well as XML, by the way). Just as standard track gauges led to the golden age of the railroad, and standard alternating current ushered in the golden age of electrification, ZapThink believes that XML and the other Web Services standards will bring about a golden age for distributed computing.

Roadblocks to Web Services Adoption

So, now to discuss the roadblocks that threaten to impede the progress to our JIT integration/embedded Web Services vision for the future. The first bump on the road is security. There’s no question that security is extraordinarily important to companies today, and Web Services introduce new risks to the organization. Many companies are currently working on Web Services security solutions (as we covered in our recent report, XML and Web Services Security, available on our Web site). However, until companies perceive that there are suitable security products available, they will wait to implement B2B applications of Web Services, except in carefully controlled situations.

Right on the heels of security is management of Web Services. How does a company know their Services are running? Are they running smoothly, or are they overburdened? Who are using the Web Services, and for what? Are the Services providing the quality of service that they are supposed to? How does the company go about upgrading their Web Services? Enterprises will struggle with these and many other questions about their production Web Services environment. Fortunately, there are many companies working to solve these management issues, as well.

Transactions also form an important requirement for Web Services adoption. The traditional picture of a transaction, say, transferring money from checking to savings, does not represent the transactional picture that Web Services paints. The banking example is synchronous–that is, you click the “transfer” button on your bank’s Web site, the bank does its business, and returns a success message to you, while you wait. Web Services, however, can be both synchronous and asynchronous. Web Services transactions can be long-lived–some may take hours or days to complete. And the most complex transactions may involve more than two parties.

As the number of available Web Services increases, and Web Services become more important to the day-to-day functioning of the enterprise, it will become increasingly important to combine Web Services in particular sequences, a process known as orchestration. Companies orchestrate Web Services to facilitate ever more complex business processes.

In the 2004-2005 timeframe and beyond, some companies will be looking for billing and metering solutions for their Web Services. While we believe that many companies will find the best use for Web Services to be for enterprise business process applications, there will also be many business models built upon the concept of selling (renting? licensing?) Web Services.

The full vision of Web Services, then, operates in a “business web” environment–not just B2B between pairs of companies, but now among suppliers, partners, customers, and other participants. At this point, business process automation is at its most complex–and most promising.

The ZapThink Take

Just because we distributed the seven roadblocks over the next four years doesn’t mean that software vendors aren’t working on solutions for all of them today. In fact, vendors may resolve the technical issues behind each roadblock well in advance of substantial enterprise demand for the particular solutions.

As we see it, the roadblocks are as much business problems as technical ones. Just because a technology is available doesn’t mean that companies are going to go out and buy it. First, they must have three things: a clear business need for the technology, a budget, and a sense of urgency. However, conducting seamless, automated business with all of a companies’ suppliers, customers, and partners in a flexible, inexpensive fashion is a powerful business motivation for the adoption of Web Services. Therefore, we feel that it is only a matter of time until the road
to the adoption of Web Services becomes smooth.