As I’m exposed more to integration projects I’m seeing two patterns of failure, first the ability to recognize the problem itself and thus understand the solution, and selecting the improper enabling technology and products. In other words, people are leveraging services as a point of integration where information is the proper choice, or leveraging information exchange when services interfaces are indicated.
Understanding these concepts is becoming more important as we move into more service-oriented solutions, including SOAs. It boils down to savvy architects that are able to analyze the problem domains and apply the proper solution patterns, and the appropriate enabling technology.
While many believe this is more art than science, I have to disagree. It’s really a matter of understand the requirements and applying the logical solution.
Coupling
Coupling, in the context of application integration, is the binding of applications together in such a way that they are dependent on each other, sharing the same methods, interfaces, and perhaps data. This is the core notion of service-oriented application integration where the applications are bound by shared services, versus the simple exchange of information.
At first glance, coupling may seem like the perfect idea. However, you should not lose sight of what it really requires – the tight binding of one application domain to the next. As a consequence of this requirement, all coupled source and target systems will have to be extensively changed to couple them (in most cases).
Further, as events and circumstances evolve over time, any change to any source or target system demands a corresponding change to the coupled systems as well. Coupling creates one system out of many, with each tightly dependent upon the other. Service-oriented application integration clearly leverages coupling in how applications are bound together.
Of course, the degree of coupling that occurs is really dependent on the SOA architect, and how he or she binds source and target systems together. In some instances systems are tightly coupled, meaning they are dependent on each other. In other instance, the are loosely coupled, meaning that they are more independent. It matters not if you’re doing this through Web services or other mechanisms, you’re typically going to have to make these architectural tradeoffs within the notion of coupling.
There are, of course, more pros and cons of coupling that should be considered in context of the problem you’re looking to solve. On the pros side you have:
• The ability to bind systems by sharing behavior, and bound data, versus simple sharing information. This provides the integration solution set with the ability to share services that could be redundant to the integrated systems, and thus reducing development costs. This is the reason we leverage SOAs.
• The ability to tightly couples processes as well as shared behavior. This means that process integration engines, layered on top of service-oriented integration solutions have a better ability to bind actually behavior (functions), versus just simple move information from place to place.
The downsides include:
• The need, in many cases, the change source and target systems to couple services. This adds cost because development and testing time is involved; it’s no longer a matter of leveraging an interface which is abstracted from the core system.
• The fact that systems coupled could cease to function if one or more of the coupled systems go down. This means that a single system failure could bring down all of coupled systems, and thus creating vulnerability.
Cohesion
In contrast to coupling, cohesion is the “act or state of sticking together” or “the logical agreement.” Cohesively integrated source and target systems are independent from one another. Changes to any source or target system should not affect the others directly. In this scenario, information can be shared between systems without worrying about changes to the applications or databases, leveraging some type of loosely coupled middleware layer to move information between applications and make adjustments for differences in application semantics.
The advantages of using cohesion included:
• The ability to avoid changing source and target systems just to facilitate integration. You no longer have to make changes to the systems because the points of integration are less invasive.
• The fact that a single system failure won’t bring down all connected systems. Since the systems are not dependent, a failure typically won’t affect the integrated systems (at least immediately).
The disadvantages include:
The inability to provide visibility into the services layer, and thus gain value from encapsulated business services and tactical functions. This is simple information movement; there is usually no notion of services access, thus remote applications can only see information not behavior, thus no reuse of services.
Always Tradeoffs
You need to consider the tradeoffs. Coupling, or service-oriented integration, provides the greatest flexibility as the application integration solution moves into the future. The notion of leveraging services makes the application integration solution much more valuable than simple information movement.
However, cohesion has its advantages. Systems can be added to, changed, or removed from a cohesive application integration solution without typically requiring changes to any of the other systems in the problem domain. Integration brokers provide the technology infrastructure of most cohesive application integration solutions. They are able to account for the differences between systems, accommodating differences in application semantics within a middle-tier process.
