Migration zu einer serviceorientierten Architektur mit den Oracle BPEL Process Manager

Transkript

1 Migration zu einer serviceorientierten Architektur mit den Oracle BPEL Process Manager DOAG Konferenz 2006 Stefan Kühnlein SerCon GmbH München

2 Agenda Motivation für eine serviceorientierte Architektur Voraussetzung für eine serviceorientierte Architektur Web-Services die Grundlage für eine serviceorientierte Architektur Lösung der Integrationsprobleme mit SOA Integrationsanforderungen Oracle BPEL Process Manager Oracle Integration Vorteile eine serviceorientierten Architektur

3 Die bisher entwickelten Architekturen haben die Probleme der IT-Abteilungen nicht gelöst Die IT-Systeme der Unternehmen sind in den vergangenen Jahrzehnten exponentiell gestiegen. Mit der Größe der IT-Systeme ist auch die Komplexität der Architekturen gestiegen und werden somit immer schwieriger zu handhaben. Die Aufgabe der IT-Abteilungen besteht darin: - sehr schnell auf neue Geschäftsmodelle zu reagieren. - neue Kunden und Geschäftspartner müssen sehr schnell integriert werden. - die IT-Kosten kontinuierlich zu senken. Viele verschiedene Architekturen wurden in der Vergangenheit entwickelt, um eine Lösung für die Integrationsprobleme der Unternehmen zu lösen. Eine umfassende Komplettlösung konnte jedoch nicht bereitgestellt werden!

4 Unternehmen benötigen eine serviceorientierte Architektur Durch die zahlreichen und verschiedenen Objektmodelle auch vom CORBA-Standard abweichende traten immer wieder neue Integrationsprobleme auf. Viele Systemarchitekten beschäftigten sich hauptsächlich mit der Lösung der technischen Probleme. Die Suche nach einer besseren Lösung wird getrieben durch - Senkung der Kosten. - Verkürzung der Zykluszeiten. - Integration von B2B und B2C Systemen. Punkt-zu-Punkt Lösungen beseitigen nicht die grundlegenden Probleme einer konsistenten Architektur mit der in kurzer Zeit neue Anwendungen erstellt werden können. Unternehmen benötigen eine Architektur mir der Services integriert werden können, um dynamische Lösungen zu erhalten.

5 Grundlegendes Problem der Komplexität Geschäftliche Probleme in den IT-Unternehmen sind permanent vorhanden wie - eine bessere Auslastung der IT-Ressourcen. - einen höheren ROI. - die Integration von bisher separaten Systemen. - und die schnellere Implementierung neuer Systeme. Komplexere Systemumgebungen, Budgetbegrenzung und höhere Prozesseffizienz erfordern die Weiterentwicklung von Legacy-Systemen, anstatt diese zu ersetzen. Der kostengünstige und zeit- bzw. ortsunabhängige Zugriff auf das Internet ermöglicht neue Geschäftsmodelle, um mit den Mitbewerbern schritt zu halten. Punkt-zu-Punkt Lösungen, die bei der Übernahme oder Fusion von Unternehmen entstehen, erschweren den Aufbau einer serviceorientierten Architektur. Es werden Systemlösungen benötigt, die Heterogenität als fundamentales Kriterium der IT-Umgebungen berücksichtigen!

6 Grundlegendes Problem der fehlenden Wiederverwendung Das Anwendungsportfolio von Unternehmen ist in den letzten Jahrzehnten durch die Fusion und Übernahme erheblich angewachsen. Unabhängig voneinander agierende Geschäftsbereiche unterbinden alle Versuche wiederverwendbare funktionale Ressourcen und Services zu entwickeln. Diese Redundanz von Anwendungen und Anwendungsfunktionen - erhöht die Kosten. - verlängert die Marktreife für neue Produkte und Services. Dieser Mangel an Widerverwendbarkeit erfordert deutlich mehr Ressourcen und häufig mehr Zeit bis zur Bereitstellung neuer Anwendungen!

7 Grundlegendes Problem von zu vielen Schnittstellen Alle Unternehmen sind mit Integrationsproblemen konfrontiert, sei es - auf Grund einer Unternehmensfusion. - einer neuen Geschäftsallianz. - durch die Verbindung vorhandener Systeme. Die direkte Verbindung von n Anwendungen erfordert bis zu (n-1) Verbindungen bzw. Schnittstellen. Die Integration der n+1 Anwendung erfordert somit 2n neue Schnittstellen, die zu programmieren, zu dokumentieren und zu testen sind. Um die Kosten für diese Komplexität zu verringern, wird eine optimale Lösung benötigt, mit der lediglich die Mindestanzahl an Schnittstellen n für n Anwendungen generiert wird!

