Service Component vs. Reusable Component: Patching

I'm discussing what makes services better than components. I've discussed the differences between patches, refactorings, and enhancements. Two points I made is that patches are inevitable and need to be deployed quickly, easily, and frequently. OK, what does that have to do with SOA?

Reusable Components

First, let's consider the component model for reusable code. You develop a set of calculator component that performs math functions. To make it easily reusable in any context, the code needs to work as a set of context-free methods. (If the code doesn't work this way, it needs to.)

If you're using Java, you package these classes up in a Jar file. If you're using Java EE, you add this Jar to the Ear with the application that uses it and deploy the Ear. Hopefully your calculator component is super useful and so ends up getting used by dozens of different apps. This means the Jar is included in dozens of different Ears deployed on lots of different servers, perhaps in multiple geographical locations. Cool component; you're a hero.

Don't get too smug. Someone will find a bug in your component. Perhaps it doesn't divide correctly. (Seem far fetched? The first Pentium CPU had a significant division bug!) Now people are all uptight that your component has a bug, and you need fix the bug pronto. This means not only developing a patch that fixes the bug, but issuing/deploying the patch as well.

Deploying the patch is where your component's popularity becomes painful. How many apps are using the component? Even once you find them all, you need to apply the patch to each one's Ear file and redeploy. Redeploying the Ear often means stopping and restarting the app, which is a real pain for anyone planning to use it 24x7 (and a real pain for the development team whose bonus is tied to 99.9999% availability). With clustering, you can minimize interruptions using rolling deployments; then just hope you don't have some users still experiencing the bug while others no longer do.

So with the reusable component model, a simple bug requiring a simple patch becomes a major pain to deploy. That's because all of the apps have to be patched, a worse yet probably need to be patched while the users are using the apps. Have fun.

Service Components

Now we come to the part where I say SOA is better. (Either that, or I'd better rethink the intro to this conversation.) So how do service components help here?

Your code starts off the same. You still have a calculator component, and it still goes in a Jar file and ultimately an Ear. But it doesn't go in the Ear for the application that's going to use it. It could go in that Ear, but it's better to deploy it as a service in its own Ear (or an Ear that only contains this and other service providers). We've already established that the public API methods are context-free. To deploy it as a service, you need to add some Service Activator-type code for invoking it remotely (via HTTP, JMS, etc.). Then you deploy it in a server; the server provides a fixed address for invoking the service, enabling any client to run your component.

Again, someone finds a bug and you need to patch your component. Now, rather than having to track down all of the applications that are using the component and patching them, you just need to patch the service provider. Although patching the provider may require restarting the service or performing a rolling redeploy, this won't affect the consumer applications as long as they can block while the provider is briefly unavailable. So the consumer application can more easily keep running 24x7 because they aren't actually being patched, just the provider is.

Conclusion

So patches are inevitable, and it's easier to patch a service than to patch every application that's using the functionality. That's one of the advantages of SOA.