SOA Terminology and the SOA Reference Model of OASIS

Transcription

1 SOA Terminology and the SOA Reference Model of OASIS Building up a shared vocabulary for the essential concepts of SOA, in spite of the hype. Borjan Cace The vocabulary we use to communicate about Service Oriented Architecture is vague and is causing confusion. The negative effects caused by the lack of precision are most obvious when we communicate outside of the community of SOA professionals. The SOA Reference Model of OASIS provides a solid basis for the needed shared vocabulary but the reviewing has identified some shortcomings. This article elaborates on these shortcomings and emphasizes the importance of four concepts commonly denoted by the terms: service, contract, interface and operation. Additionally, these terms are compared to the terms formalized by W3C. Introduction: Why write more on SOA terms and definitions? At first glance, yet another definition of SOA and it s elements appears superfluous - SOA is a big hype and many explanations of SOA terms have been made available to us already. One has just to enter SOA+glossary into Google to find enough to browse for hours. Well, that very hype has triggered me to write this article. The texts on SOA proliferate on the Internet, congresses and seminars. Everyone is talking and writing about SOA, but the language being used is vague and there is a variety of viewpoints taken on SOA. This is often confusing and misleading. Being a field practitioner of SOA, I ve witnessed (and have suffered from) misunderstandings arising from unmatched usage of terms. It appears that we are not really sharing the same vocabulary. Moreover, I am not dealing only with fellow SOA insiders but also with people whose interests and knowledge are different from mine. It is a part of my job to address their concerns, understand their perspectives and discuss their issues. The language used is also often unsuitable for the intended audience. For example, there are articles intended for non-technical people that use the term operation. May we expect that someone non-technical properly understands what is meant by that term (unless the same article explains the meaning of operation in the context of SOA)? Another problem appears when one uses the word service for referring to an individual function of the service (where the term operation would be appropriate). Other confusing phenomena are the statements from some consultants that claim that Web Services are not SOA. This might be a strong sales argument in attracting potential customers, but gives me a headache when my customers ask me to explain what it actually means. They do not understand - neither do I (actually, I believe that my colleagues want to stress that SOA is more than WS ). January

2 Among peers we may allow for leeway in the usage of terms. The exact meaning will be clear to all involved because of their shared professional knowledge. However, this does not work when communicating with other audiences. This article aims to capture the essence of SOA terminology in a minimalistic set of definitions. It is not the intention to provide an introductory text but to feed the discussion on terminology among professionals. For this I rely strongly on the Reference Model for SOA issued by OASIS. After reviewing this model and discussing its shortcomings I argue for more reliance on the practice. The next section emphasizes the essence of SOA solutions by elaborating on four high level concepts: service, contract, interface and operation. The section that follows defines those concepts by referring to additional sources. These definitions are additionally compared to the specialty definitions from the world of Web Services. SOA Reference Model of OASIS OASIS has tackled the absence of a shared language and the common understanding of the matter by producing the Reference Model for Service Oriented Architecture (SOA-RM, [OASIS, 2006]), the document that has the goal to to define the essence of service oriented architecture, and emerge with a vocabulary and a common understanding of SOA. This is a very studious work and is no doubt a solid reference point for everyone involved in SOA. However, in my opinion, the named goals have been only partially achieved. My points of dissatisfaction with SOA-RM are the following: a) The document is scarce in examples that clarify how the real-life SOA fits into the model. It would have been appropriate to show how this reference model encompasses some implementation choices, like Web Services. I agree with the authors that Web services are too solution specific to be part of a general reference model. It is indeed true that Web Services are solution specific, but having a reference model that is not clearly related (by examples) to at least one real-life technique is impractical and confusing. Both SOA definitions and the Web Services definitions rely on the same terms: service, contract, policy The idiomatic usage in SOA-RM should be strongly related (if not identical) to the existing usage in the context of Web Services. It would have been very helpful if the terms contract, interface and policy were related to WSDL, this not as a part of the reference model itself, but in an example. b) The model intentionally avoids the thorny issue of loose coupling. I agree with the authors that the term loose coupling means different things to different people, depending on their point of view. Moreover, coupling is a software design term and as such is not unique to the context of SOA. However, coupling should have been given more attention in the reference model because of its importance. Although the SOA techniques usually solve the problems of technical coupling, logical coupling remains an issue. It would be easier to discuss and quantify the logical coupling between interacting components if the reference model had stressed the importance of it. c) Equally, the model does not provide enough conceptual ground for another thorny issue, the service granularity, because the model lacks the concept of operation. The model elaborates on Interacting with services and introduces the Action model : The action model of a service is the characterization of the actions that may be invoked against the service. The term operation that is rather common elsewhere, even within the OASIS community, is not used. For example, in the SCA Assembly Model V1.00 (page 81), also published by OASIS we can read that: A service represents an addressable set of operations of an implementation that are designed to be exposed for use by other implementations or exposed publicly for use elsewhere (e.g. public Web services for use by other organizations). The operations provided by a service are specified by Interface [OASIS, 2007] January

