If you've been working with integration technologies for any length of time, you're well aware of the freight train of standards that has been careening through the industry during the last five years. These standards, particularly in the Web services space, are on the verge of doing to proprietary integration servers what SQL and J2EE standards did to database and middle-tier servers of days gone by.

Database veterans remember when Cullinet ruled the roost; many felt it had no technical equal. SQL was an interesting idea, but not for real projects. Likewise, long-time middleware developers recall the ease of use of NetDynamics and the technical capabilities of Kiva. J2EE? Another interesting idea, but again, not for real projects.

Where are these products now? They've been almost entirely replaced - by solutions based on those "interesting" ideas of SQL and J2EE. It has become clear that organizations felt standards-based architectures were more important than proprietary solutions.

Now with real synergy starting to happen between J2EE and Web services standards, particularly the latest addition of business process Web services standards, a similar story is poised to unfold within the integration space. The proprietary black box of integration appears ready to be cracked open.

Checkboxes Don't Count
So far, the integration space has proved relatively immune to the standardization process. Yes, many vendors claim checkbox compliance to a laundry list of standards, but it's often just that: a checkbox. It's like putting a relational driver on top of a network database: it works, but is it really relational?

It's getting harder to play these kinds of games. Many organizations are integration veterans and they understand the value of integration, whether it's increased efficiencies, lowered cost structures, or better visibility into internal and external processes. They have deep insight into the integration problem domain and how it can and should be standardized.

Juxtaposed against this increased level of awareness is a set of interrelated standards that tackle a broad swath of the integration space. In the runtime arena, J2EE provides key integration technologies in every J2EE compliant application server. In the Web services space, an emerging standards stack covering quality of service, business processes, interoperability and management is targeted right at the core of many integration solutions.

Types of Integration
Let's look at how the integration space is organized; Figure 1 offers a simplified illustration.

Each integration type has specific technologies and corresponding standards that map to the problem domain.

Data integration, as its name implies, focuses on moving data between systems often at the database level, sometimes independent of application APIs. Technologies range from simple but proven file transfers to more sophisticated database replication solutions to advanced message brokers. Data integration standards vary from database ETL technologies, messaging infrastructure provided by J2EE containers to Web services facades on top of message brokers. This last category is sometimes re-branded using the latest catch-phrase in this space, Enterprise Services Bus.

Moving up the stack, functional integration focuses on using business-level interfaces as the integration point. Almost every business application vendor, including Oracle, Siebel, PeopleSoft, and SAP, has a set of well-defined business APIs for core business functions. This has created a market of adapter vendors who wrap those APIs using J2EE standards such as the Java Connector Architecture and offer them through various integration servers. More recently, a number of application vendors have repackaged their business APIs as Web services.

Next in the hierarchy is process integration, which focuses on the flow or lifecycle of a business transaction. Typical technologies used in this space include human workflow and process engines. Standards have tackled process integration over the years, with the most recent industry consensus occurring around Web services orchestration standards like Business Process Execution Language (BPEL).

At the top of the stack sits process-to-process collaboration. This, too, is process-level integration but at a higher level, spanning businesses or organizations. A range of technologies - trading partner agreements and contracts, business protocol definitions, and business document definitions - exists to accommodate and formalize this increased level of abstraction. Representative standards in this space include industry-specific ones such as RosettaNet and UCCNet, and more generic standards like ebXML. More recently, Web services standards like WS Choreography Description Language (WS-CDL) have brought a Web services flavor to the space.

All of these integration technologies and standards share some common requirements. Every integration server requires transformation tooling; translation capabilities for technologies such as EDI; analytic capabilities for reporting and monitoring; and a runtime engine to provide a reliable, available, and scalable infrastructure.

Building the Standard Integration Platform
One cannot expect that the emergence of a standard automatically means industry adoption. There are many standards that have withered away without adoption. Further, there are some integration tasks that never will be resolved by standards no matter how abstract or all-encompassing they might be. That is the very nature of integration projects.

Starting with J2EE
Figure 2 illustrates a J2EE 1.4 container and the services it provides. Imagine you're an integration startup planning to offer a new integration solution in light of this platform.

Does it make sense for a startup to build a new container for managing threads, connection pooling, and other scalability characteristics when they are built into every J2EE container? Does it make sense to write a new messaging engine when you get JMS out-of-the-box? Does it make sense to write custom adapters when every container that supports JCA and third-party adapters can simply be plugged in?

Not really. The list goes on and grows in each J2EE release: security, transactions, Web services, deployment and management. These are all standardized and, by the nature of J2EE compatibility, consistent among J2EE vendors.

From a customer perspective there is no value if an integration server builds a new plumbing layer at the level of J2EE. J2EE is a popular, mature platform with large numbers of trained developers and administrators, well-known best practices and broad support across the vendor and consulting community.

