Design and Implementation of a Service-oriented Information System Architecture Based on a Case Study (Konzeption und Realisierung einer service-orientierten IS-Architektur anhand eines Fallbeispiels)

Contents

  Abbreviations  V

  List of Figures  VIII

  Listings  XII

1  Introduction  1

1.1  Motivation and Objectives  1

1.2  Structure of the Thesis  3

1.3  General Conventions  4

1.4  Cooperation  4

2  Basic Principles  5

2.1  Principles of Information and Application Systems  5

2.1.1  Information Systems  5

2.1.2  Level of Tasks and Level of Task Bearers  6

2.1.3  The Concept of a Business Task  7

2.1.4  Application Systems  9

2.1.5  Distributed Systems  9

2.2  Architectures of Information and Application Systems  11

2.2.1  Information System Architecture  11

2.2.2  Application System Architecture  13

3  Service-Oriented Architecture  14

3.1  Fundamentals of Service-Oriented Architecture  14

3.1.1  The SOA Concept  14

3.1.2  Principles of Service-Orientation  15

3.1.3  Meta-Model for Service-Oriented Architecture  21

3.1.4  Reference Model for Service-Oriented Architecture  23

3.1.5  Denition of SOA  23

3.2  Implementation of Service Oriented Architectures  26

4  SAP's Enterprise Service-Oriented Architecture  30

II

Contents

4.1  Fundamentals of Enterprise Service-Oriented Architecture  30

4.1.1  Basic Concepts of Enterprise SOA  31

4.1.2  Denition of Enterprise SOA  34

4.2  Technology Environment of Enterprise Service-Oriented Architecture  35

4.2.1  NetWeaver Overview  35

4.2.2  Composite Application Framework  41

4.2.3  Visual Composer  46

4.3  Ecosystem  48

5  Approach to Design and Implementation of an SOA  50

5.1  Design of an SOA  51

5.1.1  The Semantic Object Model (SOM)  51

5.1.2  Specication of the Business System using SOM Methodology  53

5.1.3  Specication of the Business Application System using SOM  

  Methodology  55

5.1.4  Technical Design for Implementation with SAP NetWeaver  57

5.2  Implementation of an SOA using SAP NetWeaver Technology  60

5.2.1  Creation of Processes with CAF Guided Procedures  60

5.2.2  Implementation of Back End Web Services in ABAP or Java  61

5.2.3  Implementation of Composite Services with CAF Core  62

5.2.4  Implementation of User Interfaces with Visual Composer  63

6  Design and Implementation of the Case Study Architecture  64

6.1  Introduction  64

6.1.1  Technical Environment  64

6.1.2  Scenario of the Case Study  65

6.2  Design of the Case Study Architecture  67

6.2.1  Specication of the Business System  67

6.2.2  Specication of the Business Application System  71

6.2.3  Technical Design for Implementation with SAP NetWeaver  73

6.3  Implementation of the Case Study Architecture  76

6.3.1  Process, Blocks and Actions in CAF GP  76

6.3.2  Back End Web Services based on J2EE Development  77

6.3.3  Composite Services and Web Services in CAF Core  79

6.3.4  Visual Composer iViews with Web Service Calls  85

6.3.5  Users in the Enterprise Portal  94

6.3.6  Callable Objects and Process Flow in CAF GP  94

6.3.7  Universal Work List Conguration  97

6.3.8  Process Initiation  97

III

Contents

6.4  Evaluation  97

6.4.1  Design Phase  97

6.4.2  Implementation Phase  99

7  Summary  103

  Bibliography  105

Appendix 115   

  A SOA Denitions  116

  B Case Study Design  120

  C Case Study Implementation  124

  C 1 CAF Core  124

  C 2 Visual Composer  137

  C 3 CAF GP  140

  C 4 Demo  141

  Erkl arung  150

IV

Abbreviations

ABAP Advanced Business Application Programming ARIS Architecture of Integrated Information Systems AS Application Server AS Application System BAPI Business Application Programming Interface BI Business Intelligence BO Business Object BPEL Business Process Execution Language BPM Business Process Management BPP Business Process Platform BPX Business Process Expert CA Composite Application CAF Composite Application Framework CAS Composite Application Services ccBPM Cross-Component Business Process Management CO Callable Object CRM Customer Relationship Management CRUD Create, Read, Update, Delete DBMS Database Management System DC Development Component DOM Document Object Model DSAG Deutschsprachige SAP Anwender Gruppe EDA Event Driven Architecture EJB Enterprise JavaBean EMG Event Management Group (Case Study Only)

V

Abbreviations

EP Enterprise Portal ERP Enterprise Resource Planning ES Enterprise Service ESA Enterprise Services Architecture ESOA Enterprise Service-Oriented Architecture ESR Enterprise Services Repository GP Guided Procedures GML Generalized Modeling Language GUID Globally Unique Identier HTTP Hypertext Transfer Protocol IDE Integrated Development Environment IS Information System ISV Independent Software Vendor IT Information Technology J2EE Java 2 Platform, Enterprise Edition JEE Java Platform, Enterprise Edition (Since J2EE 1.5) KM Knowledge Management MDA Model Driven Architecture MDM Master Data Management NW NetWeaver OASIS Organization for the Advancement of Structured Information Standards OMG Object Management Group PCD Portal Content Directory PLM Product Lifecycle Management PROMET Process Method RFC Remote Function Call RPC Remote Procedure Call SAP SAP AG - Systeme, Anwendungen und Produkte in der Datenverarbeitung SCM Supply Chain Management

VI

Abbreviations

SDN SAP Developer Network SLD System Landscape Directory SOA Service-Oriented Architecture SOAP Simple Object Access Protocol SOM Semantic Object Model SQL Structured Query Language SRM Supplier Relationship Management UDDI Universal Description, Discovery and Integration UI User Interface UME User Management Engine URL Uniform Resource Locator VC Visual Composer VI Virtual Interface W3C World Wide Web Consortium WD Web Dynpro WS Web Service WSD Web Service Denition WSDL Web Service Description Language WSI Web Service Interface WSIL Web Service Inspection Language WWW World Wide Web xApp Packaged Composite Application XI Exchange Infrastructure XML Extensible Markup Language

VII

  List of Figures  

1.1  Hype Cycle for Emerging Technologies, FeLi05  1

1.2  Structure of the Thesis  3

2.1  Information System, cp. FeSi06, p. 4/444  7

2.2  Structure of a Task, cp. FeSi06, p. 92  8

2.3  Structure of a Procedure, cp. FeSi06, p. 98  8

2.4  Loosely Coupled and Tightly Coupled Components, FeSi94, p. 3  10

2.5  Conceptual Framework for Distributed Systems, FeSi94, p. 4  10

2.6  Generic Architectural Framework, Sinz02, p. 1056  12

2.7  Information System Architecture, Application System Architecture  

  and Software Architecture  13

3.1  Basic Concept of SOA, Amm 05, p. 1507  14

3.2  Dierent Levels of Tight and Loose Coupling  17

3.3  SOA Layers of Abstraction, Bie 06, p. 87  18

3.4  Stateless and Stateful, Erl05, p. 308  20

3.5  Meta-model for Service-Oriented Architectures  22

3.6  Reference Model for Service-Oriented Architectures  23

3.7  SOAP Message and a WSDL service specication, Alo 04, p. 157/167  27

3.8  Web Service Interaction Model  28

3.9  WS Standards, Mult06  29

4.1  Enterprise Service Example 'Cancel Order', SAPT06e, SOA200  32

4.2  SAP's Enterprise Service-Oriented Architecture  33

4.3  From Infrastructure to Applistructure, SAPT06c  35

4.4  Enterprise SOA with SAP NetWeaver, Own Illustration  36

4.5  Anatomy of a Composite Application, SAPT06a  42

4.6  Types of Composites, SAPNb, p. 40  43

4.7  GP Process Context as a Shared Data Storage, SAPNa, p. 30  44

4.8  Meta-Model of Guided Procedures Design Time, Own Illustration  45

4.9  Options for Adding Callable Objects to Actions, Own Graphic  46

4.10  Architecture of Visual Composer, SAPT06e  47

VIII

  List of Figures  

4.11  Enterprise Services Request and Review Denition Groups  49

5.1  Enterprise Architecture of SOM FeSi98, p. 341  52

5.2  Object-Oriented Concept of Business Objects, FeSi97, p. 12  53

5.3  Transaction-Oriented Concept of Coordinating Loosely Coupled  

  Business Objects, FeSi97, p. 13  54

5.4  SOM Meta-Model of Business Process Model FeSi98, p. 344  55

5.5  SOM Meta-Model of Business Application Systems FeSi98, p. 353  56

5.6  Relationship Meta-Model for the SOM business application system  

  and Guided Procedures Design Time  58

5.7  Creation of Callable Objects in GP, SAPT06b  60

5.8  Creation of Actions in GP, SAPT06b  60

5.9  Creation of Blocks in GP, SAPT06b  60

5.10  Creation of Processes in GP, SAPT06b  61

5.11  Inside-Out and Outside-In Web Services, SAPT06d  62

5.12  Visual Composer Modeling Work ow, SAPT06e  63

6.1  Interaction Schema (left) and Task-Event Schema (right) of Business  

  Process Distribution (First Level)  68

6.2  Interaction Schema of Business Process Distribution (Final Level)  69

6.3  Schema of Task Classes  72

6.4  Guided Procedures Process Flow  73

6.5  Service-Oriented Architecture of Event Management Group  75

6.6  Guided Procedures Gallery Menu  76

6.7  Created Actions in Gallery  77

6.8  Tree Structure of GP Elements  77

6.9  Service Enablement of EDMFoundationBean  78

6.10  Backend Web Services  79

6.11  CAF Core Development Component  80

6.12  External Service EMGProjectWS  81

6.13  Attributes of Entity Services  82

6.14  Entity Service with Remote Persistency Mapping  83

6.15  Operations of Application Service  84

6.16  Creation of Portal Content Folder  86

6.17  Visual Composer Compiler Options  87

6.18  Visual Composer System Denition  88

6.19  iViews of ProjectAssignmentsCreationProcess  89

6.20  Model for iView Send Rental Order  89

6.21  Layout for iView Send Rental Order  90

IX

  List of Figures  

6.22  Mapping for Event in iView Select Employees  91

6.23  ResultStates in iView Accept Rental Order  91

6.24  Action in iView Select Employee  92

6.25  Assigned Employees Table Field in iView Select Employee  92

6.26  Layers in iView Select Material  93

6.27  Adding iViews to EP Roles  94

6.28  Creation of Portal Users  94

6.29  ResultStates of Action Accept Order in GP  95

6.30  Parameter Mapping Groups of Block Project Determination Phase  96

6.31  Roles in Process Project Assignments Creation  97

  B 1 Task-Event Schema of Business Process Distribution (Final Level) I  120

  B 2 Task-Event Schema of Business Process Distribution (Final Level) II  121

  B 3 Task-Event Schema of Business Process Distribution (Final Level) III122  

  B 4 Schema of Conceptual Classes  123

  C 1 GML Source for iView Send Rental Order  137

  C 2 Model for iView Accept Rental Order  137

  C 3 Model for iView Select Employees  138

  C 4 Model for iView Approve Employee List  138

  C 5 Model for iView Select Material  139

  C 6 Model for iView Approve Material  139

  C 7 Model for iView Send Rental Order  140

  C 8 Available Callable Object Types  140

  C 9 Process Initiation (Emil Eve)  141

  C 10 Universal Worklist (Peter Pro)  141

  C 11 Send Rental Order (Peter Pro)  142

  C 12 Universal Worklist (Richard Rent)  142

  C 13 Accept Rental Order (Richard Rent)  143

  C 14 Universal Worklist (Eric Empl)  143

  C 15 Select Employees (Eric Empl)  144

  C 16 Universal Worklist (Marcus Mat)  144

  C 17 Select Material - Assign Material (Marcus Mat)  145

  C 18 Select Material - HTML Website (Marcus Mat)  145

  C 19 Select Material - Google Web Service (Marcus Mat)  146

  C 20 Select Material - Send (Marcus Mat)  146

  C 21 Universal Worklist (Richard Rent)  147

  C 22 Approve Employee List (Richard Rent)  147

  C 23 Approve Material List (Richard Rent)  148

X

List of Figures

C.24 Universal Worklist (Peter Pro) . . . . . . . . . . . . . . . . . . . . . 148

C.25 Finalize Rental Order (Peter Pro) . . . . . . . . . . . . . . . . . . . 149

C.26 Process Review (Emil Eve) . . . . . . . . . . . . . . . . . . . . . . . 149

XI

  Listings  

  C 1 Operation ndEmployeeAssignmentListForProject  124

  C 2 Operation createEmployeeAssignmentListForProject  124

  C 3 Operation queryEmployees  125

  C 4 Operation queryProjects  126

  C 5 Operation queryProjects (External Service Access)  126

  C 6 Entity Service Employee  127

  C 7 Application Service ManageEmployee  134

XII

1 Introduction

1.1 Motivation and Objectives

In today's companies changes happen very fast. On the one hand more and more new technologies are arising, on the other hand business processes have to change because of mergers and acquisitions, new regularities, changing customer requirements and so forth. As business processes are supported by information technology, information technology has to cope with both types of changes. From a business perspective on-demand adaptation of information technology to business is required [Zach05]. Service-oriented architecture (SOA) is currently discussed as an opportunity to better adapt to those changes.

According to Gartner's hype cycle for emerging technologies shown in Figure 1.1 SOA already crossed the peak and is now in the trough of disillusionment.

Figure 1.1: Hype Cycle for Emerging Technologies, [FeLi05]

But SOA is far from being unfashionable as it would be expected during this phase [Gart]. There is still high media coverage and a lot of SOA books have been

1

1 Introduction

published recently or will be published during the next months. What is true, however, is that the expectations are getting more realistic and people start to think about the real benets. This is probably due to the fact that companies experienced that implementing a SOA is not as fast and easy as the marketing hype might have given the impression.

Although the hype surrounding SOA is immense, the concept is still in its early childhood with regards to concrete implementations. According to a survey conducted by Experton Group only three percent of 110 German enterprises, all with over 100 Employees, have a SOA based solution in place [Expe06]. Besides high costs expected from migration to SOA the lack of SOA know-how is identied as a main reason. As the survey reveals 45 percent of the interviewed enterprises have nearly no knowledge or no knowledge about SOA at all. Another 38 percent have only basic knowledge. The lack of knowledge is conrmed by a survey from the research company Quocirca, which found out, based on a sample size of 1500, that 30 percent of respondents have absolutely no knowledge about SOA and 25 percent have only minimal knowledge [Long06]. Similar results are found among enterprises using SAP software. The results of an online survey conducted by the German speaking SAP User Group (DSAG) shows that 64 percent of 344 enterprises are just a little or not at all familiar with enterprise SOA and only every fth enterprise has developed a platform strategy [P utt06]. Furthermore, enterprise SOA is still a topic of the IT department, although it would be relevant for the management and other departments as well. The president of the user group concludes that, instead of theory, more trainings and practical case studies would have to be oered by SAP [P utt06].

