Have Web Services, Will Travel

Before adding Web services to your arsenal, make sure you understand their potential pitfalls

If you develop enterprise applications, you've probably heard of Web services. They sometimes go by other names, such as Internet services or e-services, but the fundamental concept is the same - accessing software services through a TCP/IP network and linking services together to build business applications.

The level of hoopla about Web services has been rising steadily. As this hype becomes more widespread, application developers will naturally experience some confusion: What are Web services, really? Are they merely a repackaging of the distributed applications scenario? Yes. Is that all there is to it? No. How seriously should you take Web services - are they real? Do bears live in the woods? Let me try to tackle the confusion.

Web Services' Many Faces

Part of the problem is that even at this early stage, Web services have more faces than Fu Manchu. Obviously end users will learn about Web services in terms of things they can get on their computers or handhelds, for example sport scores on an hourly basis or connection to a hosted Internet version of Microsoft Word. The developer who builds these services will, of course, describe them quite differently. They'll be objects or components built with Java or C# that conform to certain Internet standards and so forth.

Web services also will have different meanings for three primary groups of users: consumers, service providers (including application software providers [ASPs], Internet service providers, independent software vendors [ISVs], and managed service providers [MSP]), and corporate application developers. Inevitably, companies involved with Web services will define them in their own way. The term Web services will be a messy catchall phrase.

Another part of the confusion is that Web services are derived from similar, well-known approaches. Programmers are familiar with objects and components for distributed applications (CORBA, Enterprise JavaBeans, DCOM, or even ActiveX). ASPs and others have been hosting software for rental for a number of years. Integrators and application developers have been looking for ways to cobble together prebuilt pieces of software into complex applications for a long time. Most of the commercial application development products, such as Borland JBuilder and IBM Visual Age, have been providing frameworks and components. Likewise, makers of middle-tier products such as application servers have been laying down the infrastructure that could just as easily have been labeled Web services as distributed applications.

Different From Before

So what is the big deal about Web services? What's different about them? From the developer's perspective, I think two factors will distinguish Web services from what has preceded them: granularity and Internet-based standards.

Object-oriented programmers should know about granularity. You have to decide how much (or how little) functionality goes into an object (or component). Some components, such as for communications, might be very large and do many things, whereas others, such as a calendar component, perform only one specific function. So far, when ASPs describe hosted software, it's almost always in terms of very large applications (Web apps) and specific large components. Web services will tend toward smaller parts. The whole idea is to entice the user into renting or leasing functionality in relatively small doses. From a user's point of view, theoretically you can get a better deal by renting only the features and functionality that you actually need or can use. For application developers and integrators, a wider choice of smaller, targeted components will be available.

The most important factor, by far, is that Web services will comply with Internet standards. These are different - singly or in combination - from standards of the past. The key standards (so far) are universal description, discovery, and integration (UDDI) for describing and locating services, XML and its many subprotocols for handling data in a uniform way, simple object access protocol (SOAP) for defining the interface and how to use the services, HTML and variants, and finally and least certain, "standard" Web services description language (WSDL).

Obviously, for Web services to become a reality, these standards must be incorporated or retrofitted into a lot of software - an awesome task. And if the industry goes down this road (as some are proposing), no ISV, IT shop, or programmer will go untouched. Yes, yet another dreaded "paradigm shift."

Who Will Benefit

At this point, the quiet guy in the back row gets up, raises his hand and asks, "Why bother?" The list of benefits is long, but a lot depends on whom you ask. Certainly ASPs and ISVs might have a bonanza. Instead of depending on the messy, demanding, and relatively infrequent upgrades of software to generate revenue, they get a nice revenue stream from people renting pieces of their programming. Service and maintenance of the software remains on the companies' own servers, largely cutting out the insanity of end-user hardware. Perhaps best of all, the company gets to repackage products in ways that can ferret out users that keep coming back for many small, regular sips at the well.

For in-house developers, the ISV scenario has less appeal (unless your company is into back-billing for services). However, Web services promise IT shops (yet again) the ability to build complex applications much more quickly and reliably than ever before. All the big software companies are giving Web Services a bear hug: IBM, Oracle, Hewlett-Packard, Sun Microsystems, and Microsoft have voiced plans to make Web Services a reality within their systems.

The thrust of Microsoft's massive .Net initiative is Web services. Microsoft has already begun releasing the products that will produce, manage, and deliver the services, including a line of server products such as Windows 2000 Data Center, Microsoft Exchange 2000, Microsoft SQL Server 2000, Microsoft BizTalk Server 2000, and Microsoft Commerce Server 2000.

For developers, Microsoft plans to release Visual Studio .Net later this year, which provides the language tools necessary to develop Web services. Over the next several years, Microsoft plans to flesh out Framework .Net, Office .Net, and Windows .Net. If nothing else, .Net is ambitious, but then Microsoft has often been criticized for not taking leadership in software trends. This time, the company is betting just about everything on the viability of Web services, even though we're years away from the full realization.

Does all this high-powered support for Web services mean the end of applications as we know them? Certainly not - at least not in the short term and quite possibly never. So far, no single approach to software covers all possible situations and Web services will be no different. Which brings me to the caveats (truth in packaging) about Web services.

Seller Beware

The overwhelming success of selling software as services over the Internet is not guaranteed. In fact, many people already don't like it, including consumers who say they don't want to pay "no stinkin' rental fees," be at the mercy of their Internet connection, or be at the mercy of megaliths like Microsoft, IBM, or Oracle. At a personal level, some corporations will feel this way, too. Some very concerted marketing efforts will be necessary to sell Web services.

One aspect of Web services that doesn't get much play is how to pay for them. Other than lip service to a "need for a viable business model," one of the trickiest aspects of renting or leasing anything is the ability to establish a working contract and payment arrangement. Given the wide range of configurations for Web services, this necessity is going to be a problem. It's a good bet that security will also be a problem.

Rate This Article Rating: 1 (best) 2 3 4 5 (worst) Comments: Optional e-mail address:

Perhaps the most worrisome difficulty is that the crucial standards aren't yet standard. They're de facto standards, which sometimes is better than official standards because the big and mighty use them and everybody falls in step. On the other hand, no official standard leaves plenty of room for splinter standards, merciless infighting, and ultimate Balkanization of protocols so that only small segments of services can actually work together. At the moment, the major players in Web services have some unanimity; this has got to hold.

The concepts are old, but Web services are a different animal from the ones we've had before. Application developers must begin considering the arduous learning curve of XML, UDDI, HTML, SOAP, and probably an appropriate programming language. IT shops need to look at all the enterprise applications and begin doing the mental gymnastics that turn them into Web services (or not). If things go as most of the commercial software industry seems to think, we'll be entering a Web services world within the next five years. This world is supposed to be connected, interoperable, feature-rich, and cost effective. Let's hope so.

NELSON KING [nelsonking@earthlink.net] has written nine books on database application programming and spends much of his time in the trenches of enterprise software development.

Resources

Microsoft .Net

UDDI

WSDL

Related Articles on IntelligentEnterprise.com:

"The Road to the Future of Web Services," May 7, 2001