I would not consider "SOA" as a term without substance. It's quite the opposite. It's a term that has been allocated too much substance, which is another reason it causes so much confusion. An architecture is not a computing platform, nor is it a design philosophy or an implementation technology. Depending on your sources, you will find SOA as a label for some or all of these things and more. By assigning it too much meaning, it loses meaning and definition. Yet the vendor community is still moving ahead with their respective SOA platforms. How do we address this issue?
Well, instead of introducing new terms and acronyms, I think we need to take a step back and look at what lies at the core of how distributed computing has evolved. There has been a very deliberate shift from how we designed distributed systems in the past to how we can approach their design today. This shift has been the result of technology innovations coupled with new industry practices.
We are in a position where we can begin to leverage these advancements in order to pursue some of the more elusive goals in IT (increased reuse, agility, federation, interoperability, etc.). To do so, we need to design a different, more suitable set of characteristics into our distributed automation logic. For this, we need a design paradigm that defines and organizes these characteristics into a set of industry principles. This is what service-orientation provides us with.
I believe the end-user community would benefit by focusing more on service-orientation and less on SOA. By that I mean understanding the objectives, benefits and requirements of the design paradigm and assessing how and to what extent it can help an organization fulfill its strategic goals. With that knowledge, you put yourself in a position to better assess the vendor marketplace and locate the technology and products most suitable for realizing your goals. With that perspective, the ambiguity around SOA loses its significance and its confusion potential. So how does Web services relate to service-orientation?
Web services provide an implementation option for the automation logic to which we can apply service-orientation. You can build service-oriented EJBs or .NET assemblies and you can choose to expose them as Web services if you like. As we know, Web services are attractive because of the open communications framework they establish. But, if the lack of WS-* support is too limiting, it will not prevent you from pursuing service-orientation with other technology platforms.
What is important is that we keep the service-orientation paradigm as well as the service-oriented architectural model separated from the technology. This establishes a healthy abstraction that gives us the freedom to standardize on a paradigm and a specific type of architecture while continuing to leverage new technology advancements. If WS-* does ultimately fail or if something superior supersedes it, our enterprise architecture will not need to be reinvented because we will not have defined it solely through the technology or through a specific vendor product roadmap. Any further thoughts?
When we look at the term "service-oriented architecture" as it exists today in the IT mainstream, we need to concentrate on the "service-oriented" part. More important than asking the question "What is SOA?" we need to ask "What does it mean for something to be service-oriented?" This question is answered by understanding the principles of service-orientation Does this mean we need to retire the term "SOA"?
No, not at all. We only need to put it into perspective and stop using it to represent Web services and service-oriented computing in general. If the industry continues to allow this misrepresentation, it will only lead to more confusion, which benefits no one. There's one more question I just have to ask: What's your definition of SOA?
I've always maintained that service-oriented architecture is a form of distributed architecture for automation logic that has been designed in accordance with service-orientation principles.