As with SOA 2.0 1 already the following hype is announced [Herr06], it makes

sense to refrain from SOA marketing eorts as far as possible and to bring more clarity into current SOA and enterprise SOA discussions. To achieve this objective, the thesis examines the topic from dierent views. The rst view is a vendorneutral, theoretical view on general SOA concepts. The second view is targeted to enterprise services architecture (ESA), also called enterprise service-oriented architecture (ESOA), which is a SOA blueprint from SAP. The third view nally provides a practical case study. It examines based on a small scenario how to implement a service-oriented architecture using SAP technology.

SOA is intended to close the gap between IT and Business. In the same way this thesis does not focus on one side or the other but brings aspects of both disciplines together. For example business process design will be part of the thesis in the same

¹ SOA 2.0 is dened by Gartner Research as a combination of service-oriented architecture (SOA) and event-driven architecture (EDA)

2

1 Introduction

way as Web services and developer tools. However, this also means that the eld of research is very broad and an in depth discussion is not always possible. To counterbalance this fact, references to further information will be provided as often as possible.

1.2 Structure of the Thesis

Figure 1.2 shows the structure of this thesis.

In Chapter 2 basic principles of information systems are discussed and the terms information as well as application architecture are dened. The concepts discussed in this chapter serve as a basis for all following chapters.

Chapter 3 presents the fundamentals of service-orientation in a vendor-neutral and theoretical way. A meta-model for SOA is provided as well as the OASIS reference model introduced. Considering the concepts discussed, an own SOA denition is given and Web services presented as one possible technical realization for SOA.

SAP's view on SOA called ESA or ESOA is added in Chapter 4. First the general concepts of ESOA and how they relate to SOA are described. Afterwards the technology around SAP NetWeaver is presented in more detail.

Chapter 5 explains an approach to design and implement a service-oriented architecture. For the design the semantic object model (SOM) is used, SAP NetWeaver tools provide the basis for the implementation.

3

1 Introduction

The approach discussed in Chapter 5 is used in Chapter 6 to design and implement a service-oriented architecture based on a case study. The architecture is deduced from functional models and implemented using NetWeaver technology. It includes all levels of the ESOA environment. Processes are implemented with Guided Procedures, user interfaces with Visual Composer, Composite services with CAF Core and backend functionality is service-enabled in NetWeaver Developer Studio.

In Chapter 7 a brief summary is given.

1.3 General Conventions

This thesis uses the Oxford way of referencing. Thereby the references are made within the text ow in squared brackets. The reference token consists of fractions of the last name(s) of the author(s) as well as the year of publishing and a page number.

Footnotes are used for further references or additional remarks which are not directly linked to the topic.

Important terms are set to italic type. Where it seemed appropriate control elements of programs are also written using italic type to separate them from normal text. The typewriter style is used to mark o naming specic to the case study implementation, like for example names of methods, attributes and services.

1.4 Cooperation

This thesis was written in cooperation with the Market Development Engineering (MDE) team from SAP AG in Walldorf. The Market Development Engineering department is part of cross-unit Platform Ecosystem within Product Technology Group (PTG). It consists of solution evangelists, solution architects and partner solution managers. The focus of the team is to help expand the SAP ecosystem by working with early adopter partners in order to spread the enterprise SOA vision and to create proof points for new SAP technology. MDE activities include internal and external technology evangelism through events and workshops, partner enablement through strategic and early adoption projects, knowledge transfer by means of how-to guides or migration kits, technical due diligence of acquisition targets as well as roll-in into product denition and development. I would like to thank the whole team for the continuous support.

4

2 Basic Principles

Success is neither magical nor mysterious. Success is the natural

2.1 Principles of Information and Application

Systems

2.1.1 Information Systems

The term information system 1 (IS) is not uniformly used in literature. This is a consequence of the dierent usage of the term information either for the activity of informing somebody or for the object type information in the sense of information processing [FeSi06, p. 9]. In this thesis the second meaning is used, that is an information system is processing the object type information. This means for example it is receiving, transforming, saving, transmitting or providing information. As information systems are very important for organizations in commerce and administration they are also called business information systems 2 [FeSi06, p. 1]. The terms information systems and business information systems are used as synonyms throughout this thesis.

Organizations in commerce and administration are referred to as business systems 3 . Following systems theory business systems are open, goal oriented and socio-technical [Fer + 96, p. 8]. They are open because they interact with their environment such as customers, suppliers and other partners. They are goal oriented

¹ In German: Informationssystem

² In German: betriebliches Informationssystem

³ In German: betriebliche Systeme

5

2 Basic Principles

because they follow business goals and objectives. Whereas goals 4 specify the goods and services to be provided by the system, objectives 5 determine to which extend the goals have to be pursued. Technical objectives refer for example to duration and quality, business objectives to prot and eciency. In addition business systems are socio-technical since the tasks are fullled by persons and machines. So the global task of a business system is partly automated [Fer + 96, p. 9]. In case a task is assigned to a person who uses a computer there is a person-tool relationship. Partner-partner relationships are dened by tasks which are assigned to persons and computers cooperating [FeSi97, p. 5].

The attributes open and goal oriented describe the outside view of a business system. The inside view is characterized by a distributed system of autonomous and loosely coupled components which cooperate in pursuing the goals of the system. The autonomous components are business processes. They produce goods and services, which are delivered to the customer or to other components that act in the same way as the business system [FeSi97, p. 5]. For exibility of a system the distribution of components is a key prerequisite. As organizations need to be distributed to obtain exibility, information systems have to be distributed as well [FeSi96, p. 2].

The business information system is the information processing part of a business system. In analogy to human beings it can be seen as the nervous system of a business system where everything is controlled. Its main task lies in planning, controlling and supervision of business processes and their interactions with the environment which should be corresponding to business objectives and goals. In addition it produces services as long as they only consist of information [Fer + 96, p. 9]. Possible examples for such services are advisory services of banks or architecture plans of architects [FeSi06, p. 2].

2.1.2 Level of Tasks and Level of Task Bearers

In order that degrees of freedom can be revealed and used when assigning persons and machines to tasks, one dierentiates during the analysis and design of business information system between a level of tasks 6 and a level of task bearers 7 [Fer + 96, p. 10]. Figure 2.1 shows the two levels of an information system as well as the information and communication relationships within the levels.

⁴ In German: Sachziele

⁵ In German: Formalziele

⁶ In German: Aufgabenebene

⁷ Also called level of actors. It is important to understand that actors or task bearers can be humans and machines. In German: Aufgabentr agerebene

6

2 Basic Principles

The level of tasks consists of the information processing tasks that are interlinked through information relationships. On the level of task bearers persons and machines (computer systems) are specied which are available for the execution of the information processing tasks. In addition there are communication systems for communication between persons, between machines as well as for communication between persons and machines on the level of task bearers. The assignment of

tasks to task bearers determines the degree of automation[Fer + 96, p. 10]. Tasks are called fully-automated in case they are assigned to machines and non-automated when they are executed by persons. Partly-automated tasks are executed both by

persons and machines cooperating [Fer + 96, p. 11].

2.1.3 The Concept of a Business Task

Every task or subtask of a business information system can be described with the task concept introduced by Ferstl and Sinz [FeSi06, p. 91 et sqq.]. According to this concept the outside view 8 of a task is dened by a task object, goals and objectives of the task, pre-events that initiate the execution as well as post-events that result from the execution of the task (cp. Figure 2.2). The outside view can give answers to the question what should be achieved at certain times. It does not specify any task bearers or any procedure for the execution [FeSi06, p. 92]. The task object is corresponding to the attributes of the business information system. It is manipulated by the execution of the task and transferred from the pre-state to the post-state. The goals determine the desired post-states. In case the

⁸ In German: Auensicht

7

2 Basic Principles

goals allow alternative states, the objectives determine which post-states should be reached. Such a task is called decision task as opposed to a transformation task where the post-states are denite [FeSi06, p. 193].

The inside view 9 describes how a task should be executed in order to fulll goals and objectives, that is, it denes the procedure 10 (cp. Figure 2.3).

For persons as task bearers the procedure is often dened using natural language. For machines imperative or declarative languages can be used. The objectives specic to task bearers are also part of the inside view. Such objectives are for instance to minimize the input of resources or to stick to given execution times [FeSi06, p. 93]. The procedure itself consists of sequential or parallel running actions which act on the task object. If an action can be described functional, machines are able to handle it, otherwise it has to be fullled by a person. The action control determines the order of the actions and initiates them in order to reach the goal. Depending on the type of procedure the actions might report back to the action control. Pre-events and post-events link the action controls of successive tasks [FeSi06, p. 97].

⁹ In German: Innensicht

¹⁰ In German: L osungsverfahren

8

2 Basic Principles

2.1.4 Application Systems

The (business) application system is the automated sub-system of the business in-formation system. It generally consists of several isolated application (sub-)systems

or a network of integrated application (sub-)systems [Fer + 96, p. 11]. On the level of tasks of the application system the automated information processing tasks and

their relationships are located. [Fer + 96, p. 11]. To be able to take over certain tasks, computer and communication systems have to be extended by programs, that is system and application software. These extended systems represent the level of task bearers of the application system and are often referred to directly as application systems. Application systems are designed for specic tasks or task elds [FeSi06, p. 4 et seq.]. The interfaces are determined by the information re-

lationships between their tasks and the tasks of their environment [Fer + 96, p. 11]. For applications planning it is suggested rst to break down the global task of a business system stepwise into subtasks and then to group the elementary tasks for the intended types of task bearers. Finally an application system can be specied

for a group of tasks [Fer + 96, p. 12]. Those tasks have to be suitable for automation of course. As computers are deterministic this is only the case if the tasks can be described functional (see [FeSi06, p. 105 et sqq.] for the formal criteria). However, tasks suitable for automation might still be not automated due to businesslike criteria [FeSi06, p. 109 et sqq.]. For example a cost-benet analysis could reveal that it is more protable to assign persons to certain tasks. But this decision then remains to the management.

2.1.5 Distributed Systems

A distributed system is dened as follows [FeSi94, Ensl78]:

From the outside view it is a black box and pursuing a set of goals.

The inside view reveals autonomous components which cooperate in pursuing these goals. No component has the global control.

As isolated components would not be able to pursue joint goals, the rst property demands a distributed system to be an integrated system. From the autonomy aspect of the second property follows that there exist separate concurrent processes, that is the components communicate exchanging messages and service packages [FeSi94, p. 3].

This characterization of a distributed system can be applied to business systems, business application systems and computer systems. In a distributed business sys-

9

2 Basic Principles

tem there are interacting business processes pursuing joint enterprise goals. For distributed application systems and distributed computer systems the denition can be further extended. The black box characteristic refers to system transparency, which means that the distribution is invisible to the user. Furthermore, the autonomy of components requires loose coupling [FeSi94, p. 3]. Figure 2.4 claries the dierence between loose coupling and tight coupling.

Figure 2.4: Loosely Coupled and Tightly Coupled Components, [FeSi94, p. 3]

Whereas tightly coupled components communicate by means of a shared memory, loosely coupled components have their own memory and communicate by exchanging messages via communication channels [FeSi94, p. 3]. However, this is only one denition of loose coupling. In Chapter 3) several levels of loose coupling are introduced.

There exist dierent degrees of distribution for a system. By coupling formerly loosely coupled components tightly the degree of distribution gets lower. Exchanging tightly coupled components through loosely coupled components increases the degree of distribution.

The architecture design of the case study in Chapter 6 will be geared to the conceptual framework for distributed systems shown in Figure 2.5.

Figure 2.5: Conceptual Framework for Distributed Systems, [FeSi94, p. 4]

The framework distinguishes three levels of specication [FeSi94, p. 4]:

1. The distributed business system level consists of cooperating business processes. A process can become distributed by being split up into several loosely coupled sub-processes. To achieve automation or semi-automation of tasks, the processes are supported by application systems. It is important

10

2 Basic Principles

to identify the scope of those application systems on the basis of the business process models before proceeding to the next level.

2. On the level of the distributed business application system domain related components are divided into sub-components for communication, application and data management. In case the (sub-)components on this level are all loosely coupled this leads to the maximum achievable degree of distribution. In a second step those domain related components can be substituted by tightly coupled components according to specic design goals. Those components nally use the machines determined at the third level.

3. On the level of the distributed computing system the virtual and real machines, which serve as task bearers for the application components, are specied. Virtual machines are for example database management systems, user-interface management systems or application-independent class libraries. Computers and communication networks are examples for real machines.

2.2 Architectures of Information and Application

Systems

2.2.1 Information System Architecture

In Section 2.1.1 information systems have been introduced. For the integral analysis and design as well as for the goal-oriented use of information systems, architectures of information systems provided an important means [Sinz02, p. 1056]. According to SINZ the architecture of an information system can be seen in analogy to architectures in the building industry. Thus an information system architecture includes the

construction plan of the business information system, in the sense of a description of its components and their relations from all relevant perspectives, as well as the

rules for creating the construction plan.

The construction plan is specied by the model system of the information system. Meta-models outline the rules for construction [Sinz02, p. 1055].

11

2 Basic Principles

Figure 2.6 shows a generic architectural framework 11 . To reduce the complexity of

the model system it is structured into dierent levels and associated views [Sinz02, p. 1056].

Figure 2.6: Generic Architectural Framework, [Sinz02, p. 1056]

Levels describe an information system completely from one perspective, each following a certain modeling goal. A relationship meta-model can be provided to describe the relationship between two adjacent levels. Views are projections onto specic levels and normally are incomplete descriptions of the level in order to better cope with the complexity [Sinz02, p. 1057]. Heuristic modeling knowledge for specic levels is oered by patterns, which further limit the structures of a model system allowed by the meta-model. Although they are mostly known from object oriented software engineering (cp. Model-View-Controller pattern), the concept of patterns can be used on all levels of the model [Sinz02, p. 1058].

The perspective of tasks, perspective of task bearers, functional perspective, software perspective as well as outside perspective and inside perspective are important perspectives which might lead to separate levels of an architecture [Sinz02, p. 1057]. Views are for example the view of data, the view of functions, the view of interactions and the process view. Whereas the process view is dynamic, the views mentioned before are static views [FeSi06, p. 130].

The level of tasks of an information system architecture corresponds to its level of functional requirements 12 . If needed it can be separated into sub levels. On the

level of task bearers it can be dierentiated between levels for machines and levels for human task bearers. The former corresponds to levels of the software concept, the latter to organizational concept levels.

¹¹ In German: Generischer Architekturrahmen

¹² Fachkonzeptebene

12

2 Basic Principles

The way of structuring the model system and the manner of describing the model levels and views are determined by the enterprise architecture approach 13 [Fer + 96, p. 31]. Enterprise architecture approaches targeted to the level of func-

tional requirements include ARIS (Architecture of Integrated Information Systems), PROMET (Process Method) and SOM (Semantic Object Model).

2.2.2 Application System Architecture