8 Technologiegrundlagen für eine serviceorientierte Architektur Lösungsversuche in der Vergangenheit - In den letzten Jahrzehnten wurden immer wieder neue Programmiermodelle entwickelt. - Jede Umstellung erfolgte allerdings nur teilweise, um den Grad der Softwarekomplexität zu bewältigen. Technologiegrundlagen für eine serviceorientierte Architektur - Mit Java wurde eine plattformneutrale Programmiersprache entwickelt. - Mit XML können selbstbeschreibende und plattformneutrale Daten bereitgestellt werden. Web-Services - Web-Service ist ein De-facto-Standard für eine effektive, skalierbare und erweiterbare Interaktion zwischen Systemen. - Web-Services sind permanent verfügbar und basieren auf offenen Standards. - Die kostengünstigen Netzwerkinfrastrukturen für verteilte Anwendungen ermöglichen eine bessere Implementierung der Web-Services. SOA kann sowohl als Architektur als auch als Programmiermodell gesehen werden!

9 Eine serviceorientierte Architektur muss alle Anforderungen eines Unternehmens erfüllen Die ideale Architektur muss: - Vorhandene Ressourcen umfassend nutzen. - Alle erforderlichen Integrationsarten unterstützen. - Die schrittweise Implementierung und Migration von Ressourcen ermöglichen. - Um ein Framework von Standardkomponenten aufgebaut sein. - Die Implementierung neuer IT-Modelle erlauben.

10 Mit Web-Services kann eine serviceorientierte Architektur aufgebaut werden Web-Services haben zu einer Veränderung in der Entwicklung, Implementierung und Verwaltung von Anwendungen geführt. Mit Hilfe von Web-Services kann eine echte serviceorientierte Architektur implementiert werden. Web-Services sind nicht mit einer serviceorientierten Architektur gleichzusetzen. Web-Services sind eine Sammlung von Technologien wie XML; SOAP; WSDL; UDDI Web-Services sind ein reines Technologiepaket. SOA ist eine Architektur und ist von einer Technologie völlig unabhängig!

11 In einer serviceorientierten Architektur werden alle Funktionen als unabhängige, direkt aufrufbare Services definiert Eine serviceorientierte Architektur zeichnet sich durch folgende Eigenschaften aus: - Alle Funktionen werden als Service definiert: Hierzu gehören reine Geschäftsfunktionen, Geschäftstransaktionen und Systemservicefunktionen. - Alle Services sind unabhängig voneinander und operieren als so genannte Blackboxes : Externe Komponenten haben keinerlei Informationen über den Ablauf des Services und Informationen über den Aufbau. Sie bekommen lediglich das Ergebnis zurückgeliefert. - Alle Schnittstellen sind direkt aufrufbar: Es spielt aus systemarchitektonischer Sicht keine Rolle, ob die Schnittstelle sich innerhalb oder außerhalb des Systems befindet. Das Verbindungsprotokoll über das die Schnittstelle aufgerufen wird hat keine Bedeutung. In einer serviceorientierten Architektur wird die Art und nicht die Technologie des Services definiert. Das System und nicht die aufrufende Anwendung muss den Aufruf des Service verwalten!

12 Lösung der Integrationsprobleme mit SOA 1. Schritt: Verbindung der Anwendungen über einen Enterprise Service Bus (ESB). 2. Schritt: Integration eines Service- oder Flow-Manager zur Verbindung der Services. - Der Flow-Manager verarbeitet eine vordefinierte Ausführungsabfolge (Service-Flow). - Die Business Process Execution Language (BPEL) realisiert einen Flow-Manager, über die ein Prozess als Gruppe von Serviceaufrufen definiert werden kann. Service 1 Service 3 Service 5 Flow- Manager Service 2 Service 4 Service 6

13 Lösung der Integrationsprobleme mit SOA 3. Schritt: Hinzufügen der Anwendungskonfiguration und Verbindung zu den Back-End- Prozessen. - In der Anwendungskonfiguration wird definiert wie die Services aufgerufen werden und bietet Schnittstellen zur Visualisierung der Eingaben und Ausgaben. System Services Externe Messaging- Schnittstelle Flow- Manager Anwendungsmanagement System Services Service 1 Service 3 Service 5 Service 2 Service 4 Service 6 Back-End-Legacy- Prozesse Mit Hilfe eines solchen Frameworks lässt sich eine serviceorientierte Architektur aufbauen. Als nächster Schritt ist eine Analyse und Zerlegung der Geschäftsprozesse in Services durchzuführen.

