The main architectural integration strategies are:
- Portal Integration
- Enterprise Information Integration (EII)
- Enterprise Application Integration (EAI)
While Portal integration consists in putting all the services in a common interface where data and logic are independent from service to service, in the EAI the logic is shared between the applications also integrating the already developed logic. EII instead takes care of providing a single method of access to all available data sources.
There are two different types of EAI approach:
- vertical decentralized, which consists in the creation of point-to-point communication for the specific applications between the applications to be integrated
- organic centralized, introducing a middleware that takes care of these communications
Point-to-point
A vertical decentralized point-to-point approach allows a direct and synchronous connection between two applications that can also share data and business rules, but needs to know and add the logic to be shared between applications and to replicate and realign data using specific batches.
This leads to future additional costs with regards to maintainability and system updates. This methodology is not applicable on systems where the number of application pairs to be integrated is high, because it would lead to a highly complex and poorly maintainable system.
Middleware
Middleware are software designed specifically to act as intermediaries between structures and programs, allowing their communication despite the diversity of protocols and operating systems. They can be divided into 3 categories:
Basic Middleware
They have architectures for the integration between data and applications.
Platform Middleware
J2EE application server, TP Monitor, ORB, various Portal Servers.
Integration Middleware
Connect application and database from different architectures.
The approach strategies of a middleware are:
- Direct : a simple connection technology is used, leaving the application layer the task of solving integration problems. (Platform Middleware)
- Indirect : consists of the introduction of an advanced intermediate level that deals with communication problems, dealing with both connections and data integration (Basic and Integration Middleware)
Integration middleware
Integration middleware must be the only communication channel between inhomogeneous applications allowing centralized management of all integration problems. Consider three types of Middleware integration:
Programmatic Integration Server
Reusing the mainframe features that are exposed with new technologies.
Integration Broker
Integrate applications developed for different architectures. Typically provided by the integration broker, they provide more advanced features than the programmatic integration server.
Enterprise Service Bus (ESB)
Similar to an integration broker but based on BUS and not on HUB. The ESBs expose the functionalities through standards while the IBs do it through proprietary technologies. Furthermore, the ESB is based on a shared bus distributed architecture, Service Oriented Architecture (SOA): all applications are designed as an aggregation of services, already ready for 'integration.
In particular the Middleware Integration provide the following functionality:
- Resource Adapter (RA): resolution of communication problems, often provided with the EAI;
- Messaging brokers: they work as both point-to-point and publish / subscribe messaging layers;
- Integration Broker: perform data mapping and intelligent routing both content-based and publish-and-subscribe;
- Workflow: management of messages and business objects during the execution of processes;
- Business activity monitor: event analysis to evaluate the accuracy, quality and safety of the activities;
From integration to services
Currently the integration between systems and services is mostly managed with asynchronous synchronization batches (which do not allow real-time access to information) and by implementation of point-to-point connections between services that entail high complexity and increasing costs both maintenance and system evolution.
Messaging, Gateway and Middleware technologies allow to simplify communication and support problems of synchronous and real-time mechanisms, but in the absence of a centralized structure, the use of these technologies is not sufficient to reduce the costs and complexity of Spaghetti Integration .
It is considered appropriate to move from a vertical P2P strategy to a horizontal integration such as SOA, oriented to the development of complex and extensible information systems, which can be integrated and easily maintained.
Integrating with SOA is called SOI (Service oriented Integration), that means transforming the functions already present into services so that they can be treated homogeneously with all the other ones in the system.
The evolution from P2P integration architectures to service-oriented integration demonstrates a greater architectural maturity of organizations that are no longer affected by the losses deriving from a wrong integration, but rather from a system design aimed at evolution and integration.
These are the principles that are fueling the growth of the Enterprise Service Bus systems or service-oriented communication middleware.
The method consists of identifying the integration points between the applications and publishing common services for use. In this way the services will also be reusable for other applications in future system evolutions.
This approach is the opposite of the " Rip and Replace " methodology which consists in having a single application that covers all the needs of the information system. This system has failed because in enterprise systems it is difficult for a single application to cover more than 40% of functional needs, instead "Wrap and re-engineer" and "Leave-and-layer" strategies are more effective.
Wrap and re-engineer
Applications are invoked by special interfaces that are more flexible and reusable by other systems.
Leave-and-layer
It consists in preserving the existing portfolio of services by reconciling their differences (logic and data) in a new layer. This layer allows you to reuse the previous one allowing a rationalization and consolidation of the same by masking logic and data outside the endpoints to be integrated.
These two methodologies allow heterogeneous systems to coexist in the new "service bus" layer, also allowing a possible incremental integration of new applications.
In conclusion, it can be said that being compatible with all the integration strategies examined, the Middleware Integration SOA is the best choice in the development of complex applications oriented towards integration.