3 This provides us with a term (operation) suitable to be used in discussing granularity, also when talking to business consultants. Another example from practice is a simple and effective definition of Pierre Reldin and Peter Sundling in their master thesis at Linköping University, Explaining SOA Service Granularity : Each service in an SOA is a collection of operations. An operation is the callable part of a service [Reldin&Sundling, 2007]. To summarize: I believe that the term operation denotes a high level concept that belongs to the reference model. d) Some statements in the reference model are disputable. d1) Chapter Interacting with services begins with: Interacting with a service involves performing actions against the service. In many cases, this is accomplished by sending and receiving messages, but there are other modes possible that do not involve explicit message transmission. For example, a service interaction may be effected by modifying the state of a shared resource. Modifying the state of a shared resource may be a legitimate way to interact, but as such does not belong to SOA. d2) Chapter A worked Service Oriented Architecture example indicates that the authors consider the scope of SOA going beyond the software, namely that SOA also covers aspects of business that do not involve software. The example provided in that chapter explains how a utility company provides electricity as a service. That may be a nice analogy, but no more than that. The importance of SOA is that business activities are being accomplished by software entities that act independently on behalf of their owners. For example, an Internet site owned by a travel agency can book a flight for you with the airline of your choice. That is an SOA solution. Businesswise, the same has been possible for 30 year, but it required the help of an employee of the agency. That person had to sign into the reservation system of the airline and to interact with that system. That was not SOA, regardless of the fact that the business services were being offered and consumed in much the same way as today. d3) Chapter 2.2 How is Service Oriented Architecture different? compares SOA with Object Oriented Programming paradigms in a way that is unnecessary, misleading and at least so far the Object Orientation is concerned, wrong 1. Disregarding this list of negative remarks, the Reference model of OASIS still provides us with a solid fundament for the proper SOA terminology. In the remaining part of this article I will try to add clarity by using additional sources. What is SOA? The Reference model of OASIS defines SOA as follows: Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. Starting from here, we need to clarify that: 1. Distributed capabilities means that SOA is concerned with software components. Those components have independent life-cycles and interact in a certain way which we call service-oriented : some components offer services (sets of individual functions called operations) and other ones (service consumers or clients) are consuming those services. SOA is an architectural style that focuses on leveraging those service-oriented interactions. 1 Disputing this chapter of the SOA-RM would require substantial elaboration and is a separate issue. That would go beyond the subject of this article; therefore I have to refrain from doing that in this text. January

4 2. The interacting software components may be under the control of different ownership domains. This means that the components have independent life-cycles and the level of coupling should be minimized, i.e. the components in SOA must be loosely coupled. The fundamental aspect of loose coupling" in SOA is that the service interfaces are defined as separate entities and that the usage of these interfaces is further formalized in contracts. 3. SOA is a solution in the context of business applications, i.e. the software that is a part of information systems in businesses. In that context, the central issue being addressed is the capability to expose specific business functionality as a set of software functions and to have that business functionality consumed by other software components. This introduces 4 terms: service, operation, interface and contract, which brings us to the terminology: what is the meaning of those terms in the context of SOA? These definitions follow. To make my contribution to the SOA vocabulary more practical, I ve extended each definition with a specialty definition narrowed to the context of Web Services (this by viewing the Web Services standards as a set of implementation constraints on SOA). All those definitions are quoted from W3C sources. SOA terminology Service A service is a coherent unit of business functionality accessible through programmatic interfaces. This definition has been based on one of the definitions of Gartner Research [Gartner, 2007]. It importantly stresses that: Any service concerns business functionality. services are accessed via programmatic interfaces, i.e. that the business functionality is made available by software. A service is an abstract resource that represents a capability of performing tasks that represents a coherent functionality from the point of view of provider entities and requester entities. To be used, a service must be realized by a concrete provider agent. [W3C, 2004b] Operation An operation is an individual function of a service associated with a single consumer-service interaction. For example, there is a Booking service of a hotel chain implemented as a part of the reservation system. This service can be accessed via two operations: CheckAvailability and MakeReservation. The functionality of the first is to return the availability status corresponding to the input parameters of the invocation (date, duration, type of the room, number of occupants, etc). The second operation does the actual reservation. A set of messages related to a single Web service action [W3C, 2004a]. An operation is an interaction with the service consisting of a set of (ordinary and fault) messages exchanged between the service and the other parties involved in the interaction [W3C, 2007a] Interface Interface is a machine-readable description of the service s abstract functionality, provided in a platform-independent form. January

