Service Oriented Gridlock: Code Reuse vs. Service Reuse

One of the oft mentioned advantages of SOA is that it provides a clean mechanism for code reuse. However, this is not strictly code reuse. In SOA, the reuser is reusing the actual running service. In code reuse, I take your library and embed it in my application. In service reuse, I call your live, running service from my application. In code reuse, if your application crashes, or the whole project is cancelled, there is no effect on me. In service reuse, I am entirely dependent upon the performance characteristics of your application. Think about the interdependencies ofa few three nines (99.9% available) applications- the availability of all of them drops. If one dies, they all could. Therefore, the "code reuse" argument for SOA is completely spurious. That's not to say that applications should never be integrated, but it shouldn't be done simply to reuse code.

The standard SOA response to dependency is indirection. In order to not create a hard dependency on your system, I use a third system (a service registry or directory) to look up the physical address of a service that offers the service your system provides. However, in your streamlined SOA, you have probably eliminated redundant applications, so there is nothing to switch to when your app is down. And now I am dependent on the service registry as well.