In section 2.1.4 application systems have been introduced as automated subsystems of information systems. Likewise, an application system architecture is a sub architecture of an automated part of an information system architecture. As such it has just like the information system architecture a level of tasks and a level of task bearers. The latter is known as the level of the software concept of application systems. Figure 2.7 again visualizes the coherences.

Figure 2.7: Information System Architecture, Application System Architecture and Software Architecture

¹³ In German: Architekturansatz

13

3 Service-Oriented Architecture

It is not the strongest of the species that survive, nor the

In the previous chapter, architecture has been introduced as a means of describing components and their relations. As the wording 'service-oriented' suggests, the components in the focus of service-oriented architecture are services. So it makes sense to think about what a service is and which role it plays in a service-oriented architecture.

3.1 Fundamentals of Service-Oriented Architecture

3.1.1 The SOA Concept

The basic concept of a service-oriented architecture (SOA) includes the three roles service provider, service consumer and service broker (Figure 3.1).

The service provider oers a service and may publish the service description to a service registry. A service broker administrates the references to services in a public or corporate registry and oers functionality to search and nd those references. The service consumer can nd services in the registry and uses them according to

14

3 Service-Oriented Architecture

the information provided in the service description. This basic concept is technology independent. Which communication technology is used for the interaction between service provider and service consumer as well as how the publish or nd phase is implemented is not specied. In the same way, how a service registry offers the possibility to nd a service description is not specied. Theoretically, even an excel sheet could serve as a registry in case every service consumer has access. But, of course, in realistic scenarios with a lot of services it will probably be fully automated, easily accessible and will oer dierent ways for searching services.

The awareness of a service is achieved through the use of service descriptions. Services use the service descriptions in a manner that is classied as loosely coupled. Messages serve as independent units of communication. Like services, messages should be autonomous and have enough intelligence to self-govern their parts of processing logic [Erl05, p. 35]. So far, this \appears similar to past distributed architectures that support messaging and a separation of interface from processing logic" [Erl05, p. 36]. What distinguishes it is how services, descriptions and messages are designed. \This is where service-orientation comes in" [Erl05, p. 36].

3.1.2 Principles of Service-Orientation

A common but dangerous assumption is the perception, that the benets promised by current mainstream SOA are attainable solely through a deeper investment in the Web services platform [Erl05, p. 3]. Jones similarly states that service-oriented architecture is \a powerful term that is regularly abused to refer to development technologies rather than an architectural approach, in the same way as Object Oriented Design was abused to refer to programming languages rather than a fundamentally dierent approach to design" [Jone06, p. 2]. Therefore it is important to determine, what it means for automation logic to be truly service-oriented [Erl05, p. 3] and what makes an individual service suitable for SOA in support of its strategic goal [Erl06a].

Dierent organizations have published their own version of service-oriented principles [Erl05, p. 311]. Nevertheless there is a \set of commonly accepted principles that, when applied, position and shape the primitive components (services, descriptions, messages) found in a typical service-oriented environment" [Erl06a]. These principles are discussed in the following section.

While service-orientation has had many in uences, its roots lie in a software engineering theory known as the separation of concerns. This theory suggests to break down a large problem into a series of smaller problems (concerns). As a

15

3 Service-Oriented Architecture

consequence the logic to solve the large problem can also be decomposed into a collection of smaller, related pieces, whereas each piece of logic addresses a specic concern [Erl06a].

Other paradigms like object-orientation or component-based approaches have also implemented this theory but key service-orientation principles provide a unique approach to how the separation is performed [Erl06a].

The principles autonomy, loose coupling, abstraction and the need for a formal contract can be considered as core principles which establish a baseline foundation for SOA. The principles that services are composable, reusable, stateless and discoverable are enable by the core principles [Erl06a].

The fact that Web services naturally support a subset of these principles may give an indication why the Web services technology platform is often considered suitable for building service-oriented solutions [Erl06a].

Services should share a formal contract

Service metadata provides information about a service. This information normally is formally dened by service description documents. Web service description documents are for example the WSDL denition and the XSD schema. Together the description documents form the service contract. The service contract provides a formal denition of the service endpoint, each service operation, every input and output message supported by each operation, the data representation model of each message's contents as well as rules and characteristics of the service and its operations. The contract denes large parts of the underlying architecture and even semantic information, that describes how the service will fulll a certain task, may be provided. As service requestors can become dependent on the service contract once it has been dened, contracts need to be carefully maintained and versioned [Erl06b].

Services should be loosely coupled

A key goal of service-orientation is to respond to unforseen changes in an ecient manner. As the factors that drive the changes are often external to the IT environment, the necessary evolution of IT systems and applications can never be accurately planned. Loosely coupled relationships between services directly sup-port agility [Erl06b]. Loose coupling is \a condition wherein a service acquires knowledge of another service while still remaining independent of that service.

16

3 Service-Oriented Architecture

Loose coupling is achieved through the use of service contracts that allow services to interact within predened parameters" [Erl05, p. 297]. Thus the dependency is limited to the information contained in the service contract and the service contract therefore should be designed in a way that it is not specic to any one service requestor. Krafzig identies several levels on which tight and loose coupling dierentiate, namely physical coupling, communication style, type system, interaction pattern, control of process logic, service discovery and binding, and platform dependencies (Figure 3.2).

