SaaS service vs. SOA service

"Service" is a horribly overloaded term that means many different things to many different people in many different contexts. No wonder there is so much confusion over the term Service Oriented Architecture!

One instance of this confusion manifested itself in a discussion I had with a collegue regarding whether there was any specific interplay and bleeding of the lines between SaaS and SOA. Both terms include our favorite word... service. And in fact, many SaaS providers expose Web service (there's that word again) interfaces as integration points, which has led some people to believe that using a SaaS application delivers you an SOA.

To clarify, "service" in the context of SaaS refers to a software delivery model, as opposed to an architectural entity. In the context of SOA, a SaaS application is architecturally identical to any third party application that is hosted in house. The integration capabilities are often similar. Most third party business applications expose Web service interfaces, as do most SaaS applications.

Such an application (SaaS or otherwise) could potentially behave as all or part of a service in the context of an SOA. Even so, you would want to wrap the application's Web service interface with an integration layer that provided richer messaging capabilities (such as guaranteed once-only message delivery and publish/subscribe) to the rest of your enterprise.

So in conclusion, you can utilise SaaS applications in your enterprise and have no SOA, you can have an SOA with no SaaS applications, or you can have both. They really are orthogonal concerns, with SOA being an architectural style, and SaaS being a software delivery model.