Who Put the S in SOA?

The problem with TLAs ("Three Letter Acronyms") is only second the problem caused by the CI's ("Computer Industry's") tendency to overload terms.

On the SRP post, one reader commented that the term "Responsibility" is problematic, because it overloads the "responsibilities" used in CRC-based analysis (see the comment for more details and my response)

Overloaded terminology adds to the confusion around SOA ("Service-Oriented Architecture"). For one there are "windows services" (thankfully in Unix/Linux we call them "daemons" so we're better off). Another overload, shared by many people, is that service is just a term for a software function (for example, SQL Server Notification Services, or "log service", "persistence service" and so on). This assumption, by the way, helps propagate the misconception that "web services" = SOA. I've seen it happen many times that people think that if they slap a web-service API on an application they are on the way to SOA nirvana. Well, that is just plain wrong. What Web services does is to allow exposing methods for remote consumption over HTTP. This can be used to create bona fide SOAs but also to create good (?)-old RPC style systems.

So, what are the Services in SOA?

The services in SOA are business functions--Accounts Receivables, Shipping, and so on. Thus, SOA means architectures that enable alignment of software components/agents to business functions. A service needs to be a cohesive (appropos SRP) bundle of objects, excecutables, and that likec that cover and encapsulate a sepecific business area.

Again, I'll further develop it when I'll explain why I think SOA is an architecture style.

Posted by Arnon Rotem-Gal-Oz at 06:04 AM  Permalink