Of course, there is really no unanimously agreed-upon definition of what’s absolutely fundamental to SOA – or even what SOA really is. But I think there are four things that most people agree on and I think I there’s even a fifth:

To me, the first four core principles are:

·         Explicitness of boundaries [read: there’s stuff that is explicitly public and the rest isn’t],
·         Data exchange governed by an implementation independent message contract,
·         Compatibility of behaviors through negotiation of capabilities based on policies and
·         Service autonomy.

Number five is:

·         Locating and binding to a remote service is always indirect [read: the most important design pattern is the factory pattern]

I hear that there's quite a bit of amusement among the more senior Microsoft folks (and people like me) that there’s a lot of "reinventing COM" going on. It’s not that there’s a push into that direction. It just seems to happen. All of a sudden folks are playing with (differently named) variants of monikers, class factories and all those things. Say what you will, the IClassFactory indirection is great thing to have – one place to find a service, one place to configure a proxy, one place to sneak in a mapper/wrapper that makes the actual service you talk to look like another service.

(Note that I don’t mention SOAP here. Must a service use SOAP? How about services that fall back to something without angle brackets because their respective policies indicate that they can?)