Repository Services

Many integration servers embrace the concept of a repository a database of information about source and target applications (which may include data elements, inputs, processes, outputs, and the inter-relationships among applications). Although many experts view repositories primarily as a part of the world of application development, they do not question their value to the world of application integration.

Application integration-enabled repositories, in their simplest form, provide the integration server user with a database of information pertaining to the following:

• Owner of the system (company)

• Location of the system (directory)

• Security parameters

• Message schema information

• Metadata

• Enabling technology

• Transformation information

• Rules and logic for message processing

• Design and architecture information (e.g., UML)

• Object information

The goal is to provide a sophisticated repository that is capable of keeping track of a good deal more than the rudimentary information (such as directory data). It should track more sophisticated information about the source and target systems (such as metadata, message schemas, and even security and ownership). The repository should provide all the information required by the application integration architect and programmer to locate any piece of information within the enterprise and to link it to any other piece of information. The repository must be the master directory for the entire application integration problem domain.

Many concepts of repositories have been taken from the application development world. Rules, logic, objects, and metadata are still tracked within a repository. The difference between the two is that by using the repository with an integration server, other, less sophisticated information such as encrypted passwords, network addresses, protocol transformation services, and even error code transformations and maintenance information can also be tracked.

In more sophisticated integration servers, the repository is becoming the axis mundi, able to access both the source and target systems in order to discover necessary information (such as metadata and available business processes). Engaged in this "auto-discovery," the integration server can populate the repository with this or any other information that may be required. Ultimately, the repository will become the enterprise metadata repository, able to track all systems and databases connected to the integration server.

The value of a repository should be clear. With the repository as a common reference point for all connected processes and databases, integrating data and methods is as straightforward as finding their equivalents and joining them together. The repository can also track the rules that the application integration architect and developer apply within the application integration problem domain. Moreover, because the repository knows the schema of both the source and the target systems, it also contains information for the proper transformation of information flowing from source to target. In many cases, this transformation can be automatically defined, freeing the user from ever needing to be involved in the definition of the transformation procedure.

However, repositories remain only the storage mechanisms in this scenario. The integration server must read the information from the repository and carry out the appropriate process. In addition to the integration server engine, the graphical user interface that accompanies most integration servers provides application integration architects and developers with a mechanism to alter the repository, and so alter the behavior of the integration server.