What do you, the potential Web service provider, really want to get out of having published a Web service? A pat on the back? Notoriety? Fame and fortune? Garnering these elusive prizes from the available tools and platforms on the market today is difficult. But how about just a steady revenue stream and a loyal customer base? Let's take a look at how you can steer clear of the current roadblocks, so down the road you can implement a successful Web service offering.

Yielding to the Pedestrian
Have you looked for a Web service to use lately? If you have, chances are you've visited one of the public UDDI registries or maybe a Web services portal, such as xmethods.com or SalCentral. And if you've visited any of these places expecting to be blown away by the novel, innovative or just plain useful Web services they index, then you've probably been disappointed.

What you found was most likely a bunch of temperature and currency converters, simple addition widgets, and maybe a flight tracker. Where are the Web services that will change the face of computing, rewrite the history of the Internet, or at least live up to the Web services hype? Sorry folks, it's not there yet -- which is not a knock on the aforementioned Web service indexes. It's simply an observation that the maturity level of the publicly available Web service offerings is, well, premature. At the present, there are only a few that are truly helpful, but you have to look carefully to find them.

So, what gives? Why are the "Web services" out there mostly toys and experiments? For one thing, the standards involved are only beginning to firm up.

Several interoperability issues still surface when it comes to SOAP implementations, and the same is true of WSDL. And both the UDDI specification and implementations have a long way to go before they really make life easier for Web service providers and users.

In addition, the technology has only really been in front of developers for a few months and people have only just begun to think about what kind of services might actually catch on for users. Most of the Web services you find available now have the look of first attempts at getting "something" working...they're not even intended to be serious services.

Both of these explanations for the lackluster offerings are fairly obvious to anyone who has been scoping around Web services. But the real deep-seated block that keeps developers and strategists from taking Web services planning to the next level is beginning to reveal itself.

The Real Culprit
There are serious shortcomings in today's first-generation Web services platforms. In fact, it's difficult to justify a Web service. No one seems to know how it might be beneficial to the provider or how it might be useful to the consumer.

Why Are We Here?
What kind of a weighty question is that? Especially in a light technical piece. What I really want to know is, "Why are we talking about Web services in the first place?" Why are so many people interested in finding out how to publish Web services and make them available to users?

Tell Me What's Happening
According to the buzz you hear in conversation, the current theory has to do with the age-old arguments for code (read service) reuse, componentization, interoperability, etc. These arguments totally miss the point of Web services, though. Some claim they want to make these useful services free because it's just a good idea and a cool thing to do for consumers. They usually have the same motives as the open-source camp. And while it's a perfectly valid stance, this claim doesn't ring true on the gut level.

Many people have told me they're interested in exposing functionality from legacy systems out to the World Wide Web and modern types of client programs. That's great, but the question still remains: "Why?"

Why would a company want to spend all that time and effort in creating a Web service for the world to use, free?

As former President Bill Clinton said in 1992, "It's the economy, stupid."

Any company devoting the energy to Web services had better think of how the bottom line gets a boost from this deal. The great thing about exposing an electronic asset (whether legacy or newly developed) to the public as a Web service is that it's a low-cost channel to a new revenue stream - a revenue stream with no hard limits on growth. Making a buck off a valuable service should be the key consideration of any corporate provider. So, what does it take to provide a successful, commercial Web service offering?

Show Me the Money
Cutting to the chase, if you want to make money from a Web service, you need to, first and foremost, figure out who's using your service. You might, in fact, want consumers to request permission before using your service or developers to notify you before embedding your offering within another Web service. Once you know who's using your service, you know where the revenue has to come from.

The next question you need to ask is how much value will users derive from your service. You can figure this any way you like, but at the very least you'll want to know when and how often particular users invoke your service, and whether requests are successfully handled. It's crucial for generating bills and billing strategies to keep track of your customers' usage statistics and patterns. A side benefit of collecting usage information is the enormous value these statistics bring to the process of planning for the future growth of your service.

Almost There But Not Quite
User identification and usage accounting get you 80% of the way to a profitable Web service. But there are a few other considerations that come into play that are fairly important in pulling together a financially successful service. The first thing is quality of service.

You could have a tremendously useful service deployed with a happy, loyal group of customers, but if these customers start to notice consistently slow service or availability problems they're going to drop you like a bad transmission. This is also true if your service returns bogus responses more than once or twice. To present a high-quality Web service, you need to constantly monitor the health of your service in terms of its ability to work through the incoming requests in a timely fashion, the validity of your service's responses, and the availability of your service to the outside world.

And, of course, some living, breathing person in your organization must be notified if things aren't performing up to expectations.

Speaking of the customer experience, let's shift the focus to the developers who will be embedding your service. What happens to them when you're ready to upgrade your Web service? If you change function signatures or add new features, these developers' applications will suddenly be out of date. If you have to take the machine on which your service is hosted offline for maintenance, what happens to all the third-party applications that use your service?

Keep in mind that these events are natural occurrences in the life cycle of any Web service. You need to have some kind of life cycle management support in place to deal with issues of migration, downtime, and upgrades gracefully. Useful error messages, forwarders, notifications of change, and provisioning of documentation about migration paths can keep developers and other users in the loop on the evolution of your service. Lack of care with these eventualities can create a perceived problem with quality of service - causing users to look elsewhere for fulfillment of needed services.

