Informations- und Anwendungsintegration mit Service-orientierten-Architekturen (SOA)

Transkript

1 Informations- und Anwendungsintegration mit ervice-orientierten-architekturen (OA) HTW Dresden presendet by Dr. Peter Eichhorst CEO OCON Inc. eite 1

2 Agenda Anforderungen und Probleme heutiger IT trukturen ervice Orientiertes Computing (OC) als Lösungsansatz ervice Orientierte Architekturen ein Framework zur Unterstützung von OC Was ist eine OA Architektur (OA) Komponenten einer OA Notwendige tandards und Technologien einer OA Vorteile einer OA Methoden OA basierter Anwendungsentwicklung Tools für OA basierte Anwendungsentwicklung Auswahl des ersten Proof of Concept Projektes Auswahl und chulung des OA Teams Deployment, Offenheit, icherheit, Qo, LAs OA Governance eite 2

3 Anforderungen und Probleme heutiger IT Landschaften Anforderungen Fusionen & Übernahmen Neue Gesetze und Regelierungen (OX/Basel II) IT Governance & Compliance Höhere Kundenerwartungen Wettbewerb neue IT-Technologien Neue Anwendungsentwicklungen Prozesse ändern sich ständig Anwendungs- Integrationen Neue Prozessentwicklungen und Prozess-Integrationen Portal basierende Executive Informations ysteme Agile Unternehmen benötigen höchst flexible IT-trukturen IT Prozesse müssen schnell neuen Geschäftsprozessen folgen können eite 3

4 Anforderungen und Probleme heutiger IT trukturen Probleme Notwendige Anwendungsänderungen können nur sehr schwer und zu langsam durchgeführt werden Entwicklung und Deployment neuer Anwendungen und Prozesse ist zu kompliziert Erstellen und Ändern von portal-basierten EI ist zu kompliziert und langsam Anwendungs- und Prozessintegration innerhalb und zwischen Unternehmen ist sehr kompliziert Unterschiedliche Laufzeit-Umgebungen Unterschiedliche Prozess-Umgebungen Prozesse bestehen aus Anwendungen und Human Activities Keine oder schlechte gemeinschaftliche icht der Problem und deren Lösungen zwischen betriebswirtschaftlichen und IT Abteilungen und Management eite 4

5 Point to Point Application Integration 8 application miteinander verbunden ergeben 56 Verbindungen Application 1 Application 2 Application 3 Application 4 Application 5 Application 6 Applikation 7 Application 8 In General : n applications connected to each other require n*(n-1) connections 10 applications require 90 connections 50 applications require 2450 connections 100 applications require 9900 connections eite 5

6 Anforderungen und Probleme heutiger IT trukturen Probleme Portal Infrastructure acting as an aggregation point for multiple data sources Portal Browser Portal Browser Internet/ Intranet Portal erver Portal martclient Application erver Backoffice App. Backoffice App. Backoffice App. Packaged App. The Portal erver C# App. Java App. Accepts web requests from a web Browser provides the presentation logic for the users of the portal acts as the interface to a variety of back end systems from which the data is extractred, aggregated, provides the sequencing of data extractions eite 6

7 Anforderungen und Probleme heutiger IT trukturen Beispiele Integration dreier Anwendungen Prozess-Beschreibung Eine Genehmigung ist notwendig, wenn der Betrag größer als 1000 ist Wenn der Betrag kleiner oder gleich 1000 ist, ist keine Genehmigung notwendig und das Bestellsystem wird direkt aufgerufen Businesslogik Bestellantrag (x>1000) (x<=1000) Genehmigung (y=ok) Ablauflogik Datentransformationslogik Bestellung eite 7

8 Prozess mit drei integrierten Anwendungen Bestellantrag (x>1000) (x<=1000) Genehmigung (y=ok) Bestellung In jeder Anwendung ist kodiert: die Businneslogik der Anwendung die Prozess (Ablauf-) logik der Datentransformationscode alle Anwendungen (Komponenten) sind fest gekoppelt jede Anwendung weiß, welche Anwendung aufgerufen werden muss (abhängig der Variablenwerte) jede Anwendung kennt den Datentyp derjenigen Anwendung, die sie aufruft Geschäftsregeln sind innerhalb der Anwendungen kodiert Der Prozessfluss ist über alle Anwendungen hinweg verteilt eite 8

9 Das Problem - Ändern eines ystems! Budget Checker Einfügen einer neuen Anwendung in den Prozess Ändern der Genehmigungsanwendung Viele Bestellanträge Bestellantrag Bestellantrag 2 (x>2000) (x>1000) Genehmigung (y=ok) Umwandlung der Anwendung Genehmigung in eine Human Activity (x<=2000) (x<=1000) Bestellung Bestellung 1 Viele Bestellsysteme Änderung der Regeln X Wiederverwendung der Anwendung Y eite 9