Moving to Web Services
With J2EE providing the integration runtime environment, the next level to look at is how to bring two or more distinct systems together. Try as organizations might, not every endpoint in a multi-system environment will be J2EE. Integrating such heterogeneous systems can be addressed by Web services.

Figure 3 provides an abbreviated pictorial of Web service standards and how they can be put together to provide an integrated Web services platform.

You can look at this platform as having two major characteristics:

1. Endpoint Normalization: Web services provide a set of standards from the message definition through quality of service to service capabilities focused on normalizing the definition of application system interfaces. These standards are defined in an operating system, programming model, and application-independent manner. This provides a base framework for both data and functional integration.
2. Process Definition: A relatively new addition to the Web services stack is the process level. Web services process languages take advantage of the interoperability provided by a normalized set of Web services endpoints, enabling integrators to tie them together into business processes. This provides a base framework for the highest level of the integration hierarchy - process and process-to-process integration.

A common critique of this Web services stack is that very few endpoints in enterprises today are Web services. The rejoinder is that there is a built-in assumption that, just like for JCA, both application providers and adapter providers will see the clear value proposition and market opportunity in offering this infrastructure. Considering the fast pace in which both types of vendors are announcing Web services features, this seems like a sound conclusion.

If one takes Web services seriously, it becomes hard to imagine building an integration solution that is not based upon them. The value proposition for building a parallel stack, like that for J2EE, is simply not there from a vendor perspective nor does it exist from a customer perspective.

Process Standardization - The Core of Integration
Process definition languages tackle standardizing a key characteristic of many integration solutions. Just like SQL was the language that exploited the relational database, the business process equivalent, BPEL, is the language that exploits Web services.

It is possible, particularly with the broad adoption of XML across most integration solutions, to do a peripheral uptake of Web services. It gets progressively more awkward with process languages that depend on key pieces of the underlying Web services standards.

Take for example BPEL, a Web services process automation language that lets integrators weave together a series of services into an executable business process. Participating services are described in Web Services Description Language (WSDL). Data types used in the process are described in XML Schema within WSDL. Correlations between running processes are described in WSDL.

The coupling of the language to WSDL is characteristic of many higher-level Web services standards - WSDL is the way information about the services is expressed. While this could be captured in another way - and often is in existing integration servers - Web-service-centric solutions will use the native Web services mechanism.

The inevitable question comes again: Why invent a new mechanism to describe processes and their characteristics when standards already exist? Why create new concepts - your own black box - when the common language of describing them is universally shared at the Web services layer?

Standards Alone Don't Make a Solution
Of course, standards themselves do not build integration solutions. What they provide is a foundation upon which to build solutions. Process languages are a prime example where there are many solution areas that have to be built for them to be useful: modeling tools, runtime environments, best practices, tuning techniques and many more.

Take for example a typical purchase order scenario where two organizations work hand in hand to fulfill the order. What becomes immediately apparent is that trying to coordinate two independent long running processes has a complexity demanding higher level tools or even higher level process languages.

Figure 4 shows how a business analyst tool could be used to model the collaboration between the two organizations, generating BPEL templates used to implement the processes in each. This scenario, in fact, corresponds to a Web services standard the next level up from BPEL called Web Services Choreography, which is proposed to describe process-to-process collaborations.

At this level of abstraction the playing field for integration servers is suddenly quite different. The competition is not how well you innovate outside the standards; it is how well you innovate within the standards. Organizations do not care who has the best, most flexible process language; they care who makes using the standard process language the easiest and most productive.

Moving Beyond the Black Box
By no means is this integration standardization train near the end of the line. The destination is reasonably evident but there is a significant distance yet to be traveled. Web services have reached into many areas but at the same time have left large parts of integration untouched.

For example, Web services have not tackled transformation in a serious way, although XQuery seems like a logical candidate. They have just begun the journey into business-to-business and process-to-process collaboration standardization with new work happening in choreography. And, Web services have had fits and starts in the area of human workflow and little of note in the area of business rules.

Despite this, the breadth of the standardization problem tackled is significant enough that integration vendors and customers are quickly looking further up the stack for differentiation. Once the foundation has commoditized, as described here, value has to be provided by higher-level capabilities.

Like with any commoditization, base level differentiation will eventually be provided around ease of use, feature/functionality, performance, reliability and the like. Already, one of the key features platform vendors are offering is an integrated J2EE and Web services runtime for their integration solutions.

It is obvious this base level of standardization opens new opportunities for innovative solutions. Just like the emergence of SQL and J2EE created new platform vendors and strong markets for supporting tools, practices and technologies, the combination of J2EE and Web services is now in the midst of doing the same to the proprietary black box of integration.