Lessons in SOA

Although I agree with the comments of George Carey about this article, I wanted to add a little personal experience to the underlying theme of the article that a SOA needs to be based on a loosely coupled abstraction layer. This is absolutely critical. Why? Because services can easily turn into a maintenance headache that is, "write once, maintain forever."

Coming from EJB/JSP-land, it's not initially apparent that point-to-point services are bad. Both Microsoft and Sun are selling how easy it is to produce and consume web services. But it becomes obvious over time that you're actually writing a public API rather than remote procedure calls. This is a significant shift in thinking and practice and shouldn't be underestimated. Under the basic constraints of API development, service signatures cannot change and contracts can't be broken. This can lead to versions of methods like getDocument(int) and then getDocument2(int, boolean), etc. Then in the future when a bug is found, you may end up maintaining getDocument() and getDocument2(). Of course we strive for proper encapsulation, but sometimes even good encapsulation cannot prevent the possibility of breaking a contract. So then you may even wind up maintaining different versions of compositions that basically perform the same task. Or, in the unlikely event that a database primary key changes, it may reverberate all the way through the system unavoidably breaking a contract. And even in a system with relatively few web services, this amount of maintenance can quickly become unacceptable.

My point is that in order to be successful with a SOA, you probably need to put even more work up front in design and more forethought in policies such as managing deprecation. And I understand that implementing a SOA is different than implementing a few web services. But as this article points out, this fundamental understanding needs to get to the core of an organization before the "if you build it, they will come" mentality.