10 Warum existieren Probleme bei der Änderung eines bestehenden ystems? Die drei ünden eine Anwendung macht einen Funktionsaufruf zu einer anderen Anwendung über Parameter Datentransformationen sind innerhalb der aufrufenden Anwendungen kodiert Prozesslogik ist innerhalb der Anwendungen kodiert Anwendungen kennen die Details von anderen Anwendungen - sie machen Annahmen - sie sind fest gekoppelt - ihre Granularität ist zu hoch Anwendungen wissen, wann sie andere Anwendungen aufrufen (fest kodiertes Prozessverhalten) Der Horror vor Änderungen eite 10

11 Problem Nr. 1 Ändern der Prozess-Regeln Alte Prozess - Beschreibung Eine Genehmigung ist notwendig, wenn der Betrag größer als 1000 ist Wenn der Betrag kleiner oder gleich 1000 ist, ist keine Genehmigung notwendig und das Bestellsystem wird direkt aufgerufen Bestellantrag (x>1000) Genehmigung (y=ok) (x<=1000) Neue Prozess - Beschreibung Bestellung Eine Genehmigung ist notwendig, wenn der Betrag größer ist als 500 AND Location = UA Wenn der Betrag kleiner oder gleich 500 AND Location <> UA ist, ist keine Genehmigung notwendig und das Bestellsystem wird direkt aufgerufen Bestellantrag (x>500 AND Loc.= UA) Genehmigung (y=ok) Anwendung Bestellantrag muss geändert werden (x<=500 AND Loc.<> UA) Bestellung eite 11

12 Problem Nr. 2 Einfügen einer neuen BA-Anwendung Bestellantrag (x>1000) Genehmigung Neuer BA (x>1000) Genehmigung (y=ok) (y=ok) (x<=1000) (x<=1000) Bestellung Bestellung Anwendungsablauf muss geändert werden Alle Translator müssen geändert werden eite 12

13 Problem Nr. 3 Einfügen eines anderen BA-ystems BA 1 (x<=1000) (x>1000) Bestellantrag (x>1000) Genehmigung (y=ok) (x<=1000) Bestellung Anwendungsablauf muss geändert werden Alle Translator müssen geändert werden eite 13

14 Problem Nr. 4 Einfügen von zwei neuen Bestellsystemen Prozess - Beschreibung Eine Genehmigung ist notwendig, wenn der Betrag größer als 1000 ist Aufruf Bestellsystem 1: - Genehmigung ok und Betrag ist kleiner oder gleich keine Genehmigung notwendig und Betrag ist größer 500 Aufruf Bestellsystem 2: - Genehmigung ok und Betrag ist größer 1200 Bestellantrag Keine Genehmigung ist notwendig, wenn der Betrag kleiner oder gleich 1000 ist Aufruf Bestellsystem 1: - Betrag ist größer 500 Aufruf existierendes Bestellsystem: - Betrag ist kleiner oder gleich 500 (x>1000) Genehmigung (y=ok) (x<=1000) (x<= 500) Bestellantrag (x>500) (x>1000) Genehmigung (y=ok) (x<= 1200) (x> 1200) (x<=1000) Bestellung Bestellung Bestellung 1 Bestellung 2 Almost everything must be changed The way to the accitential architecture eite 14

15 Problem Nr. 5 Einfügen einer neuen Anwendung Neue Prozess - Regeln Ein Budget Checker ist notwendig, wenn der Betrag größer als 1000 ist Wenn der Budget core größer als 5 ist, wird das Bestellsystem aufgerufen, ansonsten ist eine Genehmigung erforderlich Wenn der Betrag kleiner oder gleich 1000 ist, ist keine Genehmigung notwendig und das Bestellsystem wird direkt aufgerufen Bestellantrag (x>1000) (x<=1000) Genehmigung (y=ok) Bestellantrag (x>1000) Budget Checker Genehmigung (B<=5) (y=ok) (B>5) Bestellung (x<=1000) Bestellung Die Ablauflogik muss geändert werden (nicht zur Genehmigung aber zum Budget Checker) Adapter müssen geändert werden Almost everything must be changed The way to the accitential architecture eite 15

16 Problem Nr. 6 Ersetzen einer Anwendung durch eine Human Activity Bestellantrag Ändern zu einer Human Activity Genehmigung (x>1000) Anwender-Rollen werden dynamisch zur Laufzeit generiert Beispiel: (x<=1000) (y=ok) Bestellung Der Manager (Rolle) soll das Dokument derjenigen Person genehmigen, die innerhalb seiner Abteilung arbeitet. Eine komplexe Änderung Anwender=Manager(Org-Einheit(Anforderer)) fordert eine rollenbasierte Organisationsstruktur an eite 16

17 Problem Nr. 7 Wiederverwendung von Anwendungen in unterschiedlichen Prozessen X Wird in zwei Prozessen genutzt Prozess 2 Bestellantrag (x>1000) Genehmigung (z=?) Y (y=ok) (x<=1000) Bestellung Prozess 1 Komplexe Änderungen innerhalb der Antragsanwendung eite 17

