Is SOA just an implementation of Responsibility-Driven Architecture?

A response to my prior post on Responsibility-Driven Architecture got me thinking... what is the "first principle" that Service Oriented Architecture gives us that makes it "better" than simply COM?  Certainly, the four tenets do a good job of capturing the key distinctions.

 When I see a paradigm shift, I, like others I suspect, will often turn to others to get analysis and data, hoping to work my way up to understanding.  When I first heard about SOA, I looked for the distinctions and the reasonings, and SOA became appealing to me.

But if I look at the four tenets and ask "Why bother?" the answer comes up as the following, for me: to get our designs to routinely and repeatedly reflect the goals of Responsibility Driven Architecture.

In other words, if you were to ask "Why SOA?" the answer would be: to better partition our systems along the lines of a clear interfaces.  What makes interfaces clear?  Partitioning by responsibility.

Just as the alternator in a gasoline-powered-car has one responsibility, and only one, to generate electricity, and that allows considerable simplicity in both it's design and the maintenance of the overall system, a single part in a SOA only achieves the goal of loose coupling by sticking to a single responsibility and having limited, declared, connections to other components.

Leaves me to wonder: if I were to define RDA in terms of 'first principles,' what would they be?  I'll have to think a bit...