14 Bei der Integration sind weitere Themen innerhalb der Architektur zu berücksichtigen Integration der Endbenutzerschnittstelle - Zugriff der Benutzer auf die Anwendungen und Services Anwendungskonnektivität - Asynchrone und synchrone Kommunikation - Weiterleitung und Datenreplikation Prozesse und Informationen - Entwicklung von Rechnerprozessen - Lösung von Geschäftsprozessen - Integration von Prozessen in andere Prozesse Build-Integrations-Entwicklungsmodell Für die Anforderungen bei der Anwendungs- und Prozessintegration kann die Technologie BPEL for WebServices eingesetzt werden.

15 Geschäftsprozesse in einer serviceorientierten Architektur SOA ist die technische Grundlage für die Realisierung von flexiblen Anwendungen. Jedoch spielt die Fachlichkeit der Anwendung eine entscheidende Rolle - Fachliche Funktionalität wurde bisher in integrierte Prozesse ausgeliefert. - In einer serviceorientierten Architektur können diese Prozesse nun wesentlich flexibler gestaltet werden und enger an die Unternehmensstrategie ausgerichtet werden. Die fachliche Prozessbeschreibung bestimmt die Granularität der zu verwendenden bzw. zu entwickelnden Services. Das Geschäftsprozessmanagement ist eine wesentliche Voraussetzung für die Übersetzung fachlicher Anforderungen in die technischen Services einer serviceorientierten Architektur.

16 Erfolgreiches Geschäftsprozessmanagement Ein erfolgreiches Geschäftsprozessmanagement besteht aus folgenden Schritten: - Geschäftsprozessstrategie Hier wird die Strategie festgelegt welche Ziele mit einer gewünschten Prozessveränderung erreicht werden sollen. - Prozessmodellierung Definition und Dokumentation der fachlichen Geschäftsprozesse. - Implementierung Implementierung und Orchestrierung der technischen Services auf Basis der fachlichen Geschäftsprozesse. - Monitoring und Bewertung Messung der Leistungsfähigkeit der Services. Aus den Geschäftsprozessmodellen werden die entsprechenden technischen Services definiert. SOA schafft die Voraussetzung für die Integration und Kooperation von Prozessen.

17 Orchestrierung von Prozessen mit BPEL Der kritische Schritt bei der Integration eines Geschäftsprozesses in eine serviceorientierte Architektur stellt die Orchestrierung des Ablaufes und die Ausführung der unterschiedlichen Aufgaben dar. Die Orchestrierung eines komplexen Prozesses stellt eine Reihe von Anforderungen an die Architektur: - Einbindung von heterogenen Systemen - Synchrone und asynchrone Nachrichten - Datenmanipulation - Human Workflow Services - Fehlerbehandlung Mit dem BPEL-Standard wurde eine einfachere Abstraktionsebene eingeführt, die die oben genannten Anforderungen erfüllt.

18 Bausteine von BPEL Choreographie: CDL4WS Orchestrierung: BPEL4WS Geschäftsprozesse Verwaltung WS- Reliablity WS- Security UDDI WSDL Transaktionen Koordination Kontext Service- Qualität Erkennen Beschreibung SOAP XML Nachricht HTTP, IIOP, JMS, SMTP Übertragen

19 Oracle BPEL Process Manager Mit dem Oracle BPEL Process Manager stellt Oracle ein auf BPEL standardisiertes Framework zum Aufbau einer serviceorientierten Architektur zur Verfügung. Der Oracle BPEL Process Manager unterstützt beim Design, Deployment, Monitoring und Administration von Prozessen. Der BPEL Process Manager von Oracle stellt eine umfassende Plattform zur Modellierung, Implementierung und Test von Geschäftsprozessen zur Verfügung.

20 Oracle PBEL Process Manager - Überblick Mit dem Oracle BPEL Process Manager werden für den Aufbau einer serviceorientierten Architektur folgende Features zur Verfügung gestellt: - Unterstützung von Standards: Unterstützung der Process Orchestration mit BPEL und Web-Service Standards wie WDIF, XSLT, etc. WSDL als Komponentenmodell und XML als Datenmodell - Performance und Skalierbarkeit Ausführung von parallelen BPEL-Prozessen Dehydration -Speicher zur Zwischenspeicherung von Prozessergebnissen in der Datenbank - Verbindungsdienste Das erweiterbare WSDL-Framework ermöglicht die Anbindung weiterer Nachrichten und Protokolle wie JMS, , JCA, HTTP - Datendienste Datentransformation mittels XSLT/XQuery und Transformation von Non-XML-Formaten nach XML und umgekehrt - Human Workflow Services Der Human Workflow Service ermöglicht die Integration von menschlichen Interaktionen - Web-basierte Oberfläche für das Management, Administration und Debugging von Prozessen zur Verfügung