18 Problem Nr. 8 Verknüpfen von Prozess-Instanzen Welche Rechnung gehört zu welcher Prozess - Instanz? Prozess-Instanz 1 BA (x>1000) Genehmigung Rechnung (y=ok) (x<=1000) Bestellung Prozess-Instanz 2 Komplexe Änderungen innerhalb der Anwendung Bestellantrag eite 18

19 Zusammenfassung der Gründe für die Probleme heutiger IT Landschaften stark gekoppelte Objekte, Komponenten, Anwendunge und Prozesse es werden Annahmen gemacht hinsichtlich Daten-Typen und Daten-Formaten von Objekten, Komponenten, Anwendungen und Prozessen Orientierung auf Funktionen anstatt auf Prozesse Prozessverhalten (Ablauflogik) ist innerhalb der Objekte, Komponenten, Anwendungen und Prozesse kodiert keine tandards eite 19

20 Der Hauptgrund der Probleme heutiger IT Landschaften Die eigentliche Ursache heutiger IT-Probleme ist die feste Kopplung zwischen Objekten, Komponenten, Anwendungen und Prozessen! Frage Wie verbindet man zwei oder mehr Anwendungen durch eine lose Kopplung? Antwort: In dem man sie nicht verbindet! eite 20

21 Point to Point Application Integration 8 application mit einander verbunden ergeben 56 Verbindungen Application 1 Application 2 Application 3 Application 4 Application 5 Application 6 Applikation 7 Application 8 In General : n applications connected to each other require n*(n-1) connections 10 applications require 90 connections 50 applications require 2450 connections 100 applications require 9900 connections eite 21

22 ervice Orientiertes Computing (OC) als Lösungsansatz ervices A service is an autonomous unit of application logic whose interface is defined by the messages it will accept and send ervice (Client) ervice (erver/client) ervice erver A service has Endpoints and ervice Descriptions eite 22

23 ervice Orientiertes Computing (OC) ervices are coarse grainded ervices are connected trough a Message Oriented Infrastructure ervices share schemas and contracts, not classes and types ervice are loosely coupled ervices The ABC of ervices Address Binding - Contract ervice Endpoint Address Binding ervice Contract ervice Implementation ervice Description Beschreibung Policy (ecurity Protocol, Qo) eite 23

24 ervice Orientiertes Computing (OC) als Lösungsansatz Lösung lose gekoppelte Dienste! anstelle stark gekoppelter Objekte, Komponenten und Anwendungen grobe Granularität Feiner Granularität Prozess-Orientierung Funktions-Orientierung Ablauflogik aus der Businesslogik herausnehmen sie in der Businesslogik zu implementieren standardisierte Dokumentstrukturen nicht-standardisierte Dokumententypen Konfiguration Programmierung eite 24

25 ervice Orientiertes Computing (OC) als Lösungsansatz ervices kommunizieren miteinander durch Austausch von Messages ervice Adresse Bestellantrag (x>1000) Genehmigung Message (x<=1000) (y=ok) ervice Code Ablauflogik Bestellung Problem: Prozesslogik ist innerhalb der ervices kodiert eite 25

26 ervice Orientierte Architekturen (OA) ein Framework zur Unterstützung von OC Was ist eine ervice Oriented Architektur (OA)? Komponenten einer OA Notwendige tandards und Technologien einer OA Vorteile einer OA eite 26

27 Der Weg zur ervice Orientierten Architektur (OA) chritt 1 Problem: Prozesslogik ist innerhalb der ervices kodiert Lösung: ervices werden von außerhalb orchestriert! Bestellantra g(x>1000) Genehmigun g Bestellantrag D1 BA Prozess (x<=1000) (y=ok) Genehmigung D1 D2 GN D1(x>1000) D1(x<=1000) Bestellung Bestellung D1 B D2(y=ok) Physische Adressen Transformatoren Problem: ervices sind nicht lose gekoppelt eite 27

28 Der Weg zur ervice Orientierten Architektur (OA) chritt 2 Lösung: Orchestrierung von Web ervices über logische Endpunkte mit Adressen-Mapping und Daten-Transformatoren Output Dokument von X = OD(X) Input Dokument von X = ID(X) Bestellantrag D1 D1 BA Prozess OD(BA)=D1 D1 ID(GN)=D2 OD(GN)=D3 Genehmigung D2 D3 D1 D3 GN D1(x>1000) ID(B)=D4 D1(x<=1000) Bestellung D4 D1 B D3(y=ok) Adressen- Mapping Logische Endpunkte Mapping der logischen Endpunkte zu physischen Adressen ervices eite 28

29 Der Weg zur ervice Orientierten Architektur (OA) chritt 3 EB und ervice Flow Engine arbeiten im Tandem Messaging, Mapping, Address Translation, Content based Routing Output Dokument von X = OD(X) mit einem Enterprise ervice Bus ervice Orchestrierung mit einer ervice Flow Engine Input Dokument von X = ID(X) OD(BA)=D1 ID(GN)=D2 OD(GN)=D3 ID(B) =D4 Publisher D1 BA D1 Enterprise ervice Bus ervice Flow Engine orchestrates the flow of Web ervices D3 ervice Flow Engine BA GN Prozess Modell D1(x>1000) D2 D3 D4 D1(x<=1000) ubscription Rule x(d1)>1000) Genehmigung Process Rulse (x(d1)<=1000) v (y(d3)=ok) Bestellung ubscription Rule B D3(y=ok) Publisher & ubscriber ubscriber XML Dokument und Content Based Routing Festgelegte Bedingungen definieren das Prozessmodell eite 29

