Liked this presentation? Have a look at our SOA e-learning courses!

	E-learning Building the Canonical Data Model
	E-learning SOA Overview
	E-learning Service Identification
	E-learning Service Specification and Service Repositories

Economists and business scientists have been debating about this ‘service’ notion for more than two centuries (Gadrey, 2000). Often, the definitions in business literature limit the service notion to the delivery of immaterial goods. The adoption of the notion of ‘service’ by computer scientists and IT practitioners has been more recent. In both the business science field (Zeithaml et al., 1993; Gallouj and Weinstein, 1997; Hart, 1988; Goldstein et al., 2002) and the computer science field (OMG, 2006; OASIS, 2006a; The Open Group, 2006; W3C, 2006b) a service is regarded as an interaction between a requesting party (often called consumer or customer) and an offering party (often called provider or supplier). The offering party is able to produce a certain value that is requested by the other party. But even with this common notion a precise definition and mutual understanding of the term service is missing. Let us have a look at the definition given by the Open Group (The Open Group, 2006). It says that a service:

• is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports),
• is self-contained,
• may be composed of other services, and
• is a ‘black-box’ to consumers of the service.

This definition is as vague as the other definitions mentioned above and one could discuss every single statement of the definition. E.g., what is a business activity? The Open Group mentions ‘check customer credit’ or ‘provide weather data’ as business activities, but are these really business activities or are they only computational acts? What about a business activity concerning the ‘manufacturing of a car’? Such a business activity has a completely different granularity as the ones mentioned in the definition. What is self-contained?
If a service is composed of other services is it still self-contained? What is precisely meant by a black-box when a service is also defined to be an activity? What about communication activities e.g., to call the service or to accept/reject the requested result?

We start this article with further explaining the Ψ-theory. Subsequently, we provide our service definition and six different types of services. After that we present our conclusions.

The Ψ-theory

The Ψ-theory (Dietz, 2006b) finds its roots in the scientific fields of Language Philosophy, in particular the Language Action Perspective (LAP) (Flores and Ludlow, 1980; Goldkuhl and Lyytinen, 1982), and in Systemic Ontology (Bunge, 1979). It focuses on the use of language to achieve agreement and mutual understanding (Weigand, 2003). By applying the Ψ-theory one can disentangle the essential knowledge of the construction and the operation of the organization of an enterprise, by which we mean a commercial or nonprofit company as well as a network of enterprises. This essential enterprise model is called the ontological model. The theory consists of several axioms and one theorem. In this section we give a short summary of the Ψ-theory. A complete overview of the theory is available in the book (Dietz, 2006b) and the papers (Dietz and Hoogervorst, 2008; Dietz and Albani, 2005; Dietz, 2006a; Dietz and Hoogervorst, 2007).

The Operation Axiom

The first axiom, the operation axiom, focuses on the different types of acts that actors in organizations (people, also called subjects) perform and the results of these acts. It states the following (Dietz, 2006b):

Axiom 1. Actors perform two kinds of acts: production acts and coordination acts. These acts have definite results: production facts and coordination facts respectively. By performing production acts, actors contribute to bringing about the function of the organization. By performing coordination acts, actors enter into and comply with commitments regarding production acts. An actor is a subject fulfilling an actor role. Actor roles are elementary chunks of authority and responsibility.

What are these so-called production and coordination acts the axiom speaks about? And why do we need to distinguish between them? First, let us look at the production acts. Production acts are acts that deal with the delivery of material or immaterial goods by actors to their environment. Their results are production facts. Examples of production acts dealing with material goods are manufacturing and transporting. Their corresponding production facts are ‘Product P has been manufactured’ and ‘Product P has been transported’. For immaterial goods, examples are deciding and judging. Their corresponding production facts are ‘Decision D has been made’ and ‘Judgment J has been made’. Coordination acts serve a totally different purpose than production acts, though they are executed by the same actors. They do not directly contribute to the production of goods, but they coordinate the execution of production acts. An example of a coordination act and its corresponding fact is the request for manufacturing a product and ‘The production fact “Product P has been manufactured” has been requested’. In the next paragraph we will see that the different types of coordination acts form a limitative list.

