Web services' dirty little secret

They all are singing in harmony about how Web services will introduce a brave new world of interoperability, unprecedented flexibility and openness. This is exciting, but do you remember the last time these guys were all singing the same tune? They were trying to tell us that client/server applications would level the playing field and make computing cheap, easy and open. Yeah, right!

Believe me, these guys don't make the big bucks by trying to level the playing field for their competitors or make things easy for their customers. As in the past, their strategy is to talk a good game. But at the same time each is trying to create a new proprietary lock-in that will make them the winner in Web services. How? By attempting to own and control Web services, up to the application level.

The application level is the final stop on the journey from operating system to database to application server to browser. In many ways, this is the last frontier, and none of them can afford to lose--at least in the traditional way. But do you really want to be locked into a single vendor? Would you want to be forced to drive a Pontiac your whole life just because it was your first car?

The major platform vendors do have a plausible interoperability story at the "middle" platform level, where Web services are created in "integrated development environments" like Microsoft's VisualStudio.Net, and deployed on application servers like IBM's WebSphere. They're all supporting the emerging standards alphabet soup for Web services interoperability--XML (Extensible Markup Language), WSDL (Web Services Description Language), SOAP (Simple Object Access Protocol) and UDDI (Universal Description, Discovery and Integration). In principle, this standards support will enable Web services created on a platform from one vendor to actually be deployed on the platform of the other. This is actually very good for customers and the industry. For the sake of discussion, let's assume it will happen.

But don't be fooled by the collective fake-out. The real issue is at the top of the stack, where the real payoff occurs--the battleground for global hegemony in the Web services world. This is where Web services are treated as "components" and actually assembled into full-blown business applications such as portals, Web-based distribution channels, collaborative supply chains and customer self-service systems. Here is where two huge dirty little secrets for customers are lurking behind the hype.

First, the portal servers and application frameworks of the big vendors pour the "wet cement" of hardwired programming all over Web services. Based upon the same old "manual coding" architectures that preceded Web services, these tools do not truly exploit the full power of Web services to change the way software is developed, deployed and maintained.

They are fine for simple, relatively static, content-based applications. But they are way too inflexible to accommodate the new challenges customers face as they move their business processes to the Web: the constant change and update inherent in "outward-facing" business processes with complex logic and workflow--those that serve customers, business partners and employees across the Internet.

The result is huge cost in the ongoing development and maintenance of complex Web-services based applications. Many of these applications will barely make it into production before they disappear. For the big vendors, this means that the juicy revenue from consulting and integration that began to flow with client/server applications will continue. Customers will just continue to pay the piper if they buy into this story.

The second dirty little secret is that the applications that customers will create with these portal servers and application frameworks are forever tied to the rest of the stack on top of which they were created. No portability, vendor independence or interoperability here. In essence, this just recreates the technology industry's problems of the past, only with brand new acronyms and buzzwords.

Don't be overly impressed by the fact that these applications can incorporate Web services created and even deployed on different platforms. Try moving the entire application and its data to another platform when it becomes more attractive or cost-effective for the business to do so. It can't be done.

The result: If you build your Web services-based applications using their portal servers or application frameworks, you're locked into them in much the same way that customers were locked into MVS 40 years ago, and Windows 20 years ago, and are just beginning to escape now. In other words, you're driving the Pontiac for life.

If this seems insignificant so early in the game, that's precisely what the major platform vendors want you to think. The truth is that the world of Web services will be a heterogeneous one. There won't be a single winner, and smart companies will preserve their options to build mixed, multi-vendor environments to meet their business needs.

Okay, that's the pain--now for the pain reliever.

What I see emerging is a new layer of vendor-neutral software that sits on top of the Web services platforms from all the major players--the "Web services automation" layer. This layer will address both pain points. One, it will let companies bust out of the wet cement of traditional application development by automatically assembling any vendor's Web services when they're needed. With this approach, developers will code, modify and maintain one application instead of 1,000.

Second, the Web services automation layer will be entirely portable to any major application server so that customers will be forever liberated from the stack on which the Web services applications were created.

That's a good thing, and it's totally in the spirit of the original premise of Web services. This way, a company will be able to move entire Web services-based applications and their data to other platforms when they need to. The major platform vendors will survive, just not at our expense. And when the time is right, you can trade in the Pontiac for something else.