Web services fit nicely into a service-oriented architecture (SOA) and appear to be one component of the ideal solution to business application integration. When exposing applications through Web services, the contract of each service is evident through its Web Services Description Language (WSDL) description.

The WSDL document describes the names of the operations, the names and types of each of the parameters, and the name and type of the return value. After you add reliable messaging support (to ensure delivery) and a business process management engine (to route based on high-level business logic), your integration problems are over.

Of course it's not so simple. Even when using the loose coupling afforded by Web services, you must marshal data into the correct format. Organizations that do not carefully plan their integration strategy usually end up with a multiplicity of point-to-point integrations, because the simplest way to expose a Web service is through a thin veneer on application data structures. A single point-to-point integration is manageable; dozens become a maintenance nightmare. Semantic inconsistency arises between disparate systems. Exposing application data as a Web service without considering the consumers of the data defeats the loose-coupling tenet of an SOA. Fortunately, a set of best practices is emerging to address these concerns. The essence of these practices is to separate data logic from business logic, capturing the data logic in a model with accompanying rules and transformations that are preserved as metadata. This model-based approach to integration promotes reuse, error management, and controlled change.

Use Data Models
The first step in improving integration is to use an application-agnostic data model. (See Jim Gabriel's Best Practices in Integrating Data Models for SOA.) The idea here is to transform data into a common, application-neutral format. (This format can be virtual - it may exist in the development environment only to be compiled away at run time.) Then each data type in the integration project should be mapped onto this format. Adding a new data type requires a single mapping to the neutral format rather than an unmanageably large number of mappings to all of the other types in the system. This can provide maximum flexibility in replacing individual systems without forcing you to rewrite the integration. When you take this approach, you commit to modeling the inputs and outputs of all of the components in the integration project along with the transformations between them. The tools you select will capture all of those relationships as metadata, preserving the intent for future generations of programmers who must maintain the software. Because schemas change over time, many tools provide capabilities for managing schema and interface evolution in a natural way.

Resolve Semantic Inconsistency
Adopting an application-agnostic data model is the starting point, but it's not sufficient. The next step is to ensure semantic interoperability. Enterprises often have multiple definitions for customer, product, or order, as well as business requirements to present data about these entities differently according to rules and roles within the business. To take a real-world example, consider the task of integrating billing and order-entry systems at a major telecommunications provider. The billing system has specific rules about what constitutes a valid request. For example, you aren't allowed to use the "residential" bill format for a commercial account. These rules aren't known to the order-entry system, and they're not expressible in the schema for an order. Simply exposing "order" as a parameter to a Web service does not obviate the underlying constraint. In fact, exposing this concept via a Web service increases the likelihood that inconsistent or incorrect data will be supplied, with little feedback provided to the suppliers of the bad data. A properly written integration project must take explicit steps to resolve these inconsistencies.

Separate Data Logic from Business Logic
These sorts of inconsistencies are all too often swept under the rug or addressed outside the scope of the integration project. A far-too-common approach is to change human processes to avoid entering "bad" data into the system in the first place. One customer concluded that it would be easier to train the data-entry staff to never enter a purchase order containing incompatible feature combinations than it would be to fix the integration to detect and correct this situation. These errors are typically addressed in one of two ways: by writing custom Java code in the individual service adapters or by adding decision nodes to the business process definition (in WebLogic, a Java Process Definition, or JPD). New business process decision nodes mean interspersing low-level data integration logic with the high-level application logic, resulting in a business process flow that is no longer understandable to the business user for whom it is intended. Custom Java code generally works well but results in a fragile integration. The Java code is tied to a specific version of the data schema - as soon as the schema changes, you must locate and revisit the Java code. Data logic should be tightly coupled with the data definition, not distributed throughout the integration project.

Use Model-Based Integration
An emerging best practice to address these concerns is to attach the rules relating to the data (validity constraints, logical calculations) directly to the model as metadata. In this case, the application-agnostic data model mentioned earlier includes not only the definitions of the data types of the various business applications, but also the custom reconciliation rules you must define to ensure semantic interoperability. This model-based approach results in comprehensive metadata for the entire integration project and helps you manage extensions to the models and rules over time. Model-based integration projects are self-documenting and significantly reduce maintenance costs. For example, you can develop validation rules and mapping transformations graphically in conjunction with application owners instead of using the commonly accepted but slow and error-prone practice of e-mailing spreadsheets across organization boundaries.

Reuse Common Computations
A model-based integration starts with definitions of the systems involved. Some organizations have these definitions defined in XML Schema, some in Unified Modeling Language (UML), some as object-relational mappings. In any case, these definitions are incorporated into a larger model that defines each of the payloads and the relationships between them. This model may be enriched with additional data that is not present in the original schemas but spans multiple systems. For example, an enterprise may have a well-defined delineation of "loan-to-value ratio," which is critical to its notion of mortgage data exchange. This calculation should be defined once and reused throughout the set of integration projects. Ideally this calculation would be attached directly to the model, resulting in what is often called an exchange model. (See Roy Schulte's Information Architecture for the Virtual Enterprise.)