Wow, to read the positive reviews of SOA and what it’s doing for the IT industry, one would be likely to believe that there’s serious transformation occurring because of this architectural approach. Well, the truth is, implementing an SOA design such that real loose-coupling is achieved and that a service does not share a common bond with any other service down to its roots in persistence and all the way up to its consumers, using today’s technology mix, is complex, clumsy and fraught with sandtraps.

I was discussing this topic with a friend the other day who is a big advocate of “just focus on the work and stop worrying about the ideology”. I know this person knows how to develop maintainable and sustainable solutions, so when he says “just do it,” I know that implies just do it using common, agreed upon best practices for developing agile software solutions. So, we kept beating about this concept of sustainability and we both finally agreed upon that the key is focusing on understanding the business. This means sustainability comes from analyzing from the top down, not the bottom up as bottom up results in tactical solutions that do not conform to the needs of the business over time.

I know this last statement is controversial. After all, it’s difficult to accept that if you develop using good component-oriented approaches that you can’t retrofit today’s bottom up for tomorrow’s bottom up. But, the fact is that bottom up expresses the “how” not the “why” and the “how” is limited by the subjective reality of the person(s) providing the information. However, truly understanding the business allows the architect to design to an objective goal that can be presented in whatever subjective ways is needed today.

But, let’s revisit my opening premise that implementing SOA designs today is complex, clumsy and fraught with sandtraps. I believe the complexity stems from the fact that SOA works best and is most easily aligned with loose-coupling when services are stateless. This means that the service retains no knowledge of the consumer prior to or post usage and has no assumed context of the consumer.

Moreover, a service should operate in a deterministic manner and the consumer should make no assumptions that the service will operate differently based on same context. Most importantly, if any part of the implementation is implicitly linked to any other service’s or application’s implementation, then it may not maintain the ability to switch contexts as needed based on the consumer.

In many cases, statelessness is in direct opposition to the goals of business applications, which are rich in user context and assumptions of their environment. Reporting, security and governance are excellent examples of features that are hindered by moving to a loosely-coupled services architecture and, if implemented in a way that leans too heavily toward one particular application’s requirements, limits the service’s ability to operate in multiple application contexts.

For example, if a service uses a single database table that has relationships with other tables (e.g. foreign keys), and the service has no use for the data in those related tables, but yet the database is going to enforce data integrity when this one table is operated upon, thus forcing the service to be cognizant of those relationships, then loose coupling is broken simply based on the virtue that a consumer is forced to be aware of information that is outside of the scope of the service.

Additionally, there has been a strong emphasis on reuse with regard to SOA, to the point where reuse has become the single, determining factor for defining a service. However, reuse is a completely orthogonal issue to SOA. Reuse is driven by two factors, levels of specialization and interface. Low levels of specialization will drive reuse, however, high-levels of specialization do not necessarily invalidate a service design—it just makes it less reusable. An interface is merely the entry point for communication. Thus, we can create reusable components that cannot operate without the consumer’s explicit knowledge of other areas of the system, for example, a program ID, and because of these constraints disqualify it from being loosely-coupled, and hence, not a service in the sense of SOA.

I believe if you review many of the systems that today call themselves SOA you will most likely find service-enabled applications comprised of reusable software components and Web Service interfaces. Because many of today’s SOA platforms do not yet provide the necessary means to really enable true loose-coupling without sacrificing things like data integrity across services, implementing SOA designs today often requires concessions that make the resulting service less sustainable.