30 Problem Die Bedingungen verwenden externe ervice Dokumente und Variablen Output Dokument von X = OD(X) Input Dokument von X = ID(X) OD(BA)=D1 ID(GN)=D2 OD(GN)=D3 ID(B) =D4 Publisher D1 BA D1 Enterprise ervice Bus D3 ervice Flow Engine BA GN Prozess Modell D1(x>1000) D2 D3 D4 D1(x<=1000) ubscription Rule x(d1)>1000) Genehmigung Process Rulse (x(d1)<=1000) v (y(d3)=ok) Bestellung ubscription Rule B D3(y=ok) Publisher & ubscriber ubscriber XML Dokument und Content Based Routing Festgelegte Bedingungen definieren das Prozessmodell eite 30

31 Der Weg zur ervice Orientierten Architektur (OA) chritt 4 Lösung: Einführen von kanonischen Dokumenten und Adaptern Publisher Kanonische Dokumente BA D1 Translator BA Prozess Modell K1 Enterprise ervice Bus K2 ervice Flow Engine GN X(K1)>1000 ID(GN) OD(GN) ID(B) X(K1)<=1000) x(k1)>1000) (x(k1)<=1000) v (y(k2)=ok) Y(K2)=ok) Genehmigung ID(X): Input Dokument OD(X): Output Dokument Bestellung B Publisher & ubscriber ubscriber Das interne ystem (EB und FE) arbeitet immer mit denselben (kanonischen) Dokumenten Werden externe Dokumente geändert, müssen Transformer (XML Dokument-Mapper) konfiguriert werden. Keine Änderung der festgelegten Bedingungen, daher ist keine neue Prozess-Entwicklung notwendig! eite 31

32 Der Weg zur ervice Orientierten Architektur (OA) Problem: Anstatt x, y, und x(k1), sollte man Variablen und Regeln verwenden in Abstimmung mit dem von Business Analysten verwendeten Vokabular. Publisher Kanonische Dokumente BA D1 Translator BA Prozess Modell K1 Enterprise ervice Bus K2 ervice Flow Engine GN X(K1)>1000 ID(GN) OD(GN) ID(B) X(K1)<=1000) x(k1)>1000) (x(k1)<=1000) v (y(k2)=ok) Y(K2)=ok) Genehmigung ID(X): Input Dokument OD(X): Output Dokument Bestellung B Publisher & ubscriber ubscriber eite 32

33 Der Weg zur ervice Orientierten Architektur (OA) chritt 5 Lösung: Einführung von Vokabular und Enterprise Regeln Publisher BA BA Prozess Modell Kanonische Dokumente D1 Translator K1 Enterprise ervice Bus K2 ervice Flow Engine GN GN-Anfrage ID (GN) OD(GN) ID(B) Bestellung GN-Anfrage NO GN-Anfrage v Genehmigung Genehmigung Genehmigung Bestellung B Publisher & ubscriber ubscriber Vokabular: Betrag, genehmigt Regeln: Prüfung: If Betrag>1000; Bestellung: If Betrag<=1000; Genehmigung: If genehmigt=ok eite 33

34 Point to Point Connecting Application using Cononical Documents and EB with Process equencing A2 A5 A7 A1 A4 top A3 A6 A8 Application 1 OV1 Application 2 Application 3 Application 4 OV2 OV3 OV4 IV1 IV1 IV2 IV3 CD1 CD2 CD3 CD4 CD5 CD7 IV4 IV5 OV5 OV7 Application 5 Application 6 Application 7 Applikation 8 FE Process BPEL Description eite 34

35 The Need for a New Computing Paradigm Today s IT Requirements and Problems Connections between Different ystems eite 35

36 The Need for a New Computing Paradigm Today s IT Requirements and Problems ervice VFBK Y ID Beschr. IT Architektur FC Nr. Y Name Appl.ID 1 2 Fin.yst.Nr. MAN. IT FIN RT Budget Heutige IT Probleme Information Integration IT ysteme haben für fachlich gleiche Informationselemente unterschiedliche Namen und Formate. Turm von Babel Problem: IT ysteme müssen wissen, welchen ystemen sie welche Informationen in welchen Formaten senden müssen. Heutige Lösung: IT ysteme sind miteinander hart verdrahtet und Informationselemente werden innerhalb der IT ysteme übersetzt. Problem: Höchst unflexibel bei Änderungen Betrag Zweck FB Y Nr. Anw. Name Anw. Nr. 3 LM 4 Wartungszeit Verfügbarkeit Application Integration IT ysteme innerhalb integrierter Anwendungen werden entsprechend vorgegebener Abläufe ausgeführt - sie folgen einem Prozess. Heutige Lösung: Die Prozessabläufe sind innerhalb der IT ysteme kodiert. Problem: Höchst unflexible Prozessimplementationen. Prozessänderungen äußerst aufwendig eite 36

