Design and Implementation of a Service-oriented Information System Architecture Based on a Case Study

Mémoire (de fin d'études) , 2006 , 161 Pages , Note: 1,3

Informatique - Informatique Appliquée à la Gestion

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.

Contents

Abbreviations

List of Figures

Listings

1 Introduction
1.1 Motivation and Objectives
1.2 Structure of the Thesis
1.3 General Conventions
1.4 Cooperation

2 Basic Principles
2.1 Principles of Information and Application Systems
2.1.1 Information Systems
2.1.2 Level of Tasks and Level of Task Bearers
2.1.3 The Concept of a Business Task
2.1.4 Application Systems
2.1.5 Distributed Systems
2.2 Architectures of Information and Application Systems
2.2.1 Information System Architecture
2.2.2 Application System Architecture

3 Service-Oriented Architecture
3.1 Fundamentals of Service-Oriented Architecture
3.1.1 The SOA Concept
3.1.2 Principles of Service-Orientation
3.1.3 Meta-Model for Service-Oriented Architecture
3.1.4 Reference Model for Service-Oriented Architecture .
3.1.5 De nition of SOA
3.2 Implementation of Service Oriented Architectures

4.1 Fundamentals of Enterprise Service-Oriented Architecture
4.1.1 Basic Concepts of Enterprise SOA
4.1.2 De nition of Enterprise SOA
4.2 Technology Environment of Enterprise Service-Oriented Architecture
4.2.1 NetWeaver Overview
4.2.2 Composite Application Framework
4.2.3 Visual Composer
4.3 Ecosystem

5 Approach to Design and Implementation of an SOA
5.1 Design of an SOA
5.1.1 The Semantic Object Model (SOM)
5.1.2 Speci cation of the Business System using SOM Methodology
5.1.3 Speci cation of the Business Application System using SOM Methodology
5.1.4 Technical Design for Implementation with SAP NetWeaver
5.2 Implementation of an SOA using SAP NetWeaver Technology
5.2.1 Creation of Processes with CAF Guided Procedures
5.2.2 Implementation of Back End Web Services in ABAP or Java
5.2.3 Implementation of Composite Services with CAF Core
5.2.4 Implementation of User Interfaces with Visual Composer

6 Design and Implementation of the Case Study Architecture
6.1 Introduction
6.1.1 Technical Environment
6.1.2 Scenario of the Case Study
6.2 Design of the Case Study Architecture
6.2.1 Speci cation of the Business System
6.2.2 Speci cation of the Business Application System
6.2.3 Technical Design for Implementation with SAP NetWeaver
6.3 Implementation of the Case Study Architecture
6.3.1 Process, Blocks and Actions in CAF GP
6.3.2 Back End Web Services based on J2EE Development
6.3.3 Composite Services and Web Services in CAF Core
6.3.4 Visual Composer iViews with Web Service Calls
6.3.5 Users in the Enterprise Portal
6.3.6 Callable Objects and Process Flow in CAF GP
6.3.7 Universal Work List Con guration
6.3.8 Process Initiation
6.4 Evaluation
6.4.1 Design Phase
6.4.2 Implementation Phase

7 Summary

Bibliography

Appendix
A SOA De nitions
B Case Study Design
C Case Study Implementation
C.1 CAF Core
C.2 Visual Composer
C.3 CAF GP
C.4 Demo

Abbreviations

Abbildung in dieser Leseprobe nicht enthalten

List of Figures

1.1 Hype Cycle for Emerging Technologies, [FeLi05]

1.2 Structure of the Thesis

2.1 Information System, cp. [FeSi06, p. 4/444]

2.2 Structure of a Task, cp. [FeSi06, p. 92]

2.3 Structure of a Procedure, cp. [FeSi06, p. 98]

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

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

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

2.7 Information System Architecture, Application System Architecture and Software Architecture

3.1 Basic Concept of SOA, [Amm+05, p. 1507]

3.2 Di erent Levels of Tight and Loose Coupling

3.3 SOA Layers of Abstraction, [Bie+06, p. 87]

3.4 Stateless and Stateful, [Erl05, p. 308]

3.5 Meta-model for Service-Oriented Architectures

3.6 Reference Model for Service-Oriented Architectures

3.7 SOAP Message and a WSDL service speci cation, [Alo+04, p. 157/167]

3.8 Web Service Interaction Model

3.9 WS-* Standards, [Mult06]

4.1 Enterprise Service Example 'Cancel Order', [SAPT06e, SOA200]

4.2 SAP's Enterprise Service-Oriented Architecture

4.3 From Infrastructure to Applistructure, [SAPT06c]

4.4 Enterprise SOA with SAP NetWeaver, Own Illustration

4.5 Anatomy of a Composite Application, [SAPT06a]

4.6 Types of Composites, [SAPNb, p. 40]

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

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

4.9 Options for Adding Callable Objects to Actions, Own Graphic

4.10 Architecture of Visual Composer, [SAPT06e]

4.11 Enterprise Services Request and Review De nition Groups

5.1 Enterprise Architecture of SOM [FeSi98, p. 341]

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

5.3 Transaction-Oriented Concept of Coordinating Loosely Coupled Business Objects, [FeSi97, p. 13]

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

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

5.6 Relationship Meta-Model for the SOM business application system and Guided Procedures Design Time

5.7 Creation of Callable Objects in GP, [SAPT06b]

5.8 Creation of Actions in GP, [SAPT06b]

5.9 Creation of Blocks in GP, [SAPT06b]

5.10 Creation of Processes in GP, [SAPT06b]

5.11 Inside-Out and Outside-In Web Services, [SAPT06d]

5.12 Visual Composer Modeling Work ow, [SAPT06e]

6.1 Interaction Schema (left) and Task-Event Schema (right) of Business Process Distribution (First Level)

6.2 Interaction Schema of Business Process Distribution (Final Level)

6.3 Schema of Task Classes

6.4 Guided Procedures Process Flow

6.5 Service-Oriented Architecture of Event Management Group .

6.6 Guided Procedures Gallery Menu

6.7 Created Actions in Gallery

6.8 Tree Structure of GP Elements

6.9 Service Enablement of EDMFoundationBean

6.10 Backend Web Services

6.11 CAF Core Development Component

6.12 External Service EMGProjectWS

6.13 Attributes of Entity Services

6.14 Entity Service with Remote Persistency Mapping .

6.15 Operations of Application Service

6.16 Creation of Portal Content Folder

6.17 Visual Composer Compiler Options

6.18 Visual Composer System De nition

6.19 iViews of ProjectAssignmentsCreationProcess

6.20 Model for iView Send Rental Order

6.21 Layout for iView Send Rental Order

6.22 Mapping for Event in iView Select Employees

6.23 ResultStates in iView Accept Rental Order

6.24 Action in iView Select Employee

6.25 Assigned Employees Table Field in iView Select Employee

6.26 Layers in iView Select Material

6.27 Adding iViews to EP Roles

6.28 Creation of Portal Users

6.29 ResultStates of Action Accept Order in GP

6.30 Parameter Mapping Groups of Block Project Determination Phase .

6.31 Roles in Process Project Assignments Creation

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

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

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

B.4 Schema of Conceptual Classes

C.1 GML Source for iView Send Rental Order

C.2 Model for iView Accept Rental Order

C.3 Model for iView Select Employees

C.4 Model for iView Approve Employee List

C.5 Model for iView Select Material

C.6 Model for iView Approve Material

C.7 Model for iView Send Rental Order

C.8 Available Callable Object Types

C.9 Process Initiation (Emil Eve)

C.10 Universal Worklist (Peter Pro)

C.11 Send Rental Order (Peter Pro)

C.12 Universal Worklist (Richard Rent)

C.13 Accept Rental Order (Richard Rent)

C.14 Universal Worklist (Eric Empl)

C.15 Select Employees (Eric Empl)

C.16 Universal Worklist (Marcus Mat)

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

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

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

C.20 Select Material - Send (Marcus Mat)

C.21 Universal Worklist (Richard Rent)

C.22 Approve Employee List (Richard Rent)

C.23 Approve Material List (Richard Rent)

C.24 Universal Worklist (Peter Pro)

C.25 Finalize Rental Order (Peter Pro)

C.26 Process Review (Emil Eve)

C.1 Operation ndEmployeeAssignmentListForProject

C.2 Operation createEmployeeAssignmentListForProject

C.3 Operation queryEmployees

C.4 Operation queryProjects

C.5 Operation queryProjects (External Service Access)

C.6 Entity Service Employee

C.7 Application Service ManageEmployee

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.

Abbildung in dieser Leseprobe nicht enthalten

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 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 bene ts. 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 identi ed 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 con rmed 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, 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 o ered by SAP [Putt06].

As with SOA 2.01 already the following hype is announced [Herr06], it makes sense to refrain from SOA marketing e orts 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 di erent 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 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.

Abbildung in dieser Leseprobe nicht enthalten

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 de ned. 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 de nition 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.

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 directly 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 speci c 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 de nition and development. I would like to thank the whole team for the continuous support.

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 (IS) is not uniformly used in literature. This is a consequence of the di erent 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 [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 . 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 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 pro t and e ciency. In addition business sys- tems are socio-technical since the tasks are ful lled 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 de ned 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 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 di erentiates during the analysis and design of business information system between a level of tasks 6 and a level of task bearers [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.

Abbildung in dieser Leseprobe nicht enthalten

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 machines (computer systems) are speci ed 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 de ned 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

Abbildung in dieser Leseprobe nicht enthalten

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 de nite [FeSi06, p. 193].

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

Abbildung in dieser Leseprobe nicht enthalten

Figure 2.3: Structure of a Procedure, cp. [FeSi06, p. 98]

For persons as task bearers the procedure is often de ned using natural language. For machines imperative or declarative languages can be used. The objectives speci c 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 ful lled 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].

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 speci c 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 speci ed 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-bene t analysis could reveal that it is more pro table to assign persons to certain tasks. But this decision then remains to the management.

2.1.5 Distributed Systems

A distributed system is de ned 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- tem there are interacting business processes pursuing joint enterprise goals. For distributed application systems and distributed computer systems the de nition 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 clari es the di erence between loose coupling and tight coupling.

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

Abbildung in dieser Leseprobe nicht enthalten

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 de nition of loose coupling. In Chapter 3) several levels of loose coupling are introduced.

There exist di erent 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.

Abbildung in dieser Leseprobe nicht enthalten

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

The framework distinguishes three levels of speci cation [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 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 speci c 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 speci ed. 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 speci ed by the model system of the information system. Meta-models outline the rules for construction [Sinz02, p. 1055].

Figure 2.6 shows a generic architectural framework . To reduce the complexity of the model system it is structured into di erent levels and associated views [Sinz02, p. 1056].

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

Abbildung in dieser Leseprobe nicht enthalten

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 speci c 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 speci c levels is o ered 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 . If needed it can be separated into sub levels. On the level of task bearers it can be di erentiated 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.

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 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.

Abbildung in dieser Leseprobe nicht enthalten

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

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).

Abbildung in dieser Leseprobe nicht enthalten

Figure 3.1: Basic Concept of SOA, [Amm+05, p. 1507]

The service provider o ers 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 o ers functionality to search and nd those references. The service consumer can nd services in the registry and uses them according to 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 speci ed. In the same way, how a service registry of- fers the possibility to nd a service description is not speci ed. 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 o er di erent 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 classi ed 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 bene ts 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 di erent 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].