5 In Wikipedia (Computer Science), we can find the following definition: An interface defines the communication boundary between two entities, such as a piece of software, a hardware device, or a user. It generally refers to an abstraction that an entity provides of itself to the outside. This separates the methods of external communication from internal operation, and allows it to be internally modified without affecting the way outside entities interact with it, as well as provide multiple abstractions of itself. It may also provide a means of translation between entities which do not speak the same language, such as between a human and a computer. [Wikipedia, 2007] A WSDL 2.0 interface defines the abstract interface of a Web service as a set of abstract operations, each operation representing a simple interaction between the client and the service. Each operation specifies the types of messages that the service can send or receive as part of that operation. Each operation also specifies a message exchange pattern that indicates the sequence in which the associated messages are to be transmitted between the parties. [W3C, 2007a] Contract A Contract is an expression of visible aspects of Service behavior. [Microsoft, 2000] A contract is the service interface specification accompanied with an additional set of requirements and constraints that must be agreed between the client and the service. Thomas Erl (author of several popular books on SOA) uses this wording, A service contract is comprised of one or more published documents (called service description documents) that express meta information about a service. [Erl, 2007b] W3C does not provide an explicit, glossary-style definition of a contract. However, the concept of contract is considered essential to Web Services: contract represents the overall agreement between the requester entity and the provider entity on how and why their respective agents will interact, it is not necessarily written or explicitly negotiated. It may be explicit or implicit, oral or written, machine processable or human oriented, and it may be a legal agreement or an informal (non-legal) agreement. [W3C, 2004b] One may argue that any service description conforming to (a version of) the WSDL standard actually represents a contract. This cannot hold; the service provider and the owners of the consuming applications usually agree additional requirements and constraints that augment the WSDL description. Therefore the combination of these two constitutes the contract. If we would constrain the interaction in such a way that only the machine-readable agreements would be allowed, then the argumentation would be different. WSDL descriptions would become contracts, as there would be nothing else beyond it. In practice, this holds for the anonymous interactions on Internet, where the machine-readable WSDL description is the only agreement between the consumer and the service. January

6 Figure 1: Elementary SOA terms Conclusions The SOA terminology will converge but it will be a long process hampered by the ongoing SOA hype. I view SOA-RM as a step in the right direction, but there are some deficiencies and disputable points of detail. There are no discrepancies between the general SOA concepts and the Web Services concepts; the definitions in the context of Web Services are indeed specialty definitions. The terms denote exactly the same concepts, with the only difference that the Web Services definitions are narrowed by the implementation constraints. Will the definitions I ve put forward help to take away some of the confusion? I believe they will, but I would also like to stress that I m not advocating some kind of rigid language in our profession. That is not needed as long we are involved in a professional debate among peers and are discussing concrete issues. Then there is no harm done if we, for example, use the words message or method when actually referring to an operation, even in writing. More rigor is needed when we communicate with other professions, like business analysts and management on one side and developers on the other. And that is, probably needless to say, what architects do (or should be doing) regularly. Borjan Cace CaceConsult borjan.cace@ieee.org References [OASIS, 2006] Reference Model for Service Oriented Architecture V1.0 OASIS, Committee Specification 1, 2 August 2006, January

7 [OASIS, 2007] SCA Assembly Model V1.00, OASIS, March 2007, [Gartner, 2007] [Microsoft, 2000] [W3C, 2004a] [W3C, 2007a] Natis, Y., Applied SOA: Transforming Fundamental Principles Into Best Practices, Gartner Research Note Id G , April 2007, Schlimmer, J. and Young, K., Expressing Requirements and Capabilities for Web Services, Microsoft Corporation, September 2000, Web Services Glossary, W3C Working Group Note 11 February 2004, Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, W3C Recommendation 26 June 2007, [W3C, 2007b] Web Services Description Language (WSDL) Version 2.0 Part 0: Primer, W3C Recommendation 26 June 2007, [W3C, 2004b] [Erl, 2007a] [Erl, 2007b] Web Services Architecture, W3C Working Group Note 11 February 2004, Erl, T., A W3C Web Services Glossary, Web Site by Thomas Erl, Erl, T., SOA Glossary, Web Site by Thomas Erl, [Reldin&Sundling,2007] Reldin P., Sundling P., Explaining SOA Service Granularity,, Master Thesis LIU-IEI-TEK-A--07/0090 SE, Linköping University, [Wikipedia, 2007] Interface (computer science), Wikipedia, January