The Community for Technology Leaders

Guest Editor's Introduction: Service Is in the Eyes of the Beholder

Tiziana Margaria, Potsdam University

Pages: pp. 33-37

Abstract—We are in the early phases of the service era, with visions and promises, and as a community we still seek the essence and characterization of service orientation.

Service orientation is not a technology; rather, it is an extremely wide-ranging philosophy or paradigm. It spans technical scenarios like back-end services—printers, faxes, or storage—telecommunications services, 1 and scenarios as high level as business processes 2 and day-to-day Web services for everybody. 3 Service orientation's wide spectrum of maturity mirrors this range.

In particular, in the telecommunications domain—the true birthplace of service orientation—structures, standards, and tools are far developed, approved in practice, and controlled by the "engineering discipline," with a clear focus on solid functioning and reliability. In contrast, the development of Web services—which arose some 10 years later, essentially independent of the experience in the telecommunication area—is mainly driven by the more far-reaching vision described by Charles Petrie: that of a worldwide wizard, who knows at any time, in any situation, everywhere, how to serve its customers best. 4 The technological realization of this vision, which comprises service discovery, dynamic adaptation of services, and planning, is still in its infancy and is dominated by effect-focused illustrative examples.

Evolutionary Solutions

This gap between vision and maturity leads to a classic pattern of evolution: the one from art to engineering. In computer science, the transition from art (one-of-a-kind, creatively handcrafted artifacts) to engineering (state-of-the-art best practices for industrial maturity) is omnipresent.

We have seen this transition happen over the past 20 to 30 years in compiler construction, software engineering, hardware design, and many other areas. At the beginning, there is always a vision, some illustrative, striking examples that indicate a need to satisfy or a pain to relieve (today we would say a service to deliver), accompanied by a huge gap between promise and reality, which over time is appropriately redirected, refined, channeled, and further developed until we are allowed to speak of it as a "solution." We experienced this transition concerning the World Wide Web, and the same gap is currently being experienced in the Web services world. We are in the early phases of the service era, with visions and promises, and as a community we still seek the essence and characterization of service orientation.

This situation is not too surprising, as service lies in the eyes of the beholder, the receiver of the service, whose expectations strongly depend on the context of service fruition. While it is tolerable to experience delays or waiting phases—for example, for online service discovery—when a user is in the search and gathering mode looking for information, such delays are not acceptable under stricter conditions: a booking must really be booked, and a bank transfer must really be transferred and to the right account. In these circumstances, everyone expects telecommunication-level response quality: correct, anytime, anywhere.

Despite all disparities, service orientation has one common agreed-upon mission: the beholder's participation. Users should be able to directly influence, control, and adapt the services according to their needs. At least for typical day-to-day situations, this should be possible without IT knowledge. Thus, service orientation potentially has a disruptive impact on the current structures. Its effect can be compared to the translation of the Bible into the common languages, which eliminated the need to master Latin or Greek and gave the general public direct access to the text.

An 80/20 Approach

Technically, we can regard service orientation as an 80/20 approach to process management that follows the "easy for the many, difficult for the few" principle. More effort is spent on the IT front end in terms of

  • radical virtualization of all the technical details unimportant for the service level;
  • loose coupling of services to enable a maximum of freedom of choice, orchestration, and evolution of services; and
  • domain specificity, to be directly usable by the addressed user community.

This effort, complemented by consequent standardization, directly increases the beholder's power. Johannes Helbig and Alexander Scherdin 5 nicely summarize the essence of the service orientation viewpoint as

The questions What is easy? and Who are the few? directly lead to a complex division-of-labor scheme, which is also reflected in the many subdisciplines such as SO architectures, SO computing, SO programming, and SO engineering 6 all contributing as communities of "fews" to easing the work of communities of "manys."

The Intelligent Network services' domain, which offered the first systematic definition and operational adoption of service orientation in industry, addressed these questions. The IN services' architectural stack clearly identified several well-defined layers of services—although the objects handled and produced at each layer had different names—with distinct responsibilities and roles. Each layer was in the hands of a specific group of experts with well-defined skills and competencies, equipped with normative guidelines within the IN family of standards (ITU-T Q.1200 series), 7 accompanied by a published description of interfaces and abstract behaviors that could be implemented in a vendor-dependent way but whose interoperability must be guaranteed and certified.

