SOA does not mean agnostic

As a follow up to our last post about the nature of SOA, I wanted to speak to a common misconception. Here are two statements I hear with all-too-common frequency:

1) SOA is about masking the route to a service from its implementation.

2) The underlying transport protocols used in SOA should always be hidden.


It seems in technology there is an ever-pervasive interest in adding more and more layers of indirection. Its a situation where if we don't understand the reason for such layers, we can quickly add unnecessary overhead and complexity to otherwise simple problems. In the case of the above statements, the underlying goal -- to create flexible implementations while masking details from a service user -- is a good one, but without understanding the nuances involve, the commonly heard refrains noted above are in gross error.

Let's address point one. It's true that things like UDDI and other kinds of service discovery help us to change the location or even implementation of our services, but let's be clear that implementing UDDI is not a primary goal of SOA, rather a by-product of an implementation approach. You can do SOA without having an intermediary routing requests between service providers and service consumers; you will simply have a more tightly coupled implementation. To be clear, there have been ways of creating this kind of indirection since long before the word SOA entered our lexicon.

Next we should address the idea of protocol agnosticism. If I had a nickel for every time I heard the statement "SOA masks the underlying protocol" I'd be retired. Let's reflect upon reality for a minute -- even if we ask a service directory for the means of reaching a service, we've made some kind of conscious effort to ask that that service directory, which innately means we've chosen a protocol. On a related example, if we offered access to a service over both message-oriented middleware and via http, we'd be forced to supply an sdk/api to service consumers that would mask the underlying protocol used. Whoops -- sdks? apis? Isn't that part of the very draw to Web Services in the first place, that is not having to support binary apis in multiple languages for all of our consumers? In the end, it's a fallacy and in some cases even undesirable to declare protocol agnosticism realistic or even a desired goal of SOA.