Introduction
Integration professionals have realized that point-to-point integration dramatically increases the complexity of building and maintaining corporate business processes. One manifestation of this is the increasing popularity of Service-Oriented Architectures. In order to achieve maximum benefit from SOAs, it is important to carefully consider architecture and design principles before choosing technology and going to work on practical examples.
In a properly factored design, integration appliances can greatly reduce cost while simplifying implementation and ongoing maintenance. Appliances can also help insulate companies from the inevitable changes common to any integration system by minimizing supporting infrastructure.
Central Concepts of the Original SOA
In the mid-90s, commercial integration packages were being used to build large, cross-system business processes for the first time. However, the limitations of first-generation technology became a serious barrier to success:
1) Integrating every system to every other system results in complexity which grows as the square of the number of endpoints. This clearly will not scale. The introduction of hub and also bus models reduced these connections, with all of the data flowing through a central hub and repository.
2) Once all the data for a given system was flowing through a central point, designers could think about reducing the amount of work required to maintain the endpoints. Even moderately complex systems have dozens of endpoints, and the bulk of the IT administration effort involves maintaining connectivity as the endpoints change. SAP comes out with a new version of software, Oracle buys PeopleSoft, the mainframe payments system moves to a UNIX server, or vice versa.
Early integration systems were usually tied directly to low-level APIs at the endpoints. This was done by using adapters. Unfortunately, standards were few. People forget today that in 1995, even ODBC didn’t always work consistently. This resulted in large numbers of adapters having to be co-located with the target systems – at least one per application type and often more, to deal with multiple versions of an ERP system. Every time the endpoint changed, that interface had to be reworked. Worse, all the business logic behind it often was tied tightly to the adapter and had to be rewritten or ported. This led to the idea of a higher-level abstraction than a programming API.
-1-