21 Oracle BPEL Process Manager - Architektur Oracle BPEL Process Manager - ist eine Engine zum Ausführen von BPEL-Prozessen - enthält eine unternehmensorientierte Infrastruktur zum Erstellen, Bereitstellen und Verwalten von BPEL-Geschäftsprozessen Skalierbar Plattformübergreifend Plug and Play BPEL Process Manager BPEL Bereitstellen JDeveloper, Eclipse WSDL-Binding Interne Integrations-Services Web Service Java, JMS, JCA XQuery XSLT Java/ J2EE Benutzer Tasks Entwickeln Datei, FTP Datenbank iway BPEL-Core Engine J2EE-Applications-Server (Oracle AS, WebLogic, Jboss, WebSphere Dehydrierungsspeicher Verwalten

22 Service Adapter Unternehmensintegration erfordert Konvektivität zu einer breiten Palette von System, einschließlich Technologiesystemen und in einem Package integrierte Anwendungssysteme Oracle bietet einsatzbereite Konnektivität zu vielen Systemen an Adapter - Basieren vollständig auf Standards - Bieten umfassende Metadaten - Unterstützen Requests und Ereignisse - Ermöglichen automatische Zuordnung von XSLT zwischen strukturierten Daten Im JDeveloper BPEL Designer werden folgende Service Adapter unterstützt - File Adapter - FTP Adapter - Oracle Advanced Queuing (AQ) Adapter - Database Adapter - JMS Adapter - Oracle Application Adapter Mit den Service Adaptern werden die Funktionsmöglichkeiten eines BPEL-Processes weit über die Grenzen des Web Service Paradigmas hinaus erweitert.

23 Oracle Integration Oracle Integration ist eine umfassende Suite von Komponenten die interagieren, um effiziente Tools zur Integration von Prozessen mit BPEL bereitzustellen. InterConnect B2B Daten-Hub BPM BAM Messaging Transformation Routing Adapter Enterprise Service Bus Die Palette umfasst transparente Gateways, Java Connector Architecture, Web Services, SOAs Kundendatenhubs, Adapter für Datenübertragung und transformation, Oracle Integration BAM, Oracle Integration B2B, Oracle BPEL Process Manager und Oracle InterConnect als XML-Bus.

24 Oracle Integration InterConnect Mit Oracle Integration können alle Integrationsanforderungen zwischen den unterschiedlichsten Anwendungen umgesetzt werden. - InterConnect fungiert als Message Broker für Daten- und Anwendungsintegration. - InterConnect fungiert als Integrations-Hub, der die Kommunikation und die Übertragung von Nachrichten zwischen zwei oder mehr Anwendungen koordiniert. Transformation Routing istudio Messaging Oracle Datenbank Adapter Adapter Adapter Adapter Datenbank SAP MQ-Series Java

25 Oracle Integration B2B Oracle Integration B2B ist ein E-Business Integrationsprodukt für den Austausch von Services, Informationen und Produkten zwischen Unternehmen. E-Business Suite Oracle AS B2B-Integrationsserver Security MIME, S/MIME Legacy Anwendungen Dokumentenschnittstellen Übertragen HTTP, FTP, File, SMTP, IMAP Dokumentenausshnittstellen Integrierte Anwendungen File/Ftp, JMS, AQ, RDBMS PIP EDI Generisch PIP EDI Generisch B2B-Core Engine Oracle Application Server Oracle Datenbank

26 Oracle Integration Business Activity Monitoring (BAM) Mit Oracle Integration Business Activity Monitoring können alle Gechäftsaktivitäten eines Unternehmens überwacht werden. Mit BAM können Ergebnisse aller Integrationskomponenten erfasst werden. BPEL PM Oracle Integration BAM Sensoren BPEL PM BAM Modellierung Dashboard B2B Engine B2B InterConnect SDK Integrierte Prozessoren Korrelation KPI Alerts InterConnect Aktuelle Cube Ziel Cube Oracle Datenbank

27 Vorteile einer serviceorientierten Architektur Vorteile einer serviceorientierten Architektur - Nutzung von vorhandenen Ressourcen - Infrastruktur als Standardprodukt - Schnellere Marktreife - Niedrigere Kosten - Risikominimierung - Kontinuierliche Verbesserung von Geschäftsprozessen - Prozessorientierte Architektur Eine serviceorientierte Architektur kann auf vorhandenen Systemen aufgebaut werden, so dass keine vollständige Neuentwicklung notwendig ist.

28 Kontakt Stefan Kühnlein Senior Experte Integrated Business Solutions SerCon GmbH Hollerithstr München Mobil: +(49) Fax:+(49) Stefan.Kuehnlein@de.ibm.com