37 The Need for a New Computing Paradigm Today s IT Requirements and Problems Example Purchase Requisition Business Process Adding an Application to an Existing Business Process Causes of Today s IT Problems Even after the introduction of Object Oriented, Client erver, and Enterprise Application Integration (EAI) technologies, IT remains in a state of crisis. The IT is the measuring stick as to how quickly an enterprise can adapt to changing business processes and addition of new business processes. The current problems are, as seen in the simple example, relatively simple to diagnose: Tight Coupling of Applications The coupling between applications to a large degree determines which other applications an application must interact with and what other applications it can communicate with. The simple example shows that applications are handicapped when such tight coupling exists. Each application must know the data type and format of the applications it wishes to call and the appropriate data transformation. Process Logic Coded into the Applications Each application knows which application it must call according to the business rules coded into the application. Insufficient tandards The communication between applications, such as the data format, data type, and data transformation is not standardized in most cases. Reuse of Applications in Different Processes eite 37

38 ervice A service is a software building block that defines one or more functions which can be invoked by the consumer of the service. A service is a unit of work provided by a service provider that is called and utilized by a service consumer in order to achieve a desired end result. ervices are autonomous in that, from a consumer's point of view, the service contains only atomic defined functions that can be called. In other words, from the view of a service consumer, the service has no flow of functions it simply is being called, performs its functions, and then returns a response to the consumer. When a service is called, it expects a message (document) conforming to a universal message format (XML XML) and conforming to the service's defined document input structure (Input chema). In order for consumers to call the service, they must "know" the service's input document schema. Therefore, all services expose a public standardized XML document (using the Web ervice Definition Language, or WDL) that consumers can consult in order to call the service with the appropriate input document. A service's WDL document provides a well-defined service interface that is made public so that potential consumers of the service know how to communicate with the service. The service also provides a result message in a universal data format and the message adheres to a defined document structure (Output chema). The service's public WDL document also informs consumers of the service about what to expect as a result from the service (its output document schema). ervices communicate via standardized messages exchanging XML document messages conforming to published interface document schema descriptions (described in their WDL documents). ervices are coarse-grained in that they communicate with each other on a higher document level rather then on low level parameter passing as done in an object oriented environment. ervices are implemented as Web ervices, which are software components that have one or more functions implemented as Web Methods. By specifying the web address of a Web ervice and the name of the web method, a service that is implemented through a web service can be called. ervices can be composed of other services by providing an aggregate service utilizing the services of its composite services. The composed service appears to a client service as an autonomous service providing its service interface. When a composed service is requested to perform a service, a sequence of service requests to the composite services is normally executed, but totally transparent to the requesting service. Because all services utilized within a composed service are autonomous, they do not contain any flow information-their service is requested, they perform their service and might return their output document. Therefore composite services must be orchestrated by some software governing the service request sequencing. Composite ervices are made for change. To support changes services must be loosely coupled, that is services should not make service requests to service providers directly ( by calling a service using the service providers service address). Therefore a framework is needed, to design and implement flexible composite services. Therefore at least two main components are needed to implement a OA platform-where a Enterprise ervice Bus works in tandem with the ervice Orchestration Engine as shown below: eite 38

39 That s where ervice Oriented Architecture is coming in. The support of a standardized communication platform with loosely coupled services communicating via standard messages (XML, OAP, Policies, ecurity, and more). As prerequisites, a OA Messaging and Data Transformation must be completely taken out of the applications (Web ervices) and moved instead to a software component known as the Enterprise ervice Bus (EB EB). Also, Process Logic must be completely taken out of the web services and moved instead in the ervice Orchestration Engine (OE). Components of an OA In an ervice Oriented Architecture autonomous, loosely-coupled and coarse-grained services with well-defined interfaces provide business functionality and can be discovered and accessed through a supportive infrastructure. This allows internal and external system integration as well as the flexible reuse of application logic through the composition and orchestration of services. eite 39

40 Information Integration mit Glossar (Kanonischen) Elementen Glossar ystem ID IT Architektur Man. IT FIN ystem Name Account Nr. Amount Y ID ervice VFBK RT Fin.yst.Nr. Description Reliabiliy Y Name FC Nr. Appl.ID Budget Maintenance Time Beschr. ystem ID ystem Name Reliability Account Nr. Description Maintenance Time ystem ID Canonical Account Nr. Account Glossar Variable ystem ID ystem Name Account Nr. ITAR Y ID Y Name FC Nr. MFIN Appl. ID Fin.yst.Nr. FB Y Nr. LM Anw. Nr. Anw. Name XML Document Amount Budget Betrag Description Beschr. Zweck Description Account ystem ID ystem ID ystem Name Maintenance Time Reliability Reliabiliy Maintenance Time ervice VFBK RT Verfügbarkeit Wartungszeit Zweck Betrag Anw. Nr. Wartungszeit Y Nr. Anw. Name Verfügbarkeit FB LM eite 40