User recognition and tracking, quality of service, and life cycle management are a few areas you can concentrate on to greatly improve your chances of financial success for your Web service. The more you know about your users, the more reliably you fulfill their needs - and the less you irritate them, the better off you'll be.

What are examples of Web services that have these qualities?

'We Have a Problem...'
However good all that sounds, the unfortunate facts of life are that few Web services platforms actually support any of these features, and no platform supports them all. This means that when you develop your service you either implement many of these extras or ignore them.

To achieve the kind of Web services addressed, you can't do the latter. Without user recognition and usage tracking, you have no idea whom to bill or for how much. Without some kind of service monitoring and emergency alerts, your users may be denied service unexpectedly. And without a solid system for managing changes, developers who rely on your Web service can have the rug yanked out from under them.

But is it really feasible to implement the necessary infrastructure for all of this any time you want to deploy a Web service? It's true that enterprise providers may already have user databases and change management systems in place, but what kind of effort is involved with bridging these systems into the Web services space? How much work does it take to integrate an enterprise-scale, back-end security system with the average Web services platform? In short, what does it cost to provide the necessary modal features to your Web service to ensure its success?

The scenario in which all of these modalities must be fully implemented by the provider may turn out to be more costly than the perceived ROI, especially in the short term. Potential providers will take a dim view of exposing Web services if it means devoting too much development effort to ensuring a quality product on top of a financial return.

So if there is functionality lacking in Web services platforms that's also too costly or too inconvenient to develop in-house, how will you get that Web service published as a quality offering that can make you money? Luckily, a solution is staring you in the face...

New Levels of Flexibility
Architecturally speaking, the Web services style of distributed computing provides new levels of flexibility. Partitioning of subsystems and assignment of responsibilities take on a whole new meaning when you consider that specific modal features, or even entire subsystems, could be hosted at another site or outsourced altogether. Web services solutions have the option of taking advantage of other Web services to help get the job done. In other words, your Web service can easily invoke any number of other Web services in the course of fulfilling a request made of it. And this relates directly to your production of a successful Web service.

Doing Only What It's Good At
All of the things addressed so far as important aspects of Web services deployment and still lacking from existing platforms can be (and in at least one case are being) implemented in terms of other Web services. Imagine a small set of Web services, each designed for a specific, narrow purpose. In this type of world, your service should be designed the same way. Each service does only what it's good at and what it's designed for - and outsources the rest of the work. Your service provides just the value it extracts from your legacy system or derives from your business processes, and leaves the rest of the modal concerns to other, better-suited services available in other departments or other companies.

Web services are more than just simple components with SOAP interfaces. The term Web service applies to the sum of all of a service's functions, modalities, levels of service, and terms of use. In a scenario such as this, I wouldn't refer to your original component as the Web service but rather as the published, publicly available facade to your service. The full cast of helper services constitutes the actual Web service.

A Digital-Signature Scenario
You want to offer a service that provides digital signatures for submitted content and stores hashes for inspection much later in case there's some doubt about the validity of the signature. To get this service up and running, you have plenty of development tasks already. You opt to outsource the user tracking and life cycle management services. Using this scheme, here is a high-level view of the typical end-to-end request:

• A new user makes a one-time visit to the preferred authorization service to request credentials and gain access to your service.
• The user invokes the authorize() method of the Web service facade, presenting credentials.
• The Web service in turn invokes the authorization service, validating the user, returning a time-boxed authorization key.
• The key is presented by the user when a function is invoked and used to both identify and track the user.
• When activity is tracked, notifications are sent to the usage auditing service.
• At some point in the future, a billing system will query the usage auditing service for activity records to generate a bill for the users of the service.

  Or consider this upgrade situation:
  

• A week after you put the service up for the first time you realize one of the function signatures needs to be tweaked.
• You contact the life cycle management service and submit an upgrade.
• You stipulate how long the old service should remain active.
• All users and intermediates repackaging your service are notified and informed of the change by the life cycle service.
• A new service facade is created and deployed.
• At the appointed time, the old service is brought down and a forwarder is left in its place.

A Look into the Future
In future articles, I will profile several types of helper services and discuss how each contributes to the web of services collaborating on behalf of your service. I also will describe a framework for nonintrusive integration of the helper services with your services that minimize the amount of development effort involved. Finally, I will elaborate on ways that development and deployment tools could hook into such a Web for even more efficiency at the project scale.

Extending Platform Reach
We've seen how third-party Web services can be leveraged to extend the Web services platforms' reach just as third-party libraries extend the facilities of operating systems. In particular, deployment of stable, profitable Web services could use a little help from some of the helper services I proposed.

In the time since this article was originally written a number of helper services of exactly the kind I described have popped up. Examples include credit card validators, usage trackers, and uptime monitors. Check out your favorite Web service index to watch the groundwork of the service Web being laid!.

Acknowledgment
Special thanks to Courtney Wallace and Russell Alexander.

Author Bio:
Dave Howard was recently an architect with ObjectSpace, Inc., and a founding member of the OpenBusiness team, one of the first Web services platforms on the market. He is now freelancing in Dallas, Texas. Dhoward@thenetworkeffect.net