The Transaction Axiom

The second axiom, the transaction axiom, further looks into the coordination acts. It states the following (Dietz, 2006b):

Axiom 2. Coordination acts and production acts always occur in particular patterns. These patterns are paths through one universal pattern, called transaction. The result of carrying through a transaction is the creation of a production fact.

A transaction evolves in three phases, the order phase (O-phase), the execution phase (E-phase) and the result phase (R-phase), see Figure 1. Two actor roles are involved in such a transaction, the initiator, who starts and completes the transaction, and the executor, who performs the production act. In the order phase the initiator and the executor try to reach agreement about the intended result of the transaction, i.e., the production fact that the executor is going to create as well as the intended time of creation. In the execution phase this product is created by the executor, and in the result phase both actors try to reach agreement about the fact that has been produced. The so-called basic transaction pattern consists of the request, promise, state, and accept coordination acts. An example of this basic pattern looks as follows.

1. person A requests person B to manufacture a car
2. person B promises person A to manufacture a car
3. –actual delivery of the manufactured car–
4. person B states to person A that he has manufactured a car
5. person A accepts from person B that he has manufactured a car (the car conforms to his expectations)

Transactions will conform to this basic transaction pattern in a happy scenario, i.e. everything goes as it should go. However, in reality the initiator and executor may dissent in two of the states; (i) the requested state and (ii) the stated state. In the first case, the executor may (instead of promising) respond to a request by declining it. In the second case, the initiator may (instead of accepting) respond to a statement by rejecting it. By allowing these acts, a transaction can end up in a discussion state. Dietz describes that in this situation the two actors must sit together, discuss the situation at hand, and negotiate about how to get out of it. When the basic pattern is expanded with these two dissent patterns, we get the standard transaction pattern. The standard transaction pattern is the pattern already introduced in Figure 1. The complete transaction pattern is constituted by the standard pattern and four cancellation patterns. Cancellation patterns concern the revocation of a request act, promise act, state act, or accept act.

The Distinction Axiom

The third axiom, the distinction axiom, is concerned with the different abilities of a human being that are involved in the activities they perform. The axiom states the following (Dietz, 2006b):

Axiom 3. Three distinct human abilities play a role in the performance of coordination acts and production acts: the forma, informa and performa abilities.

How are these human abilities relevant for coordination acts on the one hand and production acts on the other hand? The forma ability deals with the form aspects of communication and information. Applying this to coordination acts, this means actors should have a way to utter and perceive information. Information should be expressed in a particular language or code scheme that both the initiator and the executor of a transaction understand. This is also known as syntactic (or significational) understanding. One might think, for instance, of information written in English. The informa ability concerns the content aspects of information and communication. In order to communicate, the initiator should formulate information in a way that the executor can interpret. In other words, the initiator and the executor should semantically be in agreement with each other and share the same thoughts. This is also called intellectual understanding. The performa ability states that new information and knowledge can be created through communication between the initiator and executor. Looking at coordination acts, this means that actors can expose and evoke commitments and it indicates social understanding between the initiator and executor. For the production acts we see a similar distinction. The forma ability is concerned with the form aspects of information in terms of information transmission and storage. This type of production acts are known as datalogical acts. Transactions that contain a datalogical act are called datalogical transactions (D-transactions). The informa ability states that information can be reasoned, computed or deduced. Those activities are known as infological acts. Transactions are called infological transactions (I-transactions) if they include this type of production act. The performa ability concerns making decisions, judgments, or creating material things such as products. This is what we call ontological acts. Transactions that include ontological acts are known as ontological transactions (B-transactions).

The Organization Theorem

We just presented three of the axioms of the Ψ-theory. Together with the composition axiom, which we did not discuss, they provide the basis for the organization theorem. This theorem provides a concise, comprehensive, coherent, and consistent notion of enterprise, such that the (white-box) model of an enterprise may rightly be called its ontological model (Dietz, 2006b). It states the following (Dietz, 2006b):

Theorem 1. The organization of an enterprise is the layered integration of three aspect organizations: the B-organization, the I-organization, and the D-organization.

Figure 2 shows the three aspect organizations. The B-organization concerns the essence of the enterprise. It consists of actors who directly contribute to the enterprise’s goals and functions by performing ontological production acts. These actors are known as B-actors and are able to perform B-transactions, the ontological transactions we defined in the previous paragraph. B-actors are, for instance, consultants or sales persons. The I-organization embraces the content aspects of information and knowledge in the enterprise (Dietz, 2006b). Actors in the I-organization, who are called I-actors, bring changes to information and knowledge by performing infological production acts. In other words, I-actors perform I-transactions. Business controllers are typical actors in the I-organization producing infological things. The D-organization deals with the documentation of information in the enterprise and only takes into account the form of information. To achieve this, actors in the D-organization perform datalogical production acts and thus D-transactions. These actors are known as D-actors, who are for instance archivists.

Defining Service Based on the Ψ-theory

According to the Ψ-theory, the previous paragraphs have shown, the operation of organizations is all about communication between and production by social actors. Is not the main concern of service-orientation to support the operation of an organization and therefore also to support the communication between and production by social actors? Because the Ψ-theory describes the interaction between the requesting party and the offering party in a very formal way, it provides a basis for formalizing the notion of service. Based on
this theory we have elaborated on the notion of service (Albani et al., 2009) and we will summarize in the next paragraphs the main results which are of relevance for the specification of services. The definition of service is based on the complete transaction pattern. Though a service has many similarities with a transaction in the Ψ-theory, they are not equal. While the transaction includes all acts of the initiator and the executor, the service concept only regards the executor side. We therefore define a service as a part of a transaction rather than a whole transaction.

Definition 1. A service is a pattern of coordination and production acts, performed by the executor of a transaction for the benefit of its initiator, in the order as stated in the complete, universal pattern of a transaction. When implemented it has the ability to get to know the coordination facts produced by the initiator and to make available to the initiator the coordination facts produced by itself.

By universal we mean that this pattern applies to interaction between actors in all types of organizations (non-profit and commercial) and in all countries and cultures of the world. When looking at the complete transaction pattern, everything except the coordination acts of the initiator (request, quit, reject and accept) are part of the service. But in order to communicate with the executor of the service, the initiator needs to be aware of the complete transaction pattern. Additionally, we call a service a composite service, if the execution of the service requires the executor to initiate certain other services. This happens exactly then, when a transaction is enclosed in some other transaction. This definition of a service just given is a very generic one, since it holds for two kinds of actors, human actors and IT systems and three kinds of production acts, namely datalogical, infological and ontological. Services executed by human actors or IT systems only differ in the way they are implemented; human services are implemented by human beings, whereas IT services are implemented by IT systems. IT systems assist human actors in their activities. For both human actors and IT systems we can distinguish between communication acts and production acts on the datalogical, infological, and ontological level as described in the organization theorem (though at ontological level machines can only mimic the behavior of the responsible human actors, because machines can never reach true social understanding and cannot create really new, original things). Examples of datalogical production acts are storing, copying, transmitting of documents or data. Acts such as reasoning, computing, deriving or reproducing knowledge are examples of infological production acts and the acts concerning the creation of original new things, such as creating material products or making judgments are examples of ontological production acts. The basic concept of dealing with coordination and production aspects between an initiator and an executor party as defined in Ψ-theory and in the generic service definition given above allow us to distinguish between six different types of services:

• ontological human service
• infological human service
• datalogical human service
• ontological IT service
• infological IT service
• datalogical IT service

All service types conform to the definition of service given above, following the same service pattern and the described abilities. They only differ in the way they are implemented, either by human actors or by IT systems and in the different kinds of coordination and production acts as described above.

Conclusions

In this article we provided a definition of the notion of service and introduced six different types of services, based on the Ψ-theory: ontological human services, infological human services, datalogical human services, ontological IT services, infological IT services, and datalogical IT services. The first distinction is between human services, i.e. services executed by human beings, and IT services, i.e. services executed by IT systems. The second distinction corresponds to the three aspect organizations, as proposed by the organization theorem: the B-organization, the I-organization and the D-organization.

References

A. Albani, G. Hardjosumarto, L. Terlouw, and J. L. G. Dietz. Enterprise ontology based service definition. In Proceedings of 4th International Workshop on Value Modeling and Business Ontologies, Amsterdam, The Netherlands, 2009.
M. A. Bunge. Treatise on Basic Philosophy, vol. 4, A World of Systems. D. Reidel Publishing Company, Dordrecht, The Netherlands, 1979.
J. L. G. Dietz and A. Albani. Basic notions regarding business processes and supporting information systems. Requirements Engineering, 10(3):175–183, 2005.
J. L. G. Dietz. The deep structure of business processes. Communications of the ACM, 49(5):58–64, 2006a.
J. L. G. Dietz. Enterprise Ontology, Theory and Methodology. Springer, Berlin Heidelberg, Germany, 2006b.
J. L. G. Dietz and J. A. P. Hoogervorst. Enterprise ontology and enterprise architecture, how to let them evolve into effective complementary notions. GEAO Journal of Enterprise Architecture, 2(1):3–20, 2007.
J. L. G. Dietz and J. A. P. Hoogervorst. Enterprise ontology in enterprise engineering. In Proceedings of the ACM symposium on Applied computing, pages 572–579, Fortaleza, Ceara, Brazil, 2008.
F. Flores and J. Ludlow. Doing and speaking in the office. Decision Support Systems, Issues and Challenges, pages 95–118, 1980.
J. Gadrey. The characterization of goods and services: An alternative approach. Review of Income and Wealth, 46(3):369–87, September 2000.
F. Gallouj and O. Weinstein. Innovation in services. Research Policy, 26(4-5): 537–556, 1997.
G. Goldkuhl and K. Lyytinen. A language action view of information systems. In Proceedings of the 3rd International Conference on Information Systems, pages 13–29, Ann Arbor, MI, USA, 1982.
S. M. Goldstein, R. Johnston, J. Duffy, and J. Raod. The service concept: the missing link in service design research? Journal of Operations Management, 20(2):121–134, 2002.
C. W. Hart. The power of unconditional service guarantees. Harvard Business Review, 66(4):54–62, 1988.
OASIS. OASIS, 2006a. http://www.oasis-open.org/.
OMG. Service-oriented architecture SIG, 2006. http://soa.omg.org/.
The Open Group. Service-oriented architecture, 2006. http://www. opengroup.org/projects/soa/.
W3C. W3C, 2006b. http://www.w3c.org/.
H. Weigand. The language/action perspective. Data & Knowledge Engineering, 47(3):299–300, 2003.
V. A. Zeithaml, L. L. Berry, and A. Parasuraman. The nature and determinants of customer expectations of service. Journal of the Academy of Marketing Science, 21(1):1–12, January 1993.

This article is previously published as part of chapter 4 of the PhD thesis “Modularization and Specification of Service-Oriented Systems” (link to complete dissertation)

Liked this article? Have a look at our SOA and Enterprise Ontology e-learning courses!

	E-learning SOA Overview
	E-learning Service Identification
	E-learning Service Specification and Service Repositories
	E-learning Building the Canonical Data Model
	E-learning Introduction to DEMO (Enterprise Ontology)

In the same period McIlroy (1968) and Parnas (1972) proposed modularization as a means for dealing with complexity in software systems. Parnas (1972) introduced the criterion of information hiding, i.e. each module hides the manifestation of certain design decisions from the other modules. Interfaces between modules are chosen to reveal as little as possible about their internal operations. Also, he mentions some advisable specific example decompositions. McIlroy (1968) envisioned a mature software industry in which a purchaser can consult a catalog to search for software components that he can regard as black boxes: service-orientation avant la lettre.

Many researchers, e.g. Parnas (1972), Baldwin and Clark (2000), Sanchez and Mahoney (1996), bring up one or more of the following advantages of modularization: (i) making the total system structure more comprehensible, (ii) enabling easy replacement of components, (iii) making it possible to divide work between several groups of designers without them needing to be aware of the structure of the total system, and (iv) minimizing the effect that changes in one part of the system have on the other parts of the system. However, a great degree of modularity does not only pose benefits in system design. Schilling (2000) presents a general theory of modular systems from a market perspective. She draws on systems theory from many disciplines. In this theory she answers the question of what drives some systems toward increasing modularity and others toward increasing integration. According to her, the balance between the gains achievable through recombination (of modules) and the gains achievable through specificity (of the system as a whole) determines the pressure for or against the decomposition of a system (Schilling, 2000). Schilling defines different forces that drive toward or away from modularity. First, the heterogeneity of inputs drives towards modular systems. With input the author does not refer to the input of an interface, as computer scientists usually do. But she refers to the number of components (modules), that are available to compose a system. The more heterogeneous the inputs are that may be used to compose a system, the more possible configurations are attainable through recombinability enabled by modularity (Schilling, 2000). When many components of a certain type are available vendor lock-in can easily be prevented. Another positive force for modularity is heterogeneity of demands. This means when customers of a certain product have very different needs, then it is difficult to find a ‘one size fits all’ integrated solution. The forces of heterogeneity of inputs and heterogeneity of demands reinforce each other. A factor that negatively impacts the choice for modularity is synergistic specificity. She states that if customers need very specific components, the costs of making specialized interfaces would be very high. Also, the degree of difficulty customers face in assessing the quality and interaction of components and in assembling the components will be negatively related to increasing (interfirm) product modularity. Schilling (2000) mentions technological change and competitive intensity as some of the primary factors that create urgency. In both cases suppliers need to be able to rapidly reconfigure their products. So urgency directly contributes to a need for modularity. Also, urgency reinforces the heterogeneity of inputs and the heterogeneity of demands.

Arnheiter and Harren (2006) add some other negative aspects of modularity to the list: the limitation of creativity of design because of the need for well-defined interfaces, the overuse of the same module across too many product lines, less than optimal system performance due to use of generic modules, unnecessary time and expenses of replacing an entire module when only a single component within the module is faulty. We do not agree with the last statement as being a disadvantage of modularity, since in our eyes this ‘component’, i.e. submodule, is just a module at a lower level and there is no reason why submodules cannot be available on the market. Concluding, we see that modularity has advantages as well as disadvantages.

Summarizing, the advantages are that the total structure is more comprehensible: modularity contributes to making a system intellectually manageable. Because interfaces of modules are specified, modules can be easily replaced by other ones. Modularity also contributes to the process of building/changing a system. People working on one part of the system do not have an overview of the complete system. When making changes to the system one knows what changes will and will not affect other parts as the system, as only changes of a module that affect the interface can affect other parts. Because often several different implementations of a module conforming to a certain interface are available, one can choose between different configurations of a system. This standardization also prevents vendor lock-in. Disadvantages are the higher costs involved in making a modular system in comparison to making a non-modular one. Next to this, the task of integrating the different modules can be complex. One has to assess the quality and interaction of different modules and letting everything work together can be hard. Designers can be limited in their creativity as they have to conform to the interface and it can lead to less variation in products as all products use the same modules. Finally, the total system performance may be suboptimal.

Advantages

• Total structure is more comprehensible (Sanchez and Mahoney, 1996; Parnas, 1972; Baldwin and Clark, 2000; Arnheiter and Harren, 2006).
• Modules can be easily replaced (Sanchez and Mahoney, 1996; Parnas, 1972; Baldwin and Clark, 2000; Arnheiter and Harren, 2006).
• Work division possible without everyone having overview of complete system (Parnas, 1972; Baldwin and Clark, 2000; Arnheiter and Harren, 2006).
• Effect of changes of one part of system to other parts are minimized (Sanchez and Mahoney, 1996; Parnas, 1972; Baldwin and Clark, 2000; Arnheiter and Harren, 2006).
• Many different configurations of the system are possible (Schilling, 2000; Sanchez and Mahoney, 1996; Baldwin and Clark, 2000; Arnheiter and Harren, 2006).
• Vendor lock-in is prevented due to standardization (Schilling, 2000).

Disadvantages

• For very specific modules the cost of making interfaces can be high (Schilling, 2000).
• For assemblers (integrators) it can be difficult to assess the quality and interaction of different modules (Schilling, 2000; Arnheiter and Harren, 2006).
• It can be difficult to assemble (integrate) the modules (Schilling, 2000; Arnheiter and Harren, 2006).
• The design creativity of a module designer can be limited because he needs to conform to the interface (Arnheiter and Harren, 2006).
• Less variation in products because of overuse of the same modules (Arnheiter and Harren, 2006).
• Total system performance may be suboptimal (Arnheiter and Harren, 2006).

References

C. Alexander. Notes on the Synthesis of Form. Harvard University Press, 1964.
E. D. Arnheiter and H. Harren. Quality management in a modular world. The TQM Magazine, 18(10):87–96, 2006.
C. Y. Baldwin and K. B. Clark. Design Rules: Volume 1: The Power of Modularity. The MIT Press, Cambridge, MA, USA, 2000.
M. D. McIlroy. Mass-produced software components. Proceedings of NATO Conference on Software Engineering, pages 88–98, 1968.
D. L. Parnas. On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12):1053–1058, 1972.
R. Sanchez and J. Mahoney. Modularity, flexibility, and knowledge management in product and organizational design. Strategic Management Journal, 17:63–76, 1996.
M. A. Schilling. Toward a general modular systems theory and its application to interfirm product modularity. The Academy of Management Review, 25(2):312–334, 2000.
H. A. Simon. The sciences of the artificial. The MIT Press, 1969.

This article is previously published as part of chapter 3 of the PhD thesis “Modularization and Specification of Service-Oriented Systems” (link to complete dissertation)

View bigger version of animation

He explains his theory of communicative action in these two books (The Theory of Communicative Action Part I and II):

However, reading these books is quite a challenge. So I would recommend to start with this little book (Habermas – A Very Short Introduction by James Gordon Finlayson):

The main idea of Enterprise Ontology and the DEMO methodology (see the website of the Enterprise Engineering Institute) is that an organization consists of social actors (i.e. human beings). These actors interact by performing business transactions. These business transactions are based on the notion of speech acts. The figure below shows an example of such a business transaction.

In this picture we see two human being: a customer and a waiter. A business transaction is a universal pattern of communication and production acts. Universal means that this pattern occurs in all locations and cultures in the world. The person who starts the transaction is called the initiator (in this example: the customer). The person who executes the transaction is called the executor (in this example: the waiter). The initiator starts the transaction by performing a request coordination acts (in this example: ordering a steak). The executor performs a promise coordination acts. In this case a promise act could be saying: ‘That’s OK, sir. I’ll get it for you’. Next, the executor performs the production act, i.e. the waiter gets the steak for the customer. After that the executor performs a state coordination act, i.e. he says that he has performed the production act. In this example the waiter could say: ‘Here you are. Enjoy!’. Finally, the initiator accepts the result. He could for instance say: ‘Thank you!’. Sometimes coordination acts may be tacit. The waiter could just put the plate on the table instead of saying something (tacit state act).