Di erent 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 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 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 speci c 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 de ned by service description documents. Web service description doc- uments are for example the WSDL de nition and the XSD schema. Together the description documents form the service contract. The service contract provides a formal de nition 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 de nes large parts of the underlying architecture and even semantic information, that describes how the service will ful ll a certain task, may be provided. As service requestors can become dependent on the service contract once it has been de ned, 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 e cient 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.

Loose coupling is achieved through the use of service contracts that allow services to interact within prede ned 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 speci c to any one service requestor. Krafzig identi es several levels on which tight and loose coupling di erentiate, 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: Di erent Levels of Tight and Loose Coupling

Abbildung in dieser Leseprobe nicht enthalten

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 di erent 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 di erent layers of abstraction of an SOA are visible in Figure 3.3. The service layer further abstracts underlying layers like the object and component layer and o ers 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]

Abbildung in dieser Leseprobe nicht enthalten

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 e orts through reuse, should result in more cost-e ectiveness [Erl06c].

Services should be discoverable

In order that redundant development e orts 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 su ciently 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 e ective 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].

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 di erentiate 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 di erentiated: stateless and stateful. When automating a particular task, data spe- ci c 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 di erence between the two states.

Marks and Bell [MaBe06] also mention well-de ned 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.

Figure 3.4: Stateless and Stateful, [Erl05, p. 308]

Abbildung in dieser Leseprobe nicht enthalten

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 su er 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 identi es 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 speci c 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 o ered 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 identi cation 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.

Services should be interoperable

Often there is a lack of interoperability which results from the di erential application 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 e ort 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 architectures. 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 implement application and data functionality. The functionality they o er can potentially 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 speci cations, 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 different roles and span di erent 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 de ned rules [Heu+06, p. 3].

On the desktop integration layer all applications necessary to ful ll the tasks are brought together. It represents the perspective of an employee or user. Portals and

Figure 3.5: Meta-model for Service-Oriented Architectures

Abbildung in dieser Leseprobe nicht enthalten

composite applications are the typical form of desktop integration today [Heu+06, p. 3].

3.1.4 Reference Model for Service-Oriented Architecture

A reference model is an abstract framework for understanding signi cant relationships among the entities of some environment". It consists of \a minimal set of unifying concepts, axioms and relationships within a particular problem domain, and is independent of speci c standards, technologies, implementations, or other concrete details" [Oasi06a, p. 3].

To get an overview which entities have been de ned for service-oriented architec- ture, Figure 3.6 assembles the graphics provided in the standards document into a single graphic. For the original graphics and detailed information see [Oasi06a, p. 1].

Abbildung in dieser Leseprobe nicht enthalten

Figure 3.6: Reference Model for Service-Oriented Architectures

3.1.5 De nition of SOA

After the fundamental concepts of architecture and service-orientation have been discussed, this section now tries to nd a good de nition of SOA in the context of this thesis. There exist a lot of of de nitions, each of them focusing on di erent aspects. Appendix A provides a selection of de nitions. Most people seem to agree that SOA is not a product but rather an architectural style or a concept. Besides that de nitions about SOA vary a lot. Some de nitions will be discussed in the following.

An early de nition

\A service-oriented architecture is a style of application partitioning and targeting (placement). It assumes multiple software tiers and usually has thin clients and fat servers (i.e., little or no business logic on the client), but it is more than that. It organizes software functions into modules in a way that maximizes sharing application code and data" [ScNa96, p. 3]

Although this de nition only has a technical focus, it already mentions two impor- tant aspects. Applications are partitioned into modules and the goal is to maximize reuse.

A minimalistic de nition

\[Service-oriented architecture is a] set of components which can be invoked, and whose interface descriptions can be published and discovered." [W3C04]

This W3C de nition explains in a minimalistic way what can be done with a service or its description but does neither refer to an architecture nor provide any further information how a service should be designed or what the bene t is.

A technical de nition

\A Service-Oriented Architecture (SOA) is a software architecture that is based on the key concepts of an application frontend, service, service repository, and service bus. A service consists of a contract, one or more interfaces, and an implementation." [Kra+05, p. 57]

