- Understanding Data-Oriented B2B Application Integration
- Data-Level B2B Application Integration by Example
- Working with Data-Level B2B Application Integration
Data-Level B2B Application Integration by Example
Just as a picture is worth a thousand words, understanding data-oriented B2B application integration is sometimes made easier by "painting a picture"—that is, examining a particular B2B 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 producer, a client/server system using PowerBuilder and Oracle, and the Enterprise Resource Planning (ERP) system (using an Informix relational database). Because the data movement requirements are light to moderate, and because 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 B2B application integration problem using data-oriented B2B application integration and the Internet.
First, to move data from the Oracle database to Informix, the B2B application integration architect and developer need to understand the metadata for each database so that 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 sold copper wire.
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 to signal when the data needs to be copied, such as a specific increment of time (every 5 seconds) or when a state changes (an update to a table occurs).
After these two determinations are made, the architect and the 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, message brokers, and custom-built utilities. There are advantages and disadvantages to each. 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.
Although 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 B2B application integration solution whenever an application cannot be changed, which, as we've noted many times, is generally the case with B2B application integration problem domains.
Data-oriented B2B application integration 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 can tie all source and target databases together cohesively, without requiring changes to the connected databases or application logic.
There are two basic approaches to data-oriented B2B application integration and its accompanying enabling technology: database-to-database B2B application integration and federated database B2B application integration.
Database-to-Database B2B Application Integration
Just as with the point-to-point approach, we've been doing database-to-database B2B application integration well for years. Database-to-database B2B application integration allows us to share information at the database level and, by doing so, to integrate applications. Database-to-database B2B application integration can exist in a number of configurations—one-to-one, one-to-many, or many-to-many. Regardless of the configuration, our approach to database-to-database B2B application integration is essentially the same: utilizing traditional database middleware and database replication software (replication features are built into many databases, such as Sybase), or through database-integration software. Message brokers also work with database-to-database B2B application integration.
Database-to-database B2B application integration problem domains can be addressed with two types of solutions: the basic replication solution, which moves information between databases that maintain the same basic schema information on all source and target databases, and the replication and transformation solution. Either of these solutions makes it possible to move information among many different types of databases, including various brands (such as Sybase, Oracle, and Informix) and models (relational, object-oriented, and multidimensional), by transforming the data on the fly so that it is represented correctly to the target database or databases receiving the data. This is exactly what happened in our previous inventory control system example.
The advantage of this B2B application integration approach is its simplicity. Generally, when dealing with application information at the data level, there is no need to change the source or target applications. By not changing the source or target applications, we reduce the risk and cost of implementing B2B application integration. The downside to this approach, where it exists, is that there are still too many applications that bind the application logic to the data. These applications make it difficult to manipulate the database without going through the application, or at least the application interface. This is the case with SAP R/3. To avoid integrity problems, updating the database generally demands using the SAP R/3 interface.
Federated Database B2B Application Integration
Like database-to-database B2B application integration, federated database B2B application integration works at the database level. However, rather than simply replicate data across various databases, federated database software creates a single "virtual" database model that allows developers to use various brands, models, and schemas to access any number of databases. This virtual database model exists only in the software and is mapped to any number of connected, physical databases. This virtual database functions as a single point of application integration, accessing data from any number of systems through the same single database interface.
The advantage of the federated database approach is its reliance on middleware to share information between applications rather than a custom solution. An additional benefit is that the middleware hides the differences in the integrated databases from the other applications that are using the integrated view of the databases. The downside is that this approach is not a true integration approach. Although it provides a common view of many databases—a "unified model"—there is still the need to create the logic for integrating the applications with the databases. In addition, this approach does not work well for B2B problem domains because it is difficult to create a common schema among systems that are not under central control.