I was looking at the OASIS SOA RM's definition of SOA today. It defines it as "... a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains". It appears that a key part of that definition is "under the control of different ownership domains".
So this begs the question, are you building an SOA if what you're building is within the scope of a single application? (If you want to get nitpicky and parse the definition then the answer would always be no because it defines it as an architectural paradigm and you can't "build" an architectural paradigm. But in this case I'm referring to SOA as an instantiation of a system designed using that architectural paradigm.) A lot of times you hear people talk about taking a single existing application and modernizing it to create an SOA. Are they really creating an SOA in such cases? Perhaps the question should be if you're not trying to organize and utilize distributed capabilities that are under the control of multiple ownership domains, then why are you building an SOA?
Are there other scenarios that may be valid? I think so.
A few years ago I was working for a company where we were creating a satellite command and control application. It was a CORBA-based system and we were following all the principles and design tenets of SOA such as loose-coupling, separation of concerns, interface-based development, etc., etc. We were also using the CORBA Naming Service, which can be considered a registry. There were a set of core satellite command and control services that were used by multiple client apps that made up this application suite. It was a relatively large distributed system that allowed an organization to control a fleet of satellites. Looks and smells like an SOA, doesn't it? But this was a shrinkwrapped product and we never designed it to support the notion that the core services would be under the control of multiple ownership domains ...
soa
Subscribe to:
Post Comments (Atom)
Posts
2 comments:
The key word is "may" they don't have to be under different controls. So thinking about your product example, when someone else used it then in effect they used services that were in many ways under your control.
Different organisational controls aren't mandated by the SOA RM, but what it is saying is that this is an important consideration that needs to be allowed for.
What did you think of the rest of it?
Steve,
Agree, I did notice that the key word is "may". So the part about "being under the control of different ownership domains" is certainly optional. But if that part of the definition doesn't apply, then what do you have left in the definition--"a paradigm for organizing and utilizing distributed capabilities". In this case, just about any distributed system out there can be considered an SOA and I'm sure we can all cite examples of distributed systems we've built in the past that we would not consider SOA.
I will admit that it doesn't do the document justice because I'm taking this definition out of the context of the rest of the document which does a good job of further clarifying SOA. However, I just think there are other concepts of SOA discussed in the document that are more unique to SOA that should have made it into the "one liner definition" instead of the optional part about being under different ownership domains.
For example, the concepts of visibility, interaction, and effect are used heavily throughout the rest of the document to further explain SOA. I would have preferred to see the key notions extracted out of those and put into the one liner definition.
-Tieu
Post a Comment