Central to most of these requirements is a common theme of neutrality. That is, the integration solution should be neutral to platforms, languages, application component models, transaction models, security models, transport protocols, invocation mechanisms, data formats, endpoint availability models, and so on.

In other words, the integration solution largely depends upon an abstraction layer that exposes, in a neutral format, the data and service interfaces of different endpoints participating in an integration scenario. Supporting the other aspects of neutrality, such as language neutrality, transport neutrality, etc., also requires support for a neutral data format and neutral service interface specification for different languages, platforms, transports, etc. Once such an abstraction layer is established - to expose in a common language the service and data interfaces of different endpoints - the next challenges are related to interaction patterns between the endpoints.

The interaction patterns are mainly related to determining the semantics of the data passing through the endpoints, the granularities of the service interfaces offered by the endpoints, the contextual information that needs to be exchanged along with data, and so on.

These requirements impose constraints on the interaction pattern. Note that the details of the applications behind the endpoints need to be hidden from the integration solution. In order to hide the internal application model, the endpoints must expose coarse-grained interfaces that reduce the number of interactions. The reduced number of interactions requires passing semantically richer data structures through the interfaces, and deriving finer-grained data from these rich data structures. These rich data structures are commonly called business documents, and the interaction between disparate systems via exchange of the business documents is commonly called document-style interactions.

The other style of interaction (called RPC style) typically involves passing a small number of individual data items in multiple requests, and synchronously getting a small number of reply data items in return. In this environment, the decision to invoke a particular synchronous call, and the data to be passed to the call, depends heavily upon the context, which is defined by the previously invoked RPC calls and the data returned by them.

A document-style communications approach organizes data within a collection, called business document, and makes far fewer invocations compared with the RPC style. The business document contains all of the information required for business processing and typically contains far more data than the amount passed in RPC-style parameters. While a document processing request/ response could be synchronous, an asynchronous approach is far more common.

In analyzing the requirements of neutrality with regard to the application model behind the endpoint, it's clear that the desirable interaction pattern in such an enterprise integration environment is that of the coarse-grained document style.

The document-style interaction pattern is also a natural choice for supporting different availability models. In document-style interaction, all the necessary information for invoking a service is encoded in stand-alone business documents, allowing applications to have life cycles independent of each other, or at least letting each one function normally for prolonged periods of time, without communicating with each other. This makes it possible for clients to make requests, and for a service to consume and process requests, independent of whether the client or service is immediately available.

Theoretically, the RPC style could also utilize a communication model where the client and server operate independent of each other's availability. However, this is often not useful in practice because applications using the RPC style typically depend upon an immediate response so that the application can decide its next step.

Another term that is commonly used in describing and differentiating the nature of interactions between endpoints is loosely coupled vs. tightly coupled. The coupling between any two systems essentially indicates the degree of dependency they have on each other. The degree of coupling implies some level of cooperation, as the two communicating systems must have a certain level of agreement and the degree of coupling depends upon the nature of that agreement.

If the clients are required to program their logic against a specific API and a specific application model exposed and controlled by the service, then the dependency (and hence the coupling) between the client and service is tighter. Such tightly coupled systems typically involve invocation of multiple fine-grained APIs, which essentially visit different parts of the application.

As a result, tightly coupled interactions largely depend upon a general acceptance of the component model on which the application is designed. In these systems, the connections that a client makes with the service are dedicated to specific purposes and are therefore not reusable in most cases. Integration using such models tends to result in brittle and inflexible systems in the sense that a change in the use of interface on one side requires modification on the other side.

On the other hand, loosely-coupled systems do not bind to each other using application-specific interfaces. Instead, these systems make use of abstract message definitions to mediate their binding with respect to each other. For example, the interfaces of loosely coupled systems focus on the message definitions instead of method signatures. This supports general-purpose message definitions such that the application code can independently handle the complexity of processing specific message instances, which makes the interfaces reusable.

While a tightly coupled approach offers tremendous runtime efficiency (because the common component model can be directly exploited for low-level use case scenarios), a loosely coupled approach provides flexibility to support different high-level use cases.

Conclusion
In summary, the requirements described here demand an integration technology that is neutral with respect to object models, interaction styles, and transports, and which can provide very high interoperability. The interoperability is determined by the way the exchanged documents are defined, produced, and consumed. The integration technology needs to support defining the data and service interfaces in a neutral manner - and must build on this semantically rich layer of data and service descriptions so as to support document-style, loosely coupled interactions between the endpoints.

Note that in addition to the documents themselves, the endpoints pass additional metadata such as security context. Therefore, the solution must also take care of packaging and exchanging such context information in an interoperable manner.

These interoperability considerations affect the standardization of the packaging, as well as the standardization of the actual exchange of packaged messages (in other words, both the document and metadata). Again, it should be possible to use any transport for actual exchange of the messages; the choice of the transport is based primarily on the transport facilities required by a particular use case, such as reliable messaging, message brokering, etc.

The second article in this series will describe how Web services address the architectural requirements of the integration problem domain.

Author Bios
Sanjay Patil is a distinguished engineer within the Web Services Integration Platform group at IONA Technologies. He is actively involved with many e-business standards; his areas of interest are distributed infrastructure for B2B and enterprise integration, Web services, and Internet technologies. sanjay.patil@iona.com

Nick Simha is a sales engineer working with IONA's customers to help architect e-Business solutions. His areas of interest are application integration, Web services, supply chain management, and security. nsimha@iona.com