Lade Inhalt...

Design and Implementation of a service-oriented Information System Architecture based on a Case Study

©2006 Diplomarbeit 163 Seiten

Zusammenfassung

Inhaltsangabe:Abstract:
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. 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 SOA already crossed the peak and is now in the trough of disillusionment. But SOA is far from being unfashionable as it would be expected during this phase. There is still high media coverage and a lot of SOA books have been 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 benefits. This is probably due to the fact that companies experienced, that implementing an 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. Besides high costs expected from migration to SOA the lack of SOA know-how is identified 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 confirmed 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. 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 fifth enterprise has developed a platform strategy. Furthermore, enterprise SOA is still a topic of the IT department, although it would be […]

Leseprobe

Inhaltsverzeichnis


Tobias Thiel
Design and Implementation of a service-oriented Information System Architecture
based on a Case Study
ISBN: 978-3-8366-0258-7
Druck Diplomica® GmbH, Hamburg, 2007
Zugl. Otto-Friedrich-Universität Bamberg, Bamberg, Deutschland, Diplomarbeit, 2006
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica GmbH
http://www.diplom.de, Hamburg 2007
Printed in Germany

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
Erklarung
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 Infor-
mation 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 require-
ments 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 oppor-
tunity 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 con-
ducted 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 enter-
prises are just a little or not at all familiar with enterprise SOA and only every
fth enterprise has developed a platform strategy [Putt06]. Furthermore, enter-
prise 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 [Putt06].
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 vendor-
neutral, 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
1
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.
Figure 1.2: Structure of the 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 archi-
tecture. 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 Pro-
cedures, 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 di-
rectly linked to the topic.
Important terms are set to italic type. Where it seemed appropriate control ele-
ments 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
consequence of consistently applying the basic fundamentals.
| Jim Rohn, American Business Philosopher
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 ex-
ample it is receiving, transforming, saving, transmitting or providing information.
As information systems are very important for organizations in commerce and ad-
ministration 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 sys-
tems
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 en-
vironment such as customers, suppliers and other partners. They are goal oriented
1
In German: Informationssystem
2
In German: betriebliches Informationssystem
3
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 sys-
tems 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 sys-
tem. 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 archi-
tecture 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.
4
In German: Sachziele
5
In German: Formalziele
6
In German: Aufgabenebene
7
Also called level of actors. It is important to understand that actors or task bearers can be
humans and machines. In German: Aufgabentragerebene
6

2 Basic Principles
Figure 2.1: Information System, cp. [FeSi06, p. 4/444]
The level of tasks consists of the information processing tasks that are interlinked
through information relationships. On the level of task bearers persons and ma-
chines (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
8
In German: Auensicht
7

2 Basic Principles
Figure 2.2: Structure of a Task, cp. [FeSi06, p. 92]
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).
Figure 2.3: Structure of a Procedure, cp. [FeSi06, p. 98]
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].
9
In German: Innensicht
10
In German: Losungsverfahren
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). How-
ever, 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 dis-
tributed 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 auton-
omy 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 exchang-
ing 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. Exchang-
ing 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 con-
ceptual 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 pro-
cesses. 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 compo-
nents nally use the machines determined at the third level.
3. On the level of the distributed computing system the virtual and real ma-
chines, 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 de-
scription 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 fol-
lowing 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 bet-
ter 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, soft-
ware 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 inter-
actions 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.
11
In German: Generischer Architekturrahmen
12
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 Sys-
tems), 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 sub-
systems 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
13
In German: Architekturansatz
13