Krafzig de nes SOA based on four main components. The question is whether all of those components are really needed for an SOA. But when looking at the more detailed explanations for those components one can observe that they are described very general. Application frontends for example \do not necessarily have to inter- act directly with end users. Batch programs or long-living processes that invoke functionality periodically or as a result of speci c events are also valid examples of application frontends" [Kra+05, p. 58]. And a service repository does not have to be technical but can even be paper-based. All in all the de nition might be too imprecise but the fact that interface and implementation are separated, a service is published somewhere and that a contract exists for the service is important.

A business de nition

\SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network. \Services" in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages." [MaBe06, p. 1]

This de nition has a very strong business focus and nearly gives the impression it is all about business and IT has nothing to do anymore besides maintaining a network. But it adds an important and valuable perspective to the de nitions provided so far.

An standardized de nition

\Service Oriented Architecture is a paradigm for organizing and uti- lizing distributed capabilities that may be under the control of di erent ownership domains. It provides a uniform means to o er, discover, in- teract with and use capabilities to produce desired e ects consistent with measurable preconditions and expectations." [Oasi06a, p. 29]

This de nition is provided by the OASIS standards committee in line with the SOA Reference Model o cially published in October. Although the de nition is quite abstract, it can service as a starting point for the de nition of this thesis. As Nickull, the chair of the OASIS SOA-RM Technical Committee states, the model should provide \a clear, singular point of reference" that \enables even those with unique ideas about SOA to describe their work in quanti able terms that can be commonly understood"

Final de nition

Finally, an own de nition is provided. It combines the basic principles discussed in Chapter 2 with the service-orientation concepts explained in this chapter.

\Service-oriented architecture is an information system architecture that promotes agility, reusability and business relevance of applications. On the layer of functional requirements it consists of tasks that are to be carried out when performing a business process, and services as functional units that o er formally speci ed, reusable procedures for ful- lling the tasks appropriately. On the layer of the software concept it consists of services as software units with well-de ned interfaces that have a high degree of distribution and may interact for implementing the o ered procedure."

3.2 Implementation of Service Oriented Architectures