41 IT Architektur sendet Informationen der IIB verteilt die Informationen Vname Y ID Wert 5 Vname Wert Y Name ABC Fin.yst.Nr. ervice VFBK Budget IT Architektur FC Nr.. Beschr. Man. IT FIN RT Appl.ID 5 Y ID ervice VFBK RT Fin.yst.Nr. Y Name FC Nr. Appl.ID Budget Beschr. ystem ID ystem Name Reliability Account Nr. Description Maintenance Time ystem ID Canonical Account Nr. Account Glossar Variable ystem ID ystem Name Account Nr. ITAR Y ID Y Name FC Nr. MFIN Appl. ID Fin.yst.Nr. FB Y Nr. LM Anw. Nr. Anw. Name XML Document Amount Budget Betrag Description Beschr. Zweck Description Account ystem ID ystem ID ystem Name Maintenance Time Reliability Reliabiliy Maintenance Time ervice VFBK RT Verfügbarkeit Wartungszeit Vname Zweck Betrag Y Nr. Wert 5 Zweck FB Betrag Y Nr. Anw. Nr. Anw. Name Wartungszeit Verfügbarkeit LM Vname Verfügbarkeit Wartungszeit Anw.Name Anw.Nr. Wert ABC 5 eite 41

42 Point to Point Application Integration 8 application miteinander verbunden ergeben 56 Verbindungen Application 1 Application 2 Application 3 Application 4 Application 5 Application 6 Applikation 7 Application 8 In General : n applications connected to each other require n*(n-1) connections 10 applications require 90 connections 50 applications require 2450 connections 100 applications require 9900 connections eite 42

43 Point to Point Connecting Application using Cononical Documents and EB (without Process equencing) 8 application connected with 16 connections Application 1 Application 2 Application 3 Application 4 Document Mapping CD1 CD2 CD3 CD4 CD5 CD6 CD7 CD8 CD9 CD10 CD11 CD12 CD13 CD14 CD15 CD16 Application 5 Application 6 Application 7 Applikation 8 In General : n applications connected to each other require 2n connections 10 application 20 connections (Compared to 90) 10% 50 application 100 connections (Compared to 2450) 4% 100 application 200 connections (Compared to 9900) 2% eite 43

44 Das Problem - Ändern eines ystems! Budget Checker Einfügen einer neuen Anwendung in den Prozess Ändern der Genehmigungsanwendung Viele Bestellanträge Bestellantrag Bestellantrag 2 (x>2000) (x>1000) Genehmigung (y=ok) Umwandlung der Anwendung Genehmigung in eine Human Activity (x<=2000) (x<=1000) Bestellung Bestellung 1 Viele Bestellsysteme Änderung der Regeln X Wiederverwendung der Anwendung Y eite 44

45 Lösung Einfügen eines neuen ervices (Budget Checker) Bestellantrag Budegt Checker Einfügen eines neuen ervices (z.b. Budget Checker) OD(BA) ID(BC) OD(BC) K1 Enterprise ervice Bus K2 ID(GN) GN-Anfrage OD(GN) ID(B) NO GN-Anfrage v Bestellung Genehmigung Bestellung Der Budget Checker beinhaltet eine Input/Output ervice WDL und verlangt sein Input Dokument-ID(BC) und er liefert sein Output Dokument- OD(BC) Adapter werden benötigt kein kodieren! eite 45

46 Lösung Viele Bestellanträge neuen Daten - Adapter neuen BA Publisher BA BA Mapping BA 1 OD(BA) OD(BA1) OD(BA2) K1 Enterprise ervice Bus K2 K1 Enterprise ervice Bus K2 ID(GN) Prüfung OD(GN) ID(B) Nicht Prüfung v Genehmigt ID(GN) Prüfung OD(GN) ID(B) Genehmigung Bestellung Genehmigung Bestellung Lösung: Nur einen neuen BA Publisher zum ervice Bus hinzufügen und einen neuen Daten - Adapter konfigurieren (das Mapping erfolgt in das gleiche kanonische Dokument K1)- kein kodieren! eite 46

47 cheinlösung Viele Bestellsysteme Kanonische Form BA Adapter BA Prozess OD(BA) K1 IA(GN) OA(GN) OA(BA) Enterprise ervice Bus IA(B1) K2 IA(B2) ervice Flow Engine GN K1(GN-Anfrage) GN- Anfrage ID(GN) OD(GN) ID(B1) NO GN-Anfrage v Bestellung ID(B2) K1(Bestellung) AND Betrag>500 K1 (Bestellung) Genehmigung Bestellung 1 Bestellung 2 B1 B2 Genehmigt AND K1(Betrag<=500) festgelegte Regeln müssen geändert werden? Prozess muss geändert werden (Einführen von neuen logischen Endpunkten) eite 47

