Web services is useful, but it is too complex to be implemented in many organizations. That's where [insert new technology here] comes in. Its simplification of systems integration will revolutionize the enterprise IT department.

Sorry, I'm just getting a head start on the next wave of technology.

The truth is that hard problems have hard solutions, and industry veterans agree that systems integration is a hard problem. While IT managers want integration solutions, they sometimes think the medicine is worse than the disease. When that view becomes pervasive enough, the industry invents a new technology.

You don't believe me? When the first official version of the Common Object Request Broker Architecture (CORBA) was released in October 1991, it was said to herald a new age of simplified software interoperability and platform independence. The fact was the first CORBA products shipping in the early 1990s were unwieldy, buggy, and unstable beasts. CORBA products were missing more required features than they had, but the industry marched ahead with adoption. After several years, CORBA was useful and the specifications were complete. It had enterprise features, including distributed transactions, security, and publish and subscribe messaging. There was widespread support and most enterprise software that wasn't built on CORBA provided CORBA adapters.

The complaints started softly, then became louder, that CORBA is too hard. It's true that CORBA has so many features that the learning curve is painful. CORBA is a powerful technology, but it is so complex that skilled developers are expensive. CORBA continues its adoption trend in complex, mission-critical applications, but it is out of fashion in mainstream IT, largely in favor of Java 2, Enterprise Edition (J2EE).

J2EE application servers burst onto the scene in 1999 as an immature and often unreliable technology. A key promise of J2EE, according to Sun's J2EE Overview (http://java.sun.com/j2ee/overview.html), is "Making Middleware Easier." Easier middleware means lots of low-cost programmers to crank out enterprise applications, instead of the higher-priced programmers required for CORBA.

The original J2EE application servers were missing so many features that an entire industry of J2EE server add-ons and component shops was born. One example is Flashline.com, which based much of its business model on selling J2EE components and establishing an IT market for contracting the development of bespoke functionality. Over time, however, the J2EE specifications have improved. Today, application servers are fairly complete and even useful. As the specifications have become bigger to allow for this additional functionality, development with J2EE application servers is increasingly viewed as too hard.

In the Java press these days, hardly a month goes by without an author declaring J2EE too complex. The author points out that skilled J2EE programmers are expensive because of the complexity of the technology they work in. The author usually fails to mention what portions of the specification they would strike out in the name of simplification. The reason is that features wouldn't be in the specification if they weren't useful to someone. If only there were a simpler middleware technology.

Enter Web services. To be sure, there are some truly unique and useful things about this technology. Most industry observers agree that near universal support by giants including Microsoft, IBM, and Oracle is a key feature. That sort of support, as long as the technology doesn't fracture, has the potential to ease the integration pain of enterprise IT shops.

The adoption pattern of Web services is reminiscent of the Structured English Query Language (SEQUEL), later shortened to Structured Query Language (SQL). Today SQL is ubiquitous, but it hasn't always been that way. Dr E.F. Codd at IBM is credited as the father of relational databases and SQL for his pioneering work in the early 1970s. Not everyone followed Dr. Codd and IBM exactly by using their original query language. SQL did have its competitors.

Relational Technology's Ingres RDBMS, a contemporary competitor of Relational Software's Oracle and IBM's System/R, in the 1970s and 1980s, used a language called QUEL. The SQL language was, however, so successful that Ingres was forced to adopt it in 1986. SQL was given a big boost toward standardization by the American National Standards Institute (ANSI) and the International Standards Organization (ISO).

SQL has evolved through several versions and is today the universal language of relational databases. Some people believe that, if allowed to grow and mature, Web services may become the universal language of application integration, forever ridding the world of such things as Protocol Bridges and Enterprise Application Integration (EAI) Adapters. CORBA and J2EE will continue their roles as application execution environments, but they may lose favor as integration tools. Web services is already following the path of SQL by being accepted as a standard by a recognized industry body, the World Wide Web Consortium (W3C).

There is still quite a lot of work before Web services is universal. It needs a single security standard. It needs a standard for distributed transactions. It needs an enterprise-class messaging system. It desperately needs complete specifications for mapping Web services requests into native execution environments. As these features are added, the body of specifications that is Web services will become bigger and more complex. It will also become useful.

When that happens, let's not kill it. When Web services is complete and useful enough to be derided as too complex - or better still, as dead - you will know it is ready to be the solution for your truly hard problems.