Frank Leymann is a full professor at the University of Stuttgart and co-author of many Web Service specifications, including WSFL, WS-Addressing, WS-Metadata Exchange, WS-Business Agreement, and the WS-Resource Framework set of specifications. He was one of the driving forces behind BPEL4WS. Together with other researchers, he has published a paper proposing a research roadmap for service-oriented computing.
InfoQ's Stefan Tilkov recently had the chance to talk to Frank about the roadmap, REST, WS-* standards, and SOA in general.
InfoQ: Some may say the first research topic in a SOA research roadmap should be to come up with an exact definition of SOA. Do you see this as a a problem, too? Or do you feel the definition provided in your roadmap reflects consensus?
FL: Well, there are many terms in computer science and IT that are not precisely defined. Nevertheless, the technologies that are developed around these terms have deep impact on research and industry. Examples are terms like "component", "Grid", or "business process". So, I think it is not a problem in case a term is not exactly defined. In addition to that, I think there is enough common understanding in the community about what "SOA" means, and we tried to reflect this common understanding in our roadmap.
Please note that our roadmap is about "service oriented computing (SoC)", i.e. the compute paradigm behind service-orientation. Service Oriented Architecture (SOA) is an architectural realization of this compute paradigm. You may compare this with "client/server computing" as paradigm and "browser/web server" or "DB-client/stored procedure" as two (of various other) architectural realizations of this paradigm.
InfoQ: Can you explain your reasons for creating this roadmap? What are your expectations?
FL: The main reason is to provide criteria to help focus research efforts. It is our strong belief that service orientation will have strong positive impact on IT in particular and industry in general, and how business will be performed in future. Thus, we want to describe the major research areas that we think have high potentials to make that happen faster and based on insight into potentials and limits of SOA.
InfoQ: How mature is SOA, in your opinion?
FL: We have to clearly distinguish between SOA and Web Service specifications - sometimes, both are mixed up: SOA is an architecture, Web Service specifications define an interoperable platform supporting a SOA.
SOA is not completely new. Some individual aspects of SOA are used in practice for a long time. For example, take a look at "loose coupling": Enterprises are using reliable messaging technology since decades to integrate applications, i.e. to loosely couple them. Don't get me wrong, there are new concepts in SOA, e.g. concepts resulting from the combination of concepts put together in SOA, i.e. they result from emergence.
Web Service specifications make the corresponding technologies available cross platform. I.e. the corresponding specifications do not invent fundamentally new concepts but define how these concepts and corresponding implementations work in heterogeneous environments. The resulting interoperability is groundbreaking, making SOA real.
In summary, SOA is a mixture of mature things and new emerging things.
InfoQ: In your opinion, are there any problems so critical that they must be solved before one should consider a move towards SOA?
FL: I think what you really want to ask is: "Can I introduce a SOA today in my enterprise?". And the conclusion from the above is: "Yes you can, but you have to take a look at individual technologies and concepts checking their maturity. In that sense, it depends on your functional and non-functional requirements, on your business problem whether you can move to SOA today. But there are a bunch of problem domains where you can move today...
If you insist in one or two subjects that I personally consider critical: Solving issues in the management of collections of services, especially cross enterprise, including SLA issues, pricing, trust, etc etc., as well as determining non-functional properties of composition of services is a fundamental issue.
InfoQ: You seem to focus very much on the standards and specifications in the WS-* space. What do you think of them? Can you understand some of the criticism surrounding them?
FL: I think that these specifications and standards are a major step forward. They allow to make SOA in heterogeneous environments real.
But, yes, I do understand some criticism, e.g. the large number of specifications in this space, or sometimes competing specifications. The reason why there are so many specifications be must better explained. It has to do with modularity and composability of these specifications; and this is by intend to allow a phased roll-out of implementations and to avoid reinvention of the wheel.
And the fact that the specs are difficult to comprehend (a colleague of mine called them "Dense like plutonium") result in some criticism. But this is in the nature of the problem: Ensuring interoperability in heterogeneous environment is not trivial!
InfoQ: What's your take on REST?
FL: REST is a possible style to implement a SOA. Especially if your application deals with large messages, or will benefit from caching, or has to render results immediately to end users, etc then a REST-based SOA does make a lot of sense. If you need to expose application specific interfaces, if you need message security along a message path with varying transport protocols, if you need choreography etc etc the WSDL/SOAP/... based SOA is preferable.
So, REST/SOA is not an either/or as some people tell. It's a matter of the requirements you have. And some problems can be solved based on both bases.
InfoQ: Terms like "Web 2.0" and "SOA 2.0" don't appear in your paper. Should they? What do you think of them?
FL: We could not mention or comment on each term in this space. We are focussing on stable concepts, not on moving "version numbers".
Web 2.0 is about community collaboration based on Web technology. It has a lot to do with user interface aspects. SOA itself does not focus on these aspects - its about application interaction. But services built based on a SOA can be used from an AJAX client, for example. Web 2.0 applications can be created exploiting services. In this sense, Web 2.0 and SOA are orthogonal.
I was quite astonished about the term "SOA 2.0". SOA 2.0 wants to fold concepts from Event Driven Architecture (EDA) into SOA. But EDA -in its heart- is about publishing messages to subscribers: Something that is already an integral part of SOA today (see the OASIS work on Web Services Notification, for example). Thus, there seems to be consensus in the SOA community that event mechanisms are needed in SOA.
InfoQ: Thank you very much for your time.