48 Lösung Viele Bestellsysteme BA Anwender Regeln X(D1)<=500 V Bestell. V Bestell.1 BV K1 BA ervice Flow Engine else BV Participant Evaluator Document Dispatcher GN D1(x>1000) D1(x<=1000) Doc. Repository Y(D3)=ok) K2 B ID(B1) NO GN-Anfrage v Bestellung ID(B2) GN-Anfrage ID(GN) OD(GN) Bestell. 1 Bestell. 2 GN Definieren der Prozesslogik festgelegte Regeln Definiere eine Anwender-Regel und bekomme einen Translator für Bestellung 2 Das ist alles keine weiteren Änderungen eite 48

49 Prozess XY Wiederverwendung X Bestellantrag (x>1000) Genehmigung Y (y=ok) (x<=1000) Bestellung BA Prozess 1 Modell Prozess 1 GN X(K1)>1000 X Prozess XY OD(X) Prozess 1 BA OD(BA) B Y(K2)= ok) X(K1)<=100 0) KX K1 Enterprise ervice Bus K2 ervice Flow Engine ID(GN) Prüfung OD(GN) ID(B) ID(Y) X Prozess 2 Modell GN Genehmigung Bestellung Y B eite 49

50 Orchestrieren von ervices mit Human Workflows ehr schwierig! Anwender-Rollen werden dynamisch zur Laufzeit generiert BA Beispiel: Der Manager (Rolle) soll das Dokument derjenigen Person genehmigen, die innerhalb seiner Abteilung arbeitet. ID(GN) GN-Anfrage K1 OD(BA) Enterprise ervice Bus K2 OD(GN) ID(B) NO GN-Anfrage v Bestellung Genehmigung Bestellung Anwender=Manager(OU(Anforderer) eite 50

51 Konventionelle Portal Infrastruktur Portal Browser Portal Browser Portal martclient Internet/ Intranet Portal erver Packaged App. C# App. Java App. Application erver Backoffice Backoffice Backoffice App. App. App. Portal Browser Portal Browser Portal martclient Internet/ Intranet OA basierte Portal Infrastruktur Portal erver Aggragated XML Format Enterprise ervice Bus ervice Flow Engine Prozess Modell Pack. App. C# App. Java App. Application erver Backoffice Backoffice Backoffice App. App. App. eite 51

52 ervice Orientierte Architektur (OA) Technologien und tandards OA ist ein Framework und ein et von Tools, welches die Ausführung und Entwicklung eines ystems mit unterschiedlichen Anwendungen ermöglicht, das den Prinzipien des ervice Orientierten Computing folgt. Es beinhaltet insbesondere ein Framework für: lose gekoppelte ervices ervice Orchestrierung mit einer tandard Prozess-Beschreibung (BPEL) ervice Messaging mit standardisierten Dokumentstrukturen (XML, WDL,OAP, XLT) sichere und zuverlässige Datenübertragung (W Policies, W Rel. Mess., W Addressing ) synchrone und asynchrone Datenübertragung Atomare und Long Running Transaktionen (W transaction standards) eite 52

53 Vom Objekt Orientierten zum ervice Orientierten Computing ervice-orientiertes Computing vereint in sich die Erfahrungen der letzten 20 Jahre von - Objekt-orientierter Programmierung - Komponenten - Distributed Computing und basiert auf entscheidenden Technologien und tandards - Web ervices - tandards (XML, OAP, UDDI, XLT, XQuery) - Content Based Routing - MOM - W*: W Policy, W ecurity, W Adressing, Reliable Messaging, W Notification, W Transactions, W Coordination, W Business Ativities, - Andere eite 53

54 Andere Probleme und Anforderungen Anforderungen tandard ervice Orchestrierung Business Partner Rollen Atomare Transaktionen Long Running Transaktionen icherheit & Reliable Messaging ynchr./asynchr. Kommunikation MOM Integration (MMQ/MQeries) Human Workflow Integration o Org Facility o Ad Hoc Activities o Dynamic Role based Routing ervice Orientierte Anwendung & Prozess-Integration Verwendung vorhandener ysteme Lösungen BPEL komplementäre ervice Flow Engine (FE) ervice Rollen W Transaktionen Compension/W Business Activities W ecurity/w Policy/W Reliable Messaging TCP/JM-MDB upport Kommunikations-Adapter Integrierte Workflow Engine o Org Unit/Roles/People o Jump/Deligate/Insert o Role coping Hetoregene ystem Wrap (Legacy) Applications eite 54

55 Notwendige Technologies and tandards einer OA XML Web ervices ervice Oriented Architecture Business Process Management eite 55

56 Extensible Markup Language (XML) An instance of an XML document can be seen below in a Purchase Request XML document: eite 56

57 Relationship Between XML pecifications Describes XML Documents earches Transforms XD XPath XLT Uses Uses eite 57

58 XML chema Definition Language (XD) Purchase Request XML document as an instance of the xml schema (right) XML schema (XD) for the Purchase Request XML document (left eite 58

59 XML Path Language (XPath) XPath: To search for Elements xmldoc.selectnodes("/product/name") XLT: To transform XML Documents XML Input Dokument XML Output Dokument XLT CODE XML Input chema XML Output chema eite 59

60 Web ervices A Web service is an autonomous unit of application logic whose interface is defined by the messages it will accept and send ervice (Client) ervice (erver/client) ervice erver eite 60

61 Web ervices ervices are coarse grainded ervices are connected trough a Message Oriented Infrastructure ervices share schemas and contracts, not classes and types ervice are loosely coupled Address Binding - Contract ervice Class/Object Model Endpoint Address Binding ervice Contract ervice Implementation ervice Description TCP, X.509 ecurity Interface, Operations of a ervice WDL W Policy ecurity Protocol, Qo, eite 61

62 ervice Hirarchy Complex application composed from Enterprise ervice Composite Applications Web service for business abstraction, crossapplication Enterprise ervice Web service that provides services from applications Application ervice Web-enabled function Web ervice Function ervice eite 62

63 Web ervices Invocation of Web ervices through XML Messaging A Message is is a (XML) document Envelope OAP Transport HTTP, TCP, FTP, ,... ynchronous Messaging: Message Client expects immediate responseconnection stays open Asynchronous Messaging: Message Client expects no immediate response- connection is closed eite 63

64 Web ervice tandards uses BPEL4W Provides for long running transactions provides protocols fororchestrates processes Business Activities uses W- Transaction describes the process W Choreography W- ecurity orchestrates enables distributed transactions for provides end-to-end security for uses UDDI enables discovery of WDL describes Web ervices governs W- Policy is accessed using binds to enables communication between improves reliability of provides transitive messaging uses OAP provides gauranteed delivery for W-Reliable Messaging uses uses uses W Addressing eite 64

65 OAP und UDDI OAP UDDI OAP Envelope Header finds Publishes WDL Client ends Message erver Payload OAP eite 65

66 BPEL4W - Business Process Execution Language (BPEL) für Web ervices Bestellantrag (x>1000) (x<=1000) Genehmigung (y=ok) Bestellung tandard-upport von großen Herstellern beschreibt im XML Format: - den Ablauf der Anwendungen - Typen von verteilten Daten - wie Partner eingebunden werden - Handhabung von Fehlern - Beziehungen - Handhabung von Ereignissen partnerlinks definieren involvierte Partner sequence, switch - Prozessfluss invoke ervice Aufruf Weitere prachelemente: reply while pick wait empty throw terminate compensate eite 66

67 Human Activities BPEL does not provide any concepts of Human activities, Org. Units, Participants(Users) or Rules. Implementation as Web ervices without Roles Implementation as W with execution controlled by an integrated workflow engine eite 67

68 Komponenten und Tools einer einer OA BPEL Designer Process imulator Process Translator ervice Dev. Environment ervie Life Cycle Mgmt. ervice Orchestration Engine Portal Human Workflow Engine Messaging Framework Run Time Environment/ervice Repository Operating ystem Rule Engine Org Designer Bus. Rule Editor Bus. Process Editor Message Mapper Endpoint Configurator Deployment Tool BAM Tool eite 68

69 Tools und Methoden OA basierter Anwendungsentwicklung Tool Task Team Member Business Rule Editor Define Vocabulary Define Business Rules Business Analyst Business Process Designer Define Business Process Business Analyst Define chemas Business ervice Bus Editor Define Canonical Doc. OA Architect Create Mappings W Dev. Tool V 2005/Eclipse ecurity/end Point Cofiguration Tool Test/Deployment Tool Build/Include Web erv. Config. ecurity/eps Test/Deploy Process oftware Engineer Enterprise Architect Test/Deployment Engineer eite 69

70 Vorteile einer OA Bessere Integration Reuse Flexible Entwicklung von composite ervices Einbindung von Legacy ystemen durch Wrapping tandardisierte Daten Representation Prozess Orientiert tandardisierte Business Prozess Representation Basis für Enterprise weites Business Prozess Management Fokusiertes Investment an enterpriseweite IT Kommunikations trukturen chaffung agiler Unternehmen Transformation der IT vom Kostenfaktor zum strategischen Asset Zusammenrücken der Fach- und IT Bereiche eite 70

71 Wrap bestehende Anwendungen als Web ervices ervice Class/Object Model Endpoint Address Binding ervice Contract ervice Implementation TCP, X.509 ecurity ervice Description WDL W Policy ervice Class/Object Model Endpoint Address Binding ervice Contract ervice Implementation Adapter (Legacy) Application TCP, X.509 ecurity ervice Description WDL W Policy eite 71

72 Zusammenrücken der Fach- und IT Bereiche Betriebswirtschaftliches ystem eite 72

73 Beispiel eines Vertriebs-Informations-ystems Vertriebs Informations ystem Produktionsplanung Auftragsbearbeitung CRM BWD Kunde Artikel Preis Rechnung Besteluung BWF Kreditwürdigkeit prüfen Lieferbarkeit prüfen Versand durchführen Fakturierung durchführen eite 73

74 Verschiedene ichten Fachbereichs icht BWD BWF eite 74