While the majority of our attention has been devoted to various approaches to EAI, you'll discover as you shop for solutions that each EAI vendor has its own take on what EAI is. Who's right? Who's wrong? Unfortunately, as with everything else in the EAI domain, the answer is not black and white.
EAI is a combination of problems, and each organization has its own set of integration issues to address. As a result, it is virtually impossible to find a single technological solution set that can be applied universally. A particular enterprise's EAI solution will generally require products from several different vendors. At this time, and in the foreseeable future, one-step shopping is simply not an EAI reality.
Although vendors' approaches to EAI vary considerably, it is possible to create some general categories. These include:
- Data oriented
- Application integration oriented
- Process automation oriented
- Transaction oriented
You should note that these vendor solutions are independent of the levels of EAI (database, method, application interface, and user interface), and may inhabit one, two, or three of the levels of EAI.
Data-Oriented
Vendors that promote the data-oriented approach to EAI make the case that integration should occur between the databases—that is, databases should be viewed as the primary points of integration; thus they believe in data-level EAI. Even within data-level EAI, there are many approaches, and each vendor is quick to promote its particular solution. Data-level solutions can be categorized into two categories: data replication and data federation.
Data Replication
Data replication means moving data between two or more databases, databases that can come from the same vendor or many vendors, or even databases that employ different models. The trick with database replication is to account for the differences between database models and database schemas by providing the infrastructure to exchange data. Such solutions are plentiful and inexpensive. Most relational database vendors, including Sybase and Oracle, provide database replication services within their own product offering. These replication engines typically exist within the database engines, at either end (see Figure 20.3).
Many database-oriented middleware solutions are on the market that provide database replication services as well. This is accomplished by placing a layer of software between two or more databases. On one side, the data is extracted from the source database or databases, and on the other side, the data is placed in the target database or databases. Many of these solutions provide transformation services as well—the ability to adjust the schemas and the content so they make sense to the target database (see Figure 20.4).
The primary advantages of database replication are simplicity and low cost. Database replication is easy to implement, and the technology is cheap to purchase and install. Unfortunately, data replication loses value if methods need to be bound to the data or if methods are shared along with the data. To accomplish these things, method sharing solutions such as transaction-oriented or application integration–oriented EAI must be considered (see the discussion of these solutions later in this chapter).
Data Federation
Although database federation has been around for awhile, the solution set has been perfected only recently. Database federation is the integration of multiple databases and database models into a single, unified view of the databases (see Figure 20.5). Put another way, database federations are virtual enterprise databases that are comprised of many real physical databases.
Figure 20.5 Data federation software is middleware that allows an application to view a number of databases through a single view.
Database federation software places a layer of software (middleware) between the physical distributed databases and the applications that will be viewing the data. This layer connects to the back-end databases using available interfaces and maps the physical databases to a virtual database model that exists only in the software. The application uses this virtual database to access the required information, and the database federation handles the collection and distribution of the data as needed to the physical databases.
The advantage of using database federation software is the ability to bind many different data types into one unified enterprise-wide model.
Database federation allows access to any connected database in the enterprise through a single well-defined interface. This nails the data-level EAI problem, providing the most elegant solution. While this solution, unlike replication, does not require changes to the source or target applications, changes do have to be made at the application level to support federated database software. This is due to the fact that different interfaces are being used to access a different database model (the virtual database).
Application Integration–Oriented
Application integration–oriented product solutions focus on the integration of both packaged and custom applications by using well-defined application interfaces, and supports the data, method, application interface, and user interface EAI levels. Right now, the interest in integrating popular ERP applications (e.g., SAP, PeopleSoft, and Baan) has made this the most exciting EAI sector. (While distributed object and transaction-oriented solutions may be applied to this space—because here you program your way to success—message brokers vendors are promoting their products as the preferred solution.)
Message brokers support application integration–oriented solutions by connecting into as many custom or packaged applications as possible through adapters. They also connect into technology solutions that include middleware and screen scrapers as points of integration (see Figure 20.6).
Figure 20.6 Application integration–oriented solutions link to packaged or custom applications or other points of integration to integrate applications.
The advantage of using application integration–oriented products is the efficient integration of many different types of applications. In just a matter days, it is possible to connect a SAP R/3 application to a Baan application, with the application integration–oriented solution accounting for the differences between schema, content, and application semantics by translating on the fly the information moving between the systems. Moreover, this type of solution can be used as a database replication solution, which is also able to connect to application interfaces.
The downside to using application interface–oriented products is that there is little regard for business logic and methods that may exist within the source or target systems, logic and methods that may be relevant to a particular integration effort. In such a case, transaction- or distributed object–oriented solutions (composite applications or a pure method-level approach) are probably a better choice. Ultimately, application interface–oriented technology will learn to share methods as well as information, perhaps by joining forces with transaction-oriented or distributed object–oriented solutions. However, for now you will have to make an either/or decision.
Process Automation–Oriented
Process automation–oriented products, as covered in the previous chapter, are those solutions that layer a set of easily defined and centrally managed processes, or workflow solutions, on top of an existing set of processes contained within a set of enterprise applications (see Figure 20.7).
Figure 20.7 Process automation–oriented products layer a set of centrally managed processes on top of an existing set of enterprise processes.
The focus is to bring together any relevant enterprise processes to obtain the maximum amount of value while supporting the flow of information and logic between these processes. These products view the middleware or the plumbing as a commodity and provide easy-to-use visual interfaces for binding these processes together.
In reality, process automation is another layer of value on top of existing EAI solutions, solutions that include message brokers, application servers, distributed objects, and other middleware layers. They offer a mechanism to bind disparate processes together and to create workflow solutions that automate tasks once performed manually. However, by diminishing the importance of the plumbing, they miss the larger picture. In reality, no single EAI vendor has solved the plumbing issues. Ultimately, the solution to these issues will be delivered by a combination of process automation and middleware vendors. That being the case, it is clear that the binding of middleware and process automation tools represents the future of EAI.
Transaction-Oriented
Transaction-oriented products are those middleware products that use the notion of a transaction, with connectors to back-end systems, to integrate applications, a clear method-level EAI approach. Examples of these products include TP monitors and application services. Although transaction-oriented products can be used for data integration, method-level integration is where these products shine. With these products, it is possible to create common methods (transactions, really) and share those methods among many connected applications.
The advantages of transaction-oriented products are scalability and reliability. However, success with these products requires a tremendous amount of coding. As time marches on, transaction-oriented middleware will combine forces with messaging and message brokers, providing EAI architects and developers with the best of method-level, data-level, and application interface–level EAI.
0 comments