Next Generation Application Integration: From Simple Information to Web Services

It's Just Data

IOAI's simplicity and speed-to-market advantages are the consequences of a business logic that rarely has to be altered (a cohesive rather than coupled approach). It frees the enterprise from having to endure seemingly endless testing cycles, or the risk and expense of implementing newer versions of applications. Indeed, most users and applications will remain blissfully ignorant of the fact that data is being shared at the back end, because application behavior rarely changes.

The advent of application integration-specific technology, such as integration brokers, application integration management layers, and simple data movement engines, enables the enterprise to move data from one place to another from anywhere to anywhere without altering the target application source. What's more, this can now be done in real time, with automated mechanisms for transformation and routing.

Although the technology for moving data between two or more applications is familiar and well tested in real applications, this familiarity does not exempt the architect or developer from understanding the data that is being moved, or from understanding the flow and business rules that must be applied to that data.

IOAI by Example

Just as a picture is worth a thousand words, it is likely that understanding IOAI is sometimes made easier by "painting a picture," that is, examining a particular application integration problem. For example, let us say that a copper wiring manufacturing company would like to hook up to the inventory control system that exists at its raw material goods supplier: a client/server system using PowerBuilder and Oracle at the manufacturing site, and an Enterprise Resource Planning (ERP) system using an Informix relational database at the supplier site. Because the data movement requirements are light to moderate, and changing the proprietary ERP application to bind its logic with the inventory control system is not an option (the supplier won't allow it), the company would like to solve this application integration problem using IOAI and the Internet.

First, in order to move data from the Oracle database to Informix, the application integration architect and developer need to understand the metadata for each database so they can select the data that will move from one database to the next. In our example, let us assume that only sales data must move from one database to the other. So, when a sale is recorded in the inventory system (creating an event), the new information is copied over to the supplier's ERP system to ensure that the correct amount of raw materials will be available to create the amount of copper wire recorded in the sale.

Second, the architect and developer must determine the frequency of the data movement. In our example, let us determine that real time is a requirement for this problem domain. The event to be captured must also be defined in order to signal when the data needs to be copied, such as a specific increment of time (e.g., every 5 seconds) or when a state changes (e.g., an update to a table occurs).

Once these two determinations are made, the architect and developer must choose the method for moving the data. As we have come to understand, there are many technologies and techniques for moving the data from one database to the next, including database replication software, integration brokers, and custom-built utilities. There are advantages and disadvantages to each, advantages and disadvantages that will become apparent later in this book. In our example, we'll choose to go with a database replication and integration solution a piece of software that runs between the databases that can extract information from one database, say the Informix database, reformat it (changing content and schema) if needed, and update the Oracle database (see Figure 2.2).

Figure 2.2. Moving information between systems may require changing both the content and schema on the fly.

While ours is a one-to-one scenario, one-to-many works in the same way, as does many-to-many (albeit with more splitting, combining, and reformatting).

With the middle-tier database replication software in place, the information is extracted, reformatted, and updated from the Oracle database to the Informix database, and then back again. The information is replicated between the two databases when an update occurs at either end of the corresponding sales table.

Using this simple approach, the data moves between the databases at the data level. The application logic is completely bypassed. There are no changes to the application logic at the source, or, as in this case, the target systems. Clearly, this approach provides an effective application integration solution whenever an application cannot be changed, which, as we've noted many times, is generally the case with application integration problem domains.

IOAI makes sense for more complex problem domains as well, domains such as moving data between traditional mainframe, file-oriented databases and more modern, relational databases; relational databases to object databases; multidimensional databases to mainframe databases; or any combination of these. As in other domains, database replication and translation software and message brokers provide the best solutions. They are able to tie all source and target databases together cohesively, without requiring changes to the connected databases or application logic.

Related

Категории