Service-Oriented Architecture is an abstract concept or paradigm. Which technol- ogy is chosen for implementation is not the primary focus [Zach05]. The OASIS SOA Reference Model (cp. Figure 3.6 de nes an execution context as the \set of technical and business elements that form a path between those with needs and those with capabilities and that permit service providers and consumers to inter- act" [Oasi06a, p. 28]. As Jones states at this level technology like Web services should be discussed but that this is independent from the value ascribe to an in- vocation of a service as well as the reasons why this service is called [Jone06, p. 8]. \Technology based SOA places a disproportionate level of importance on the exe- cution context which obscures the basic fact: without the consumer and producer there would be no need for that context, and the objective of the execution context should be to simplify that invocation as much as possible [Jone06, p. 8].

Mahmoud states that although Web services and SOA are two di erent things, Web services are the preferred standards-based way to realize SOA" [Mahm05]. This is supported by many authors, some of them therefore even dedicate their book to SOA discussed under a Web service perspective (e.g. [Dos+05], [NeLo05]). According to Newcomer, the \major advantages of implementing an SOA using Web services are that Web services are pervasive, simple, and platform-neutral" [NeLo05, p. 20]. Erl makes clear that the Web services framework is exible and provides the potential to ful ll the characteristics of SOA and service orientation discussed earlier in this chapter. However, \Web services can be designed to du- plicate the behavior and functionality found in proprietary distributed systems, or they can be designed to be fully SOA-compliant" [Erl05, p. 112]. Although Web services became very popular and part of many existing application environ- ments because of this exibility, it \also reveals the fact that Web services are not necessarily inherently service-oriented" [Erl05, p. 113].

Sun already used the term SOA in conjunction with Jini in the late 1990's. Jini is \an environment for dynamic discovery and use of services over a net- work" [Mahm05]. This concept of services has been extended in a way that Web services are delivered using Web technologies such as Extensible Markup Lan- guage (XML), Web Service Description Language (WSDL), Simple Object Access 1

Protocol (SOAP), and Universal Description, Discovery, and Integration(UDDI) [Mahm05]. Whereas SOAP is a way to communicate via messages, WSDL de- scribes services and UDDI is a standard for name and directory servers [Alo+04, p. 151]. XML provides the common syntax, so data structures and formats of the standards are described as XML documents [Alo+04, p. 151]. Figure 3.7 provides a schematic representation of a SOAP message as well as of a WSDL speci cation.

Abbildung in dieser Leseprobe nicht enthalten

Figure 3.7: SOAP Message and a WSDL service speci cation, [Alo+04, p. 157/167]

SOAP messages are used as an envelop to send whatever information needed. This envelop consists of a SOAP header and a SOAP body. Whereas the SOAP header is optional, the SOAP body is mandatory. Both may have several sub-parts in form of header blocks or body blocks [Alo+04, p. 157]. WSDL speci cations have an abstract and a concrete part. The abstract part de nes a type system in order that messages exchanged can be interpreted correctly at both ends of the commu- nication. A port type is a logical collection of related operations and an operation determines a simple exchange of messages. A message is representing the data exchanged in a single logical transmission and as such a unit of communication with Web services. The concrete part of a WSDL speci cation consists of interface bindings, ports and services. The message encoding and protocol bindings for all operations and messages de ned in a given port type are speci ed by the interface bindings. Ports combine the interface binding with a network address speci ed by a URI where the implementation can be found. They are also known as endpoints. Services nally represent a logical grouping of ports [Alo+04, p. 167 et sqq.].

Figure 3.8 shows the interaction model of Web services. The service provider creates a service de nition in WSDL and publishes the service description to the UDDI services directory. A service consumer may query the directory for service information and, in case he receives a response, can bind and initiate a SOAP request. In return the service consumer receives a SOAP response.

Figure 3.8: Web Service Interaction Model

Abbildung in dieser Leseprobe nicht enthalten

As can be seen the interaction model is very similar to Figure 3.1. So Web services are one option for realizing the SOA basic concept. And as the realization is based on standards it is also a preferable option.

However, the basic Web service standards are not enough to provide a reliable and secure communication environment for services and more di cult interaction mechanism are necessary to realize business processes. Furthermore, for example semantic information can be useful for searching and binding services. That's why many more Web services standards have been de ned, summarized under the term WS*-Extensions. Figure 3.9 gives an overview of current Web service standards. Most standards are currently de ned by the standards bodys W3C and Oasis Open3.

Abbildung in dieser Leseprobe nicht enthalten

Figure 3.9: WS-* Standards, [Mult06]

4 SAP's Enterprise Service-Oriented Architecture

Once an organization loses its spirit of pioneering and rests on its early work, its progress stops. | Thomas Watson Sr., President of IBM

The previous chapter described the general principles of SOA and topics related to it. This chapter will supplement SAP's view of a service-oriented architecture and explain the meaning of enterprise services architecture, the blueprint introduced by SAP in 2003 (cp. [Wood03]). The terms \enterprise services architecture" (ESA) and \enterprise service-oriented architecture" (enterprise SOA/ESOA) are used as synonyms in this chapter because SAP began to promote the term enterprise service-oriented architecture in the second quarter 2006 and SAP press releases, articles and books use both terms without stating any di erences (see [SAP06a, WoMa06]). In a newly published book, Bonnen and Herger state that whereas \ESA focuses mainly on service-enablement of applications and SAP solutions, the Enterprise SOA concept goes one step further". The main di erentiator \is the capability to take existing services and combine them to build new applications, so- called composite applications" [BoHe07, p. 436]. But this probably rather re ects a focus shift in current development activities than a real di erence in terminology or concepts as composite applications have always been an important part of the ESA blueprint (cp. [Wood03, WoMa06]).

4.1 Fundamentals of Enterprise Service-Oriented Architecture

SAP introduced its new architecture enterprise services architecture (ESA) blueprint in 2003 but there is still confusion about what it is and how it di er- entiates from the general SOA concept. In fact, SAP itself \has had a di cult time helping customers and partners fully understand the ESA roadmap, and how it is fundamentally di erent from just adopting SOA technologies [CaMo07, p. 4]. One reason might be that it really requires a change in the way of thinking (SOA has also caused much confusion), another one that the ESA roadmap has been set up as a vision several years in advance and is still not fully completed, so customers and partners had to believe in the vision without being able to make real prove points for themselves.

However, the question remains whether ESA is only fundamentally di erent from adopting SOA technologies or whether it is also fundamentally di erent from SOA as a concept.

4.1.1 Basic Concepts of Enterprise SOA

Campbell and Mohun state that \ESA is a completely new architectural blueprint for SAP. It contains both a technology aspect based on industry-driven SOA and related IT trends, as well as an enterprise business dimension built from SAP's Solution Maps and the company's deep horizontal and vertical process knowledge" [CaMo07, p. 4].

This leads to an important aspect. It is helpful to keep in mind that SAP is primarily a solution provider. As such the company is o ering solutions and bestpractice processes for whole industry segments and for many years already. With ESA, SAP is restructuring its own solution landscape. So in contrast to other vendors in the SOA eld, SAP is not only delivering technology but also solutions which follow the principles introduced by the ESA roadmap.

\The fundamental premise of Enterprise Services Architecture is the abstraction of business activities or events, modeled as enterprise services, from the actual functionality of enterprise applications. Aggregating Web services into businesslevel enterprise services provide more meaningful building blocks for the task of automating enterprise-scale business scenarios. Enterprise services allow IT organizations to e ciently develop composite applications, de ned as applications that compose functionality and information from existing systems to support new business processes or scenarios" [SAPa, p. 7].

There are three main points in this statement: Firstly, enterprise services are used for automating business scenarios. Secondly, enterprise services are an abstraction from the actual functionality of enterprise applications. And nally, composite applications are a means of developing e cient applications based on enterprise services.

Enterprise services are introduced as an aggregation of Web services. Fritz states that \enterprise services are simply Web services that provide enterprise-level busi- ness functionality. They may range from very simple lookup services (like nding a company's location or product o erings) to more complex and composite services - but what they have in common is that they're highly integrated into your process or application" [Frit04].

Figure 4.1: Enterprise Service Example 'Cancel Order', [SAPT06e, SOA200]

Abbildung in dieser Leseprobe nicht enthalten

Figure 4.1 shows an enterprise service Cancel Order which aggregates several Web services to o er more business value. The order cancellation results in several internal steps implemented through Web services, including for example a rollback of inventory, a shipment cancellation and a planning adjustment.

Enterprise services follow clear semantics, which are de ned at di erent levels. The basic elements are global data types. They become the \semantic vocabulary of an enterprise and a basis for describing business objects and de ning the phrases (or messages, technically speaking) that are exchanged by consumers and providers" [Bon+06].

Regarding to the second point, abstraction from actual functionality, it is quite obvious that SAP cannot rebuild its whole application suite in one go following the enterprise services concept. So a large initiative called service-enabling has been started to create enterprise services based on existing functionality of systems like ERP, CRM SCM and so forth. Of course, new functionality will be developed already with the enterprise services concept in mind and therefore o er even more exibility. The rst service-enabled enterprise services have been delivered a few month ago and many more will follow. The ESA Preview System on SDN provides an overview of available and planned services.

Figure 4.2 shows the business process platform (BPP), the basis for SAP's ESA strategy. There are two main parts: SAP NetWeaver as the technological basis of

Abbildung in dieser Leseprobe nicht enthalten

Figure 4.2: SAP's Enterprise Service-Oriented Architecture

BPP. And the application platform which provides reusable business functional- ity through platform process components. A central enterprise service repository allows to identify services and build composite applications on top of them.

4.1.2 De nition of Enterprise SOA

After the basic concepts of ESA or enterprise SOA have been discussed, the question from the beginning, whether ESA is only fundamentally di erent from adopting SOA technologies or whether it is also fundamentally di erent from SOA as a concept, is still open. Probably there exists no clear answer as both terms are used di erently by di erent people. However, although some people may still talk about SOA as a pure technological concept, Chapter 3 made clear that SOA is seen as a business-driven concept. So from a conceptual point of view the ideas are similar. The big di erence is that SAP is not only talking about concepts but also building its own applications in a service-oriented way using SAP technology. So it o ers enterprise services which can be used in a concrete SOA environment of a customer as well as best practices and tools to develop own services and applications using the services.

This results in a nal de nition for enterprise SOA:

\Enterprise SOA (in the way the term is used by SAP) is a refer- ence architecture for service-based, enterprise-scale business solutions and SAP's recommendation for establishing a service-oriented archi- tecture. The focus is on enterprise services used in prechoreographed, easily adaptable business processes and provided by an application plat- form, as well as on the technology platform SAP NetWeaver, which is o ering the supporting infrastructure, frameworks and tools. Enterprise Services are robust, coarse-grained Web services designed at SAP using enterprise-wide harmonized business objects and global data types. The creation of such services is surveyed by a governance process to ensure reuse and high business relevance." Own De nition

In the following, the technology environment of enterprise SOA is introduced in detail.

4.2 Technology Environment of Enterprise

Service-Oriented Architecture

In the following SAP technology for realizing an SOA is discussed. First an overview of the current NetWeaver release is given, including explanations on how the different components and tools are used in the context of SOA. Afterwards the components which are part of the case study, the Composite Application Framework (CAF) and Visual Composer (VC), are introduced more detailed.

4.2.1 NetWeaver Overview

During the last years SAP NetWeaver evolved from a transaction platform to an integration and composition platform (Figure 4.3) [SAPT06c].

Figure 4.3: From Infrastructure to Applistructure, [SAPT06c]

Abbildung in dieser Leseprobe nicht enthalten

The transaction platform mainly consists of the Application Server which provides the necessary infrastructure for applications and for development. Because of its two parts AS ABAP and AS Java, NetWeaver is able to serve as a platform for both worlds, ABAP and Java. Integration capabilities are provided by the Exchange Infrastructure (XI). Human integration (Enterprise Portal) and information inte- gration (Master Data Management, Business Intelligence) is also said to be part of the integration platform. The composition platform nally supports the develop- ment of composite applications, which is a way of developing new applications in a relatively fast and easy manner by using available services. Since then XI also contains the interface de nitions of enterprise services. The Enterprise Services Repository (ESR), which is often mentioned in the context of enterprise SOA, is an evolution of the XI integration repository.

Abbildung in dieser Leseprobe nicht enthalten

Figure 4.4 shows SAP components and tools in the context of enterprise SOA. It consists of two main parts: mySAP Business Suite 2005, which is the current release of SAP's application suite as well as SAP NetWeaver 2004s, the current release of SAP's platform that serves as a basis for the Business Suite and other solutions. Currently available documentation focuses mostly on a speci c product. This graphic was created to get an overall view and to understand the coherences and di erences between certain products. It can serve as a starting point for discussing enterprise SOA concepts. However, it can naturally not cover all aspects but focuses on the ones which were thought to be useful in the context of this thesis.

A well known principle for structuring software systems is to divide them into a communication, application and data layer. The communication layer provides the user interface to enable human-system interaction, the application layer pro- vides the application functionality and the data layer stores the data (see [FeSi06, p. 305]). In service-oriented architectures the application layer is subdivided into a service and a process layer (cp. Chapter 3). The service layer thereby provides the application logic via services, whereas the process layer provides the process logic, that is the control when and in which order those services are accessed.

The graphic takes the separation of layers into account and allocates the com- ponents and tools to those layers. One has to bear in mind that each of these components and tools are applications which could be divided into the di erent layers themselves, but this is not the intention here. The graphic shows which layers are touched by a newly developed application and which applications and tools are necessary for developing and running the application in case of using SAP technology.

Data Layer

In contrast to other vendors' platforms, SAP NetWeaver does not require a cer- tain database. Instead the application server includes a database abstraction layer so that di erent databases can be accessed in the same way using Open SQL. In large enterprises data is normally spread across many databases. In order to get reliable and clean data for analytics the data has to be managed accordingly. SAP NetWeaver Business Intelligence (BI) and Master Data Management (MDM) are supporting this task. BI is used for the IT scenarios enterprise data warehousing, reporting, querying and analysis as well as business planning and analytical ser- vices. Ensuring data quality is another scenario and an important requirement for e ective analysis [WoMa06, p. 309]. BI is becoming service enabled through the XML for Analysis (XMLA) standard. By means of this standard, programmers can specify and execute OLAP queries through a Web service interface. In addition, SAP provides so-called BI consumer services, for example to get the top ten results of a query or to specify alerts, which should provide additional functionality useful for composite applications [WoMa06, p. 310]. Whereas BI is mainly for transac- tional data, that is keeping track of all business activities like for example purchase orders, invoices and so on, Master Data Management is focusing on master data. Master data is not speci c to a certain transaction rather used in several trans- actions [WoMa06, p. 302]. Examples for important master data objects include customer, product, employee or supplier. Master data is an important factor of the business and should be consistent over the whole enterprise to be able to take decisions based on reliable information. MDM provides a lot of functionality which helps to get this uni ed perspective. A rich client interface is provided to browse and clean the master data in the various enterprise applications [WoMa06, p. 302]. Through a process called master data consolidation it is possible to bring master data from distributed systems into a central repository supported by mechanisms like cleansing, de-duplication, normalization and taxonomy management. Master data harmonization is the capability of automated or interactive data distribution so that data changes in one application are transmitted to other applications in order to keep a consistent view. The global data synchronization capabilities allow companies to publish enriched data via a data hub so that business partners can use them in their systems. In addition there is the possibility of central MDM, which means that master data is not created separately in each application anymore but managed centrally in MDM and distributed to the applications every time they need the data [WoMa06, p. 305]. Much of this functionality will be available to composite applications via enterprise services. Uni ed key mapping will be the rst available service; more services for example for nding duplicate data, controlling distribution and synchronization will follow [WoMa06, p. 307].

Service Layer

Services are the basis of any SOA. They can be called from the process layer, communication layer or by other services. NetWeaver 2004s provides di erent ways of creating services.

The rst possibility, called outside-in development, is to start with the creation of a service de nition, that is data types, message type, fault message type and message interface, in the integration repository (cp. [SAPL06e]). Afterwards, an executable interface, known as proxy, is generated from the message interface in the respective development component.

There is a distinction between server proxies and client proxies. Server proxies are needed when certain functionality should be made available for other applications. For a server proxy the message interface has to be speci ed as inbound because request messages should be received. In contrast, client proxies are needed in order to access functionality from other applications. As the message interface is used for sending requests, the category outbound has to be chosen. In a service-oriented scenario, server proxies are needed for the service provider, client proxies for the service consumer.

The proxy generation converts the non-language speci c WSDL interface description into an executable interface and generates an associated class with an empty method. This method, which is automatically executed when the proxy is used, needs to be implemented by the developer in accordance with the required functionality ([SAPL06i, SAPL06a].

After the functionality is implemented it can be made available as a Web service using the Web Service Creation Wizard. This is the same wizard as described in the next paragraph.

The second possibility to create services is called inside-out development. Inside- out development means that functionality which already exists within applications is made accessible from the outside via Web services. There exist wizards both for ABAP and Java, which help to create the web service. In ABAP a remotely enabled function module, a Remote Function Call (RFC) or a BAPI can serve as a source for creating the web service [WoMa06, p. 335]. The documentation ([SAPL06j]) provides more information on how to create a Web service from an ABAP source.

SAP distinguishes composite service creation from general service creation. General services can be consumed by composite applications but in addition the composite application framework o ers a way to extend the functionality provided by the backend and to create own services.

Process Layer

On the process layer there are three di erent applications visible. They all o er a way to implement business processes. However, they have di erent functionality and are used for di erent purposes.

Cross-Component Business Process Management (ccBPM) is part of XI. As the name suggests the main focus is on implementation of processes across compo- nents or di erent applications. Those processes, which are also called integration processes, are designed in the Integration Builder of XI. They might be designed using BPEL-Standard elements complemented by SAP's add-ons where the stan- dard is not su cient. BPEL is an execution language for the orchestration of Web services. In case the applications do not support Web services or other communi- cation technology should be used, XI o ers a large number of adapters to support the integration scenario. Furthermore, it o ers the possibility to de ne mappings between corresponding attributes of integrated applications. Because of its reliable engines and secured environment, the focus of ccBPM is on high-volume ows of transactions between applications. As XI includes messaging and queuing func- tionality, ccBPM is also suitable for long-running transactions and asynchronous communication [SAPI]. However, BPEL does only support backend processes. Hu- man integration, that is the ful llment of speci c process activities by people using a user interface, is not part of the current BPEL speci cation and also not possible with ccBPM. WOODS and MATTERN therefore use the term backend process orchestration to describe the purpose of ccBPM [WoMa06].

The second application at the process layer is Business Work ow, also called WebFlow Engine, which is part of AS ABAP. As opposed to ccBPM, the focus of Business Work ow is the automation of processes within an application. It of- fers various work ow templates which can be easily adjusted to company needs. With Business Work ow not only backend processes but also interactive processes can be automated. In general it is linked to the company's employee directory so that human tasks can be assigned to certain employees or roles. Business work ow uses the object-oriented paradigm. Although external service calls might be pos- sible they usually are not used because XI o ers a better and more secure service infrastructure [SAPI].

The third possibility of process implementation is via Guided Procedures (GP). Guided Procedures, which are part of the composite application framework (CAF), are especially for lightweight, user-centric processes. Through callable objects Guided Procedures are able to easily integrate available services and user interfaces and thus to design new processes. GP allow background execution of certain func- tionality but are mainly for conversational processes supported by user interfaces. WOODS and MATTERN therefore use the term frontend process orchestration [WoMa06]. During design time GP actions, which are basically process steps, are assigned to Enterprise Portal roles. At runtime the user is guided through the process steps by a standard graphical element (thus probably the term Guided Procedures). Each process step thereby might be assigned to a di erent user, so the process can be very interactive.

Whereas ccBPM and Business Work ow are supported by an ABAP work ow en- gine at runtime, GP comes with an embedded Java work ow engine. The work ow is executed completely in the Java stack and context information is stored in the Java server database. However, it is possible to con gure the processing layer of GP so that Business Work ow is the underlying work ow engine. If this is the case, GP process templates are transformed into Business Work ow templates at acti- vation and context information is stored in the ABAP server database [SAP06b, p. 160].

As we have already discussed above, the BPEL standard does not support human interaction. This however is seen as a limitation by IBM and SAP. Therefore they are currently writing on a speci cation to extend the BPEL standard [SAPN06c]. This extension is called BPEL4People and will bring human integration character- istics as described for Business Work ow into BPEL processes. Thus it might well be that ccBPM will support human integration at a later point in time.

Communication Layer

The communication layer o ers several ways for accessing information provided by the underlying applications. The possibilities include mobile devices, MS o ce (joint MS-SAP product Duet) as well as Adobe Interactive Forms or the Enterprise Portal. The UI technologies are not discussed in detail here. But more information regarding to portal technology is provided in the following chapters.

4.2.2 Composite Application Framework

General Explanations

Collaborative processes are often paper- or excel-based and proceeding or parallel to existing processes. Unfortunately, those collaborative processes then are not tracked by systems. Thus composite applications try to provide process exibility and an intelligent user experience to overcome the current problems [SAPI].

\The Composite Application Framework is the 'factory' in which SAP xApps are built, quickly and easily. It contains the tools, methodologies, rules, and patterns that allow SAP and its partners to develop SAP xApps e ciently while leveraging all integration layers" [SAPb]

The Composite Application Framework (CAF) has already been shortly discussed in the context of Figure 4.4. Figure 4.5 shows the typical anatomy of a composite application.

Figure 4.5: Anatomy of a Composite Application, [SAPT06a]

Abbildung in dieser Leseprobe nicht enthalten

A composite application uses, as far as possible, services already available in the backend. Those services might be accessed through the Exchange Infrastructure (XI) or directly. XI can act as a messaging middleware for service communication, connectivity, transformation and portability [SAPT06e]. In some cases it might be su cient to assemble the available backend services into a process, augmented with user interfaces where human action needs to be involved. In many cases however, it will be necessary to add additional business logic in the composite, so composite services are implemented. Remote composite services still make use of backend services to provide the necessary business logic, local services only utilize other local services and business objects. The uni ed service model o ers service abstraction and shield higher layers from service implementation details so that they can easily replaced. A business object, such as customer or invoice, represents a speci c view on a well de ned business content. If the representation of the business object is available in the backend, a remote business object, which provides a certain degree of abstraction from the backend but still transmits all data, is su cient in the composite. In case there is no representation of the business object in the backend, a local business object has to be created which stores its data automatically in a local database. Like for services, a uni ed model is provided for business objects as well, so that transparent usage of local and remote business objects is possible. The business logic implemented in composite services can be made available to the user interface layer, the process layer or even to other applications and services just like backend services. User interfaces can be built on top of the services and can be included with other user interfaces and services in a composite process. Actions with user interfaces are assigned to persons in certain roles.

Depending on the layers involved and the overall complexity, there are di erent types of composite applications. Figure 4.6 illustrates the types which are distin- guished.

Figure 4.6: Types of Composites, [SAPNb, p. 40]

Abbildung in dieser Leseprobe nicht enthalten

Ultra light composites include only processes and user interfaces, so they are ac- cessing the backend directly. Light composites already have backend abstraction by means of an own business object model but the data of the business objects is still stored in the backend. In case the persistency for new business objects resides in the composite it is referred to as medium weight composite. Medium weight composites also include more complex business logic. Heavy weight composites are composites with very complex business logic and with additional data about back- end business objects in the composite. In this case replication and synchronization between composite and backend system is necessary, which adds additional com- plexity to the implementation of the composite. The current focus of composite development is on light and medium weight composites, which are aimed at less than six month of development [SAPNb, p. 40].

[...]

• Université: University of Bamberg
• Note: 1,3
• Auteur: Tobias Thiel (Auteur)
• Année de publication: 2006
• Pages: 161
• N° de catalogue: V71427
• ISBN (ebook): 9783638620635
• ISBN (Livre): 9783656827122
• Langue: anglais
• mots-clé: Design, Implementation, Service-oriented, Information, System, Architecture, Based, Case, Study, Realisierung, IS-Architektur, Fallbeispiels)