Service Levels

Looking at this structure from today's service perspective, we observe that we can easily map this architecture to the more general domain of enterprise services, where it also identifies distinct roles and responsibilities, and therefore a transparent division of labor, following a leveled "easy for the many and difficult for the few" pattern.

The equivalent of an end-to-end IN service like a virtual private network or universal personal number could be a cross-enterprise service such as supply-chain management, spanning several enterprises or organizations, with the definition carried out top-down by a company's officials according to guidelines like CobiT. 8 The definition here is coarse-grained in terms of component services that provide as services the aggregated functionalities and processes available at each participant's site. The location and detailed communication are abstracted away: What counts is what the coarse services provide and how they are orchestrated to yield a coherent whole. Service orientation's mission is to enable business/application experts (the many) to manage and control this level without requiring IT support (done by the few) for their day-to-day work.

The notions of the few and the many might seem irritating, as IT support teams often outnumber the teams of business managers, business developers, and business analysts. However, we consider the current situation as historically rooted, and it currently is a misconception, as in today's business landscape too many people are reinventing the wheel far too often. We are convinced that service orientation is an adequate paradigm to fight this misconception.

At the next level, the coarse services are refined as a layer of distributed processes that collectively implement the end-to-end process. Choreography plays a role here, and it also determines the next level of abstraction: identifying which local processes can be used to enact the distributed choreography. This requires knowledge of the organization's architecture, but should, after an adequate setup has been established, require IT expertise (support by the few) only in exceptional cases.

The local processes are finer-grained services that participate in several end-to-end processes. They are similar to the reusable features of the telecommunication domain, which are abstract enough to be understood by the users (the many) without knowing their implementation details and yet concrete enough to be quite directly mapped to a vendor's basic service offers (by the few).

At the bottom level, there is the collection of services that the available platforms offer: Whether they are communication or storage or office services, they are the finest unit of granularity for services and virtualize the platform's specification to their customers. This level belongs to the competence of software developers.

The "real few," however, are the people developing and elaborating the architecture outlined in Figure 1. It is their responsibility to make the division of labor effective, which means


Figure 1   The Intelligent Network service conceptual model planes.

  • constructing technological bridges between the four levels,
  • developing technologies to control the interplay between the different levels of abstraction, and
  • supporting and controlling service-level agreements for development time and runtime.

This establishes new and future-oriented job profiles that span application domains and IT: service engineers, business process architects, and engineers. They capture the needs of the business architects and engineers and set up the layered architecture, possibly according to agreed-upon blueprints.

A Faraway Vision

The goal of this special issue on service orientation is to contribute to the convergence of the currently scattered SO communities, a must when attacking the goals described here. A wider understanding of the common essence—not only between the subdisciplines of the service communities and maybe today's information systems/database community, but also with the state of the art of component-based design, programming languages, and distributed systems modeling—would benefit the transfer of methods, techniques, and tools between the different communities, building on the existing stable knowledge, instead of reinventing the wheel. This would also foster the development of a common global technology- and level-spanning structure similar to the domain structure now stably and successfully adopted in technologically mature engineering domains: for example, hardware design and telecommunications. Such a structure would clearly position technologies, competencies, and issues in the SO landscape, a necessary precondition when aiming at the concrete realization of the still faraway vision of the Web services community.

An analysis of the entire stack is still not available today. If carried out, it would more or less automatically highlight needs like descriptions of goals and contracts (perhaps by generalized service-level agreements), hierarchical decomposition, division of labor, granularity of design and provision, and many more, as a means of transferring the essence of modeling between the various levels. Reaching a consensus in the community on a stable organization of competencies is the most important point, as it isn't possible to adequately address issues like security, performance, and stability at a single level.

In This Issue

The contributions to this special issue on service orientation give a broad overview of this outlined landscape.

