Кәсіпорындық қолданбаларды интеграциялау: қағидалар мен үлгілер

Enterprise application integration (EAI) is the use of software and computer systems' architectural principles to integrate a set of enterprise computer applications.

Enterprise application integration is an integration framework composed of a collection of technologies and services which form a middleware or "middleware framework" to enable integration of systems and applications across an enterprise. The various systems that need to be linked together may reside on different operating systems, use different database solutions or computer languages, or different date and time formats, or could be legacy systems that are no longer supported by the vendor who originally created them. In some cases, such systems are dubbed "stovepipe systems" because they consist of components that have been jammed together in a way that makes it very hard to modify them in any way.

If integration is applied without following a structured EAI approach, point to point connections grow across an organization. Dependencies are added on an impromptu basis, resulting in a complex structure that is difficult to maintain. This is commonly referred to as spaghetti, an allusion to the programming equivalent of spaghetti code. For example, the number of connections needed to have fully meshed point to point connections, with n points, is given by (see binomial coefficient). Thus, for ten applications to be fully integrated point to point, point to point connections are needed, following a quadratic growth pattern. However, the number of connections within organizations does not necessarily grow according to the square of the number of points. In general, the number of connections to any point is only limited by the number of other points in an organization, but can be significantly smaller in principle. EAI can also increase coupling between systems and therefore increase management overhead and costs. EAI is not just about sharing data between applications but also focuses on sharing both business data and business processes. A middleware analyst attending to EAI will often look at the system of systems.

This section describes common design patterns for implementing EAI, including integration, access and lifetime patterns. These are abstract patterns and can be implemented in many different ways. There are many other patterns commonly used in the industry, ranging from high level abstract design patterns to highly specific implementation patterns.

EAI supports both asynchronous (fire and forget) and synchronous access patterns, the former being typical in the mediation case and the latter in the federation case.

An integration operation could be short lived (e. g., keeping data in sync across two applications could be completed within a second) or long lived (e. g., one of the steps could involve the EAI system interacting with a human work flow application for approval of a loan that takes hours or days to complete).

There are two major topologies: hub and spoke, and bus. Each has its own advantages and disadvantages. In the hub and spoke model, the EAI system is at the center (the hub), and interacts with the applications via the spokes. In the bus model, the EAI system is the bus (or is implemented as a resident module in an already existing message bus or message oriented middleware). Most large enterprises use zoned networks to create a layered defense against network oriented threats. For example, an enterprise typically has a credit card processing (PCI compliant) zone, a non PCI zone, a data zone, a DMZ zone to proxy external user access, and an IWZ zone to proxy internal user access. Applications need to integrate across multiple zones. The Hub and spoke model would work better in this case.

Currently, there are many variations of thought on what constitutes the best infrastructure, component model, and standards structure for Enterprise Application Integration. There seems to be a consensus that four components are essential for a modern enterprise application integration architecture:
A centralized broker that handles security, access, and communication. This can be accomplished through integration servers (like the School Interoperability Framework (SIF) Zone Integration Servers) or through similar software like the enterprise service bus (ESB) model that acts as a services manager. An independent data model based on a standard data structure, also known as a canonical data model. It appears that XML and the use of XML style sheets have become the de facto and in some cases de jure standard for this uniform business language. A connector, or agent model where each vendor, application, or interface can build a single component that can speak natively to that application and communicate with the centralized broker. A system model that defines the APIs, data flow and rules of engagement to the system such that components can be built to interface with it in a standardized way. Although other approaches like connecting at the database or user interface level have been explored, they have not been found to scale or be able to adjust. Individual applications can publish messages to the centralized broker and subscribe to receive certain messages from that broker. Each application only requires one connection to the broker. This central control approach can be extremely scalable and highly evolvable. Enterprise Application Integration is related to middleware technologies such as message oriented middleware (MOM), and data representation technologies such as XML or JSON. Other EAI technologies involve using web services as part of service oriented architecture as a means of integration. Enterprise Application Integration tends to be data centric. In the near future, it will come to include content integration and business processes.