In this example only the happy path of the transaction (called the basic transaction pattern) is shown. Of course many things can go wrong, see the figure below.

The transaction pattern that deals with all exceptions that can occur is called the complete transaction pattern. It includes decline coordination acts and cancellation coordination acts.

Now let’s revisit Habermas. In these business transactions we see the claim to truth, the claim to justice, and the claim to sincerity. Though one of these claims is dominant, they are all present. In our example the customer could ask the waiter to deliver 100 steaks at once (challenging the claim to truth). The waiter could rightly decline this request since it is impossible for him to deliver 100 steaks at once. When I ask a waiter who is going home and changed to his regular cloths (because he has finished his shift) to deliver a steak I would challenge the claim to justice. It is not socially appropriate to make this request. When I would request a ‘vegetarian steak’, the waiter would probably know I am fooling him (and challenging the claim to sincerity). Maybe he would even play along and deliver me a salad.

Liked this article? Have a look at our Enterprise Ontology e-learning course!

E-learning Introduction to DEMO (Enterprise Ontology)

This book focuses on human computer interaction. Each chapter of this book presents interviews with great designers. For example, chapter 1 presents interviews about the mouse and the desktop with Doug Engelbart, Stu Card, Tim Mott, and Larry Tesler. Chapter 7 deals with the Internet by interviewing Terry Winograd, Larry Page and Sergey Brin, Steve Rogers, and Mark Podlaseck. In the book we encounter famous design examples like the Apple Lisa, SimCity, the Star Trek bridge, the Google search engine, and the iPod.

I cannot say anything negative about this book. It’s a great read and very cheap ($22.90 at amazon.com (28-7-2011) for a 766 pages hardcover book).

This book starts out with defining three major schools of thought about interaction design: a technology-centered view, a behaviorist view, and the social interaction design view. A very brief history of interaction design starting from 1830 is presented. We see examples like the morse code transmitter, punch cards, the Apple Lisa, and a karaoke machine. This book presents four approaches to interaction design, viz. user-centered design, activity-centered design, systems design, and genius design. Each approach is thoroughly explained and examples are provided. We learn about design strategy and design research. The book provides in-depth advice on how to realize good designs. It’s an easy read and really helps designers to make any type of system that requires interaction with human beings.

Edward R. Tufte is one of the thought leaders in the field of visualization. He deals with visualization in general, so not only in the field of software engineering or enterprise architecture. The books contains many, many graphics and shows many ways to depicts information (e.g. graphs and statistical maps). We see representations of brains, planets, and even learn how to dance. This book is really a pleasure for the eye. It is not so much a book to really read starting from the first page and ending at the last page. It’s better to just browse, select interesting graphics and read the text explaining these graphics.

This book starts with quotes from from great philosophers (Aristotle, Descartes, and Kant) to explain the importance of visualization. It explains some basic notions about human perception, e.g. how the human eye works and the basics of pattern recognition. Next, we learn about visualization using graphs, a very common way of depicting relationships between software modules. The books shows different static (e.g. spider diagram, 3D sequence diagrams and bar charts) as well as dynamic program visualizations (e.g. 3D animations, sorting algorithms animations). Also, it provides ways of visualization the evolution of a software system.

Like most Springer books this book is a bit scientific. However, it is very easy to comprehend (well-written) and it has many pictures. So all in all, it’s not to hard to read. The book deals with software visualization only.

Do’s:

1) Appoint a service catalog manager

Though the service provider is responsible for specifying his service, we also need a service catalog manager. This person checks whether the quality of the service specifications meets the standards. He keeps the catalog up and running. And, most importantly, he leads the processes of accepting a new service, changing the life cycle status of a service, versioning services, and killing services. No chance for JABOWS with a service catalog manager around!

2) Make a canonical data model

It is important for services to speak the same language. Usually the ESB is used for mapping data from a native application format to the canonical data model. The canonical data model differs from the so-called corporate data model. The corporate data model describes all data within the enterprise. The canonical data model only describes data to be exchanged by services. Do not only pay attention to specifying the syntax of the data, but also to the semantics. We would not want another space shuttle to crash because of a simple inch/centimeters mix-up.

3) Specify who, what, and how

Essentially thee aspects are important in a service specification: the who, what, and how. We want to know who offers the service; do we trust this person and how can we contact him if needed? We want to know what the service does, e.g. input, output, preconditions, postconditions, description of behavior. Also, the non-functional behavior (e.g. availability, security etc) belongs to this `what’ part. Finally, we are interested in how we can access the service. We need to know the location of a service (usually a logical location) and what protocols to use. Sometimes we are also interested in `how much’, i.e. what do we need to pay to use the service.

Don’ts:

1) Assume WSDL is enough

Don’t think the WSDL is enough for the consumer of the service to know what the service does. It just isn’t. Additionally, the WSDL is only suitable for one type of stakeholder: the software engineer.

2) Assume the UDDI standard is enough

The UDDI standard work fine for dealing with a number of technical aspects and it gives information about who offers the service and how to access the service. However, it lacks proper means to describe the `what’ part. Most organizations use commercial service registries with add-ons on the UDDI standards, or additional Word or Excel templates.

3) Assume providers will fill the catalog if they are not rewarded

Building as well as specifying services takes time, money, and effort. It is important to realize that service providers will only make services for service consumers if they are somehow rewarded. Both parties should have costs and benefits. A provider will not cooperate if there are only costs involved for him.

Liked this article? Have a look at our SOA e-learning courses!

	E-learning SOA Overview
	E-learning Service Identification
	E-learning Service Specification and Service Repositories
	E-learning Building the Canonical Data Model

So first of all, the lowest level of cloud computing: IaaS. Infrastructural components (let’s say: ‘machines’) are delivered as a service to consumers. This means the notion of infrastructural components is known in the platform. Different examples of IaaS providers exist, Amazon EC2 being the most famous one.

Fig 1: IaaS abstraction level

So why do we call it IaaS and not simply hosting? The idea behind cloud computing is flexibility, machines able to stretch beyond their limits. In classical hosting scenarios physical machines are used which are bound by their fixed memory and computing limits. Virtual machines can be stretched (often even at runtime) on-demand by a virtualization layer called hypervisors. VMWare is a very popular hypervisor which allows virtual machines to be stretched at runtime. Hardware and machine specs are de-coupled, that’s why we talk about ‘infrastructure as a service’, or IaaS. Famous examples of such platforms are Amazon EC2 (Elastic Computing Cloud) or VMWare ESX server for clouds in your own datacenter. Payment is often done by calculation of uptime hours of a certain virtual machine.

One level beyond the concept of a machine is the concept of a platform. In order to be able to deploy applications on a platform without the need to worry about (physical or virtual) machine specifications we need an abstraction in which machines no longer play an active role.

Fig 2: PaaS abstraction level

If we wrap the concept of machines into a pool in which only the platform is visible along with a number of services we reach the level of PaaS, or Platform as a Service. Developers only need to worry about writing code that can make use of the platform and it’s services (often a certain fixed programming language and a specific provider’s libraries). Only the concept of ‘applications’ exist and they can grow as big as the entire platform. There are a few examples nowadays of clouds like this but the one closest to a true PaaS is the Google App Engine. The payment model of these platforms can be radically different; literally, app engine applications are payed by use (that is, actions the platform needs to perform when requests are done to the application).

So cloud computing is all about abstraction and optimization of a certain well-defined set of services. The higher the abstraction level, the broader the functional possibilities, along with flexibility in scaling and optimization