The Roman general Pompey added a grain of salt to his food, believing it would counteract poisons added by would-be assassins. Thinking himself safe, he was eventually stabbed to death.

So take what you read about Web services … a technology that’s solidly in the “hype” phase of the technology life cycle (the other phases being “disillusionment” and “application”) … not with a grain of salt, but with a spoonful of salsa. Neither will prevent assassination, but at least the salsa will spice things up enough to keep you awake at night. And although Web services might turn out to be a useful architecture, it’s doubtful it will turn out as useful as it is now being promoted, so you need to stay alert to maintain the skepticism you need.

Last week we explored some of Web services’ problems, among them production scheduling. When you distribute a batch job over a bunch of computers running in other companies’ data centers and communicating at unpredictable latencies, run times become unpredictable and long.

The most straightforward technical solution is caching, which gives the user control over both computing power and network performance.

But the vendors that create the components you link together to build a Web services application will want to profit from their efforts. My guess is they’ll prefer an ASP (application service provider) model, where customers pay based on usage. Otherwise vendors would just be renting what amounts to a subroutine library, a pretty uninteresting business and one that’s never generated the kind of wealth that attracts venture capital.

Since caching makes ASP-style billing awfully difficult, it’s probably out. What probably will work, though, is similar: You’ll build or license and install web services applications pretty much as you do with existing architectures — on your own hardware in your own data centers. Once all the ASP-modeled Web services vendors run out of venture capital, they’ll rent you their components as libraries, too. They won’t get rich, but they might stay in business that way, eventually becoming something that looks a lot like a traditional software vendor.

If it doesn’t happen this way, Web services probably won’t emerge from the disillusionment stage.

Pompey, who took his food with a grain of salt, was killed in Egypt, where years later an asp killed Cleopatra, according to legend the most beautiful woman of her time. Is it just coincidence the ASP mentality might just be what kills the beautiful architecture of Web services?

Alfred Hitchcock promoted one of his movies with the slogan, “The Birds is coming.” He got tremendous free publicity through debates about his grammar. Pedestrian grammarians complained about the lack of agreement between subject (birds) and verb (is). The more insightful recognized that The Birds was a movie title, and therefore singular.

So what should we make of “web services.” Is it singular — the name of an architecture — or plural? Let’s use the phrase in some sentences and see how it comes out. So …

What is “web services”? The core concept is that you’ll build applications out of pre-built components scattered about the web using standard protocols that enable runtime binding. According to its advocates, the result(s) will be dramatic reductions in development time and orders-of-magnitude improvements in quality.

Unfortunately, web services contains huge, fundamental flaws. While not insurmountable, they’re not easily solved. Neal Goldman of the Yankee Group brought one to my attention: Version control.

Imagine your company uses a web-services application, and the provider of a key component changes its behavior. The new component runs fine, of course — that’s built into the protocols — but sadly, it no longer does what you expect it to do. So surprise! Payroll tax withholding suddenly changes, and there’s nothing you can do about it — you don’t control the code and you don’t control the versioning, either. It’s like DLL hell, only the application doesn’t crash. You just wish it had, instead of creating business chaos by doing the wrong thing.

A second big problem is latency. When you run an application on your own computers, components communicate with latencies measured in microseconds. With web services they communicate across the Internet, which means latencies measured in tens, hundreds, or even thousands of milliseconds. Do you seriously think you can solve this with service level agreements? Me neither. Imagine a component that computes daily interest for a million customers. Even an excellent service level — 10 msec — adds nearly 3 hours just from Internet latency. That’s a lot of run time to add for just one component … and your entire application is built out of components like this. Web services could easily change overnight batch to over-year batch.

You might think you can solve this through the miracle of caching. Maybe you can … but next week we’ll see how a third major, entirely non-technical issue with web services could eliminate caching as an option.