| QUESTION & ANSWER |
Thomas Erl on why we should focus on service-orientation more than SOA |
 |
By SearchWebServices.com
19 May 2006 | SearchWebServices.com |
|
|
Following some of the recent attention surrounding concerns about how SOA is being defined and perceived, we asked noted author and industry expert Thomas Erl for his comments. In the following exclusive Q&A with SearchWebServices.com Thomas explains why he thinks the industry is focusing on the wrong issue.In your line of business, you work exclusively on SOA projects plus you've authored several books about SOA. What are your comments regarding some of the recent remarks made about the use of the term "SOA" and the state of Web services?
Thomas Erl:
I appreciate the frustration people have with the rate of progress in the Web services industry. The convergence of the WS-* specifications we envisioned years ago is taking longer than expected and it's testing the end-user community's patience. I also understand how annoyed people are getting with the manner in which the term "SOA" has been used and abused. One of the first things we tell our clients is to approach the SOA marketplace with caution and skepticism. The branding of a product with "SOA" has little significance right now because of the wide spread ambiguity of the term.
Is SOA then just a marketing buzzword with no substance?
Erl: 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?
Erl: 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?
Erl: 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?
Erl: 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"?
Erl: 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?
Erl: 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.
|
|
|
|