Services should abstract underlying logic

A service can be seen as a black box which hides the details from the consumer. This is also called service interface-level abstraction. The service contract determines which functionality is made consumable and which stays hidden. The amount of application logic a service can represent is not restricted, the source of application logic is determined neither. A service can support a simple task or be an entry point to a whole application. It can be based on application logic from a single system or access dierent system to solve the task. Services are containers for service operations. Thus in fact the collective level of abstraction attained by the single service operations determine the abstraction level of the service as a whole [Erl06c].

Many people wonder what is new about services because objects and components abstract underlying logic as well. However, this is not necessarily a contradiction. Abstraction has always been an important means to cope with the complexity of information systems. SOA just establishes another abstraction layer to hide complexity from the consumer. The dierent layers of abstraction of an SOA are visible in Figure 3.3. The service layer further abstracts underlying layers like the

17

3 Service-Oriented Architecture

object and component layer and oers services to the process layer. The process layer is a realization of the business models established on the enterprise layer.

Services should be reusable

Service reuse improves an organizations overall responsiveness to change because it normally reduces the time needed to develop new application logic. Reuse is encouraged even when no immediate requirements for reuse exist. The decrease development eorts through reuse, should result in more cost-eectiveness [Erl06c].

Services should be discoverable

In order that redundant development eorts are avoided, a service needs to be discoverable. So the overall purpose of the service as well as the functionality of service operations need to be suciently described. Although this principle is related to discovery mechanisms like service repositories and service registries on an architecture level, it is distinct from them and services should be designed as discoverable as possible regardless of whether such mechanisms currently exist [Erl06d].

Services should be composable

Service composition is important because \it ensures that services are designed in such a manner so they can participate as eective members, or controllers, of these composition" [Erl06d]. As composition is just another form of reuse, service operations need to be designed in a standardized manner and with the right level of granularity to maximize composition opportunities [Erl06d].

18

3 Service-Oriented Architecture

Services should be autonomous

Reuse is an important strategic goal of service-orientation. So a service is made available to a large number of consumers and as a consequence can be part of several business processes and service compositions. High usage volumes, unpredictable usage scenarios and concurrent access may be the result. So the service should be designed in a way that it facilitates concurrent access and other reliability-related concerns. This is where the principles statelessness and autonomy come in [Erl06e].

Autonomy is a measure for the degree of control a service has over its underlying resources. By increasing the degree of control, dependencies on shared resources in an enterprise are reduced and reliability and predictability of the service are increased. Although exclusive ownership of resources can not always be provided, it should at least attain a reasonable level of control. One can dierentiate between pure autonomy and service-level autonomy. Whereas pure autonomy means that the underlying logic is under complete control and ownership of the service, servicelevel autonomy is reached when a service shares underlying resources but the service boundaries are distinct [Erl06e].

Services should be stateless

The second principle which should facilitate concurrent access as well as promote reusability and reliability, is the principle of statelessness. When a software program is invoked or executed in enters in an active state. While it is not in use it stays in a passive (non-active) state. For active states two primary conditions are dierentiated: stateless and stateful. When automating a particular task, data specic to that task, data information, has to be processed. A program is considered to be stateless when it is active but no engaged in the processing of state information. In case it is actively processing or retaining state information it is called stateful [Erl06e]. \The principle states that services should minimize the amount of state information they manage, as well as the duration for which they remain stateful" [Erl06e]. To make this happen, the architecture needs to be equipped with state deferral extensions and stateless processing considerations have to be applied to the service logic [Erl06e]. Figure 3.4 illustrates the dierence between the two states.

Marks and Bell [MaBe06] also mention well-dened service contracts, loose coupling, discoverability, composability and reusability but add the importance of coarse-grained, business aligned, durable and interoperable service into the discussion.

19

3 Service-Oriented Architecture

Services should be coarse-grained

Coarse-grained means that \services should represent business functions, processes, or transactions and encapsulate other ne-grained components or services within them" [MaBe06, p. 39]. Services will not be reusable and suer from performance issues in case they are too big [MaBe06, p. 40]. Additionally, if they bundle too much functionality and are specialized for certain applications the reusability will be limited. On the other hand, too ne grained services may result in an uncontrollable set of services especially in large systems [Amm + 05, p. 1506].

Stevens identies too ways of applying the concept of granularity. A service itself can be coarse grained or ne grained, which refers to how much functionality a service covers. The second way refers to the way service methods are implemented. A ne-grained service would only return single parameters matching the needs of specic clients, whereas a coarse-grained service would try to match more needs [Stev]. In his opinion a nal decision whether coarse-grained or ne-grained services are oered best is not necessary as both can exist in parallel so that clients can use the service that ts their requirements. What he suggests are multi-grained services by creating ne-grained services and wrapping them in coarse-grained facades [Stev]. However, thereby one has to be aware of aspects like reusability, autonomy and that a higher number of services has to be managed.

Services are business aligned

According to Marks and Bell the identication and analysis of services should begin with business imperatives and business requirements, and afterward other services like technical, data and infrastructure services can be considered.

20