In "Service-Oriented Computing: State of the Art and Research Challenges," Michael P. Papazoglou, Paolo Traverso, Schahram Dustdar, and Frank Leymann summarize the state of the art and the research issues in the area of service-oriented computing, spanning foundations, composition, management and monitoring, and engineering.

"Evolution of SOA Concepts in Telecommunications" by Thomas Magedanz, Niklas Blum, and Simon Dutkowski recalls the birth and evolution of the concept of service orientation in the telecommunication domain, ranging from its inception and first operational adoption in the Intelligent Network added-value services to today's convergence of the communication platforms, including Web services via Parlay-X and next-generation networks.

The three short contributions by Jan Bosch, Stefan Friedrichs and Stefan Jung, and Johannes Helbig and Alexander Scherdin address the needs, solutions, and effects of service orientation in application areas as diverse as mobile telecommunication, e-government, and logistics. The rich span of alternatives, projects, and motivating needs illustrates how essential a domain engineering- driven approach is.

In "Toward the Realization of Policy-Oriented Enterprise Management," Matthias Kaiser discusses the current status of service orientation from the point of view of enterprises. Goal-driven business process composition based on the enterprise physics metaphor 9 should be generated on the basis of solid foundations that formalize Web service descriptions, business policies, and business goals.

In "Full Life-Cycle Support for End-to-End Processes," Bernhard Steffen and Prakash Narayan discuss this from the point of view of methodologies and platforms that support an end-to-end and round-trip engineering experience at the user level. The central idea here is the "one-thing" approach, which enforces semantic compatibility between the layers of Figure 2. This is a necessary precondition for enabling round-trip engineering from the top level down to the physical realization and back that does not suffer from conceptual gaps between the object dealt with at the different levels.


Figure 2   The business service stack: from end-to-end cross-enterprise processes to technical services.

"Component Contracts in Service-Oriented Architectures" by Francisco Curbera focuses on the (distributed) contracts between components of a service-oriented architecture and the corresponding emerging standards. Policies are declarative statements of relevant aspects of a component's behavior. Curbera explores the role of QoS policies in service-oriented architectures from the point of view of interoperability, as defined by the Web services stack, and composition, as defined in the service component architecture.

From these last three contributions a proposal for a unifying approach emerges:

  • gather, use, and maintain the user's knowledge at his abstraction level and within his own application domain;
  • keep it as declarative as possible: use policies to gather the do's and don'ts like compliance issues, business rules, and so on. Good candidate formalisms seem to be logics—simple XOR/AND structures, as in WSPolicy, but also temporal and first-order logics—for which automatic proof and reasoning algorithms exist;
  • sketch the solution's backbone as a model and refine it along the design life cycle, introducing a "one-thing" approach that avoids the cultural and technological gaps still customary in today's IT. Here, widespread formalisms are Petri-net-like, but finite state machines with fork/join parallelism are simpler and cover the majority of the practical cases; and
  • use the knowledge to evaluate the models and provide guidance to generate or modify the models in away that conforms to it. Central here is the capability of automatic proof of the (logic) constraints on the models, as in model checking, and the automatic synthesis of processes from (temporal) logics, which can be extended toward theorem-proving-backed planning.


In a sense, the enterprise physics metaphor defines the sweet spot for the solution to a business problem as the equilibrium between the current knowledge (analog to the laws of physics) and the needs (the concrete problem to be solved). Such an equilibrium is realizable as logical consistency, possibly refined by adding weight functions, priorities, or preferences. We need good ways for finding it and maintaining it consensually in an evolutionary setup.


About the Authors

Tiziana Margaria is chair of service and software engineering at the Institute of Informatics, Potsdam University, Germany. Her research focuses on model-based system and service engineering as well as biologically inspired computing. Margaria received a PhD in computer and systems engineering from the Politecnico di Torino, Italy. She is a member of the IEEE, the ACM, the International Federation for Information Processing, and the German Association for Computer Science as well as president of the European Association of Software Science and Technology. Contact her at
74 ms
(Ver 3.x)