Communications of the ACM

• network technologies, devices, and OSs;
• middleware solutions and communication paradigms;
• programming languages;
• services and interface technologies;
• domains and architectures; and
• data and document formats.

Even worse, the problem becomes a multidimensional problem when integrated solutions must also cope with non-functional requirements such as security aspects, availability, transactions, to name just a few.

All these facets of heterogeneity have offered many benefits and were intentionally brought into IT solutions. As a consequence, the goal should not be to try and eliminate the heterogeneity, but to help developers to master it and manage it. There have been many approaches to integrate heterogeneous technologies. However, these EAI technologies cannot provide a common solution because they try to solve the problem using an (incomplete) set of proprietary technologies. For example, when multiple companies integrate systems that were themselves integrated using different EAI products, developers face the recursive problem of integrating integration solutions. Hence, it is necessary to establish a holistic, commonly accepted and standardized approach instead of the proprietary solutions mentioned here. In this approach the systems and technologies remain heterogeneous, but their interface and collaboration patterns are standardized using lightweight standards such as XML and Internet protocols. OO middleware and component technologies such as EJB, CORBA, or COM+/.NET have already helped to solve many integration problems without causing architectural drift. What about combining Web technologies with OO middleware technologies? Finally, we have entered the world of XML Web services.

• <soap:Envelope>
  <soap:Header>
  <transaction>
  <soap:mustUnderstandstand= "true" xmlns= "http://tx.com">
  <id> 12345678 </id>
  </transaction>
  <soap:Header>
  <soap:Body>
  <m:getPhoneNumber>
  <theName> Bill Gates </theName>
  <m:/getPhoneNumber>
  </soap:Body>
  </soap:Envelope>

Step 2: Implementing an Interface Definition Language. In the next implementation step, an interface definition language is introduced to express structural and deployment information in an implementation-neutral fashion. From the specifications written in this language, tools will automatically generate the implementations of client-side and server-side proxies. Again, XML represents the appropriate means to define such a data representation language. As a result WSDL (Web Services Description Language)—see www.w3c.org/TR/wsdl—was created providing the following constituents:

• Types are used as core elements to build messages (XML Schema Notation).
• Messages define packages exchanged within a single message transfer. Requests and responses represent separate messages.
• Porttypes group messages to abstract operations.
• Bindings map Porttypes to concrete protocols.
• Ports denote the concrete communication addresses of services.
• A Service comprises a collection of ports.

Step 3: Implementing a Service Directory. Before a client can access a service, it must find the service. For this purpose, a central broker must be available that allows implementers to register their services as well as clients to locate these services. Again, XML denotes the core technology to store and retrieve service registrations. UDDI (Universal Discovery, Description, and Integration)—see www3.ibm.com/services/uddi/standard.html—provides all functionality expected from a service broker. In UDDI, servers use the Publishers API to register services as well as additional business information with the global repository (see Figure 3). Clients access the Inquiry API to browse the repository and retrieve service descriptions. SOAP is used as communication protocol in all interactions. The client obtains the WSDL description from the UDDI repository both dynamically or statically, generates a client-side proxy, and invokes the Web service.

A Broker Is Not Enough. As was illustrated, Broker-based Web service implementations abstract away many low-level communication details. The main aspect they offer is the seamless (platform-independent) integration of programming language object models into a distributed context. For building sophisticated solutions it is not sufficient to provide a stack of protocol layers, there are many problems that must additionally be solved—a few examples include:

• Information and services must be consumable from any device, any time, any place. For this purpose, a device-independent framework needs to be available. This can be effectively achieved by providing a virtual execution system such as the Java VM or Microsoft's CLR.
• Web-based, front-end layers must provide both Web server functionality and Web service provisioning.
• Web services infrastructures should support context information such as transaction IDs, security information, and location. Thus, the result of a Web service computation does not only depend on the (functional) arguments but also on the context of the service invocation.
• Web services are no islands. They can be connected to complete workflows, thus addressing B2B and B2C contexts. Workflow engines control both the computation flow and the application of business rules. They often represent gateways to existing back-end servers such as database systems, ERP servers, mainframes, or legacy code. Therefore, strong support for back-end integration is required. This is the major reason why existing OO middleware does not become obsolete due to Web services. In fact, OO middleware and especially component technologies such as EJB will become more important as an integration layer.
• Reuse and integration are supported by introducing core services application programmers might facilitate. For instance, calendar services, single sign-on functionality, and events are potential candidates for such reusable horizontal services.

Web services solutions cannot restrict themselves to UDDI, WSDL, and SOAP, because the development of sophisticated applications requires more than just a few communication layers. Instead, Web services protocols need to be supplemented by many additional technologies. In the future, whole Web service frameworks will be available addressing all or at least most of the issues explained here. Solutions such as Microsoft .NET and Sun ONE are only the beginning.

Integration via Web Services. As discussed in the previous section, Web services represent an integration technology. In contrast to other approaches such as proprietary EAI solutions, they are completely based on Web standards and XML. In combination with other standards they can help solve different kinds of integration problems: