Okay, sorry about the delay in getting this blog done. I was going to do it on Friday, but decided to go to the gym instead. Moreover, I was going to do it yesterday, but hey it was Monday.

However, it also gave many PR people the opportunity to send e-mail after e-mail pitching their company as the "data integration solution for SOA." Very funny. It's just a blog guys, relax.

Okay, back to work.

In order for a technology to be truly a SOA technology, or so I argue, it needs to support the notion of coupling, as well as cohesion, and not just one or the other. This is where some data integration products fall down.

Coupling, in the context of application integration and SOA, is the binding of applications together in such a way that they are dependent on each other, sharing the same services, methods, interfaces, and perhaps data. This is the core notion of SOA where the applications are bound by shared services, versus the simple exchange of information (using services or not).

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 SOA solutions have a better ability to bind actually behavior (functions, methods, services), versus just simple move information from place to place.

The problem is that many data integration solution are more about information/data and not about sharing services, thus they are hard fit for many SOAs. ESBs have a similar issue, but not as obvious. Thus, the marriage between data integration and SOA could end up in divorce if coupling is a requirement. Again, generally speaking.

More on this topic tomorrow, or if I feel fat, the day after.

Posted by Dave Linthicum on July 18, 2006 06:29 AM