3 Service-Oriented Architecture
It is not the strongest of the species that survive, nor the
most intelligent, but the ones most responsive to change.
| Charles Darwin, English Naturalist
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).
Figure 3.1: Basic Concept of SOA, [Amm
+
05, p. 1507]
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 tech-
nology 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 of-
fers 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. Ser-
vices 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 process-
ing 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 fun-
damentally 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 princi-
ples [Erl05, p. 311]. Nevertheless there is a \set of commonly accepted principles
that, when applied, position and shape the primitive components (services, descrip-
tions, 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 en-
gineering 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 founda-
tion 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 doc-
uments 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 oper-
ations. 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 en-
vironment, 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 con-
tract 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, interac-
tion pattern, control of process logic, service discovery and binding, and platform
dependencies (Figure 3.2).
Figure 3.2: Dierent Levels of Tight and Loose Coupling
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.
Figure 3.3: SOA Layers of Abstraction, [Bie
+
06, p. 87]
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, service-
level 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 pro-
gram 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 spe-
cic 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 infor-
mation. 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 cou-
pling, discoverability, composability and reusability but add the importance of
coarse-grained, business aligned, durable and interoperable service into the discus-
sion.
19

3 Service-Oriented Architecture
Figure 3.4: Stateless and Stateful, [Erl05, p. 308]
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 uncon-
trollable 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 ser-
vice 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 spe-
cic 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

3 Service-Oriented Architecture
Services should be interoperable
Often there is a lack of interoperability which results from the dierential applica-
tion of policies, standards and other design criteria. So Marks and Bell suggest
to enforce a body of SOA policies across the service lifecycle.
Services should be durable
Durable nally means that in a SOA the lasting assets should be designed as
services [Stev]. But this somehow is also a logical consequence with regards to
design and development costs. Investing the high eort probably does not make
sense for a short period.
3.1.3 Meta-Model for Service-Oriented Architecture
Whereas design principles are discussed very diverse in literature, there is to a
large extend agreement on what the elements of service-oriented architectures are
[Sch
+
06, p. 23]. Figure 3.5 introduces a meta-model for service-oriented architec-
tures. Therein SOA is perceived as an integration architecture, which links the
process level with the application system level and which emphasizes services as
an integral part [Sch
+
06, p. 25].
The application systems layer consists of business application systems which im-
plement application and data functionality. The functionality they oer can po-
tentially be used in business activities [Heu
+
06, p. 3].
Functionality provided by the application systems layer is structured and encapsu-
lated within services depending on functional requirements of the processes. The
services form a standardized layer of interfaces and communication spanning the
whole organization. They communicate via messages and are described by service
specications, which are published in a central repository. Application domains
group functions and data which are functional dependent [Heu
+
06, p. 3].
The work ow integration layer controls business processes which may involve dif-
ferent roles and span dierent application systems. A work ow at runtime is an
automated sub-process which transfers documents, information and tasks from one
working resource to another one based on dened rules [Heu
+
06, p. 3].
On the desktop integration layer all applications necessary to fulll the tasks are
brought together. It represents the perspective of an employee or user. Portals and
21

3 Service-Oriented Architecture
Figure 3.5: Meta-model for Service-Oriented Architectures
composite applications are the typical form of desktop integration today [Heu
+
06,
p. 3].
22

Details

Seiten
Erscheinungsform
Originalausgabe
Jahr
2006
ISBN (eBook)
9783956360770
ISBN (Paperback)
9783836602587
Dateigröße
8.9 MB
Sprache
Englisch
Institution / Hochschule
Otto-Friedrich-Universität Bamberg – Wirtschaftsinformatik und Angewandte Informatik, Studiengang Wirtschaftsinformatik
Erscheinungsdatum
2007 (April)
Note
1,3
Schlagworte
enterprise wirtschaftsinformatik service
Zurück

Titel: Design and Implementation of a service-oriented Information System Architecture based on a Case Study
book preview page numper 1
book preview page numper 2
book preview page numper 3
book preview page numper 4
book preview page numper 5
book preview page numper 6
book preview page numper 7
book preview page numper 8
book preview page numper 9
book preview page numper 10
book preview page numper 11
book preview page numper 12
book preview page numper 13
book preview page numper 14
book preview page numper 15
book preview page numper 16
book preview page numper 17
book preview page numper 18
book preview page numper 19
book preview page numper 20
book preview page numper 21
book preview page numper 22
book preview page numper 23
book preview page numper 24
book preview page numper 25
book preview page numper 26
book preview page numper 27
book preview page numper 28
book preview page numper 29
book preview page numper 30
book preview page numper 31
book preview page numper 32
book preview page numper 33
book preview page numper 34
163 Seiten
Cookie-Einstellungen