Analyse und Entwurf einer serviceorientierten Architektur zur flexiblen Abbildung von Geschäftsprozessen in der Energiewirtschaft

Größe: px
Ab Seite anzeigen:

Download "Analyse und Entwurf einer serviceorientierten Architektur zur flexiblen Abbildung von Geschäftsprozessen in der Energiewirtschaft"

Transkript

1 Master Thesis im Studiengang Application Architectures Analyse und Entwurf einer serviceorientierten Architektur zur flexiblen Abbildung von Geschäftsprozessen in der Energiewirtschaft Master Thesis zur Erlangung des Grades Master of Science im Studiengang Application Architectures an der Fakultät Wirtschaftsinformatik der Hochschule Furtwangen University vorgelegt von Stefan Becke Betreuer: Externe Betreuer Prof. Dr. Bernardin Denzel Dipl.-Wi.-Ing. Klaus Zabel Eingereicht am:

2

3 Eidesstattliche Erklärung Ich erkläre hiermit an Eides statt, dass ich die vorliegende Thesis selbstständig und ohne unzulässige fremde Hilfe angefertigt habe. Die verwendeten Quellen sind vollständig zitiert. Hamburg, den Stefan Becke

4 Rechtliche Hinweise SAP/R3 und alle weiteren in dieser Arbeit genannten Produkte der SAP AG sind Warenzeichen der SAP Deutschland AG. Java und alle Java-Warenzeichen sind Warenzeichen der Sun Microsystems Inc.. Alle weiteren Firmen-, Produkt- und Dienstleistungsnamen können Warenzeichen der jeweiligen Rechteinhaber sein.

5 Abstract III Abstract Master Thesis Analyse und Entwurf einer serviceorientierten Architektur zur flexiblen Abbildung von Geschäftsprozessen in der Energiewirtschaft Stefan Becke Europäische und nationale Gesetzesvorgaben bewirken eine Deregulierung und Globalisierung der Energiemärkte sowie eine zunehmende Dezentralisierung der Stromerzeugung und eine weitere Liberalisierung des Messwesens. Die über lange Zeit stabilen Rahmenbedingungen in der Energieversorgung sind somit seit einigen Jahren in Bewegung und verändern sich aktuell grundlegend. Dementsprechend stehen Energieversorgungsunternehmen (EVU) einem immer steigenden und dynamischen Wettbewerb gegenüber und müssen sich flexibel und zeitnah auf variierende Rahmenbedingungen einstellen sowie kontinuierlich neue, innovative Geschäftsprozesse etablieren. Das Konzept einer serviceorientierten Architektur (SOA) verspricht, die Informationstechnologie eines Unternehmens, wie z.b. eines EVU, flexibel an veränderte Geschäftsprozesse anzupassen. Diese Arbeit analysiert das Nutzenpotential einer SOA durch die Kapselung von Funktionalitäten in voneinander unabhängigen Diensten für ein EVU. Hierbei steht insbesondere die Anwendungsintegration mithilfe eines Enterprise Service Bus (ESB) als Integrationsinfrastruktur und die Orchestrierung von Services zu einem Geschäftsprozess im Vordergrund. Im Zuge des Entwurfs und der Implementierung wird ein Prototyp anhand betriebswirtschaftlicher Anforderungen eines exemplarischen Geschäftsprozesses der Energiewirtschaft realisiert und dessen technologische Umsetzbarkeit dargestellt. Die Ergebnisse dieser Arbeit zeigen auf, dass eine SOA für ein EVU geeignet ist, wobei bekannte Konzepte, wie eine nachrichtenorientierte Middleware, verwendet werden sollten. Offene Standards ermöglichen eine hersteller- und plattformunabhängige Integration. Jedoch ist grundsätzlich zu beachten, dass die Umsetzung einer SOA ein methodisches, systematisches Vorgehen erfordert.

6 Inhaltsverzeichnis IV Inhaltsverzeichnis Abstract... III Inhaltsverzeichnis...IV Abbildungsverzeichnis...VI Tabellenverzeichnis...IX Abkürzungsverzeichnis...X 1 Einleitung Problemstellung und Ziel der Arbeit Aufbau und Vorgehensweise Einführung in die Energiewirtschaft Energiewirtschaft in Deutschland Herausforderungen eines Energieversorgungsunternehmens Anforderungen an die IT-Architektur Grundlagen der Enterprise Application Integration Motivation für Enterprise Application Integration Integrationsebenen EAI-Architektur EAI-Lösungen Serviceorientierte Architekturen Grundlagen Services Klassifizierung von Services Serviceidentifikation Umsetzung serviceorientierter Architekturen Asynchrone Kommunikation Transaktionssicherheit Orchestrierung von Geschäftsprozessen Transaktionen und Fehlerbehandlung in WS-BPEL Spracherweiterungen von WS-BPEL... 52

7 Inhaltsverzeichnis V 4.5 Infrastruktur ESB Architektur Java Business Integration Prototypischer Entwurf einer SOA Analyse Geschäftsprozess Angebotskalkulation Strom Design Geschäftsprozess Angebotskalkulation Strom Services Prozess User Interfaces Anwendungs- und Systemarchitektur Prototypische Implementierung einer SOA Integrations- und Technologieplattform Services Prozess-Orchestrierung User Interfaces Bewertung Serviceorientierte Anwendungsintegration für ein EVU Integrations- und Technologieplattform - Sun openesb Zusammenfassung und Ausblick Literaturverzeichnis Quellenverzeichnis Anhang A: Servicebeschreibungen Anhang B: Datenbankdesign Anhang C: Interface-Beschreibungen Anhang D: Systemkonfiguration Anhang E: WS-BPEL Angebotskalkulation Strom Anhang F: JBI Container Angebotskalkulation Strom Anhang G: CD zur Master Thesis

8 Abbildungsverzeichnis VI Abbildungsverzeichnis Abbildung 1: Wettbewerbliche Teilmärkte in der Energiewirtschaft... 5 Abbildung 2: Entwicklungsmöglichkeiten von Enerviersorgungsunternehmen.10 Abbildung 3: Architektur einer Punkt-zu-Punkt-Verbindung Abbildung 4: Hub&Spoke-Architektur Abbildung 5: Bus-Architektur Abbildung 6: Find-Bind-Execute Paradigma Abbildung 7: Schichten einer SOA Abbildung 8: Serviceidentifikation Meet-in-the-middle-Ansatz Abbildung 9: Basisstruktur einer SOAP-Nachricht Abbildung 10: Basisstruktur einer WSDL-Datei Abbildung 11: Umsetzung einer SOA durch Web Services Abbildung 12: Synchroner Web Service-Aufruf Abbildung 13: Zustandsdiagramm Volatile2PC und Durable2PC Abbildung 14: Zustandsdiagramm WS-Business-Activity Abbildung 15: Basisstruktur eines WS-BPEL-Dokuments Abbildung 16: Service Container Abbildung 17: JBI Service Container Abbildung 18: Angebotserstellung/-anpassung Strom Abbildung 19: Angebotskalkulation Strom vereinfachte Darstellung Abbildung 20: Analyse der Anwendungsintegration Abbildung 21: Servicedesign auf Basis bestehender Funktionsbausteine Abbildung 22: Data-Service LsyasCostingVersionElectricityDataService Abbildung 23: Sequenzdiagramm - Callback -Interaktionsmuster Abbildung 24: Sequenzdiagramm - Polling -Interaktionsmuster mit JMX- Service... 79

9 Abbildungsverzeichnis VII Abbildung 25: Sequenzdiagramm - JMS Message Queue Abbildung 26: Layout UI; Erfassung Angebotskalkulationsversion Abbildung 27: Layout UI; Übersicht/Auswahl Angebotskalkulationsversion Abbildung 28: Design der Anwendungsintegration Abbildung 29: Verteilungsdiagramm Abbildung 30: Web-Service-Bean des Web Services LsyasPremiseService.89 Abbildung 31: Web Service MTOM Konfiguration LsyasLoadCourseService 89 Abbildung 32: Message-Driven Bean Lsyas NotificationService Abbildung 33: Schnittstelle des Services Lsyas NotificationService Abbildung 34: Input-Nachricht Lsyas NotificationService Abbildung 35: Binding-Element Lsyas NotificationService Abbildung 36: Service-Element Lsyas NotificationService Abbildung 37: Schnittstellen LsyasQuotationCostingElectricityBPELProcess 92 Abbildung 38: Input-/Output-Nachricht LsyasQuotationCostingElectricity- BPELProcess Abbildung 39: Property-Element LsyasQuotationCostingElectricity- BPELProcess Abbildung 40: Korrelationsmenge LsyasQuotationCostingElectricity- BPELProcess Abbildung 41: Korrelationselement LsyasQuotationCostingElectricity- BPELProcess Abbildung 42: MTOM Konfiguration LsyasQuotationCostingElectricity- BPELProcess Abbildung 43: Partner-Link des Services LsyasPremiseService Abbildung 44: Assign-Aktivität LsyasMeteringPointService Abbildung 45: Struts Komponenten - Prototyp contactenergy Abbildung 46: Erstellung einer Angebotskalkulationsversion ohne Callback.. 101

10 Abbildungsverzeichnis VIII Abbildung 47: Zuordnung Actions und Web Service Operationen Abbildung 48: JAX-WS-Client QuotationCostingProcessAction Abbildung 49: NetBeans openesb JBI-Manager

11 Tabellenverzeichnis IX Tabellenverzeichnis Tabelle 1: Formen und Auswirkungen des Unbundling... 8 Tabelle 2: Herausforderungen eines EVUs und Anforderungen an die IT Tabelle 3: Übersicht der Backend-Funktionalitäten für den Geschäftsprozess 71 Tabelle 4: Übersicht Prozessschritte und Services Tabelle 5: Parameter UI, Erfassung Angebotskalkulationsversion Tabelle 6: Parameter UI, Übersicht/Auswahl Angebotskalkulationsversion... 83

12 Abkürzungsverzeichnis X Abkürzungsverzeichnis 2PC AVB BAPI BC BPD BPELJ BPEL4People BPML BPMN BTP CORBA CRM bzgl. bzw. DCOM d.h. EAI EDM EJB EnWG ERP ESB et al. EVU ggf. GIS HPFC Hrsg. HT HTML Zwei-Phasen-Commit Allgemeine Versorgungsbedingungen Business Application Program Interface Binding Components Business Process Diagramm BPEL for Java WS-BPEL Extension for People Business Process Modeling Language Business Process Modeling Notation Business Transaction Protocol Common Object Request Broker Architecture Customer Relationship Management bezüglich beziehungsweise Distributed Component Object Model das heißt Enterprise Application Integration Energiedatenmanagement Enterprise Java Bean Energiewirtschaftsgesetz Enterprise Resource Planning Enterprise Service Bus et altera Energieversorgungsunternehmen gegebenenfalls Geografisches Informationssystem Hourly Price Forward Curve Herausgeber Hochtarif HyperText Markup Language

13 Abkürzungsverzeichnis XI HTTP HyperText Transfer Protocol IDL Interface Definition Language i.d.r. in der Regel JBI Java Business Integration JSP JavaServer Pages IT Informationstechnologie JCo Java Connector JCP Java Community Process JDBC Java Database Connectivity JMS Java Message Service JMX Java Management extensions JPA Java Persistence API JPQL Java Persistence Query Language MDB Message-Driven-Bean MOM Message-orientierte Middleware MTOM Message Transmission Optimization Mechanism MVC Model-View-Controller NLT Systeme der Netzleittechnik NMR Normalized Message Router NT Niedertarif o.g. oben genannte(n) OMG Object Management Group ORB Object Request Broker RDA Remote Data Access RFC Remote Function Call RPC Remote Procedure Call RMI Remote Method Invocation S. Seite SE Service Engine SLA Service Level Agreements SOA Serviceorientierte Architektur sog. so genannte(n)

14 Abkürzungsverzeichnis XII SQL Structured Query Language u. a. unter anderem UDDI Universal Description, Discovery & Integration UI User Interface WS-AT WS-Atomic-Transaction WS-BPEL Web Service - Business Process Execution Language WS-CAF WS-Composite Application Framework WSDL Web Service Description Language WS-HT Web Service - Human Task WS-I Web Service Interoperability Organization WS-TX WS-Transaction XML Extensible Markup Language Z.B. zum Beispiel

15 Einleitung 1 1 Einleitung Die über lange Zeit stabilen Rahmenbedingungen in der Energieversorgung sind seit einigen Jahren in Bewegung und verändern sich aktuell grundlegend. Europäische und nationale Gesetzesvorgaben, wie z.b. das Energiewirtschaftsgesetz (EnWG), bewirken eine Deregulierung und Globalisierung der Energiemärkte, eine zunehmende Dezentralisierung der Stromerzeugung und und eine weitere Liberalisierung des Messwesens. Energieversorgungsunternehmen (EVU) stehen somit einem immer steigenden und dynamischen Wettbewerb gegenüber. Um langfristig am Markt bestehen zu können, müssen sich EVU flexibel und zeitnah auf variierende Rahmenbedingungen einstellen und kontinuierlich neue, innovative Geschäftsprozesse etablieren und bestehende Geschäftsprozesse optimal gestalten. Zur Umsetzung von Geschäftsprozessen spielen Informationssysteme eine zentrale Rolle. 1 Die Informationstechnologie (IT) eines EVU steht somit vor der Herausforderung, in immer kürzeren Zyklen, neue, innovative Geschäftsprozesse zu unterstützen und auf Änderungen der Unternehmensstruktur flexibel zu reagieren. Ein derzeit aktuelles Thema im Bereich der Informationstechnologie sind sog. serviceorientierte Architekturen (SOA). Das technologieunabhängige Architekturkonzept einer SOA soll eine flexiblere Abbildung der Geschäftsprozesse in der Informationstechnologie ermöglichen, als die bisher traditionellen, monolithischen Applikationen und Systeme einer heterogenen IT-Landschaft. Darüber hinaus sollen SOA Kosteneinsparungen erbringen und das Entwicklungsrisiko senken. Hierbei sollen bei neuen oder geänderten Geschäftsprozessen lose gekoppelte Dienste ohne großen technischen Aufwand ausgetauscht und neu zusammengefügt werden, um somit IT-Systeme einfacher und flexibler zu ges- 1 Vgl. [Allw05], S. 42.

16 Einleitung 2 talten und dabei die Wiederverwendung bestehender Komponenten (Dienste) zu unterstützen Problemstellung und Ziel der Arbeit Die Abbildung von flexiblen, schnell anpassbaren Geschäftsprozessen und neuen Funktionalitäten ist aus Sicht der Informationstechnologie oftmals ein Problem der Integration bestehender und neuer Anwendungen, zu deren Umsetzung klassische Middleware-Technologien, wie z.b. RDA, RPC, ORB oder MOM herangezogen werden. Diese traditionellen IT-Architekturen von Unternehmen, so auch der EVU, müssen aufgrund eines immer steigenden und dynamischeren Wettbewerbs in vielerlei Hinsicht überdacht und neu konzipiert werden. Aus diesem Grund wird im Rahmen dieser Arbeit ein Konzept für eine serviceorientierte Architektur in der Energiewirtschaft konzipiert und bewertet, das als Basis für zukünftige Entwicklungen dienen soll. Variierende fachliche Anforderungen und eine Heterogenität der zu integrierenden Anwendungen sind dabei besondere Herausforderungen für die Konzeption einer entsprechenden serviceorientierten Architektur. Das Nutzenpotential einer serviceorientierten Architektur durch die Kapselung von Funktionalitäten in voneinander unabhängigen Diensten ist für ein EVU zu analysieren. Hierzu ist beispielhaft ein Geschäftsprozess der Energiewirtschaft zu analysieren und prototypisch umzusetzen. Zur Abbildung des Geschäftsprozesses sind die betriebswirtschaftlich benötigten Funktionalitäten zu identifizieren und mithilfe von Services (Diensten) bereit zu stellen. Hierzu ist ein Servicedesign zu entwickeln, um die benötigten Dienste aus Sicht des Geschäftsprozesses und der bereits bestehenden Backend-Funktionalitäten zu entwerfen. Der erwartete Erkenntnisgewinn dieser Arbeit liegt in der Aussage und Bewertung der Einsetzbarkeit des Architekturkonzeptes einer SOA zur Anwendungsintegration in der Energiewirtschaft. Konkret wird erarbeitet, inwieweit die Umsetzung einer SOA den gestiegenen Anforderungen zur Abbildung von flexiblen, schnell ändernden Geschäftsprozessen in der Informationstechnologie ge- 2 Vgl. [RLPB07], S. 8.

17 Einleitung 3 recht werden kann und wie eine prototypische Umsetzung aussehen kann. Die Realisierung soll dahingehend flexibel und erweiterbar sein, dass Services ohne große manuelle Anpassungen bzw. Implementierungsaufwand hinzugefügt oder ausgetauscht werden können. Die Sicherheit von SOA mittels SAML, XACML und den WS-* Sicherheitsstandards, die Möglichkeiten zur Verfügung stellen, Sicherheitskonzepte technisch umzusetzen, wird in dieser Arbeit nicht behandelt, da dies den Umfang dieser Thesis überschreiten würde. 1.2 Aufbau und Vorgehensweise Zu Beginn dieser Arbeit wird allgemein auf die Branche Energiewirtschaft und deren Herausforderungen eingegangen, um entsprechende Anforderungen an die IT-Architektur zu definieren. Anschließend werden die Motivation für Anwendungsintegration (Enterprise Application Integration; EAI), verschiedene Integrationsebenen, entsprechende Architekturen und mögliche Umsetzungen mittels klassischer Middleware-Lösungen vorgestellt. Nachdem ein allgemeines Verständnis für die Energiewirtschaft und für das Thema Enterprise Application Integration geschaffen wurde, werden die allgemeinen Konzepte einer serviceorientierten Architektur und deren technologische Umsetzung dargestellt. Innerhalb dieser Kapitel wird insbesondere auf die Abbildung von Geschäftsprozessen in einer serviceorientierten Architektur und einer notwendigen Integrationsinfrastruktur eingegangen. Nach der Analyse der theoretischen Grundladen werden die Konzepte auf ein mögliches IT-Architekturkonzept übertragen und auf den exemplarischen Geschäftsprozess der Angebotskalkulation Strom in der Energiewirtschaft angewandt. Dabei wird zwischen der Analyse und der anschließenden Implementierung des Geschäftsprozesses im Sinne einer serviceorientierten Architektur differenziert. Abschließend wird das IT-Architekturkonzept einer SOA für eine flexible Abbildung von Geschäftsprozessen in der Energiewirtschaft bewertet. Die gewonnen Erkenntnisse werden in einer Zusammenfassung dargestellt und ein weiterer Ausblick wird gegeben.

18 Einführung in die Energiewirtschaft 4 2 Einführung in die Energiewirtschaft In diesem Kapitel wird die Energiewirtschaftsbranche in Deutschland näher betrachtet und deren Besonderheiten beleuchtet. Es werden vor allem solche Aspekte näher untersucht, die Auswirkungen auf die Abbildung von Geschäftsprozessen in der IT haben. Insgesamt findet die Darstellung in komprimierter Art statt und soll dem Leser einen Überblick über die Energiewirtschaftsbranche und deren aktuellen Herausforderungen vermitteln. Zudem soll die Darstellung ein Verständnis für die Notwendigkeit einer IT-Architektur zur flexiblen Abbildung von Geschäftsprozessen in der Energiewirtschaft geben. Im Folgenden wird auf die aktuelle Situation der Energiewirtschaft in Deutschland eingegangen. Anschließend werden Herausforderungen für ein Energieversorgungsunternehmen (EVU) konkretisiert und Anforderungen an eine entsprechende IT-Architektur für ein EVU definiert. 2.1 Energiewirtschaft in Deutschland Die Energiewirtschaft in Deutschland befindet sich seit der Deregulierung des Strommarktes in einem fundamentalen Wandlungsprozess. Das am 07. Juli 2005 in Kraft getretene Gesetz über die Elektrizitäts- und Gasversorgung, kurz Energiewirtschaftsgesetz EnWG, sowie die Nachfolgeverordnungen zu den am außer Kraft getretenen Allgemeinen Versorgungsbedingungen (AVB) für Strom und Gas haben für EVU im Strom- und Gasbereich weit reichende Konsequenzen. Inhaltlich regelt das EnWG vor allem die Prinzipien des Netzzugangs. Das Leitbild ist hierbei ein diskriminierungsfreier, effizienter und transparenter Netzzugang zu angemessenen Preisen. Dies stellt die Entflechtung (Unbundling) der wettbewerblichen Teilmärkte (Erzeugung/Einkauf, Handel und Vertrieb) von den natürlichen Monopolen (Übertragung und Verteilung) dar, was wiederum die Entflechtung eines EVU entlang der Wertschöpfungskette (siehe Abbildung 1) in Netzbetrieb und Energievertrieb darstellt.

19 Einführung in die Energiewirtschaft 5 Abbildung 1: Wettbewerbliche Teilmärkte in der Energiewirtschaft Ziel der Deregulierung des Energiemarktes ist es, für alle auf dem Markt agierenden EVU gleiche Voraussetzungen für den Vertrieb zu schaffen und somit jedem Kunden freie Wahl zwischen den im Wettbewerb stehenden EVU zu ermöglichen. Der Energiemarkt zeichnet sich dabei durch die Besonderheit aus, dass dieser durch ein natürliches Netzmonopol geprägt ist, da von der Erzeugung über die Übertragung/Verteilung der Energie bis hin zum Endkunden eine Netzinfrastruktur notwendig ist. So wurde vor der Deregulierung ein Wettbewerb zwischen den EVU aufgrund geschlossener Versorgungsgebiete (Netzgebiete) ausgeschlossen. Der lokale Netzbetreiber war automatisch der entsprechende Versorger für den lokalen Endkunden. Zentraler Punkt der Marktliberalisierung ist ein diskriminierungsfreier Netzzugang. Somit ergibt sich das Faktum, dass der Teil Übertragung/Verteilung der Wertschöpfungskette bei den Netzbetreibern, d.h. den integrierten EVU in einem natürlichen Monopol angesiedelt ist, während die weiteren Teile der Wertschöpfungskette frei auf den Märkten zu realisieren sind. Um dabei eine Bevorzugung der Netzbetreiber, die gleichzeitig Versorger und/oder Erzeuger sind, zu verhindern, sind die wettbewerblichen Teilmärkte (Erzeugung/Einkauf, Handel und Vertrieb) von den natürlichen Monopolen (Übertragung/Verteilung) zu trennen. Dies wird als sog. Unbundling bezeichnet. Entsprechend dem EnWG vom 07. Juli 2005 muss jeder Netzbetreiber einem EVU gegen Zahlung eines sog. Nutzungsentgeltes eine diskriminierungsfreie Durchleitung von Energie bis zum Endkunden ermöglichen. Netznutzungsentgelte werden dabei von den Netzbetreibern für den Transport und die Verteilung

20 Einführung in die Energiewirtschaft 6 der Energie erhoben. Die Ermittlung der Netznutzungsentgelte ist in der Stromnetzentgeltverordnung (StromNEV) geregelt. Netzbetreiber müssen ihre kalkulierten Netznutzungsentgelte der Bundesnetzagentur zur Genehmigung vorlegen. Die Bundesnetzagentur prüft und korrigiert ggf. die kalkulierten Netznutzungsentgelte, um somit eine Durchleitung von Energie zu marktgerechten Preisen zu gewährleisten. Dies bedeutet einen Kostendruck für den Netzbetrieb eines EVU um eigenständig am Markt zu bestehen, da diese Kosten nur bis zu dem Preis der Netznutzungsentgelte gedeckt sind. Um langfristig auf dem Energiemarkt bestehen zu können, müssen sich EVU auf die Herausforderungen der veränderten Rahmenbedingungen einstellen und eine konsequente Ausrichtung an Kunde und Markt verfolgen. So umfasst die Beschaffung/Erzeugung von Energie nicht nur die eigentliche Erzeugung in möglicherweise eigenen Kraftwerken, sondern auch den Handel von Strom auf Strommärkten. Die Möglichkeit des Handels mit Strom führt zu einer Vielfalt an neuen Produkten, Dienstleistungen und potenziellen Handelspartnern. So drängen mit der Öffnung der Energiemärkte in Deutschland und der Etablierung von Strombörsen, wie z.b. der EEX in Leipzig, immer mehr Anbieter mit alternativen Konzepten auf den Markt, den zuvor nur wenige Marktteilnehmer mit zum Teil langfristigen Verträgen dominiert haben. Anbieter versuchen dabei durch innovative Marketing- und Kommunikationskonzepte und deutliche Preisnachlässe auf den Markt zu drängen und ihren Marktanteil zu erhöhen. Des Weiteren führen Gesetze zur Einspeisung erneuerbarer Energien und zur Kraft-Wärme-Kopplung, bedingt durch das Aufkommen alternativer Energieerzeugungsformen, wie z.b. Windenergie, Biomasse oder Solarenergie, zu Veränderungen in der Erzeugerstruktur. Diese Gesetze fördern den Bau dezentraler Erzeugungseinheiten, wie z.b. Windenergieanlagen. Diese dezentralen Erzeugungseinheiten führen jedoch auch zu einer wachsenden Unkalkulierbarkeit der Einspeisung in das Stromnetz und verursachen ein komplexeres Gesamtsystem. Dies ist darin begründet, dass bisherige Netzinfrastrukturen und

21 Einführung in die Energiewirtschaft 7 Netzmanagementstrategien auf eine zentrale Versorgung ausgerichtet sind und nunmehr auf eine dezentrale Versorgung umgestellt werden müssen. 3 Zudem führt das am in Kraft getretene Gesetz zur Öffnung des Messwesens bei Strom und Gas zu einer weiteren Liberalisierung des Messwesens, indem neben dem Messstellenbetrieb, d.h. Zählereinbau und -wartung auch die Zählerablesung liberalisiert wird. Nunmehr können die Anschlussnutzer und nicht mehr die Anschlussnehmer die Beauftragung eines dritten Messstellenbetreibers veranlassen. Ab dem sind Messstellenbetreiber verpflichtet, sog. intelligente Zähler in neuen und sanierten Wohneinheiten einzubauen, die den tatsächlichen Energieverbrauch und die tatsächliche Nutzungszeit widerspiegeln. Die Lieferanten haben bis spätestens ab dem lastvariable oder tageszeitabhängige Tarife anzubieten. Außerdem hat der Kunde das Recht auf eine monatliche, halbjährige oder vierteljährige Abrechnung von dem Lieferanten Herausforderungen eines Energieversorgungsunternehmens Die im vorherigen Abschnitt dargestellten nationalen und europäischen Gesetzesvorgaben bewirken eine Deregulierung und Globalisierung des Energiemarktes, eine zunehmende Dezentralisierung der Stromerzeugung und eine weitere Liberalisierung des Messwesens. Dies führt somit zu neuen Anforderungen an die Informations- und Kommunikationsinfrastruktur sowie an die entsprechenden Geschäftsprozesse eines EVU. Im Folgenden werden die wesentlichen Herausforderungen eines EVUs spezifiziert. Zur zeitgenauen Messung des Strom- oder Gasverbrauchs sollen elektronische Zähler sog. Smart Meter eingesetzt werden, welche die gemessenen Verbrauchswerte über eine Datenverbindung an die Systeme des Messstellenbetreibers weiter geben. Hierbei handelt es sich somit um eine fernauslesbare Zählerstruktur mit einem hohen Kommunikationsaufwand, die eine relativ einfache und flexible Anbindung an die jeweiligen IT-Systeme, wie z.b. Zählerdaten- 3 Vgl. [LMW07], S Vgl. [EnWG], 21b, ; [EnWG], 40 Abs. 3.

22 Einführung in die Energiewirtschaft 8 Managementsystem oder Abrechnungssystem des Messstellbetreibers notwendig macht. Dezentrale Erzeugungseinheiten, wie z.b. Windkraftanlagen, führen zu einem deutlich zunehmenden Bedarf an informationstechnischen Schnittstellen sowie Planung- und Steuerungsstrategien, welche die bisherigen zentral ausgerichteten Netzmanagementstrategien nicht vorsehen. Somit müssen die dezentralen Systeme der verschiedenen Erzeugungseinheiten relativ einfach und flexibel an die IT-Systeme des Netzbetreibers angeschlossen werden können. Des Weiteren bewirken Deregulierung und Globalisierung des Energiemarktes ein Unbundling, welches weitreichende strukturelle Veränderungen eines EVUs verursacht (siehe Tabelle 1). Form Auswirkungen Buchhalterisches Unbundling Getrennte Kontenführung und Erstellung von Bereichsbilanzen in der internen Rechnungslegung Informatorisches Unbundling Vertrauliche Behandlung und getrennte Verwendung sensibler Daten zwischen Vertrieb und Netzbetrieb Organisatorisches Unbundling Gesellschaftsrechtl. Unbundling Aufbau separater Abteilungen, eigenes Management, funktionale Trennung der Mitarbeiter, finanzielle Unabhängigkeit Gesellschaftsrechtliche Trennung von Bereichen, eigene Tochtergesellschaften Tabelle 1: Formen und Auswirkungen des Unbundling 5 So schreibt z.b. das informatorische Unbundling eine Trennung sensibler Daten zwischen Vertrieb und Netzbetrieb vor und soll für eine diskriminierungsfreie Bereitstellung von Daten für alle Marktteilnehmer sorgen. Dies bedeutet eine Trennung von Prozessen und Systemfunktionalitäten in jeweils eigene Sichtweisen für Vertrieb und Netzbetrieb. Hierdurch soll verhindert werden, dass der Vertrieb eines Netzbetreibers aufgrund von internen Daten einen Wettbewerbsvorteil gegenüber einem Marktteilnehmer erlangt, indem der Vertrieb z.b. einem Endkunden aufgrund von Daten des Netzbetriebs ein maßgeschneidertes Angebot unterbreiteten kann. Eine vollständige Unabhängigkeit von Übertragung/Verteilung von den wettbewerblichen Teilmärkten Erzeugung/Einkauf sowie Handel und Vertrieb wird dabei nur durch eine eigentumsrechtliche Trennung erreicht. Dies führt dazu, dass die Anwendung eines EVUs, die bisher für 5 Vgl. [EnwG], Teil 2.

23 Einführung in die Energiewirtschaft 9 Vertrieb und Netzbetrieb genutzt wurde, in zwei unabhängige Anwendungen aufgeteilt werden muss. Somit sind Daten, die zuvor in einem Stammdatensystem mit einem Kundentypen vorgehalten wurden, nunmehr in zwei unabhängigen Systemen oder Mandanten abzubilden. Insofern müssen die gemeinsamen Daten wie z.b. Adressdaten doppelt gepflegt oder Änderungen mittels geeigneter Systemfunktionalitäten und Schnittstellen ausgetauscht werden. Des Weiteren ist bei allen Datenzugriffen, Optimierungsfragen oder Geschäftsprozessen eine diskriminierungsfreie Anwendungsintegration aller Marktteilnehmer zu berücksichtigen. Wie bereits im Abschnitt 2.1 beschrieben, führt die Deregulierung und Globalisierung des Energiemarktes zu einer Vielzahl an neuen Produkten, Dienstleistungen und potenziellen Handelspartnern. Aufgrund der Gegebenheit, dass das Produkt Energie keine Differenzierbarkeit zwischen den konkurrierenden EVU hergibt, findet der Wettbewerb um Endkunden über den Preis oder die Serviceleistungen statt. Hierbei ist zu berücksichtigen, dass nach Angaben der Bundesnetzagentur nur zwei Prozent des Strompreises zur Deckung der Vertriebskosten und zur Realisierung einer Gewinnmarge für den Vertrieb zur Verfügung stehen. Den größten Kostenblock bilden mit rund 39 Prozent die Steuern und Abgaben. Beschaffung- oder Erzeugungskosten belaufen sich auf ca. 31 Prozent und die Netznutzungsentgelte auf ca. 28 Prozent. Dieser verstärkte Preiswettbewerb sowie die Entwicklung von neuen und innovativen Diensten der Konkurrenten zwingen EVU dazu, bestehende Geschäftsprozesse optimal zu gestalten und kontinuierlich neue, innovative Geschäftsprozesse zu etablieren, um somit die Prozesskosten stetig zu senken sowie die Kundenorientierung und das Serviceangebot kontinuierlich zu steigern. 6 Dies beinhaltet auch die Entwicklungsmöglichkeiten von EVU, neue Märkte, neue Produkte, neue Vertriebswege, neue Geschäftsmodelle und neue Kooperationen zu erschließen (siehe Abbildung 2). 6 Vgl. [FaKl07], S. 18.

24 Einführung in die Energiewirtschaft 10 Abbildung 2: Entwicklungsmöglichkeiten von Enerviersorgungsunternehmen 7 So werden z.b. Geschäftsprozesse, die vor der Deregulierung ganzheitlich durch ein EVU vorgehalten wurden, wie z.b. die Abrechnung von Leistungen, aufgrund einer kostenseitigen Entlastung und Flexibilisierung in Teilbereiche oder komplett ausgelagert. Kleinere EVU schließen sich zu aufgabenspezifisch orientierten losen Netzwerken zusammen oder sind Teil entsprechender Unternehmensverbünde. 8 Diese Veränderungen bestehender und neuer Geschäftsprozesse sind möglichst flexibel und kostengünstig mithilfe der entsprechenden IT-Systeme abzubilden. Des Weiteren sind neue Funktionalitäten bereit zu stellen und in die entsprechende IT-Architektur einzubinden. Bedingt durch das Unbundling ist z.b. die Rechnungsstellung des Netzbetriebs an den Vertrieb hinzugekommen. Des Weiteren ist zu beachten, dass viele unterstützende Geschäftsprozesse, wie z.b. kurz-, mittel- und langfristige Einsatzplanung, dezentrales Lastgangmanagement oder diskriminierungsfreier Stromhandel, noch nicht hinreichend erforscht sind und sich daher nach und nach Anpassungen ergeben, die flexibel mithilfe der IT-Systeme abgebildet werden müssen. 9 Die darstellten Herausforderungen eines EVUs und deren Anforderungen an die IT sind abschließend in der Tabelle 2 zusammengefasst. 7 Vgl. [Zaji07], S. 14ff. 8 Vgl. [FaKl07], S Vgl. [LMW07], S.344.

25 Einführung in die Energiewirtschaft 11 Herausforderungen eines EVUs Deregulierung und Globalisierung des Energiemarktes (Unbundeling) Dezentralisierung der Erzeugung Liberalisierung des Messwesens Verbesserung von Kundenorientierung und Serviceangebot Erhöhtes Kostenmanagement aufgrund erhöhter Markttransparenz und Wettbewerbsdruck Anforderungen an die IT Diskriminierungsfreie Anwendungsintegration aller Marktteilnehmer Optimale Gestaltung bestehender Geschäftsprozesse Flexible Etablierung neuer, innovativer Geschäftsprozesse Senkung von Prozesskosten (Abbildung möglichst automatisierter Geschäftsprozesse) Senkung von Entwicklungs- und folgender Wartungskosten von Softwarekomponenten, d.h. Diensten (Wiedervendbarkeit) Tabelle 2: Herausforderungen eines EVUs und Anforderungen an die IT Somit ergibt sich ein zunehmender Bedarf an unternehmensübergreifenden Anwendungsintegrationen und flexiblen, schnell anpassbaren Abbildungen von Geschäftsprozessen und Funktionalitäten innerhalb der IT-Landschaft eines EVU. Dabei ist eine entsprechende Herausforderung der IT, in immer kürzeren Zyklen, neue, innovative Geschäftsprozesse zu unterstützen und auf Änderungen der Unternehmensstruktur flexibel zu reagieren. Um dabei eine möglichst hohe Prozesseffizienz zu erreichen, sollten die Geschäftsprozesse möglichst IT-gestützt und somit automatisiert ablaufen. Des Weiteren sind die Entwicklungs- und Wartungskosten von Diensten durch eine möglichst hohe Wiederverwendbarkeit zu senken. Zur Umsetzung der Anforderungen an die IT eines EVUs ist ein entsprechendes IT-Architekturkonzept erforderlich, dessen Anforderungen im folgenden Abschnitt näher definiert werden. 2.3 Anforderungen an die IT-Architektur Die gewachsene IT-Architektur eines EVUs beruht oftmals auf heterogenen IT- Systemen. Eine Unterstützung der in vorherigen Abschnitt definierten Anforderungen an die IT stellt dabei in erster Linie ein Problem der Anwendungsintegra-

26 Einführung in die Energiewirtschaft 12 tion dar. 10 Somit muss die zurzeit vorliegende IT-Architektur eines EVUs in vielerlei Hinsicht überdacht und neu konzipiert werden, um eine einfache und kostengünstige unternehmensinterne als auch unternehmensübergreifende Integration von Anwendungen und Diensten zu ermöglichen. Dabei stehen Aspekte wie Datenintegration, Integration von Altsystemen, Standardisierung, aber auch der Aufbau neuartiger IT-Architekturen und Integrationsplattformen im Vordergrund. 11 Zur Einführung eines entsprechenden IT-Architekturkonzeptes müssen dabei gewisse Minimalanforderungen erfüllt werden, die in dieser Arbeit hinsichtlich einer serviceorientierten Anwendungsintegration für ein EVU untersucht werden. Diese Minimalanforderungen werden im Folgenden erläutert. 12 Integration: Aufgrund einer stärkeren Vernetzung und einer höheren Kommunikation zwischen allen Akteuren eines Energiemarktes soll die Architektur eine plattform- und herstellerunabhängige Integration von hoch verteilten Anwendungen und Diensten im Umfeld heterogener Systeme und Plattformen ermöglichen. Innerhalb der Systemlandschaft eines EVUs existieren eine Reihe unterschiedlicher kaufmännischer Systeme, wie z.b. Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Data Warehouse und technische Systeme, wie z.b. Systeme der Netzleittechnik (NLT) oder das Geografische Informationssystem (GIS). Zusätzlich existieren eine Menge weiterer Anwendungen für spezielle Aufgabenstellungen, die zusätzlich in die IT- Architektur integriert werden müssen. Hierbei ist nicht nur eine unternehmensinterne, sondern ebenfalls eine unternehmensübergreifende Integration notwendig, um z.b. Mitbewerbern im Stromhandel einen diskriminierungsfreien Zugang zu Informationen zu ermöglichen. Hierzu muss zunächst eine geeignete IT-Infrastruktur geschaffen werden, um die heterogenen und in hohem Maße autonomen und dynamischen Systeme interoperabel zu gestalten. Dienste, d.h. sog. Services sollen hier- 10 Vgl. [LMW07], S Vgl. [LMW07], S Vgl. [KBS04], S. 6, [LMW07], S.345.

27 Einführung in die Energiewirtschaft 13 bei von den verschiedenen Akteuren des Energiemarktes angeboten werden und relativ einfach an die IT-Infrastruktur angeschlossen werden können. Hierzu ist zur Abbildung einer losen Systemkopplung neben einer synchronen auch eine asynchrone Kommunikation erforderlich. Des Weiteren sind transaktionsgesicherte Aufrufe über Systemgrenzen sicherzustellen. Entkopplung von Funktionalität und Technologie: IT-Systeme unterschiedlicher Marktteilnehmer sollen problemlos und kostengünstig in die bestehende IT-Infrastruktur eingebunden und unterschiedliche Dienste ohne großen Migrationsaufwand gegeneinander ausgetauscht werden können. Hierzu muss die Architektur eines EVUs erlauben, sich weitestgehend unabhängig von einer speziellen Technologie zu bewegen. Dies beinhaltet ebenfalls die Vermarktbarkeit einzelner Dienste oder einer Produktlösung, die in heterogene Systemlandschaften bei unterschiedlichen Energieversorgern eingebettet werden könnte. Um diese Anforderungen umzusetzen, bedarf es eines hohen Grads der Standardisierung, wie z.b. von Austauschformaten und Schnittstellen, sowie eine klare Trennung von Geschäftslogik und Infrastrukturdetails. Einheitliche Standards sollen somit die Interoperabilität der unterschiedlichen IT-Systeme garantieren. Wiederverwendbarkeit: Für verschiedene Nutzergruppen innerhalb eines EVUs, wie z.b. Beschaffung/Erzeugung, Übertragung/Verteilung o- der Vertrieb, müssen unterschiedliche fachliche Basisdienste realisiert werden. Aufgrund eines immer stärkeren Kostendrucks auf die IT- Systeme sind dabei fachliche Basisdienste anwendungsübergreifend im Sinne des informatorischen Unbundling zu nutzen und zu neuen Anwendungen zu kombinieren. Somit sollen Entwicklungs- und folgende Wartungskosten eingespart werden. So ist ein Basisdienst z.b. sowohl für den Netzbetrieb als auch für den Vertrieb zu nutzen. Des Weiteren kann ein Basisdienst z.b. für den Vertrieb in unterschiedlichen Vertriebsprozessen eingesetzt werden. Hierzu bedarf es einer geeigneten Einteilung von Diensten und Schnittstellen, so dass Dienste für verschiedene potentielle Nutzergruppen verwendbar sind.

28 Einführung in die Energiewirtschaft 14 Flexibilität: Die Flexibilisierung umfasst die Anforderung der Erweiterbarkeit, Wartbarkeit und Skalierbarkeit. Aufgrund von Veränderungen in bestehenden Geschäftprozessen oder der Einführung neuer Geschäftsprozesse innerhalb eines EVUs bedarf es einer effizienten, flexiblen Durchführung von Geschäftsprozessen. Geschäftsprozesse eines EVUs müssen schnell und effizient an dynamische Rahmenbedingungen angepasst werden können, die sich aus gesetzlichen Änderungen, Umstrukturierungen, geänderten Marktsituationen, Verbesserung von Kundenorientierung und Serviceangebot oder technologischen Änderungen ergeben. Hierzu bedarf es lose gekoppelter Dienste und einer hohen Flexibilität in der Abbildung von Geschäftsprozessen. Um dabei die Prozesskosten zu senken, sind die Prozesse klar zu definieren und möglichst vollständig mithilfe der IT, d.h. einem geeigneten Workflowmanagement System, flexibel abzubilden und zu überwachen. Basierend auf diesen Anforderungen an die IT-Architektur wird in dieser Arbeit eine serviceorientierte Lösung für das Problem der Integration von Anwendungssystemen innerhalb eines EVUs vorgestellt und bewertet. Dabei soll sich das Modell sowohl auf unternehmensübergreifende als auch auf unternehmensinterne Anwendungsintegration anwenden lassen.

29 Grundlagen der Enterprise Application Integration 15 3 Grundlagen der Enterprise Application Integration Der Begriff Enterprise Application Integration (EAI) ist Anfang der neunziger Jahre entstanden. Auch wenn EAI ursprünglich als Bezeichnung für die Integration von Anwendungen gedacht war, sind in der Literatur ganz unterschiedliche Definitionen mit entsprechenden Schwerpunkten zu finden. In dieser Arbeit steht EAI für das Konzept einer flexiblen Integration von heterogenen Anwendungen zur Unterstützung von Geschäftsprozessen. Anwendungen sollen hierbei als Dienste gekapselt werden und somit anderen Anwendungen zur Verfügung gestellt werden. 13 Im Folgenden werden kurz die Motivation für EAI, die Integrationsebenen, mögliche EAI-Architekturen und technische EAI-Lösungen vorgestellt. 3.1 Motivation für Enterprise Application Integration Funktionalität eines Geschäftsprozesses wird häufig von mehreren heterogenen Anwendungen abgedeckt, die weit über das Unternehmen verstreut sind. Dies bedeutet, dass eine Vielzahl von unterschiedlichen Anwendungen in einem Unternehmen eingesetzt wird, die jeweils nur einen spezifischen Teilbereich unterstützen und teilweise auf völlig verschiedenen Technologien beruhen (Heterogenität der Systemlandschaft). Darunter zählen Standardanwendungen, wie z.b. ERP- oder CRM-Systeme, selbst entwickelte Individualsoftware oder Erweiterungen von Anwendungen sowie erworbene Software von Drittanbietern. Die aus dieser Notwendigkeit der Abwicklung von Gesamtprozessen über mehrere Anwendungen zu realisierenden Verbindungen stellen den Bedarf einer Anwendungsintegration dar. Dabei sind heterogene Anwendungen innerhalb des eigenen Unternehmens auch als Anwendungen von Geschäftspartnern, die über einen zwischenbetrieblichen Geschäftsprozess in Abhängigkeit zueinander stehen, miteinander in Verbindung zu setzen. 13 Vgl. [RMB01], S. 2f; [Kaib02], S. 83; [Kell02], S. 9.

30 Grundlagen der Enterprise Application Integration 16 Eine unzureichende Integration von Anwendungen und somit eine mangelnde Möglichkeit der automatisierten Prozessausführungen innerhalb des Unternehmens als auch mit Geschäftspartnern kann zu Effizienzeinbußen und eventueller konkreter Existenzgefährdung führen. Das Ziel einer EAI ist somit die Kopplung von bisher isoliert voneinander betriebenen Anwendungen unter dem Aspekt einer so gering wie möglich gehaltenen Komplexität Integrationsebenen Enterprise Applikation Integration kann auf den folgenden drei Ebenen stattfinden: 15 Präsentationsebene Datenebene Funktionsebene/Prozessebene Eine Integration auf der Präsentationsebene ist die primitivste Form der EAI. Hierbei werden einzelne Anwendungen mit einer gemeinsamen Präsentation, wie z.b. in Web-Portale, integriert, um dem Benutzer eine einheitliche Benutzeroberfläche zu bieten. Somit werden Benutzerschnittstellen dafür verwendet, Daten und Funktionalitäten aus verschiedenen Anwendungen zu extrahieren. 16 Als Beispiel kann hierfür ein gemeinsames HTML Interface zu einer SAP-R/3- Anwendung und einer Mainframe-Anwendung angeführt werden. Des Weiteren können mithilfe von sog. Screen-Scraping -Tools die benötigten Daten von Benutzeroberflächen extrahiert und in einer gemeinsamen Benutzeroberfläche abgebildet werden. Jedoch skaliert eine Integration auf dieser Ebene relativ schlecht und kann allgemein als instabil bezeichnet werden. 17 Die Datenintegration umgeht die Präsentations- und Prozessebene und greift zum Zweck der Integration direkt auf die Datenbanken einer Anwendung zu. Hierdurch steht bei der Datenintegration, im Gegensatz zur Präsentationsebene, ein breiteres Datenspektrum zur Verfügung. Die datenorientierte Integration 14 Vgl. [ScWi02], S Vgl. [CHKT06], S Vgl. [CHKT06], S Vgl. [RMB01], S

31 Grundlagen der Enterprise Application Integration 17 basiert entweder auf Datenschnittstellen, der Replikation zwischen Datenbanken oder der Datenföderation. 18 Ein wesentlicher Vorteil der Integration auf Datenebene besteht darin, dass keine Modifikation der Datenbanken oder Anwendungslogik in bereits bestehenden Anwendungen erforderlich ist. 19 In vielen Fällen müssen jedoch Datenbestände abgeglichen oder von verschiedenen Stellen abgefragt werden, wodurch Integrationsprobleme hinsichtlich Datenmodellheterogenität, Schema- oder Modellierungsheterogenität und Heterogenität auf Datenebene auftreten können. 20 Hierzu existieren ausgereifte EAI-Werkzeuge und Techniken, um Daten zu konvertieren, zu aggregieren, zu synchronisieren und einheitlich zur Verfügung zu stellen. Grundsätzlich muss aber die Abhängigkeit vom verwendeten Datenmodell berücksichtigt werden. Sobald sich das Datenmodell verändert, ändert sich die Basis der Integration und zieht umfangreiche Änderungen mit sich. Außerdem muss die Logik zur Aggregation der Daten erneut implementiert werden, da diese in den bestehenden Anwendungen verbleiben, die bei der Integration auf Datenebene nicht genutzt werden. Insgesamt kann eine Integration auf Datenebene aber als ein erprobtes und weit verbreitetes Integrationskonzept betrachtet werden. 21 Die Funktionsintegration ist eine Integrationsform auf Ebene der Anwendungslogik. Beteiligte Anwendungen müssen dabei anderen Anwendungen über definierte Schnittstellen Funktionalität zur Verfügung stellen. Wenn Funktionalität entlang der Geschäftsprozesse integriert wird, kann von Prozessintegration gesprochen werden. Dabei stellt die Integration auf Prozessebene die stabilste und flexibelste, jedoch auch die komplexeste und schwierigste Integration dar, da neben den technischen auch semantische Anforderungen hinsichtlich der Geschäftslogik gestellt werden. 22 Ihr Grundkonzept besteht darin, einzelne Teilfunktionen von Anwendungen als Dienste anzubieten und somit die gemeinsame Nutzung von Funktionalität durch mehrere Anwendungssysteme zu ermöglichen. 23 Wesentlicher Vorteil der Integration auf Prozessebene ist somit die 18 Vgl. [Lint00], S. 28ff; [Kaib02], S Vgl. [CHKT06], S Vgl. [CHKT06], S Vgl. [CHKT06], S Vgl. [RMB01], S. 23, 26-27, Vgl. [RMB01], S. 27ff; [Kaib02], S. 65ff.

32 Grundlagen der Enterprise Application Integration 18 Möglichkeit, zur Abbildung eines Prozessschrittes auf Funktionalitäten bereits bestehender Anwendungen zuzugreifen und diese wieder zu verwenden. 24 Heterogene Technologien und unterschiedliche Qualität und Umfang von Schnittstellen können jedoch zu Kompatibilitätsproblemen bei der Integration führen und hohe Kosten im Falle einer Modifikation der vorhandenen Schnittstellen verursachen. 3.3 EAI-Architektur Ziel einer EAI-Architektur ist es, Daten und Funktionalitäten unterschiedlicher Anwendungen einheitlich zu verwenden und neue Anwendungen, flexibel in die bestehende IT-Landschaft einzubinden. Zur Umsetzung einer EAI-Architektur können die möglichen Topologien einer Hub&Spoke-Architektur oder einer Bus- Architektur herangezogen werden. Des Weiteren ist in diesem Zusammenhang die sog. Punkt-zu-Punkt-Verbindung zu nennen. Oftmals ist die IT-Landschaft eines Unternehmens historisch ohne Architekturkonzept gewachsen und die Anwendungen per Punkt-zu-Punkt-Verbindung miteinander verbunden. Diese Art der Anwendungsintegration ist jedoch nur bei wenigen Anwendungen und wenigen Verbindungen praktikabel. Dies bedeutet, dass bei einer stetigen Zunahme der Anwendungen, deren Integration komplizierter wird. Sollen alle Anwendungen miteinander verbunden sein, so beträgt die Anzahl der Schnittstellen n*(n-1)/2 (siehe Abbildung 3). Diese IT-Landschaft wird somit auch als sog. Spaghettiarchitektur bezeichnet. Abbildung 3: Architektur einer Punkt-zu-Punkt-Verbindung Vgl. [CHKT06], S Vgl. [Dun08+], S. 9.

33 Grundlagen der Enterprise Application Integration 19 Das Ziel einer EAI-Architektur ist es, diese heterogene IT-Landschaft zu systematisieren. Es soll somit eine IT-Architektur geschaffen werden, in der Daten und Funktionalitäten der unterschiedlichen Anwendungen einheitlich verwendet werden können, um unternehmensinterne sowie unternehmensübergreifende Geschäftsprozesse einfach und flexibel abzubilden. Die meisten EAI-Werkzeuge verwenden hierzu eine Hub&Spoke-Architektur ( Nabe&Speichen-Architektur ). Bei dieser Architektur wird ein Hub als zentrale Integrationsinfrastruktur, dem sog. EAI-Broker zwischen die zu verbindenden Anwendungen ( Spokes ) eingesetzt, welches sämtliche Informationen, die zwischen den Anwendungen ausgetauscht werden, empfängt, transformiert und weiterleitet. Hierzu ist es notwendig, dass jede Anwendung ( Spoke ) mithilfe eines Adapters mit dem Hub verbunden wird, um somit die Daten der Anwendung weiter zu leiten. Hierbei stellt eine Hub&Spoke-Architektur charakteristisch eine Sterntopologie dar (siehe Abbildung 4). 26 Abbildung 4: Hub&Spoke-Architektur 27 Bei dieser EAI-Architektur kann ein zentraler Hub bei sehr hohem Kommunikationsaufkommen zum sog. Performance-Bottleneck (Flaschenhals) werden. Entgegenwirkend kann mit mehreren EAI-Brokern die Last verteilt werden, wodurch jedoch der Administrationsaufwand steigt. 28 Mithilfe der Bus-Architektur (siehe Abbildung 5) soll der Nachteil eines sog. Flaschenhalses bei einer Hub&Spoke-Architektur aufgehoben werden. Der dargestellte Bus ist ein virtuelles Konstrukt, das durch das Vermitteln von Nachrichten entsteht. Wie bei der Hub&Spoke-Architektur erfolgt die Anbindung mithilfe von 26 Vgl. [Pere06], S Vgl. [Pere06], S Vgl. [Pere06], S. 3.

34 Grundlagen der Enterprise Application Integration 20 Adaptern. Der Hauptunterschied zur Hub&Spoke-Architektur liegt allerdings darin, dass die Transformation und Weiterleitung der Daten von den jeweiligen Adaptern übernommen wird. Aufgrund dessen wird eine Bus-Architektur auch als eine verteilte Architektur bezeichnet. Diese verteilte Architektur skaliert im Gegensatz zu einer Hub&Spoke-Architektur besser, jedoch ist diese aufgrund der verteilten Architektur ebenfalls schwierig zu administrieren. 29 Abbildung 5: Bus-Architektur EAI-Lösungen EAI-Lösungen werden bislang überwiegend unter dem Aspekt der eingesetzten Middleware-Technologie diskutiert. 31 Middleware ist eine anwendungsneutrale Softwareschicht zwischen betrieblichen Anwendungen, welche auf Basis einheitlicher Schnittstellen und Protokolle Dienste für eine transparente Kommunikation verteilter Anwendungen bereitstellt. Sie soll somit eine Infrastruktur bieten, um neue und bestehende Anwendungen schnell zusammenzuführen. 32 Die entsprechende Middleware-Technologie muss dabei u.a. über ausreichende Dienste zum Transport komplexer Daten (sog. Messaging), zur Vermittlung von Funktionsaufrufen, Transaktionssicherheit, Verschlüsselung, Verkryptung und Authentifizierung verfügen. 33 Im Bereich der Middleware-Technologien kann nicht von einem allgemein akzeptierten Standard gesprochen werden, da eine Vielzahl unterschiedlicher hersteller- und plattformabhängiger Lösungen auf dem Markt existieren. 34 Die Abgrenzung der verschiedenen Middleware- Technologien ist in der Literatur nicht einheitlich. 29 Vgl. [Pere06], S Vgl. [Pere06], S Vgl. [SDLD02], S Vgl. [Vogl06], S Vgl. [SDLD02], S Vgl. [Vogl06], S. 64.

35 Grundlagen der Enterprise Application Integration 21 Im Folgenden werden die wesentlichen Technologien der letzten Jahre kurz dargelegt: 35 Remote Data Access (RDA) Remote Procedure Call (RPC) Object Request Broker (ORB) Message-orientierte Middleware (MOM) Remote Data Access (RDA) ermöglicht über eine (standardisierte) Abfragesprache, wie z.b. Structured Query Language (SQL), den Zugriff auf eine unabhängig vom jeweiligen Anwendungssystem geführte Datenbank. Die bekannteste Form des Remote Data Access ist die von Microsoft definierte ODBC- Schnittstelle, mit der auf die gebräuchlichen Datenbanksysteme zugegriffen werden kann. Des Weiteren ist für die Nutzung von Datenbanksystemen durch die Programmiersprache Java die von SUN basierend auf den Konzepten von ODBC entwickelte Java Database Connectivity (JDBC) zu nennen. Von Nachteil bei RDA ist jedoch, dass hier lediglich eine Integration auf Datenebene und keine funktionale Integration auf Prozessebene erfolgt. 36 Mithilfe von Remote Procedure Calls (RPC) können Funktionen aus verteilten Anwendungen heraus aufgerufen werden. RPC gilt als ein eher allgemeines Konzept und wird inzwischen als veraltet angesehen. Eine lokale Funktion oder Prozedur kapselt einen Programmcodeabschnitt und stellt diesen über ein Netzwerk zur Verfügung. Der Programmcode kann somit von einer entfernten Anwendung wie eine eigene Funktion aufgerufen werden, indem der Aufruf ü- ber das Netzwerk an die Quellanwendung weitergeleitet wird. Die Quellanwendung führt die entsprechende Funktionalität durch und liefert das Ergebnis an die aufrufende Anwendung über das Netzwerk zurück. Von Nachteil synchroner RPC-Systeme ist, dass die aufrufende Anwendung (Client) 37 während des Prozeduraufrufs so lange blockiert ist, bis die Quellanwendung (Server) 38 geant- 35 Vgl. [SDLD02], S Vgl. [ScWi02], S. 12f. 37 Der Begriff Client wird hier lediglich zur Identifizierung der Seiten verwendet, die eine entfernte Prozedur (Funktionalität) aufrufen. 38 Der Begriff Server wird hier lediglich zur Identifizierung der Seiten verwendet, die eine entfernte Prozedur (Funktionalität) zur Verfügung stellen.

36 Grundlagen der Enterprise Application Integration 22 wortet hat. Eine Definition des Funktionsaufrufs wird fest im Programmcode eingefügt, somit erfordert eine Aktualisierung des Funktionsaufrufs einer Anwendung oftmals die Modifikation aller abhängigen Anwendungen. Bei einer größeren Anzahl von Anwendungen steigt der Wartungsaufwand, da mindestens (n*(n-1))/2 Schnittstellen benötigt werden, um alle Anwendungen miteinander zu verbinden. Genau diese Punkt-zu-Punkt-Verbindung soll jedoch durch das Konzept einer EAI vermieden werden. Des Weiteren müssen Mechanismen, wie z.b. zur Gewährleistung von Sicherheit, Performance oder Verteilung, explizit vom Programmierer berücksichtigt werden. 39 Mithilfe von sogenannten Object Request Broker (ORB) können Funktionen über Objekte aufgerufen werden, wobei häufig aufgerufene Objekte im Hauptspeicher vorgehalten werden können. Dabei stellt der ORB Dienste u.a. zur Koordination der Transaktionen, Ereignisse, Sicherheit der Übertragung und zur Bekanntmachung der Dienste zur Verfügung. Hierbei versucht einerseits die Object Management Group (OMG) unter dem Namen CORBA (Common Object Request Broker Architecture) einen unabhängigen Standard einer objektorientierten Middleware (Object Middleware) zu definieren, für den sich Implementierungen unterschiedlicher Hersteller finden lassen. Auf der anderen Seite sind in diesem Zusammenhang komponentenorientierte Middleware Konzeptionen (Component Middleware), wie z.b. das von Microsoft definierte Distributed Component Object Model (DCOM/COM+) für Microsoft-Plattformen und die Java Remote Method Invocation (RMI) für den Aufruf von Java Programmen auf geographisch entfernten Rechnern, zu nennen. Jedoch liegt bei diesen Lösungen i.d.r. eine Hersteller- oder Plattformabhängigkeit vor. 40 Insbesondere Message-orientierte Middleware (MOM), welche die synchrone oder asynchrone Übertragung von Nachrichten zwischen an der Integration beteiligten Applikationen bietet, hat sich im Umfeld von EAI-Lösungen weitestgehend etabliert. Wesentliches Element einer MOM stellen Nachrichten (Messages) dar, welche das Datenpaket beinhalteten, bestehend aus einem Header, einem Body und wahlweise bestimmter Eigenschaften. Diese Message wird 39 Vgl. [ScWi02], S Vgl. [ScWi02], S. 13f.

37 Grundlagen der Enterprise Application Integration 23 über virtuelle Message Channel von einem Sender zu einem oder mehreren Empfängern transportiert. Dabei sind Message Chanels logische Adressen innerhalb des Messaging Systems, indem Nachrichten gespeichert und anderen Anwendungen zur Verfügung gestellt werden. Message Channels unterteilen sich in Point-to-Point-Channel (ein Sender, ein Empfänger) oder Publish- Subscribe Channel (ein Sender, mehrere Empfänger). Bei einem Point-to-Point- Channel werden so genannte Message Queues aufgebaut. Durch das Zwischenspeichern der Nachrichten des Senders in eine oder mehrere Warteschlangen (Queues) kann nach dem Absetzen einer Nachricht der entsprechende Verarbeitungsprozess fortgesetzt werden und falls eine Antwort erwartet wird, diese zu einer gegebenenfalls späteren Zeit abgefragt werden. Bei einem Publish- und Subscribe-Channel weiß der Sender einer Nachricht nicht, wie viele Empfänger seine Nachricht erhalten. Hierbei handelt es sich um eine themenorientierte Nachrichtenverteilung. Die Nachrichten werden dabei über sog. Topics ausgetauscht. Ein Topic steht für ein bestimmtes Themengebiet oder einen bestimmten Bereich. Die Empfänger, d.h. die Konsumenten registrieren sich für ein bestimmtes Topic, zu welchem sie Nachrichten empfangen möchten und Anwendungen verbinden sich über so genannte Endpoints mit dem Messaging-System. Ein Endpoint übernimmt dabei das Empfangen (Inbound) und Versenden (Outbound) von Nachrichten über das Messaging- System. 41 Der Versand von Nachrichten kann dabei auf verschiedene Arten, wie z.b. durch Routing, einen Filter oder Transformationen, beeinflusst werden. Für jede dieser Arten gibt es unterschiedliche Ablaufmuster, d.h. sog. Integration Pattern. 42 So wird z.b. mithilfe des Content-Based Routing Pattern eine Nachricht aufgrund bestimmter Merkmale (Contents) zum Empfänger gesandt und mithilfe des Message-Filter Pattern sicher gestellt, dass lediglich die Nachrichten an den Empfänger gehen, die auch von Interesse sind. 43 Eine vollständige Beschreibung möglicher Enterprise Integration Pattern würde an dieser Stelle den Umfang dieser Arbeit überschreiten. Somit wird auf die hier verwendete Fachliteratur verwiesen. 41 Vgl. [ScWi02], S Vgl. [HoWo03], S Vgl. [HoWo03], S

38 Serviceorientierte Architekturen 24 4 Serviceorientierte Architekturen Der Schwerpunkt von EAI-Lösungen liegt, wie im Kapitel 3.4 beschrieben, primär auf der technischen Integration einer Anwendungslandschaft. Unter dem Stichwort EAI wird dabei oftmals eine Integrationsform auf Basis bestehender Anwendungen diskutiert, bei der die Kopplung über die technologisch heterogenen Strukturen und Grenzen unter Einsatz von Middleware-Lösungen stattfindet. Zur flexiblen Integration von heterogenen Anwendungen zur Abbildung von Geschäftsprozessen innerhalb der IT-Landschaft resultiert hierdurch eine hohe Komplexität der notwendigen Integrationsbeziehungen. Dieses Kernproblem der EAI beruht dabei maßgeblich in einer fehlenden Standardisierung der Schnittstellen und der darin notwendingen Interoperabilität zwischen Anwendungssystemen. Serviceorientierte Architekturen (SOA) versprechen, diese Probleme einer EAI zu bewältigen und dabei IT-Kosten zu senken. SOA fokussieren dabei nicht auf die technologische, sondern auf die fachliche Ebene in einem Unternehmen und dessen Geschäftsprozesse. SOA versprechen, aufgrund einer standardisierten Prozessintegration eine höhere Flexibilität bei der Abbildung neuer Geschäftsprozesse in immer kürzeren Zyklen und bei der Umgestaltung der Anwendungslandschaft. 44 Im Folgenden werden die Grundlagen einer SOA und deren technologische Umsetzung beschrieben. Hierbei wird verstärkt auf die definierten Anforderungen einer flexiblen Abbildung von Geschäftsprozessen und einer entsprechenden Anwendungsintegration eingegangen. 4.1 Grundlagen SOA ist kein Produkt, keine Technologie oder Technologiestandard. SOA ist ein technologieunabhängiges IT-Architekturkonzept, nachdem die einfache und flexible Gestaltung von Softwaresystemen und die Wiederverwendung bestehen- 44 Vgl. [RHS05], S. 413.

39 Serviceorientierte Architekturen 25 der Services unterstützt werden sollen. 45 Dabei soll Interoperabilität umgesetzt werden, so dass die Verwendung einer Hard- und Software, einer Programmiersprache oder eines Betriebssystems unerheblich ist. 46 In der Literatur werden verschiedene Aspekte einer SOA unterschiedlich stark gewichtet. 47. Demzufolge existiert noch keine eindeutig normierte Architektur oder ein klar umrissenes Begriffsgebäude einer SOA. 48 Kernprinzip einer Serviceorientierten Architektur ist der Aufbau von Softwaresystemen aus lose gekoppelten Services (loose coupling). 49 Mehrere, weitgehend voneinander unabhängige, Services kapseln die Geschäftslogik eines Softwaresystems. 50 Dabei werden Funktionalitäten oder Ressourcen mit großer Ähnlichkeit (Kohäsion) so zusammen gefasst, dass sie gegenüber anderen Komponenten eine möglichst geringe Abhängigkeit aufweisen. Hierbei wird auch von einer Autonomie und Modularität von Services gesprochen. Durch diese lose Kopplung der Services können diese innerhalb neuer oder geänderter Geschäftsprozesse ohne großen technischen Aufwand ausgetauscht oder neu zusammengefügt werden. 51 Somit gestalten SOA, im Gegensatz zu bisher monolithischen Softwarearchitekturen, die Anpassung von Softwaresystemen auf geänderte Ausgangssituationen flexibler. 52 Ein Service ist eine Softwarekomponente mit einer klar definierten Leistung, die in unterschiedlichen Umgebungen mehrfach wieder verwendet werden kann. 53 Services kapseln dabei Daten und Anwendungslogik und sind tendenziell grobgranular geschnitten. Für jeden Service gibt es eine oder mehrere Schnittstellen und eine Servicebeschreibung (Service Description). Eine Schnittstelle (Interface) 54 stellt eine Funktionalität eines Services in Form von Operationen 45 Vgl. [RLPB07], S Vgl. [Melz07], S Vgl. [Melz07], S. 11, [KBS04], S. 57, [Erl06], S Vgl. [RHS05], S Vgl. [Melz07], S Vgl. [RLPB07], S Vgl. [RHS05], S Vgl. [RLPB07], S Vgl. [RLPB07], S Die Begriffe Schnittstelle und Interface werden synonym verwendet.

40 Serviceorientierte Architekturen 26 zur Verfügung, die vom Servicenutzer aufgerufen werden können. 55 Die eigentliche Implementierung eines Services, die vom Serviceanbieter durchgeführt wird, bleibt dem Servicenutzer gemäß einer Black-Box verborgen. 56 Eine Service Description stellt dabei eine formale Beschreibung der Schnittstelle dar. Diese sollte für alle Servicenutzer lesbar vorliegen und unabhängig von der Implementierung, der verwendeten Programmiersprache oder der auszuführenden Plattform sein. 57 Serviceschnittstellen und deren Beschreibung verkörpern zwischen dem Serviceanbieter und dem Servicenutzer stabile und verbindliche Kontrakte und dürfen nur in klar definierten Änderungszyklen oder nach explizierter Absprache angepasst werden. 58 Services werden vom Servicenutzer bei Bedarf dynamisch gesucht, gefunden und eingebunden. Hierbei handelt es sich um eine Bindung zur Laufzeit, d.h. zum Zeitpunkt der Übersetzung des Programms ist nicht bekannt welcher Service aufgerufen wird. Damit eine dynamische Bindung möglich ist, muss der Servicenutzer zunächst in der Lage sein, einen entsprechenden Service zu finden. Hierzu gehört zur Umsetzung einer SOA ein Verzeichnisdienst bzw. Registry, in dem zur Verfügung stehende Services vom Serviceanbieter registriert werden. 59 Im Registry werden Service Descriptions abgelegt, die zur Identifikation geeigneter Services sowie zu deren Nutzung benötigt werden. 60 Innerhalb einer SOA lassen sich somit drei verschiedene Rollen identifizieren: 61 Serviceanbieter Verzeichnisdienst/Registry 62 Servicenutzer Das Zusammenspiel zwischen Serviceanbieter, Registry und Servicenutzer findet nach einem einheitlichen Mechanismus, dem Find-Bind-Execute Paradigma 55 Vgl. [KBS04], S. 59f. 56 Vgl. [KBS04], S Vgl. [Melz07], S Vgl. [RHS05], S Vgl. [Melz07], S Vgl. [KBS04], S Vgl. [Melz07], S Die Begriffe Verzeichnisdienst und Registry werden synonym verwendet.

41 Serviceorientierte Architekturen 27 (siehe Abbildung 6), statt. Über diesen Mechanismus werden Services plattformunabhängig aufgerufen, wobei alle technischen Details verborgen bleiben. 63 Abbildung 6: Find-Bind-Execute Paradigma 64 Der Serviceanbieter veröffentlicht eine Service-Beschreibung im Registry (Schritt 1) und der Servicenutzer sucht einen Service im Registry (Schritt 2). Wird ein passender Service gefunden ( Find ), erhält der Servicenutzer einen Verweis auf einen Service, d.h. eine Adresse (Schritt 3). Der Funktionsaufruf wird somit an diese Adresse gebunden ( Bind ). Anschließend erfolgt vom Servicenutzer, unter der Verwendung eines Kommunikationsprotokolls, eine Abfrage der Beschreibung beim Serviceanbieter (Schritt 4). Abschließend erfolgt die Nutzung ( Execute ) des Services, indem Eingabeparameter an den Service übermittelt und Ausgabeparameter als Antwort auf den Aufruf zurückgeliefert werden (Schritt 5). 65 Hierbei ist es wichtig, dass für die technische und fachliche Standardisierung offene, plattformunabhängige und verbreitete Industriestandards verwendet werden. So muss der Service in der Lage sein, dem Servicenutzer seine Schnittstelle vollständig darzulegen. Zudem findet eine Kommunikation zwischen Servicenutzer und Serviceanbieter über ein Protokoll statt, das beiden bekannt sein muss. 66 Durch die Verwendung von Standards in dem Find-Bind-Execute Paradigma kann eine Interoperabilität in einer SOA erreicht werden Vgl. [Melz07], S. 12ff. 64 Vgl. [Melz07], S Vgl. [Melz07], S. 12ff. 66 Vgl. [Melz07], S Vgl. [Melz07], S. 22.

42 Serviceorientierte Architekturen 28 Zusammenfassend lassen sich somit die folgenden Merkmale einer SOA identifizieren, die in der Literatur jedoch unterschiedlich stark gewichtet werden: Lose Koppelung von Services Autonomie und Modularität von Services (Verteilheit) Formale Serviceschnittstellenbeschreibung (Service-Vertrag) Orientierung an Geschäftsprozessen (Bedarfsorientierung) Verzeichnisdienst Dynamisches Binden Verwendung von Standards / Interoperabilität Hierbei ist zu beachten, dass insbesondere der Punkt einer losen Koppelung für eine SOA von zentraler Wichtigkeit ist. 4.2 Services Für eine Konzeption einer SOA sind lose gekoppelte Services grundlegend. Diese werden im folgenden Abschnitt innerhalb verschiedener Schichten einer SOA klassifiziert. Anschließend werden methodische Vorgehen zur Serviceidentifikation beschrieben und ein praxisorientiertes Vorgehen identifiziert Klassifizierung von Services Services lassen sich in vier Servicearten, Basis-Services, Vermittlungs- Services, Prozess-Services und öffentliche Unternehmens-Services, unterscheiden. Ebenso sind in diesem Zusammenhang die Application Frontends zu nennen, die selbst keine Services, jedoch die aktiven Elemente einer SOA darstellen. Sie initiieren alle Geschäftsprozesse und empfangen schließlich deren Resultate. Beispiele sind grafische User Interfaces oder Batch-Prozesse. Die vier Servicearten können gemäß einer Schichtenarchitektur in vier Schichten (siehe Abbildung 7) gegliedert und gegeneinander abgegrenzt werden Vgl. [KBS04], S. 69ff.

43 Serviceorientierte Architekturen 29 Unternehmensschicht (Enterprise layer) Prozessschicht (Process layer) Vermittlungsschicht (Intermediary layer) Basisschicht (Basic layer) Abbildung 7: Schichten einer SOA Die Unternehmensschicht ist die oberste Schicht einer SOA und beinhaltet Application Frontends sowie öffentliche Unternehmens-Services, die zur Interaktion mit einer SOA dienen. Mittels Application Frontends interagiert ein Benutzer mit dem System. Unternehmens-Services stellen Schnittstellen für unternehmensübergreifende Integrationen der Services zur Verfügung. Diese Services können somit auch außerhalb des Unternehmens von z.b. Partnern oder Kunden genutzt werden. Hierzu sind jedoch besondere Mechanismen für Kommunikation, Sicherheit, Abrechnung und Monitoring von Service Level Agreements (SLA) zu berücksichtigen. Die Prozessschicht enthält prozessorientierte Services (Business Process Services), die andere Services zu Prozessen unterschiedlichster Granularität zusammenfasst. Somit ist es möglich, die Prozesslogik in einer Schicht zu kapseln und Geschäftsprozesse, soweit möglich, zu automatisieren. Die Komplexität dieser Business Process Services wird dabei vor z.b. Application Frontends durch eine einheitlich definierte Schnittstelle verborgen. Prozesszentrierte Services besitzen als einzige Serviceart einen Status. Hierzu können geeignete Laufzeitumgebungen wie Workflow- oder Prozess- Engines genutzt werden, die auf diese Anforderung einer Statusverwaltung hin ausgelegt sind. Die Vermittlungsschicht beinhaltet Business-Services in Form von Fassaden, Adaptern oder technologischen Gateways innerhalb einer SOA. Diese helfen, Unterschiede in der technischen Infrastruktur oder im Design von Services zu überbrücken. Ebenfalls können Business-Services genutzt werden, um weitere Funktionalität zu einem bestehenden Service hinzuzufügen, um somit einen Prozessschritt eines Geschäftsprozesses abzubilden. Business- Services kapseln sowohl Services der Basisschicht als auch Services ihrer eigenen Schicht, um die Funktionalität eines Prozessschrittes in der entsprechenden Granularität zu realisieren und stellen somit die entscheidene Schicht einer SOA dar und bedürfen besonderer Berücksichtigung. Die unterste

44 Serviceorientierte Architekturen 30 Schicht, die Basisschicht, enthält alle Basis-Services. Diese sind der Grundstein einer SOA und können in datenzentrierte und logikzentrierte Services unterschieden werden, deren Grenzen jedoch oftmals fließend sind. 69 Datenzentrierte Services, d.h. Entitiy Services, regeln den Zugriff auf unterschiedliche Daten, wie z.b. Datenbanken. Logikzentrierte Services, kapseln Geschäftslogik und stellen generische, wieder verwendbare Funktionalitäten für eine bestimmte Aufgabenstellung, wie z.b. die Berechnung eines voraussichtlichen Liefertermins zur Verfügung. Hierunter zählen auch Funktionalitäten von Backend- Systemen, die z.b. mittels Wrapper-Technologien als Basis-Services zur Verfügung gestellt werden oder direkt mithilfe einer entsprechenden Backend- Anwendung als Services publiziert werden. 70 Im Zuge der Umsetzung einer SOA ist es aber nicht zwingend notwendig, alle Schichten bzw. Servicearten einer SOA zu verwenden. Hierbei sollte beachtet werden, dass sich eine SOA auch in zwei oder drei Schichten realisieren lässt Serviceidentifikation Services stellen Funktionalitäten über eine stabile und verbindliche Schnittstelle zur Verfügung. Dabei bildet die Abgrenzung betriebswirtschaftlicher Funktionalitäten, die als Services bereitgestellt werden sollen, die Ausgangsbasis für eine Serviceidentifikation. 72 Funktionen mit großer Kohäsion sind so zusammenzufassen, dass sie gegenüber anderen Subsystemen eine möglichst geringe Abhängigkeit aufweisen. Services verfügen somit über eine gewisse Eigenständigkeit, wonach servicegeeignete Funktion über Wiederverwendungspotentiale verfügen. 73 Bisher hat sich kein einheitliches methodisches Vorgehen zur Serviceidentifikation etablieren können. Hierzu werden in der Literatur Methoden vorgeschlagen, die Services ausgehend von den fachlich-funktionalen Anforderung (Top-down) idenfizieren, von dem zur Verfügung stehenden Backend-Systemen (Bottom- 69 Vgl. [KBS04], S. 69ff. 70 Vgl. [KBS04], S. 70ff; [Erl06], S. 342f. 71 Vgl. [KBS04], S Vgl. [KlKn07], S Vgl. [KlKn07], S. 49.

45 Serviceorientierte Architekturen 31 up) ableiten oder einen Kompromiss zwischen den beiden Vorgehensweisen (Meet-in-the-middle) verfolgen. 74 Vor diesem Hintergrund werden im Folgenden die Methoden gegeneinander abgegrenzt und ein geeignetes Verfahren für eine EVU identifiziert. Im SOA-Kontext soll Geschäftslogik in lose gekoppelte Services gekapselt werden, um somit Anpassung und Neugestaltung von Geschäftsprozessen auf geänderte Ausgangssituationen flexibler zu gestalten. Hierbei sollen gleichartige Prozessschritte identifiziert, modularisiert und zusammengefasst werden. Somit kann durch eine Vermeidung von Redundanzen eine angestrebte Wiederverwendung von Diensten erreicht werden. Aus dieser Betrachtungsweise sollte die Ermittlung von Servicekandidaten auf der Basis eines geschäftsprozessorientierten Top-down-Ansatzes erfolgen. 75 Hierbei werden die Geschäftsprozesse eines EVU im Sollzustand analysiert, verfeinert und modularisiert. Eine solche Modularisierung kann über mehrere Ebenen erfolgen, bis sog. elementare Geschäftsprozessschritte definiert werden. Hierbei handelt es sich um Prozessschritte (Aktivitäten), die in ihrer Granularität Diensten auf Geschäftsebene entsprechen. Diese Dienste können sowohl Basis-Services (Basisschicht einer SOA) als auch Business-Services (Vermittlungsschicht einer SOA) repräsentieren. Business-Services können wiederum Services der Basisschicht als auch Services ihrer eigenen Schicht kapseln. 76 Andererseits bestehen in den meisten EVU verschiedene Backend-Systeme, wie z.b. ERP-, CRM, SCM oder Data-Warehouse-Systeme, deren bestehende Backend-Funktionalitäten und Daten genutzt und in eine serviceorientierte Architektur integriert werden sollen. Dieser Aspekt spricht wiederum für eine Bottom-up Ausrichtung bei der Serviceidentifikation, indem bestehende Funktionalitäten eines Backend-Systems in Basis-Services gekapselt werden. Aus technologischer Sicht sind somit die entsprechenden Funktionalitäten der Backend- Systeme mittels Wrapping-Technologien als Basis-Services zur Verfügung zu stellen. Viele Backend-Systeme verfügen mittlerweile auch über Funktionalitä- 74 Vgl. [KlKn07], S Vgl. [KlKn07], S. 49; [Erl06], S. 363ff. 76 Vgl. [HWSD07], S. 42f.

46 Serviceorientierte Architekturen 32 ten, um Backend-Funktionalitäten technologisch direkt als Web Services zu publuzieren. 77 Beide Ansätze, Top-down wie auch Buttom-up, haben jeweils ihre Berechtigung. Der Top-down-Ansatz aus Sicht der abzubildenden Geschäftsprozesse und einer fachlich-funktionalen Anforderung sowie der Buttom-up-Ansatz aus technologischer Sicht und einer Berücksichtigung bestehender Backend- Funktionalitäten. Die Konvergenz beider Ansätze soll in einen Meet-in-themiddle -Ansatz zu komplettieren versucht werden, um somit ein für den Erfolg versprechendes praxisorientiertes Vorgehen für ein EVU zu gewährleisten. Hierzu sind in einem ersten Schritt bestehende Backend-Systeme zu analysieren und mögliche Servicekandidaten zu identifizieren. In einem zweiten Schritt sind ausgehend vom Geschäftsprozess elementare Geschäftsprozessschritte zu modularisieren und entsprechende Services abzuleiten. In einem dritten Schritt wird analysiert, inwieweit notwendige Services durch bestehende Backend-Funktionalitäten abgebildet werden können und Neuentwicklungen notwendig sind (siehe Abbildung 8). 78 Abbildung 8: Serviceidentifikation Meet-in-the-middle-Ansatz Vgl. [KlKn07], S. 49; [Erl06], S. 363ff. 78 Vgl. [KlKn07], S. 49; [Erl06], S. 363ff; [HWSD07], S. 44f. 79 Vgl. [KlKn07], S. 49; [Erl06], S. 363ff; [HWSD07], S. 44f.

47 Serviceorientierte Architekturen Umsetzung serviceorientierter Architekturen Serviceorientierte Architekturen sind ein fachliches Konzept und technologieunabhängig, so dass Services in einer heterogenen Umgebung miteinander kommunizieren können. Fälschlicherweise werden Web Services oftmals mit SOA gleichgesetzt, Web Services beschreiben jedoch lediglich eine konkrete Implementierung einer SOA. Neben Web Services gibt es weitere Umsetzungsalternativen, wie z.b. mittels den EAI-Lösungen, CORBA oder DCOM. Das Problem dieser Ansätze ist die fehlende Generalität, da jede dieser Technologien entweder sprach-, betriebssystem- oder herstellerabhängig oder zu komplex ist. Web Services sind momentan die am weitest fortgeschrittene Technologie zur Umsetzung einer SOA und bieten Interoperabilität. 80 Somit sollen in dieser Arbeit Web Services zur technologischen Umsetzung einer SOA für ein EVU herangezogen werden. Unter dem Begriff Web Services werden verschiedene Standards subsumiert, die im Folgenden näher erläutert werden. In der Literatur finden sich zahlreiche Definitionen zum Begriff Web Service, die sich zum Teil sehr unterscheiden und jeweils verschiedene Aspekte unterschiedlich stark betonen. 81 Offizielle Konsortien wie das W3C 82, OASIS 83 und die Web Service Interoperability Organization (WS-I) 84, hinter denen namhafte Unternehmen, wie z.b. Microsoft, IBM und SAP, stehen, bemühen sich um eine einheitliche Definition und die Standardisierung der Web Service Thematik. An dieser Stelle soll die folgende Definition der W3C vorgestellt werden, da diese konkrete Technologien und Spezifikationen nennt: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards Vgl. [Melz07], S. 17, [RHS05], S. 414f. 81 Vgl. [Melz07], S Für weitere Informationen über W3C: 83 Für weitere Informationen über OASIS: 84 Für weitere Informationen über WS-I: 85 Vgl. [Melz07], S. 50.

48 Serviceorientierte Architekturen 34 Dieser Definition lässt sich entnehmen, dass ein Web Service ein Softwaresystem ist, das über ein Netzwerk aufgerufen werden kann. Ein Web Service besitzt eine Schnittstelle, die in WSDL beschrieben und über SOAP-Nachrichten erreichbar ist, wobei typischerweise webbasierte Standards wie HTTP/HTTPS und XML verwendet werden. Im Folgenden werden die maßgeblichen Standards SOAP, WSDL und UDDI/WS-Inspection vorgestellt. SOAP 86 ist ein standardisiertes Kommunikationsprotokoll für Web Services, mit dessen Hilfe sowohl eine synchrone als auch eine asynchrone Kommunikation zwischen Softwaresystemen erfolgen kann. Mit SOAP können innerhalb einer dezentralen, verteilten Umgebung leichtgewichtige Nachrichten über verschiedene zugrunde liegende Protokolle ausgetauscht werden. 87 Eine SOAP Nachricht ist dabei ein XML-Dokument, das aus drei Teilen, dem SOAP-Envelope, dem SOAP-Header und dem SOAP Body, besteht. Der SOAP-Envelope (wörtlich: (Brief-) Umschlag) bildet das Wurzelelement und kapselt die anderen beiden Teile der SOAP-Nachricht. 88 Der optionale SOAP-Header wird zum Transport von nicht zwingend notwendigen Angaben wie Sicherheitsinformationen genutzt. 89 Der SOAP-Body ist zwingend erforderlich, da dieser die zu übertragenden Informationen als XML-Dokument enthält. 90 Zur Verdeutlichung wird in der Abbildung 9 die Basisstruktur einer SOAP-Nachricht dargestellt. Abbildung 9: Basisstruktur einer SOAP-Nachricht SOAP war ursprünglich ein Akronym für Simple Object Access Protokoll. Da SOAP aber keinen Zugriff auf Objekte im objektorientierten Sinn darstellt, wurde seit der Verabschiedung der SOAP Version 1.2 des W3C die Erweiterung des Akronyms nicht mehr verwendet. 87 Vgl. [Melz07], S Vgl. [Melz07], S. 72f. 89 Vgl. [Melz07], S. 73f. 90 Vgl. [Melz07], S Vgl. [Melz07], S. 73ff.

49 Serviceorientierte Architekturen 35 SOAP-Nachrichten können anhand eines Übertragungsprotokolls, wie z.b. HTTP/S, SMTP oder JMS zwischen Serviceanbieter und Servicenutzer ausgetauscht werden. In der Praxis hat sich HTTP als Standardprotokoll für die Übertragung und TCP als Transportprotokoll von SOAP-Nachrichten durchgesetzt. 92 WSDL ist das Akronym für Web Service Description Language und ist eine standardisierte XML-basierte Sprache zur Servicebeschreibung. Im Gegensatz zur Interface Definition Language der OMG, die bei der Middleware-Lösung CORBA eingesetzt wird, erlaubt WSDL, beliebige Protokoll- und Transportschichten in der Servicebeschreibung festzulegen. Die Spezifikation der Schnittstelle mittels WSDL erfolgt hierbei in einem abstrakten und einem konkreten Teil. Somit lässt sich mithilfe einer WSDL-Datei eine Trennung von Schnittstelle und Implementierung erreichen. Im abstrakten Teil werden die Schnittstellen, deren Operationen sowie deren Ein- und Ausgabenachrichten mithilfe der Elemente Interface, Operation und Message unabhängig von einer konkreten Adresse und eines Kommunikationsprotokolls spezifiziert. Im Interface -Element werden eine Menge von Nachrichten mittels Message -Elementen spezifiziert, die ein Service empfangen oder senden kann. Diese Nachrichten werden in Operationen ( Operation - Elemente) gruppiert, welche spezifische Funktionalitäten repräsentieren. Operationen können dabei gemäß der in dieser Arbeit verwendeten WSDL Version in einer der folgenden vier Interaktionsmuster (Message Exchange Pattern) unterschieden werden: 94 Request/Response (in-out): Der Service empfängt vom Servicenutzer eine Eingabenachricht und sendet nach der Verarbeitung eine Antwort o- der Fehlermeldung an den Servicenutzer zurück. One-Way (in): Die Operation besteht aus dem Empfang einer Nachricht. Der Servicenutzer sendet eine Eingabenachricht an den Service. Ein Er- 92 Vgl. [Melz07], S Mithilfe der WSDL-Version 2.0 stehen des Weiteren die Interaktionsmuster Robust In-Only, In-Optional-Out, Robust Out-Only und Out-Optional-In zur Verfügung. Für weitere Informationen wird auf die folgende Spezifikation verwiesen: W3C (Hrsg.): Web Services Description Language (WSDL) Version 2.0 Part 2: Message Exchange Patterns. 94 Vgl. [Melz07], S. 102ff.

50 Serviceorientierte Architekturen 36 gebnis wird dabei nicht erwartet. Es besteht somit auch keine Möglichkeit, den Servicenutzer über Fehler zu informieren. Notification (out): Der Service versendet eine Nachricht an den Servicenutzer. Solicit-Response (out-in): Der Service versendet eine Nachricht an den Servicenutzer, auf die von dem Servicenutzer geantwortet wird. Im konkreten Teil werden die technischen Details anhand der Festlegung der Bindung an ein Kommunikationsprotokoll mithilfe des Binding -Elements und der Spezifikation der Adressen mithilfe der Service - und Endpoint -Elemente konkretisiert. Ein Endpoint -Element repräsentiert eine konkrete Softwarekomponente, die sich hinter einer bestimmten URI verbirgt. Ein Service -Element gruppiert Endpunkte ( Endpoint -Elemente), die eine gemeinsame Schnittstelle implementieren. Mithilfe des Binding -Elements kann, obwohl Web Services typischerweise unter Verwendung des SOAP-Protokolls implementiert werden, die abstrakte Beschreibung der Schnittstelle auch auf ein anderes Kommunikationsprotokoll als SOAP abgebildet werden, sofern das im konkreten Teil entsprechend formuliert wird. 95 Zur Verdeutlichung wird in Abbildung 10 die Basisstruktur einer WSDL-Datei in der Version 1.1 dargestellt. Abbildung 10: Basisstruktur einer WSDL-Datei 96 Um die vom Web Service angebotenen Dienste nutzen zu können, müssen die jeweiligen Servicebeschreibungen in Form von WSDL Dokumenten bzw. deren Lokalisierung bekannt sein. Die daraus bedingte Publikation und das Auffinden von Services in einer standardisierten Service Registry soll z.b. durch die Web 95 Vgl. [Melz07], S. 102ff. 96 Vgl. [Melz07], S. 104ff.

51 Serviceorientierte Architekturen 37 Services Inspection Languages (WS-Inspection) oder durch die Universal Description, Discovery and Integration (UDDI) ermöglicht werden. 97 WS-Inspection beschreibt ein Konzept von Spezifikation von IBM und Microsoft. Hierbei werden von wenigen Anbietern angebotene Web-Services über WS- Inspection-Dokumente in dezentralisierten Verzeichnissen veröffentlicht, welche Verweise auf Web-Service-Beschreibungen wie WSDL-Dokumente oder auch auf UDDI-Einträge enthalten, in denen die Dienstbeschreibungen vorliegen. Auch können UDDI-Einträge auf WS-Inspection-Einträge verweisen. Somit ist es durch WS-Inspection möglich, eine Verbindung zwischen mehreren dezentralen Verzeichnissen herzustellen. 98 UDDI beschreibt ein Konzept von Ariba, Microsoft und IBM. Seit 2005 wird die Standardisierung und Weiterentwicklung von UDDI von der Organization for the Advancement of Structured Information Standards (OASIS) übernommen. UDDI ist auf wenige, zentralisierte Verzeichnisse mit vielen Anbietern und Diensten ausgelegt, wobei über standardisierte APIs spezifiziert wird, wie Services gefunden werden können. Hierbei wird auf eine Beschreibung des entsprechenden Services zurückgegriffen, wobei sich diese in drei Abschnitte, White-, Yellow- und Green-Pages, gliedert. 99 White-Pages: Informationen zum Serviceanbieter und Kontaktdaten. Yellow-Pages: Branchenverzeichnis zur Suche eines konkreten Anbieters. Verweise auf die White-Pages. Green-Pages: Technische Informationen zum angebotenen Service. Das unter Kapitel 3.1 vorgestellte Find-Bind-Execute Paradigma einer SOA kann durch die Verwendung der vorgestellten Standards, SOAP, WSDL und UDDI/WS-Inspection, konkretisiert werden (siehe Abbildung 11) Vgl. [Melz07], S Vgl. [Melz07], S. 128ff. 99 Vgl. [Melz07], S. 131ff. 100 Vgl. [Melz07], S. 52.

52 Serviceorientierte Architekturen 38 Abbildung 11: Umsetzung einer SOA durch Web Services 101 Ein Serviceanbieter erstellt zunächst eine WSDL-Schnittstellenbeschreibung in Form eines XML-Dokuments. Dieses WSDL-Dokument wird anschließend in einem UDDI- oder WS-Inspection-basierten Verzeichnisdienst veröffentlicht (Schritt 1). Der Servicenutzer sucht in der Service-Registry nach einem entsprechenden Service (Schritt 2). Hierzu müssen WS-Inspection- oder UDDI- Spezifikationen und eine SOAP-Schnittstelle zur Verfügung stehen. Hat der Servicenutzer den für sich geeigneten Web Service gefunden, kann er die Schnittstellenbeschreibung in Form eines WSDL-Dokuments anfordern. Der Verzeichnisdienst liefert hierzu eine Referenz (URI) auf das WSDL-Dokument, welches der Servicenutzer im folgenden Schritt anfordert (Schritt 4). Anschließend können mithilfe der WSDL-Beschreibung die Programmteile zur Kommunikation mit dem Service des Serviceanbieters erzeugt werden, welche die Anwendung des Servicenutzers in die Lage versetzt, mit der Anwendung des Serviceanbieters mittels SOAP zu kommunizieren (Schritt 5) Asynchrone Kommunikation Alle Serviceoperationen, die Servicenutzer aufrufen, sind in synchrone und a- synchrone Operationen zu unterscheiden. Bei einem synchronen Serviceaufruf bleibt ein Servicenutzer gesperrt, bis dieser eine Antwort vom Serviceprovider 101 Vgl. [Melz07], S Vgl. [Melz07], S. 52f.

53 Serviceorientierte Architekturen 39 erhält. 103 Beispielhaft wird in Abbildung 12 ein synchroner Web Service-Aufruf dargestellt. Abbildung 12: Synchroner Web Service-Aufruf Asynchronität ist eine Voraussetzung für lang laufende Geschäftsprozesse, da bei einem asynchronen Aufruf eines Services der Servicenutzer nicht wartet, bis eine Antwort von dem Serviceanbieter eintrifft, sondern seine Arbeit unmittelbar fortführen kann. Hierdurch werden keine Ressourcen, wie Threads oder Datenbankverbindungen, über einen längeren Zeitraum exklusiv blockiert. 104 Hinsichtlich der Umsetzung von asynchronen Services, die technologisch Web Services repräsentieren, gibt es unterschiedliche Interaktionsmuster, wie z.b. Fire and Forget, Callback oder Polling, die standardmäßig z.b. von JAX-WS- Webservices unterstützt werden. 105 JAX-WS (Java API for XML - Web Services) ist eine Java API zum Erstellen und Konsumieren von Web Services. Die entsprechenden Interaktionsmuster werden im Folgenden kurz vorgestellt. Bei Fire and Forget wird ein Web Service mittels einer Einwegoperation (oneway-operation) vom Servicenutzer (Client) aufgerufen. Hierbei wird keine Antwort vom Service erwartet und der Client wird während der Ausführung der Web-Service-Operation nicht blockiert. Eine typische Einweg-Operation ist eine Bestätigung. Diese lose Kopplung beinhaltet jedoch auch, dass der Servicenutzer keine Information erhält, ob die Operation erfolgreich durchgeführt werden konnte oder ob es zu Fehlern während der Ausführung kam. So kann bei Einwegoperationen keine Zuverlässigkeit der Zustellung und Verarbeitung gewährleistet werden. 103 Vgl. [Melz07], S Vgl. [Melz07], S Vgl. SUN (Hrsg.), The Java API for XML-Based Web Services (JAX-WS) 2.1, S. 61ff.

54 Serviceorientierte Architekturen 40 Bei Polling kann ein Client eine synchrone Web-Service-Operation (start_request-operation) anstoßen und ein Antwortobjekt mit einer eindeutigen ID empfangen. Diese ID wird anschließend verwendet, um den Status der Operation zu überwachen, zu bestimmen, wann die Operation abgeschlossen wurde (check_status-operation) und die Ergebnisse (get_results-operation) abzurufen. Somit kann, sobald der Dienst antwortet, das Ergebnis abgerufen werden. Die Interaktionen erfolgen somit ausschließlich vom Servicenutzer. Dieses Interaktionsmuster produziert jedoch eine große Anzahl von Nachrichten, was die Netzwerkverbindungen und die Systemperformanz negativ beeinflusst. Um den Kommunikationsaufwand zu reduzieren, kann das Callback - Interaktionsmuster angewandt werden. Hierbei wird einer Einwegoperation neben den Aufrufparametern eine Referenz (URI) übergeben, an die der Service die asynchrone Antwort senden kann (Callback). Der Servicenutzer stellt hierfür einen Callback-Handler bereit, der eine eingehende asynchrone Antwort oder Fehlermeldung entgegen nimmt, akzeptiert, verarbeitet und an den eigentlichen Servicenutzer weiterleitet. 106 Dieses Entwurfsmuster bringt jedoch aufgrund der Umsetzung eines Callback-Handlers auf Seiten des Clients eine zusätzliche Komplexität mit sich. Um die vorgestellten Methoden asynchroner Kommunikation mittels Web Services hinsichtlich zuverlässiger Nachrichtenübermittlung zu unterstützen, stehen entsprechende Spezifikation, wie z.b. WS-Addressing, WS-Reliable Messaging oder WS-Reliability aus dem Kontext von WS-* zur Verfügung. Bei WS- Addressing werden im Header jeder SOAP-Nachricht zusätzliche Metainformationen über den Absender und den Empfänger der Antwort sowie den Empfänger von Fehlermeldungen eingefügt. Somit besteht eine flexible Festlegung der Kommunikationsteilnehmer. WS-Reliable Messaging und WS-Reliabilit ermöglichen eine garantierte Zustellung, zweifache Nachrichteneliminierung und einen geordneten Nachrichtenaustausch, indem die eigentliche Kommunikation mit- 106 Vgl. [WeOs07], S. 26f.

55 Serviceorientierte Architekturen 41 tels Vermittler auf Seiten des Servicenutzers und des Serviceanbieters erfolgt. 107 Neben den hier vorgestellten Interaktionsmustern Fire and Forget, Callback und Polling kann eine asynchrone Kommunikation auch mithilfe eines geeigneten Nachrichtensystems, aufbauend auf eine MOM, mittels Queues oder Topics erfolgen. Die Bereitstellung eines Nachrichtensystems innerhalb einer SOA ist dabei Bestandteil einer entsprechenden Infrastruktur und wird im Kapitel 4.5 näher beschrieben Transaktionssicherheit Unter einem Geschäftsprozess kann formal eine Transaktion oder eine Folge von Transaktionen verstanden werden. So kann ein Geschäftsprozess in einer SOA aus einer Folge von Diensten bestehen, die transaktionales Verhalten nach den vier ACID-Eigenschaften (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit) gewährleisten müssen. Nach der Darstellung einer konkreten technologischen Umsetzung einer serviceorientierten Architektur am Beispiel von Web Services geht dieser Abschnitt auf transaktionales Verhalten beim Aufruf von Diensten unter Verwendung von Web Service zur technologischen Umsetzung ein. Im Bereich der Transaktions-Spezifikationen für Web Services herrscht im Gegensatz zu SOAP oder WSDL, die auf breiter Ebene akzeptiert und verbreitet sind, noch Uneinigkeit. Zurzeit existieren drei Spezifikationen für Transaktionssicherheit von Web Services: 108 WS-Composite Application Framework (WS-CAF) u.a. von Sun Microsystems und Oracle Business Transaction Protokoll (BTP) von OASIS WS-Transaction (WS-TX) u.a von IBM, Microsoft und BEA 107 Vgl. [Melz07], S. 89ff. 108 Vgl. [Melz07], S. 265.

56 Serviceorientierte Architekturen 42 Seit der ersten Veröffentlichung wurden die drei Spezifikationen stetig weiter entwickelt und unterscheiden sich heute nur noch in wenigen Punkten. In der Praxis ist zu beobachten, dass WS-TX häufiger vertreten ist, was unter anderem darin begründet liegt, dass diese Spezifikationen u.a. von IBM und Microsoft entwickelt wurden und nun in den eigenen Produkten integriert werden. 109 Im Rahmen dieser Arbeit wird der Fokus auf WS-Transaktion gelegt, da eine Vertiefung aller drei Spezifikation den Rahmen dieser Thesis übersteigen würde. WS-TX ist seit 2005 als offizieller OASIS-Standard anerkannt und liegt zurzeit in der Version 1.1 vor. WS-TX gliedert sich in die drei Unterspezifikationen WS-Coordination, WS-Atomic-Transaction und WS-Business-Activity auf. Diese drei Teil-Spezifikationen werden im Weiteren genauer dargestellt. 110 WS-Coordination ist ein erweiterbares Framework zum Etablieren der Koordinierung zwischen Web Services und eines Koordinators. Die wesentlichen Elemente sind hierbei der Coordination Service und der Coordination Context. Der Coordination Service entspricht einem sog. Koordinator, der die Steuerung mehrer Web Services in einer Transaktion übernimmt. Der Coordination Service besteht aus den Services Activation Service, Registration Service und den Protokoll Services. Der Activation Service nimmt Anfragen für eine neue Transaktion entgegen und erstellt einen Coordination Context, der auf XML basierend u.a. eine eindeutige Transaktionsnummer (ID) enthält und übergibt diesen an den anfragenden Dienst. Der Registration Service registriert einen Dienst zu einer bereits laufenden Transaktion. Die Protokoll Services sind protokollspezifisch und jeder Koordinierungstyp, wie WS-Atomic-Transaction oder WS-Business-Activity, kann mehrere Koordinationsprotokolle beinhalten. Somit könnte jede Phase eines sog. Zwei-Phasen-Commit-Protokolls (2PC-Protokolls) als eigenes Protokoll aufgefasst werden. 111 WS-Atomic-Transaction basiert auf WS-Coordination und beschreibt, wie sich Transaktionskonzepte, wie z.b. das 2PC-Protokoll, auf Web Services übertragen lässt. Hierbei wird in der Regel eine Ressource exklusiv für eine kurze Zeit- 109 Vgl. [Melz07], S Vgl. [Melz07], S Vgl. [Melz07], S

57 Serviceorientierte Architekturen 43 dauer gesperrt, um im Falle eines Fehlers einen vollständigen Rollback, wie im Datenbank-Umfeld bekannt, auszuführen. WS-Atomic-Transaction besteht aus den drei Koordinationsprotokollen Completion, Volatile2PC und DurablePC. Das Completion -Protokoll ermöglicht einem Dienst, dem Koordinator mitzuteilen, dass dieser eine bestimmte Transaktion beenden oder dem Dienst den Ausgang der Transaktion mitteilen soll. Mit dem Volatile2PC - und dem DurablePC -Protokoll unterscheidet WS-AT zwischen zwei 2PC-Protokollen. Das DurablePC -Protokoll entspricht im Wesentlichen dem klassischen 2PC- Protokoll und wird für Dienste eingesetzt, die persistente Ressourcen verwalten. Das Volatile2PC -Protokoll realisiert die Fähigkeit, mit Diensten umzugehen, die flüchtige Ressourcen, wie z.b. Caches verwalten. Hierbei beginnt der Koordinator, nachdem er zur Beendigung der Transaktion die Commit-Nachricht erhalten hat, das Volatile2PC -Protokoll auszuführen. Dabei sendet der Koordinator zunächst eine Prepare-Nachricht an alle für dieses Protokoll registrierten Dienste. Diese werden somit aufgefordert, die im Zwischenspeicher befindlichen Daten an den persistenten Speicherungsmechanismus zu übergeben. Nachdem alle Dienste den Koordinator mit einer Prepared-Nachricht über den Erfolg der Operation informiert haben, ist das Volatile2PC -Protokoll abgeschlossen, wobei Dienste des flüchtigen 2PC-Protokolls nicht zwingend über den Ausgang der Transaktion informiert werden müssen. Bei einem DurablePC -Protokoll ist die Transaktion erfolgreich, wenn der Koordinator nach dem Versenden der Prepare -Nachricht nur Prepared - oder ReadOnly - Nachrichten der beteiligten Dienste zurück erhält. In diesem Fall benachrichtigt er die teilnehmenden Dienste über den erfolgreichen Abschluss der Transaktion mit einer Commit -Nachricht. Bei einer Cancel -Nachricht eines Dienstes hängt die Reaktion des Koordinators von der Art der Transaktion ab. Bei einer atomaren Transaktion sendet der Koordinator eine Abort -Nachricht, was dazu führt, dass alle Dienste ihre Arbeitsschritte (Operation) rückgängig machen müssen. Bei einer nicht notwendigerweise atomaren Transaktion kann der Koordinator eine Geschäftslogik aufrufen, um zu entscheiden, ob der Dienst der Cancel -Nachricht für die Transaktion entscheidend war und falls nicht, dennoch eine Commit -Nachricht an die teilnehmenden Dienste sendet. In

58 Serviceorientierte Architekturen 44 Abbildung 13 ist das Zustandsdiagramm der Volatile2PC- und Durable2PC- Protokolle gemäßt der WS-Atomic-Transaction Spezifikation dargestellt. 112 Abbildung 13: Zustandsdiagramm Volatile2PC und Durable2PC 113 Dienste, die an einer WS-Atomic-Transaction beteiligt sind, werden während der Transaktion exklusiv gesperrt, somit sollte eine entsprechende Transaktion nur einen kurzen Zeitraum umfassen. In einer asynchronen Web Service Umgebung kann eine Transaktion jedoch auch mehrere Tage umfassen und in einem solchen Fall ist das Sperren der beteiligten Ressourcen eher ungeeignet. Hierzu ist die Unterspezifikation WS-Business-Activity konzipiert worden. Die WS-Business-Activity basiert ebenfalls auf WS-Coordination und soll dazu eingesetzt werden, mehrere kurz laufende WS-Atomic-Transactions zu einer lang laufenden Transaktion zu koppeln. Hierbei wird zwischen den Protokollen BusinessAgreementWithCoordinatorCompletion und BusinessAgreement- WithParticipantCompletion unterschieden. Beim BusinessAgreement- WithCoordinatorCompletion-Protokoll signalisiert der Koordinator, das keine weiteren Aufgaben zu erwarten sind. Beim Einsatz des BusinessAgreement- WithParticipantCompletion-Protokolls entscheidet der eingebundene Dienst selbständig, wann seine Aufgabe beendet ist. Grundsätzlich darf eine WS- Business-Activity, die eher lang laufend ist, selbst keine Ressourcen exklusiv sperren. Nur eine kurz laufende WS-Atomic-Transaction, die Bestandteil einer Business-Activity ist, darf Ressourcen über eine kurze Zeit sperren. An einer 112 Vgl. [Melz07], S , S Vgl. [Melz07], S. 270.

59 Serviceorientierte Architekturen 45 WS-Business-Activity beteiligte Dienste werden sofort durchgeführt, wobei Änderungen an Daten permanent sind. Im Falle eines Fehlers bei der Ausführung einer Business-Activity müssen alle bereits erfolgreich ausgeführten Operationen innerhalb einer Business-Activity-Scope 114 mithilfe eines definierten Compensation-Handler 115 kompensiert werden. Kompensation bedeutet, dass entsprechende Operationen aufgerufen werden, die Effekte einer bereits erfolgreich beendeten Operation (auch im Status completed) rückgängig machen. Zur Verdeutlichung ist in Abbildung 14 das Zustandsdiagramm der WS- Business-Activity BusinessAgreementWithCoordinatorCompletion-Protokoll gemäßt der WS-Atomic-Transaction Spezifikation dargestellt. 116 Abbildung 14: Zustandsdiagramm WS-Business-Activity 117 Kompensation bedeutet für den Entwurf von Diensten, dass zu den eigentlichen fachlichen Operationen, explizit kompensatorische Operationen implementiert und innerhalb von entsprechenden Web Services zur Verfügung gestellt werden müssen, um bereits durchgeführte Modifikationen auszugleichen. Damit ähneln sie dem SAGA-Konzept, indem gekettete Transaktionen mit der Möglichkeit zur Kompensation dargestellt werden. Hierbei ist jedoch zu beachten, dass eine komplette Kompensation unter Umständen nicht möglich ist und lediglich die Auswirkungen der Transaktion begrenzt werden können. Dies ist z.b. der Fall, sofern auf veränderten Daten, die kompensiert werden sollen, bereits aufwän- 114 Ein Business-Activity-Scope kann z.b. mit einem Java-try-Block verglichen werden. 115 Ein Comensation Handler kann z.b. mit einem Java-catch-Block verglichen werden. 116 Vgl. [Melz07], S Vgl. [Melz07], S. 272.

60 Serviceorientierte Architekturen 46 dige Operationen, wie z.b. eine statistische Analyse, Data Mining oder OLAP, ausgeführt oder an den veränderten Daten wiederum Änderungen vorgenommen wurden. Kompensation einer Operation bedeutet jedoch, einen Zustand herzustellen, der identisch ist mit einem Zustand, bei dem die Operation niemals ausgeführt wurde. Somit kann der Umfang einer nötigen Kompensation sehr langläufig werden, so dass es erheblichen Aufwand darstellt, alle Änderungen rückgängig zu machen. Kann eine Kompensation dabei nicht erfolgreich abgeschlossen werden, ist letztendlich ein manueller Eingriff erforderlich. Eine exklusive Sperrung einer Ressource ist somit die effektivste Methode zur Abbildung einer Transaktionssicherheit. Andere Alternativen, wie z.b. die Kompensation von Operationen im Sinne der WS-Business-Activity, können einen erheblichen Aufwand verursachen oder beinhalten zudem weitere Schwachstellen. Jedoch könnte das exklusive Sperren zur Aushungerung anderer Transaktionen oder Prozessen führen, die ebenfalls auf die gesperrte Ressource zugreifen wollen. 118 Abschließend lässt sich zusammen fassen, dass derzeit kein einfaches Transaktionsverfahren für langlaufende Web Services existiert. Somit sollten Services möglichst atomar, isoliert und grobgranular geschnitten und verteilte langläufige Transaktionen über mehrere Services möglichst vermieden werden. Sollten fachliche Anforderungen den Aufruf mehrerer Services in einer Transaktion notwending gestalten, so ist für kurz laufende Transaktionsverfahren das WS-Atomic-Transaction zu wählen. Bei langlaufenden Prozessen ist trotz Schwachstellen das WS-Business-Activity zu nutzen, wobei kompensatorische Services zu entwerfen und einzubinden sind. Dies ist darin begründet, dass es zurzeit kein geeigneteres, einfacheres Verfahren gibt. Bei der Umsetzung einer Transaktionsicherheit mittels WS-TX ist jedoch im Vorfeld zu prüfen, dass alle beteiligten Servicenutzer und Serviceanbieter die notwendigen Standards unterstützten. Des Weiteren sollte aufgrund einer hohen Komplexität die Umsetzung durch entsprechende Tool-Unterstützung konfigurativ behandelt werden können. 118 Vgl. [Melz07], S

61 Serviceorientierte Architekturen Orchestrierung von Geschäftsprozessen Geschäftsprozesse bestehen meistens aus mehr als einem Service. Somit muss gewährleistet sein, dass Geschäftsprozesse durch eine Komposition von Services abgebildet werden können. 119 Die Komposition von Geschäftsprozessen beinhaltet zwei voneinander unabhängige Formen: Choreographie und Orchestrierung. Choreographie beschreibt die Aufgaben und die Kooperation mehrerer Prozesse unter dem Aspekt der Zusammenarbeit. Hierbei handelt es sich um ein beschreibendes Protokoll, das die Sequenz der Nachrichten darstellt, die zwischen Prozessen ausgetauscht werden. Orchestrierung beschreibt die ausführbaren Aspekte eines Geschäftsprozesses aus der Sicht eines Prozesses. Hierbei handelt es sich um ein ausführbares Protokoll, welches beschreibt, in welcher Reihenfolge und mit welchen Aufrufparametern die einzelnen Services auszuführen sind. 120 Im weiteren Verlauf wird somit auf die Orchestrierung von Geschäftsprozessen eingegangen, um somit Web Services in einer bestimmten Reihenfolge gemäß eines Geschäftsprozesses auszuführen. Viele IT-Unternehmen haben standardisierte Sprachen zur Orchestrierung von Geschäftsprozessen entwickelt, da diese im Gegensatz zur Implementierung der Prozesslogik einige Vorteile bieten. So ermöglicht z.b. die Verwendung von entsprechend umfangreichen Modellierungstools eine Abstraktion von technologischen Details und gewährleistet somit die leichtere Lesbar- und Änderbarkeit von Prozessen. 121 Durch eine parallele Entwicklung von verschiedenen IT- Unternehmen und Konsortien sind eine Vielzahl von Prozessbeschreibungssprachen, wie z.b. XLang, BPML, WSFL, WSCI, WS-CDL oder WS-BPEL entstanden. 122 WS-BPEL hat sich hierbei als De-facto-Standard zur Orchestrierung von Geschäftsprozessen auf Basis von Web Services durchgesetzt. 123 WS-BPEL ist das Akronym für Web Service - Business Process Execution Language und ist aus einem Zusammenschluss der Sprachen XLang und WSFL 119 Vgl. [Melz07], S Vgl. [Melz07], S. 226f. 121 Vgl. [BaRü07], S Vgl. [Melz07], S Vgl. [TLD07], S. 43.

62 Serviceorientierte Architekturen 48 entstanden. 124 WS-BPEL liegt dabei als ein OASIS Standard zuzeit in der Version 2.0 vor. 125 Die teilweise verwirrenden, unterschiedlichen Bezeichnungen dieser Prozessbeschreibungssprache in Form von BPEL, BPELWS, BPEL4WS oder WS-BPEL sind durch die historische Entwicklung der Sprache bedingt. Im Verlauf dieser Arbeit wird ausschließlich die aktuelle Bezeichnung WS-BPEL verwendet. WS-BPEL basiert wie SOAP, WSDL oder UDDI vollständig auf XML. Mithilfe von standardisierten und semantisch festgelegten Sprachelementen wird die Ausführungsreihenfolge der bereitgestellten synchronen wie auch asynchronen Web-Services und somit der Nachrichtenaustausch koordiniert. Zudem stellt WS-BPEL den definierten Prozess selbst als Web Service mit einem WSDL- Dokument zur Schnittstellenbeschreibung bereit. 126 Um einen Web Service in einen WS-BPEL-Prozess einzubinden, ist mithilfe des Elements partnerlinks zu definierern, wie der WS-BPEL-Prozess mit dem Web Servic kommuniziert. Für jede Verbindung ist dabei festzulegen, welche Rolle der eigene Prozess (myrole) und welche Rolle der externe Partner (partnerrole) übernimmt. Hierbei kapselt das optionale Element (partners) alle Partnerbeziehungen, um diese gebündelt darzustellen. 127 Des Weiteren ist in der entsprechenden WSDL-Beschreibung das Konstrukt partnerlinktype anzufügen, das in seiner Definition auf den PortType der WSDL, in welchem alle zur Verfügung gestellten Operationen gebündelt sind, verweist. Das Binden an den konkreten Web Service kann zum Modellierungszeitpunkt, statisch während des Installierens oder dynamisch zur Laufzeit erfolgen. 128 Das Wurzelelement eines WS-BPEL-Dokuments ist immer process und enthält mindestens eine Aktivität. 129 Zur Verdeutlichung wird in der Abbildung 15 die Basisstruktur eines WS-BPEL-Dokuments dargestellt. 124 Vgl. [Melz07], S Vgl. OASIS (Hrsg.), Members Approve WS-BPEL as OASIS Standard, S Vgl. [ThHa07], S Vgl. [Melz07], S. 243ff. 128 Vgl. [ThHa07], S Vgl. [Melz07], S. 232.

63 Serviceorientierte Architekturen 49 Abbildung 15: Basisstruktur eines WS-BPEL-Dokuments 130 Innerhalb des process - Elements werden die entsprechenden Aktivitäten beschrieben, die zur Ausführung des Prozesses notwendig sind. Diese Aktivitäten lassen sich in elementare und strukturierte Aktivitäten unterscheiden. 131 Im Folgenden werden die wichtigsten Elemente des WS-BPEL-Schemas näher untersucht. Zur vollständigen Definition der WS-BPEL-Elemente wird auf die Spezifikation 132 verwiesen. Elementare Aktivitäten stellen Operationen dar, die für den Aufruf von Diensten oder für die Manipulation der Daten benutzt werden. Die elementaren Aktivitäten dürfen dabei keine weiteren Aktivitäten enthalten. Zu den elementaren Aktivitäten zählen z.b. folgende: 133 <invoke>: Aufruf von Operationen, die ein Web Service zur Verfügung stellt; request/response (synchroner Aufruf) oder request-operation (asynchroner Aufruf) <receive>: Spezifiziert Nachrichtenempfang eines Partners (Service). <reply>: Versendet Antwort an Partner (Service) als Folge auf receive. <empty>: Dient zur Synchronisation von nebenläufigen Aktivitäten und zum Einfügen späterer Aktivitäten. 130 Vgl. [Melz07], S Vgl. [Melz07], S Für weitere Informationen über die WS-BPEL 2.0 Spezifikation : OASIS (Hrsg.): Web Sevices Business Process Execution Language Version Vgl. [Melz07], S. 232ff.

64 Serviceorientierte Architekturen 50 <assign>: Manipulation von Variablenwerten (kopiert, verändert und erzeugt Daten). <wait>: Eine bestimmte Zeit abwarten. <throw>: Beschreibung eines Fehlers und Fehlerbehandlung. <terminate>: Beenden einer Prozessinstanz. Eine strukturierte Aktivität definiert eine kausale Ordnung auf elementaren Aktivitäten und legt den Ablauf eines Prozesses eindeutig fest. Diese können dabei beliebig verschachtelt und miteinander kombiniert werden. Die Ordnung kann z.b. über folgende strukturierte Aktivitäten festgelegt werden: <sequence>: Eine sequentielle Ausführung von Aktivitäten; alle elementaren Aktivitäten, die in dem <sequence>-element enthalten sind, werden sequentiell ausgeführt. <while>: Eine while-schleife; iterative Ausführung von Aktivitäten, bis die Bedingung erfüllt ist. <Repeat-Until>: Bedingung wird im Gegensatz zu einer while-schleife erst nach der Ausführung des Schleifenkörpers überprüft. Die Aktivität innerhalb der Schleife wird somit mindestens einmal ausgeführt. <foreach>: Wiederholung einer Aktivität, bis die Bedingung erfüllt ist. <if-then-else>: Auswahl eines Kontrollpfades; die Auswahl erfolgt dabei über die angegebenen Bedingungen. <pick>: Ausführung einer Aktivität, die von einem Ereignis abhängig ist. <flow>: Eine serielle, parallele, synchronisierende oder beliebige Abfolge von Aktivitäten. Da der WS-BPEL-Standard selbst keine graphische Darstellung der modellierten Prozesse definiert, ist hierzu die Business Process Modeling Notation (BPMN) vorgesehen. Die BPMN spezifiziert mit dem Business Process Diagramm (BPD) ein Geschäftsprozessdiagramm. Dieses Diagramm ermöglicht eine Modellierung von Geschäftsprozessen und sieht Transformationsregeln

65 Serviceorientierte Architekturen 51 vor, anhand derer aus einem BPMN-Modell eine formale Prozessbeschreibungssprache, wie z.b. WS-BPEL, generiert werden kann. 134 Nachdem ein Geschäftsprozess mithilfe von WS-BPEL definiert wurde, dient das erstellte WS-BPEL-Dokument als ausführbarer WS-BPEL-Prozess, welcher zur Unterstützung eines Geschäftsprozesses Web Services aufruft. Der WS- BPEL-Prozess kann durch eine Komponente, d.h. durch eine Prozess-Engine zur Ausführung gebracht werden. Die Komponente muss eine Schnittstelle zur Übernahme des WS-BPEL-Dokuments besitzen und die darin enthaltenen Anweisungen ausführen können Transaktionen und Fehlerbehandlung in WS-BPEL Ein WS-BPEL Prozess kann aus mehreren synchronen und asynchronen Web Service-Aufrufen bestehen und aufgrund von Nutzerinteraktionen und rechnerintensiven Aufgaben über eine lange Zeitspanne hinweg bestehen. Transaktionen, welche die vier ACID-Eigenschaften (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit) erfüllen, sind nicht möglich, da Sperrungen nicht über lange Zeiträume gehalten werden können. Dies bedeutet, dass fehlgeschlagene Transaktionen innerhalb von WS-BPEL-Prozessen rückgängig gemacht werden müssen. 136 Hierbei werden Teile der Spezifikation WS-Business-Activity (siehe Kapitel 4.3.1) innerhalb der WS-BPEL Spezifikation verwendet. Innerhalb des optionalen WS-BPEL-Konstruktes Scope können komplexe strukturierte Aktivitäten abgebildet werden, welche beliebig tief geschachtelt sind. Somit können innerhalb eines Scope-Konstruktes mehrere Aktivitäten in einem gemeinsamen Kontext gebündelt und zu einer transaktionalen Einheit zusammengefasst werden. Scopes beinhalten Variablen zur Speicherung von Daten, faulthandler, eventhandler oder compensationhandler. Somit können mithilfe des compensationhandlers vorangegangene gebündelte Aktivitäten kor- 134 Vgl. OMG (Hrsg): Buisness Process Modeling Notation (BPMN) Specification, S Vgl. [Melz07], S Vgl. [ThHa07], S. 46.

66 Serviceorientierte Architekturen 52 reliert werden. Zum expliziten Aufruf des compensationhandler stellt WS- BPEL die Aktivität compensate zu Verfügung. 137 Fehler können durch die Aktivität throw, beim fehlerhaften Aufruf eines Web Services oder bei internen Fehlern, wie z.b. type-miss-match, verursacht werden. Zur Fehlerbehandlung existieren in WS-BPEL die Aktivitäten fault- Handler und compensation-handler. Innerhalb eines fault-handlers ist jedes catch- Element für einen Fehlertyp verantwortlich. Fehler, die nicht explizit durch ein catch-element beschrieben sind, werden durch das optionale catchall-element behandelt. Durch die Anweisung compensate innerhalb eines fault-handlers wird die Rücknahmebehandlung durch einen compensation- Handler initiiert. Ist innerhalb einer Scope kein fault-handler deklariert, wird der Fehler an den nächst höher stehenden Scope weitergegeben, bis das Wurzelelement process erreicht wird. Sollte selbst im Gültigkeitsbereich des Elementes process keine Fehlerbehandlung durchgeführt werden, so wird der Prozess terminiert. Das terminate-element beendet die Instanz eines WS- BPEL-Prozesses ohne vorherige Kompensation oder Fehlerbehandlung Spracherweiterungen von WS-BPEL Im Folgenden sollen die Spracherweiterungen BPEL for Java und WS-BPEL Extension for People von WS-BPEL kurz vorgestellt werden, um einen Einblick in die mögliche weitere Entwicklung von WS-BPEL zu geben. BPEL for Java (BPELJ) ist eine von BEA und IBM vorangetriebene Erweiterung des WS-BPEL-Standards, die es Aktivitäten erlaubt, selbst auch Java- Konstrukte aufrufen zu können. BEA und IBM begründen dieses Vorgehen damit, dass alle Systeme und Objekte zunächst als Web Services publiziert werden müssen, bevor diese in einem WS-BPEL-Prozess eingebunden werden können. Hierdurch wird zuviel Overhead generiert und die Komplexität eines Systems unnötig gesteigert. Mithilfe von BPELJ kann der Prozess selbst be- 137 Vgl. [Melz07], S Vgl. [ThHa07], S. 46.

67 Serviceorientierte Architekturen 53 schleunigt werden. 139 Die Realisierung von Java-Funktionalität auf Prozessebene bedeutet jedoch eine Abhängigkeit von der Programmiersprache Java und somit den Verlust von Plattformunabhängigkeit und Portabilität. In einem Joint White Paper von IBM und SAP (BPEL4Peope) 140 werden notwendige Erweiterungen von WS-BPEL formuliert, die Benutzerinteraktionen in einem WS-BPEL-Prozess ermöglichen sollen, da WS-BPEL im Standard derzeit keine Unterstützung für Benutzerinteraktionen bietet. 141 Dieses Joint White Paper wurde des Weiteren von Active Endpoints, Adobe, BEA, IBM, Oracle und der SAP AG als Grundlage für eine detailliertere Spezifikation von BPEL4People 142 und der separaten Spezifikation WS-Human-Task (WS-HT) 143 herangezogen. In der BPEL4People Spezifikation wird dabei eine neue Aktivität, die sog. people activity, definiert, mit deren Hilfe Benutzerinteraktionen aufgerufen werden sollen. Die Einzelheiten der Benutzerinteraktionen werden dabei mithilfe von WS-HT beschrieben. Hierbei sollen Benutzerinteraktionen über eine Web Service Schnittstelle standardisiert verfügbar gemacht werden. Somit sollen die mittels WS-HT beschriebenen Benutzerinteraktionen anhand von BPEL4People in einen Geschäftsprozess eingebunden werden. Des Weiteren sollen mittels BPEL4People Eskalationsfunktionen definiert werden können, die greifen, falls die Benutzerinteraktionen nicht vom Web Service verarbeitet werden können. 144 Jedoch gibt es für BPEL4People und WS-HT zurzeit noch kaum konkrete Umsetzungen und fast jeder Softwarehersteller versucht seine eigene proprietäre Lösung auf dem Markt zu etablieren Vgl. [ThHa07], S Für weitere Informationen über das Joint White Paper BPEL4People : IBM und SAP (Hrsg.): WS-BPEL Extension for People BPEL4People. 141 Vgl. [Lieb07], S Für weitere Informationen über die BPEL4People - Spezifikation : IBM, SAP, et al. (Hrsg.): WS-BPEL Extension for People (BPEL4People). 143 Für weitere Informationen über die WS-HT Spezifikation : IBM, SAP, et al. (Hrsg.): Web Services Human Tasks (WS-Human Task). 144 Vgl. [Reit07], S Vgl. [Lieb07], S. 43.

68 Serviceorientierte Architekturen 54 Da viele Prozesse eine Benutzerinteraktionen erfordern sind, ist momentan jeder, der WS-BPEL verwenden möchte, darauf angewiesen, BPEL4People und WS-HT in seine IT-Landschaft zu etablieren, eigene Lösungen für diese Interaktion zu finden oder herstellerbezogene Produkte einzusetzen. 4.5 Infrastruktur Die Serviceorientierung hat vor allem den Vorteil, dass Geschäftsprozesse mithilfe von Services, die i.d.r. Business-Funktionalitäten repräsentieren, flexibel abgebildet werden können. Soll eine IT-Landschaft eines Unternehmens auf Basis einer SOA umgesetzt werden, kann schnell eine komplexe Service- Landschaft entstehen. Zur Bewältigung dieser Komplexität wird eine SOA- Infrastruktur benötigt, in der die Prozesse ablaufen und in der die Kommunikation zwischen den einzelnen Diensten gesteuert und überwacht werden können. 146 Ein Enterprise Service Bus (ESB) basierend auf einer Bus-Architektur (siehe Kapitel 3.3) soll diese Herausforderungen in einer SOA bewältigen. 147 Seit Aufkommen des Begriffes ESB, im Jahre 2002, wurden verschiedene Definitionen aus Sicht der Forschung und der Softwareindustrie entwickelt. Im selben Jahr lieferte Roy Schulte (Gartner Group) eine erste Definition: "An Enterprise Service Bus (ESB) is a new architecture that exploits Web services, messaging middleware, intelligent routing, and transformation. ESBs act as a lightweight, ubiquitous integration backbone through which software services and application components flow." 148 Hierbei wird ein ESB als eine neue Architektur gesehen, die zur Integration für Dienste und Anwendungen dient. Bestandteile sind hierbei Web Services, nachrichtenorientierte Middleware, intelligentens Routing und Transformation. David A. Chappell definiert in seinem Buch Enterprise Service Bus den Begriff ESB wie folgt: An ESB is a standard-based integration platform that combines messaging, web services, data transformation, and intelligent routing to reliably 146 Vgl. [Verm07], S Vgl. [Degn05], S Vgl. [Pere06], S. 6.

69 Serviceorientierte Architekturen 55 connect and coordinate the interaction of significant numbers of diverse applications across extended enterprises with transactional integrity. 149 Demnach handelt es sich bei einem ESB zum einen um ein Konzept zur Realisierung einer Integration und zum anderen um eine Integrationsplattform. Die Aufgaben umfassen die Integration unterschiedlicher Anwendungen, die Koordination von Interaktionen und die Gewährleistung transaktionaler Integrität. Die Bestandteile bilden hierbei Nachrichten, Web Services, Datentransformation sowie intelligentes Routing. Zurzeit besteht somit keine einheitliche Definition eines ESB, wobei im Wesentlichen aber Konsens über die Funktionalitäten und Bestandteile eines ESB existiert, die nachfolgend in kurzer Form aufgelistet sind: 150 Nachrichtensystem: Dem ESB liegt ein Messaging-System zugrunde, welches die Kommunikationsarten wie Publish-and-Subscribe, synchron/asynchron und ereignisgesteuerte Kommunikation ermöglicht. Des Weiteren muss eine ESB mittels Adapter die Möglichkeit bieten, neben Web Services auch Anwendungen weiterer, möglichst standardisierter Technologien zu adaptieren. Intelligentes Routing: Das typ-, inhalts- und wegplanbasierte Routing von Nachrichten muss vollständig vom ESB übernommen werden. Somit können z.b. je nach Typ und Inhalt eines Nachrichteninhaltes verschiedenen Endpunkte angesprochen oder im Fehlerfall gesondert behandelt werden. Eine Routing-Engine sollte jedoch nicht für die Abbildung eines komplexen, langläufigen Geschäftsprozesses genutzt werden, da eine Routing-Engine i.d.r. keine Funktionalitäten wie strukturierte Aktivitäten wie WS-BPEL beinhaltet und im Gegensatz zu einer WS-BPEL-Engine keinen Prozessstatus halten kann. Eine Abbildung solcher Funktionalitäten würde entsprechende Eigenentwicklungen zur Folge haben. Service Orchestrierung: Zur Abbildung von Geschäftsprozessen sind Services zu orchestrieren. Grundlage für Orchestrierungen können auf 149 Vgl. [Chap04], S Vgl. [Chap04], S. 7ff.

70 Serviceorientierte Architekturen 56 WS-BPEL basierende Laufzeitumgebungen bilden (siehe Kapitel 4.4). Dies bedeutet, dass fachliche Workflows nicht im ESB realisiert werden, sondern durch entsprechende Prozess-Engines ausgeführt werden. Transformation und Mapping: Mapping einfacher Datentypen und umfangreicher Transformationen, wie Aggregation und Dekomposition von Dienstinhalten und ihrer Semantik, kann mithilfe einer Programmiersprache zur Transformation, wie z.b. XSLT, erfolgen, die eine Formattransformation von XML-Dokumenten übernimmt. Des Weiteren ist die Transformation von Protokollen, wie z.b. von HTTP nach Java Message Service (JMS), eine wichtige Aufgabe eines ESB. Monitoring und Management: Das Monitoring und Management ist eine sehr wichtige Eigenschaft des ESB, da eine verteilte Infrastruktur sehr komplex und schwierig zu verwalten ist. Das Monitoring umfasst die Ü- berprüfung der Dienste mittels Protokollierung und Protokollverwaltung. Das Management umfasst die Administration und das Deployment der Dienste, die über einen ESB kommunizieren. Nichtfunktionale Anforderungen: Der ESB sollte Quality of Service- Aufgaben hinsichltich einer Überwachung zur Einhaltung von SLA übernehmen. Idealerweise bietet er weitere Funktionalitäten an, um eine sichere Nachrichtenübertragung, Transaktionsverwaltung oder Benutzerauthentifizierung gemäß allgemeiner Standards zu ermöglichen. Anhand der wesentlichen Funktionalitäten soll ein ESB die Integration von hoch verteilten Anwendungen und Diensten im Umfeld heterogener Systeme und Plattformen ermöglichen und somit eine Integrationsinfrastruktur innerhalb einer SOA bereitzustellen. Eine SOA stellt Funktionalitäten zur Abbildung von Geschäftsprozessen als Services zur Verfügung. Ein ESB liefert konkrete Integrationsfunktionalitäten zur Überrückung von z.b. unterschiedlichen Nachrichtenformaten oder Transportprotokollen. So sind mithilfe eines ESB die Mechanismen zum Aufrufen von Diensten von der Geschäftslogik zur Abbildung von Geschäftsprozessen getrennt. Ein Dienst muss sich lediglich seine fachlichen Funktionalitäten zur Verfügung stellen. Hierbei sollen bestehende Standards für Flexibilität, automatische Integration und Herstellerunabhängigkeit genutzt wer-

71 Serviceorientierte Architekturen 57 den. Durch eine Interoperabilität mit unterschiedlichen standardisierten Technologien, die nicht unbedingt einem Web Service Standard entsprechen müssen, können diese schrittweise an einen ESB angeschlossen werden. 151 Die innerhalb des ESB eingesetzten Konzepte sind dabei nicht vollkommen neu. Grundlage bilden u.a. Konzepte, die sich schon bei EAI-Lösungen finden lassen. So soll ein ESB im Sinne einer EAI die Trennung von Geschäfts- und Integrationslogik innerhalb einer SOA realisieren. Des Weiteren liegt einem ESB eine MOM zugrunde, welche dafür sorgt, dass Nachrichten schnell und zuverlässig zwischen den Diensten übertragen werden. 152 Die MOM stellt dabei den Bus beim ESB dar, indem diese die Kommunikationsplattform zur Verfügung stellt und zum Transport von Nachrichten oder Verwaltungsinformationen verwendet wird. So findet die Weiterleitung einer Anfrage und gegebenenfalls einer Antwort eines entsprechenden Zieldienstes oder anderen Instanzen, wie z.b. einer Fehlermeldung eines Zwischendienstes, über die Nachrichtenvermittlung eines ESB statt. Dabei sind MOM-Konzepte und entsprechenden Enterprise Integration Pattern, wie in Kapitel 3.4 beschrieben, zu unterstützen. 153 Grundsätzlich sollen somit mithilfe eines ESB zwei wesentliche Ansätze verfolgt werden. Zum einen die lose Kopplung der Systeme und zum anderen die Verteilung der Integrationslogik, im Gegensatz zu einem zentralen EAI-Broker und deren Hub&Spoke Architektur, in klare, einfach zu verwaltende Teile. 154 Bei einem ESB als verteiltes System, können die Prozesse und Services mit Vorteilen hinsichtlich Skalierbarkeit und Ausfallsicherheit über mehrere Rechner verteilt werden. Der ESB bietet somit eine solide Basis für die Kommunikation zwischen Services und somit der Einführung einer SOA. 155 Jedoch muss bei der Einführung eines ESB auch dessen Komplexität berücksichtigt werden. Eine mögliche ESB-Architektur wird im folgenden Abschnitt beschrieben. Des Weiteren wird auf die Spezifikation Java Business Integration (JBI), JSR 208, einem möglichen Standard für den ESB, eingegangen. 151 Vgl. [Chap04], S Vgl. [Chap04], S Vgl. [Degn05], S Vgl. [Chap04], S Vgl. [Degn05], S. 17f.

72 Serviceorientierte Architekturen ESB Architektur In diesem Abschnitt werden die einzelnen Komponenten einer ESB Architektur genauer erklärt. Wie bereits im Kapitel 4.5 beschrieben, stellt ein hochgradig skalierbares Messaging System eine wichtige Komponente einer ESB Architektur dar. Eine MOM garantiert die Zustellung von Nachrichten an den richtigen Empfänger, ermöglicht die Verarbeitung unter Transaktionskontrolle und unterstützt unterschiedliche Kommunikationsarten. 156 Abgesehen von dem Messaging System bilden Service Container den eigentlichen ESB. Jeder Service benötigt eine Laufzeitumgebung, in der er vorgehalten und bei Aufruf ausgeführt wird. Im Java-Umfeld kann dies z.b. ein J2EE-EJB- Container sein. Ein Service Container stellt die Realisierung einer solchen Laufzeitumgebung dar und ist die physikalische Realisierung eines abstrakten Endpunktes. Abstrakte Endpunkte stellen logische Abstraktionen von Eintritts- sowie Austrittsendpunkten dar, die mit einem ESB verbunden sind. Die tatsächliche Implementierung eines abstrakten Endpunktes kann ein lokales Binding an einen Anwendungsadapter oder der Aufruf eines externen Web Services sein. Die Implementierungsdetails eines Dienstes werden dabei nicht sichtbar, da dieser mithilfe einer Schnittstellenbeschreibung, wie z.b. ein WSDL-Dokument, beschrieben wird. 157 Die physikalische Erscheinung eines abstrakten Endpunktes wird als Service- Container bezeichnet. Ein Service-Container kann einen einzelnen Dienst oder mehrere Dienste beinhalten und regelt den Nachrichtenfluss von einem Senderzu einem Empfänger-Endpunkt. Um dabei eine Überwachung und Protokollierung zu gewährleisten, bietet ein Service Container die weiteren Endpunkte Tracking, Fehler und Abgelehnt an. Des Weiteren werden durch ein sog. Invocation and Management Framework" Funktionalitäten, wie z.b. Nachrichtennachverfolgung und Prüfung (Tracking & Auditing), Threading- und Transak- 156 Vgl. [Degn05], S Vgl. [Chap04], S. 9.

73 Serviceorientierte Architekturen 59 tionsmanagement sowie Sicherheitsmechanismen, unterstützt. Der Aufbau eines Service Containers ist in der Abbildung 16 beispielhaft dargestellt. 158 Abbildung 16: Service Container 159 Die meisten Funktionalitäten eines ESB, wie in Kapitel 4.5 beschrieben, werden somit mithilfe von Service Container realisiert. So werden mithilfe eines Service Containers z.b. Protokolle zur Anbindung an die MOM definiert, Daten- und Protokoll-Anpassungen durchgeführt, Funktionalitäten um Dienste zu finden, Nachrichten zu routen oder andere Dienste aufzurufen realisiert, sowie Quality of Service Anforderungen festgesetzt. Zur Steuerung der Funktionalitäten eines Service Containers dient ein Management Framework. Die dafür notwendige Kommunikation, für Management als auch für Metadatenaustausch, kann z.b. über Java Management extensions (JMX) realisiert werden Java Business Integration Im Rahmen des Java Community Process (JCP) wurde eine Spezifikation namens Java Business Integration (JBI), JSR 208, definiert, um einen Standard für Integrationsplattformen zu schaffen. Da bis dato noch kein Standard für den Bereich Integrationsplattform vorlag, musste die Integration sehr stark produktabhängig durchgeführt werden, wodurch, wie bei klassischen ORB, eine Herstellerabhängigkeit geschaffen wurde Vgl. [Chap04], S Vgl. [Chap04], S. 113, S Vgl. [Chap04], S. 113, S 116ff. 161 Vgl. [Trop05], S. 15.

74 Serviceorientierte Architekturen 60 Ziel von JBI ist es, eine offene Plattform zu definieren, die bestehende Standards wie zum Beispiel JMX und WSDL 2.0 nutzt. Dabei stellt JBI in erster Linie eine Spezifikation bezüglich der Architektur von Service-Containern dar (siehe Abbildung 17) und definiert, wie die Container untereinander kommunizieren und von außen angesprochen werden können. Ein weiteres Ziel von JBI besteht in der Standardisierung des SOA-Managements mittels JMX. 162 Abbildung 17: JBI Service Container 163 Eine JBI-Architektur lässt sich in die drei folgenden Bestandteile unterteilen: 164 Normalized Message Router (NMR): Innerhalb der JBI-Umgebung findet der Nachrichtenaustausch nur über Normalized Messages (NM), bestehend aus Eigenschaften (Message Properties), Inhalt/Nutzlast (Message Payload) und Anhängen (Message Attachments), statt. Der NMR übernimmt das Routing der Nachrichten. Management Framework: Kontroll- und Überwachungsmöglichkeiten durch JMX basierte Administrations-Tools. Component Framework: Unterscheidung in die Komponententypen Service Engine und Binding Component. Somit soll eine Trennung von Geschäftslogik und Infrastrukturdetails erreicht werden. 162 Vgl. [Trop05], S Vgl. Sun (Hrsg): JSR 208, Java Business Integration (JBI) 1.0, S. 14ff. 164 Vgl. [Trop05], S. 13.

75 Serviceorientierte Architekturen 61 Eine Service Engine (SE) wird mittels einer WSDL beschrieben und beinhaltet Geschäftslogik innerhalb einer JBI Umgebung. Eine SE kann ihrerseits auch Services von anderen SEs konsumieren. Eine SE agiert damit sowohl als Anbieter sowie als Konsument von Services. Beispiele für SEs sind WS-BPEL- Engines, XSLT-Service-Engines oder Routing-Engines. So stellt ein JBIkonformer ESB die Infrastruktur zur Verfügung, damit Business-Prozesse ablaufen und geführt werden können. Dabei sorgt z.b. die WS-BPEL-Engine für den Ablauf innerhalb des Prozesses. 165 Binding Components (BC) stellen die Kommunikation zu Diensten außerhalb der JBI Umgebung her. Ein Dienstanbieter meldet dem NMR zur Laufzeit die angebotenen Services und liefert mithilfe einer WSDL-Datei Informationen darüber, wie der Service angesprochen werden kann. Hierbei sind eingehende und ausgehende Nachrichten einer Normalized Message in das Format des entsprechenden Dienstes zu transformieren. Die Hauptaufgabe der BC besteht somit in der Bereitstellung unterschiedlicher Bindungen (bindings) wie z.b. HTTP, JMS oder RMI um somit die Umwandlung von Protokollen in das normalisierte Nachrichtenformat (Normalized Message) und zurück zu gewährleisten. Somit lässt sich mithilfe eines lokalen SOAP/HTTP-Binding der Aufruf eines Web Services realisieren. Jedoch können auch beliebige Backend-Systeme über die Entwicklung und Integration geeigneter Binding-Komponenten integriert werden. 166 Mithilfe des JBI Standards können SE und BC zwischen unterschiedlichen JBI- Implementierungen ausgetauscht werden. Denkbar ist auch, die gesamte Integrationsinfrastruktur zwischen unterschiedlichen JBI-konformen ESB- Implementierungen zu transportieren. JBI beschreibt somit den Aufbau einer verteilten, plattform- und technologieunabhängigen serviceorientierten Infrastruktur. 165 Vgl. [Trop05], S Vgl. [Trop05], S. 15.

76 Prototypischer Entwurf einer SOA 62 5 Prototypischer Entwurf einer SOA Zur Umsetzung der Anforderungen an die IT-Architektur eines EVUs (siehe Kapitel 2.3) ist ein entsprechendes IT-Architekturkonzept erforderlich. Das technologieunabhängige Architekturkonzept einer SOA, wie im Kapitel 4 beschrieben, stellt hierbei einen Ansatz zur Entwicklung einer flexiblen, agilen und effektiven Systemarchitektur dar. Diese soll eine flexiblere Anwendungsintegration und Anpassung der Geschäftsprozesse durch Services ermöglichen, als die bisher traditionellen, monolithischen Applikationen und Systeme einer heterogenen IT- Landschaft und die IT-Kosten senken. In diesem Kapitel wird somit ein Entwurf einer SOA vorgenommen. Hierbei wird das Nutzenpotential einer SOA durch die geschäftsprozessorientierte Kapselung von Funktionalitäten in voneinander unabhängigen Diensten hinsichtlich der im Kapitel 2.3 definierten Minimalanforderungen, Integration, Entkopplung von Funktionalität und Technologie, Wiederverwendung sowie Flexibilität entworfen. Organisatorische Maßnahmen zur Regulierung und Kontrolle einer SOA im Sinne einer SOA-Governance 167 und die Einrichtung einer Service- Repository zum Auffinden von Services sind nicht Thema dieses Entwurfes. Sie sind aber nicht minder wichtig und sollten außerhalb dieser Arbeit untersucht werden. Die praktische Umsetzung einer Anwendungsintegration wird bei einem Enterprise Service Bus als Integrationsinfrastruktur angesiedelt, mit dem eine Entkopplung von Funktionalität und Technologie sowie eine entsprechende Integration gewährleistet werden soll. Hierzu soll eine JBI-Implementierung eingesetzt werden, um somit den Aufbau einer verteilten, plattform- und technologieunabhängigen serviceorientierten Infrastruktur zu garantieren. Des Weiteren kann hierdurch eine Wiederverwendung der zu entwickelnden ESB- Komponenten über Anbieter- und Produktgrenzen ermöglicht werden, da JBI eine einheitliche und offene Integrationsplattform spezifiziert. Die Kommunikation innerhalb des ESB erfolgt dabei gemäß eines NMR nachrichtenorientiert, 167 SOA Governance beschreibt z.b. die Definition von Zuständigkeiten für einzelne Services.

77 Prototypischer Entwurf einer SOA 63 wobei Unterschiede in den Nachrichtenformaten oder Transportprotokollen, wie z.b. von SOAP/HTTP nach JMS, überbrückt werden können. Hierzu müssen entsprechende Adapter (Binding-Components) für verbreitete Standards wie SOAP/HTTP und JMS vorliegen. Spezifische Binding-Components (BC) zur Adaption von Standardanwendungen, wie z.b. einem SAP-System, sollen hierbei möglichst nicht zum Einsatz kommen. Stattdessen werden Backend- Funktionalitäten als Web Services zur Verfügung gestellt. Hierdurch soll eine Hersteller- und Produktabhängigkeit von proprietären Anwendungsadaptern (Binding-Components) vermieden werden. Um eine Plattform- sowie Technologieneutralität hinsichtlich der Orchestrierung von Services zu erreichen, wird der De-facto-Standard WS-BPEL als Prozessbeschreibungssprache zur Abbildung komplexer, langläufiger Geschäftsprozesse eingesetzt. Eine WS-BPEL-Engine (Service Engine) wird somit in Kombination mit einem ESB eingesetzt, so dass einerseits keine Prozesslogik in dem ESB versteckt wird und andererseits keine Integrationslogik die Komplexität des Geschäftsprozess unnötig erhöht. Die Modellierung des Geschäftsprozesses erfolgt dabei mithilfe eines geeigneten Modellierungswerkzeuges in BPMN und wird, falls möglich, direkt in WS-BPEL transformiert. Anschließend ist der WS- BPEL-Prozess mithilfe einer WS-BPEL-Engine zum Einsatz zu bringen und auszuführen. Grundsätzlich wäre eine Orchestrierung von Services auch mithilfe einer Programmiersprache, wie z.b. Java, zu realisieren. Dies würde jedoch eine Abhängigkeit von der jeweiligen Programmiersprache und somit den Verlust von Plattformunabhängigkeit und Portabilität bedeuten. Die für den Aufbau einer serviceorientierten Architektur benötigten Funktionalitäten werden als Services gekapselt. Diese sollen in die definierten Servicearten Basis-Services, Vermittlungs-Services, Prozess-Services und öffentliche Unternehmens-Services (siehe Kapitel 4.1) unterschieden werden. Für die Identifikation von Services hat sich, wie bereits im Kapitel beschrieben, kein einheitlich methodisches Vorgehen zur Serviceidentifikation etablieren können. Da in bestehenden IT-Landschaften eines EVUs schon Backend- Funktionalitäten zur Verfügung stehen, die in eine SOA eingebunden werden sollen, wird im Rahmen dieser Arbeit eine Meet-in-the-middle Vorgehensweise

78 Prototypischer Entwurf einer SOA 64 verfolgt. Hierbei sollen Services aus funktionaler Sicht möglichst eine komplette Prozessaktivität unterstützen. Anschließend sind die bereits zur Verfügung stehenden Backend-Funktionalitäten zu identifizieren und den Services zuzuordnen. Diese Funktionsbausteine sind ggf. zusammen zu fassen, zu erweitern oder zu verfeinern. Abschließend ist zu analysieren, inwieweit notwendige Services durch bestehende Backend-Funktionalitäten abgebildet werden können und inwiefern Neuentwicklungen notwendig sind. Für ein Servicedesign, insbesondere für Serviceimplementierung, wurden Services hinsichtlich ihrer Interoperabilität, Granularität und Transaktionssicherheit untersucht und folgende allgemeine Richtlinien zum Servicedesign definiert: Schnittstellenbeschreibung: Hauptaugenmerk bei einer serviceorientierten Anwendungsintegration ist auf eine einheitliche und allgemein verständliche Schnittstellenbeschreibung zu legen, da sich eine Integration im Wesentlichen um die Spezifikation einer Schnittstelle dreht. Somit soll eine Schnittstellenbeschreibung mittels WSDL erfolgen. Liegt bereits eine Schnittstellenbeschreibung, wie z.b. Interface Definition Language (IDL) einer CORBA-Anwendung vor, ist diese in eine WSDL-Datei zu transformieren. Damit alle Servicenutzer in der Lage sind, die Menge von Datenelementen aus dem WSDL-Dokument zu extrahieren und die Datenstruktur wiederherzustellen (Unmarshalling), sollen für alle Servicenutzer zugängliche, einfache Datentypen verwendet werden. Interoperabilität: Um eine Einhaltung einheitlicher Standards und somit eine Interoperabilität von Softwareprodukten zu gewährleisten, sollen Services technologisch primär mittels Web Services umgesetzt werden. Sollten bestehende Backend-Systeme, wie z.b. SAP- oder COBOL- Systeme, die eingesetzten Web Service-Standards nicht in ausreichendem Maß unterstützen, sind die Funktionalitäten mittels Wrapper- Technologien als Web Services zu publizieren. Eine Verwendung von proprietären Anwendungsadaptern, wie teilweise bei klassischen ORB, soll aus Gründen einer möglichen Hersteller- und Produktabhängigkeit möglichst vermieden werden.

79 Prototypischer Entwurf einer SOA 65 Granularität und Performance: Um die Anzahl der Serviceaufrufe aus Performancegründen möglichst gering zu halten, sollen Services aus funktionaler Sicht eine komplette Prozessaktivität eines Geschäftsprozesses unterstützen. Somit erfolgt eine an Geschäftskonzepten orientierte Servicegranularität. Hierzu sind die Basis-Services zu erweitern oder innerhalb von Business-Services zu kapseln, die als Fassaden fungieren. Aus Datensicht sollen Services alle für den unterstützten Geschäftsprozessschritt benötigten Informationen liefern. Transaktionssicherheit: Services interagieren mit ihren Nutzern möglichst statuslos und sind für ihre interne Transaktionssicherheit verantwortlich. Wenn Services mehrere Arbeitsschritte kapseln, wie z.b. neben dem Schreiben von Partnerstammdaten auch Partnerrollen anlegen, müssen sie Operationen anbieten, um bereits ausgeführte Aktionen rückgängig machen zu können (Kompensation), falls eine der Aktionen misslingt. Dies ist darin begründet, dass bei langläufigen Transaktionen über mehrere Services eine exklusivs Sperrung von Ressourcen nicht gewährleistet werden kann (siehe 4.3.2). Da Services hinsichtlich einer Meet-in-the-middle-Vorgehensweise oftmals bestehende Backend-Funktionalitäten kapseln, wurden für ein Servicedesign, insbesondere für Serviceimplementierung auf Basis bestehender Funktionsbausteine, folgende Richtlinien zur Modellierung von Services festgelegt, nach denen die benötigten Services definiert und implementiert werden sollen: Entwicklung neuer Funktionalitäten: Gewisse funktionale Anforderungen an einen Service können über die bereits vorhandenen Backend- Funktionalitäten hinausgehen. In diesen Fällen kann die benötigte Funktionalität im Backend-System erweitert werden und diese als Basis Service publiziert werden. Sollten jedoch keine Erweiterungen bzw. Neuentwicklungen im Backend-System vorgenommen werden, um die Stabilität des integrierten Gesamtsystems nicht zu gefährden oder sind die entsprechenden Backend-Funktionalitäten bereits als Basis-Services publiziert, so sind diese durch neuentwickelte Services in Business-Services zu kapseln. Somit soll ein einheitlicher Zugriff im Sinne einer Facade er-

80 Prototypischer Entwurf einer SOA 66 möglicht werden. Neuentwicklungen können auch das Überschreiben e- xistierender Funktionalität beinhalten, bis die Backend-Funktionalität nicht mehr notwendig ist, da der neue Service die kompletten Funktionalitäten beinhaltet. Zusammenfassung von zu feingranularen Interfaces: Funktionale Anforderungen an einen Service beinhalten mehrere Backend- Funktionalitäten. Somit sind diese in einen Vermittlungsservice zu kapseln. Der Vermittlungsservice stellt in diesem Fall eine Facade dar, die einen einheitlichen Zugriff auf die Backend-Funktionalitäten bietet. Verfeinerung von zu grobgranularen Interfaces: Einige Backend- Systeme stellen in ihrer generischen Form umfangreiche Interfaces zur Verfügung, deren Parameter nur zum Teil benötigt werden und ein Interface sehr unübersichtlich gestalten. Des Weiteren kann die Größe von ausgetauschten Nachrichten die Systemperformance verschlechtern. Um grobgranulare generische Interfaces eines Backend-Systems zu spezialisierten Services zu verfeinern, können diese in einen Basis Service eingebunden und in diesem definiert werden. Diese verfeinerten Services stellen dabei nur Basisdaten zur Verfügung. Somit besteht jedoch die Gefahr, dass diese Services für andere Prozesse nicht alle benötigten Daten zur Verfügung stellen können und daher in einem anderen als dem ursprünglich geplanten Kontext nicht wieder verwendbar sind. Bei der Kapselung von Backend-Funktionalitäten durch Web Services muss im Vorfeld genau analysiert werden, welche Funktionalitäten publiziert werden und welcher Grad der Granularität sinnvoll ist. Ausgehend von der Geschäftslogik können Web Services auch mehrere Backend-Funktionalitäten und Neuentwicklungen kapseln. 5.1 Analyse Geschäftsprozess Angebotskalkulation Strom Als Vorlage zur prototypischen Umsetzung einer serviceorientierten Architektur in der Energiewirtschaft soll der Geschäftsprozess Angebotskalkulation Strom dazu dienen, die betrieblichen Anforderungen eines Geschäftsprozess in der

81 Prototypischer Entwurf einer SOA 67 Energiewirtschaft zu definieren. Dieser Geschäftsprozess stellt neben den Prozessen Angebot eröffnen/selektieren, Absatzprognose durchführen und Angebot fixieren einen Subprozess einer Angebotserstellung dar (siehe Abbildung 18). Auf eine Prozessübersicht aller relevanten Geschäftsprozese in der Energiewirtschaft wird hier bewusst verzichtet, da dies den Umfang dieser Arbeit übersteigen würde. Abbildung 18: Angebotserstellung/-anpassung Strom Bei einer Angebotserstellung wird ein Angebot vom Vertriebsmitarbeiter z.b. aufgrund von Eigeninitiative, Angebotsanfrage eines Kunden, Nachbesserung eines Angebots, Angebotsabsage eines Kunden oder aufgrund auslaufender Verträge erstellt und gepflegt. Hierzu ist im Vorfeld eine Absatzprognose für die anvisierte Vertragslaufzeit zu erstellen. Dabei werden Lastgänge 168 eines Zählpunktes analysiert, ggf. korrigiert und für die anvisierte Vertragslaufzeit prognostiziert. Anschließend erfolgt die Angebotskalkulation anhand technischer und kaufmännischer Stammdaten, einer Absatzprognose, entsprechender Beschaffungspreise sowie vertrieblicher sowie gesetzlicher Prämissen 169, wie z.b. Margen, Konzessionsabgaben oder Stromsteuer. Nach der Prüfung einer Kalkulationsversion durch einen Vertriebsmitarbeiter kann die Kalkulationsversion einem Angebot zugeordnet werden und an den Kunden versendet werden. Nachdem das Angebot dem Kunden zur Annahme vorliegt, wird ein Monitoring der für dieses Angebot relevanten Beschaffungskosten durch Nachkalkulationen durchgeführt. 168 Der Lastgang wird vom Netzbetreiber für den Entnahmepunkt bzw. für den Einspeisepunkt zur Verfügung gestellt. Hierbei handelt es sich um die Gesamtheit von Viertelstunden- Energiemengenwerte, die innerhalb einer Messperiode ermittelt wurden. 169 Prämissen stellen Rahmenbedingungen dar und beeinflussen je nach Vorgabe das Kalkulationsergebnis. Innerhalb einer Kalkulation werden bestimmte Vorraussetzungen oder Annahmen geprüft und berücksichtigt.

82 Prototypischer Entwurf einer SOA 68 Bei der Annahme eines Angebotes durch den Geschäftspartner kommt es zu einem Vertrag. Somit sind die Vertragsbedingungen an ein Abrechnungssystem und die Beschaffungsmengen an ein Beschaffungssystem des EVUs zu übermitteln. Hierbei ist eine zeitnahe Mitteilung an das Beschaffungssystem notwendig, damit die jeweiligen Mengen kostengünstig beschafft werden können. Der mittels BPMN modellierte Geschäftsprozess einer Angebotskalkulation Strom ist der Abbildung 19 zu entnehmen. Hierbei wird zwischen den Lanes Benutzer und Hintergrundverarbeitung unterschieden. Somit wird dargestellt, welche Prozessschritte eine Benutzerinteraktion erfordern und welche Prozessschritte im Hintergrund von Services verarbeitet werden. Abbildung 19: Angebotskalkulation Strom vereinfachte Darstellung Ein Vertriebsmitarbeiter erfasst die für die Kalkulation notwendigen Daten, wie z.b. Geschäftspartner, Lieferstelle, Vertragslaufzeit oder Prämissen (siehe Kapitel 0), und initiiert die Hintergrundverarbeitung. Hierbei erfolgt zunächst eine Ermittlung benötigter Daten, wie Zahlpunktattribute aus einem Abrechnungssystem und prognostizierte Absatzmengen aus einem Energiedatenmanagementsystem (EDM-System). Die prognostizierten Absatzmengen, die als Viertelstundenwerte vorliegen, werden anschließend in Monatswerte aggregiert sowie hinsichtlich Winter/Sommer Hochtarif (HT) und Winter/Sommer Niedertarif (NT) unterschieden. Eine Mengendifferenzierung hinsichltich HT und NT ist gegebe-

83 Prototypischer Entwurf einer SOA 69 nenfalls für eine Berechnung von Netznutzungsentgelten oder einer Erlöskalkulation hinsichtlich HT- und NT-Preise erforderlich. Darauf folgt eine Bewertung der einzelnen Kostenpositionen, indem die Prämissen anhand vertrieblicher und gesetzlicher Vorgaben in der Prämissenverwaltung bewertet und eine Bepreisung anhand der prognostizierten Absatzmengen (Viertelstundenwerte) durchgeführt werden. So wird innerhalb der Prämissenverwaltung eine Bewertung der einzelnen Positionen, wie z.b. Netznutzungsentgelte, gesetzliche Abgaben und Margen, vorgenommen. Bei einer Bepreisung handelt es sich um die Ermittlung der Strom-Beschaffungskosten. Hierbei können unternehmensinterne Regelungen unterschiedliche Bewertungsverfahren vorsehen. In dieser Arbeit wird abhängig von prognostizierten Absatzmengen zwischen einer automatisierten und einer individuellen Bepreisung unterschieden. Bei einer automatisierten Bepreisung werden nach sog. Terminpreiskurven (Hourly Price Forward Curve - HPFC) 170 stündliche Preise anhand gegebener Marktpreise ermittelt. Bei einer individuellen Bepreisung können die Bezugspreise manuell von einem Beschaffungsmitarbeiter festgelegt werden. Diese möglicherweise langläufige Benutzerinteraktion erfordert eine asynchrone Kommunikation, was wiederum bedeutet, dass der Geschäftsprozess einer Angebotskalkulation ebenfalls langläufig sein kann und auch eine asynchrone Kommunikation erfordert. Anschließend wird anhand der bis dahin ermittelten Daten die Kalkulation als Kernprozess der Angebotskalkulation durchgeführt, die eine Kosten- und Erlösermittlung beinhaltet. Abschließend sind die erfassten Stammdaten, die ermittelten Daten aus verschiedenen Anwendungssystemen und das Ergebnis der Kalkulation als Kalkulationsversion zu speichern. Der Vertriebsmitarbeiter prüft anschließend das Kalkulationsergebnis für den Zählpunkt und kann die Kalkulationsversion einem Angebot zuordnen oder gegebenenfalls eine neue Kalkulationsversion erstellen. 170 Hourly Price Forward Curve (kurz: HPFC) stellt eine Methode dar, um die Entwicklung von Bezugspreisen im Energiehandel stündlich aufzuzeichen. Hierbei werden die aktuellen Terminmarktpreise herangezogen und mittels Gewichtungsfaktoren, die auf Erfahrungswerten berufen, bewertet, um Marktpreise für einen zukünftigen Zeitpunkt zu prognostizieren.

84 Prototypischer Entwurf einer SOA 70 Zur Abbildung des Geschäftsprozesses einer Angebotskalkulation werden somit Anforderungen hinsichtlich einer Integration unterschiedlicher Anwendungssysteme bzw. Dienste, wie z.b. CRM, EDM, Beschaffung, Kalkulation, Abrechnung, oder Datenbanken, gestellt, um eine Prozessintegration zu gewährleisten. Die Integration der verschiedenen Dienste soll mithilfe eines ESB erfolgen (siehe Abbildung 20). Abbildung 20: Analyse der Anwendungsintegration 5.2 Design Geschäftsprozess Angebotskalkulation Strom Nach einer fachlich-funktionalen Analyse des Geschäftsprozesses Angebotskalkulation Strom wird in diesem Abschnitt ein technologieabhängiges Design vorgenommen. Der Prozess aus dem Analyse-Prozessmodell wird dabei im Verhältnis 1:1 in einen Serviceprozess des Design-Prozessmodells überführt. Bei der technologischen Umsetzung soll es sich nicht um eine vollständige Abbildung des Geschäftsprozesses handeln, stattdessen sollen die wesentlichen Aktivitäten bzw. Funktionalitäten innerhalb eines Prototyps abgedeckt werden Services Anhand der fachlich-funktionalen Anforderungen, die bereits im Kapitel 5.1 erläutert wurden, sind die Prozessschritte mithilfe von entsprechenden Services abzubilden. Diese Services sollen dabei hinsichtlich einer Meet-in-the-middle- Vorgehensweise möglichst bereits zur Verfügung stehende Backend- Funktionalitäten nutzen. Hierzu sind die für den Geschäftsprozess relevanten Backend-Funktionalitäten zu analysieren (siehe Tabelle 3).

85 Prototypischer Entwurf einer SOA 71 Tabelle 3: Übersicht der Backend-Funktionalitäten für den Geschäftsprozess Die SAP-Funktionsbausteine KALKULATION_PRAEMISSEN und KALKULA- TION_STROM stellen für die Prozessschritte Prämissenbewertung durchführen und Angebot kalkulieren benötigte Funktionalitäten zur Verfügung. Somit ist für diese Prozessschritte keine Entwicklung neuer Funktionalitäten erforderlich. Für die weiteren Prozessschritte sind hingegen entsprechende Neuentwicklungen erforderlich, da bislang keine entsprechenden Dienste existieren. Die Prozessschritte Zählpunktattribute ermitteln, Absatzprognose ermitteln, Individualbepreisung durchführen und Standardbepreisung durchführen sollen hierbei mittels Mock-Implementierungen 171 realisiert werden, da hierzu keine notwendingen Anwendungen, wie ein Abrechnungssystem, EDM-System und Beschaffungssystem zur Verfügung stehen und eine vollständige Implementierung der notwendigen Funktionalitäten den Rahmen dieser Thesis übersteigen würde. Damit die vorhandenen Funktionsbausteine des SAP-Systems eingebunden werden können, sind diese als Services zur Verfügung zu stellen, da die Verwendung eines proprietären SAP-Anwendungsadapters des ESB aus Gründen einer möglichen Hersteller- und Produktabhängigkeit vermieden werden soll (siehe Kapitel 4.2.2). Bei der Entwicklung von Services unterscheidet die SAP AG zwischen den Programmiersprachen ABAP und Java. Zur Erstellung eines Web Services unter der Programmiersprache ABAP stellt die SAP AG seit dem Release 6.40 des SAP Web Applikation Servers einen Web Service Creation Wizard innerhalb der ABAP-Workbench zur Verfügung, der den Benutzer durch alle notwendigen Schritte führt, um einen Web Service aus einem vorhanden 171 Mock-Objekte implementieren die benötigte Schnittstelle und stellen sicher, dass die erwarteten Operationen vollständig mit den korrekten Parametern und in der erwarteten Reihenfolge durchgeführt werden. Vom Mock Objekt werden festgelegte Werte zurückgeliefert.

86 Prototypischer Entwurf einer SOA 72 RFC-fähigen Funktionsbaustein zu erstellen. Bei der Entwicklung von Services unter Java werden die über die Schnittstellen eines SAP-Funktionsbausteins definierten Methoden mit deren Ein- und Ausgabeparametern mittels RFC in eine stateless Session Bean 172 (Web-Service-Bean) eingebunden und als Web Services publiziert. Die Nutzung dieser Wraper-Technologie ermöglicht, dass z.b. weitere Geschäftslogik innerhalb eines Basis-Services hinzufügt werden kann oder Schnittstellen angepasst werden können ohne Erweiterungen bzw. Neuentwicklungen im Backend-System vornehmen zu müssen, wodurch die Stabilität des integrierten Gesamtsystems nicht gefährdet wird. 173 Da die benötigten SAP-Funktionsbausteine bislang einen SAP Web Applikation Server mit dem Release 6.20 als Laufzeitumgebung nutzen, steht ein Web Service Creation Wizard innerhalb der ABAP-Workbench nicht zur Verfügung. Somit sind die benötigten Services für die Prozessschritte Prämissenbewertung durchführen (hier: LsyasPremiseService) und Angebot kalkulieren (hier: LsyasQuotationCalculationService) unter Verwendung der Programmiersprache Java zu erstellen, indem stateless Session Beans die von der SAP zur Verfügung gestellte JCo-Bibliothek (Java Connector) verwenden. Diese Java- Bibliothek kapselt dabei das zugrunde liegende RFC-Protokoll für den Zugriff auf die Funktionsbausteine KALKULATION_STROM sowie KALKULATI- ON_PRAEMISSEN und stellt Methoden zur beidseitigen Kommunikation zur Verfügung. In Abbildung 21 wird das Zusammenwirken der SAP- Funktionsbausteine und der hier definierten Services verdeutlicht. Abbildung 21: Servicedesign auf Basis bestehender Funktionsbausteine 172 Eine stateless Session Bean ist eine standardisierte Komponente innerhalb eines Java-EE- Servers (Java Enterprise Edition). 173 Vgl. [WoMa06], S

87 Prototypischer Entwurf einer SOA 73 Zur Abbildung des Prozessschrittes Zählpunktattribute ermitteln (hier: Lsyas- MeteringPointService) sind anhand einer eindeutigen Zählpunkt-Nummer und des Datums des Vertragsbeginns technische Zählpunktattribute zur Prämissenbewertung, wie z.b. Netznutzungsentgelte, aus einem Abrechnungssystem zu ermitteln. Hierbei wird ein Zugriff auf ein Abrechnungssystem mithilfe eines Mock-Objekts (Services) simuliert. Zur Realisierung des Prozessschrittes Absatzprognose ermitteln ist eine Datei, die eine prognostizierte Absatzmenge, d.h. einen Lastgang eines Zählpunktes aus einem EDM-System repräsentiert, bei der Stammdatenerfassung durch den Benutzer auszuwählen und mithilfe einer Web-Anwendung (siehe Kapitel 0) einzulesen. Da es sich hierbei um Viertelstundenwerte über die anvisierte Vertragslaufzeit handelt, können hohe Nutzlasten entstehen. Um diese Daten an eine XML-Anwendung wie einem Web Service zu senden, sollen die Daten in der ursprünglichen Form erhalten bleiben und als Binärdaten mittels Message Transmission Optimization Mechanism (MTOM) 174 als Anhang der SOAP- Nachricht angefügt werden. Durch Messungen an der Universität Cardiff konnte nachgewiesen werden, dass ein Datentransfer über Anhänge zwar einen deutlichen Mehraufwand bei kleinen Nutzlasten, jedoch bei Datenmengen von mehr als einigen Tausend Bytes eine große Ersparnis (sechs bis sieben mal schneller als die Übertragung innerhalb einer XML-Struktur) bedeutet. MTOM kann dabei Binärdaten als unformatierte Bytes in einer SOAP-Nachricht übertragen. Dadurch spart MTOM Zeit zum Parsen von XML-Daten und erzeugt kleinere Nachrichten, wodurch ein geringerer Speicherplatzbedarf entsteht. 175 Die prognostizierte Absatzmenge ist anschließend an die Services zur Abbildung der Prozessschritte Absatzmenge aggregieren (hier: LsyasLoadCourse- Service), Standardbepreisung durchführen (hier: LsyasPurchasePriceService) und Individualbepreisung durchführen (hier: LsyasPurchasePriceAsyncB- PELProcess) zu übermitteln. Somit haben diese Services ebenfalls MTOM zu unterstützen. Der Service zur Abbildung des Prozessschrittes Individualbeprei- 174 Message Transmission Optimization Mechanism (MTOM) ist ein Standard der W3C zur Versendung von Binärdaten im Web Service Umfeld. 175 Vgl. [PrAl06], S

88 Prototypischer Entwurf einer SOA 74 sung durchführen erfordert eine Benutzerinteraktion und ist asynchron darzustellen. Um diesen Prozessschritt innerhalb eines Prototyps darzustellen, ist der Service LsyasPurchasePriceService innerhalb eines asynchronen WS-BPEL- Prozesses zu kapseln und mithilfe eines Wait -Elements eine Benutzerinteraktion zu simulieren. Abschließend ist eine Kalkulationsversion mit den ermittelten Daten unter einer eindeutigen ID in einer Datenbank zu speichern. Neben Operationen zum Erzeugen von Kalkulationsversionen in einer Datenbank stellt der Service (hier: LsyasCostingVersionElectricityDataService) Operationen zum Auffinden und zum Löschen von Kalkulationsversionen zur Verfügung. Hierzu ist die Datenbank als mysql-datenbank zu realisieren. Das entsprechende Datenbankdesign ist der Anlage B zu entnehmen. Auf die Datenbank ist über das Java Persistence API (JPA) zuzugreifen, wobei als Implementierung das ORM- Framework Hibernate genutzt werden soll. JPA ist eine Java-Persistenz- Spezifikation, die sich ausschließlich auf relationale Datenbanken konzentriert. Sie definiert ein Programmiermodell für persistente Objekte, ein Objektrelationales Mapping 176 und eine an SQL angelehnte Abfragesprache (Java Persistence Query Language; JPQL). Die JPQL-Abfragen ähneln syntaktisch SQL- Abfragen, beziehen sich aber auf Entitäten, d.h. auf Entity-Klassen statt auf Datenbanktabellen. Eine Entity-Klasse repräsentiert dabei eine Datenbanktabelle einer relationalen Datenbank, d.h. ein sog. Objekt-relationales-Mapping. Um eine einheitliche Sicht auf die Entity-Klassen zu gewährleisten, sind diese in einer gemeinsamen SessionBean zu kapseln, die mithilfe eines Entity-Managers 177 z.b. einen gemeinsamen Transaktionscontext bereit stellt (siehe Abbildung 22). 176 Metadaten für das Objektrelationale Mapping können direkt in der Java-Klasse über Annotationen spezifiziert oder in XML-Dateien ausgelagert werden. 177 Der Entity Manager stellt alle persistenzbezogenen Funktionalitäten zur Verfügung.

89 Prototypischer Entwurf einer SOA 75 Abbildung 22: Data-Service LsyasCostingVersionElectricityDataService In der Tabelle 4 wird das Zusammenwirken der in Kapitel 5.1 definierten Prozessschritte mit den hier definierten Services dargestellt. Die Servicebeschreibungen sind der Anlage A zu entnehmen. Prozessschritt Service Bemerkungen Prognostizierte Absatzmenge ermitteln - Eine Datei, d.h. ein Lastgang eines Zählpunktes (EDM-System) wird vom Benutzer bei der Erfassung der Stammdaten ausgewählt und dem Prozess zur Verfügung gestellt (Upload) Absatzprognose aggregieren (1) LsyasLoadCourseService Aggregation prognostizierter Absatzmengen sowie Mengendifferenzierung hinsichtlich Winter/Sommer Hochtarif (NT) und Winter/Sommer Niedertarif (NT). Zählpunktattribute ermitteln (2) LsyasMeteringPointService Simuliert den Zugriff auf ein Abrechnungssystem. Prämissenbewertung durchführen Standardbepreisung durchführen Individualbepreisung durchführen Angebot kalkulieren Kalkulationsversion speichern (3) LsyasPremiseService Bewertung aller vertrieblichen und gesetzlichen Prämissen. Kapselt den SAP-Fuba KALKULA- TION_PRAEMISSEN. (4) LsyasPurchasePriceService Simuliert den Zugriff auf ein Beschaffungssystem und führt eine Bepreisung durch. (5) LsyasPurchasePriceAsync Stellt einen WS-BPEL-Prozess dar und simuliert BPELProcess eine Benutzerinteraktion (asynchroner Prozessschritt). Kapselt den Service LsyasPurchasePriceService und ein Wait -Element (6) LsyasQuotationCalculation Service (7) LsyasCostingVersionElectricityDataService Tabelle 4: Übersicht Prozessschritte und Services Kosten- und Erlösermittlung. Kapselt den SAP- Fuba KALKULATION_STROM. Persistiert die Kalkulationsversion in einer Datenbank (Data-Service).

90 Prototypischer Entwurf einer SOA Prozess Zur Orchestrierung der beschriebenen Services zum fachlich-funktionalen Geschäftsprozess einer Angebotskalkulation Strom wird die plattform- sowie technologieneutrale Prozessbeschreibungssprache WS-BPEL eingesetzt. Dieser Orchestrierungsdienst stellt technologisch wiederum einen Web Service dar. Wie bereits in Kapitel beschrieben, ist für den Geschäftsprozess Angebotskalkulation Strom eine asynchrone Kommunikation bereitzustellen. Somit ist der WS-BPEL-Prozess (hier: LsyasQuotationCostingElectricityBPELProcess ) asynchron aufzurufen. Zur Abbildung einer asynchronen Kommunikation, stehen, wie bereits im Kapitel dargestellt, die Interaktionsmuster Fire & Fergot, Polling oder Callback zur Verfügung. Bei dem Interaktionsmuster Fire and Forget kann aufgrund einer einfachen Einwegoperationen keine Zuverlässigkeit der Zustellung und Verarbeitung gewährleistet werden. Der Servicenutzer erhält keine Rückmeldung über den Prozessverlauf oder dem Prozessergebnis. Somit kommt das Interaktionsmuster Fire and Forget für den hier darzustellenden Geschäftsprozess nicht in Frage. Beim Polling - Interaktionsmuster wird der Status eines Services regelmäßig abgefragt und sobald ein Ergebnis vorliegt, kann dieses vom Servicenutzer abgefragt werden. Bei diesem Interaktionsmuster werden jedoch viele Nachrichten produziert, was die Netzwerkverbindungen und die Systemperformanz negativ beeinflusst. Dies soll durch das Callback -Interaktionsmuster behoben werden. Jedoch bringt dieses Interaktionsmuster aufgrund der Umsetzung eines Callback-Handlers auf Seiten des Clients eine zusätzliche Komplexität mit sich. Im Folgenden werden die Interaktionsmuster Polling und Callback hinsichtlich der Umsetzung innerhalb eines WS-BPEL-Prozesses analysiert und entworfen. Im Standard unterstützt WS-BPEL das Callback -Interaktionsmuster zur Abbildung einer asynchronen Kommunikation, indem zwei Services mit Einwegoperationen (one-way-operationen) zur Verfügung gestellt werden und somit das Message Exchange Pattern Request/Response repräsentieren. Der erste Service nimmt den asynchronen Serviceaufruf (one-way-operationen), der eine Referenz (URI) auf den Callback-Handler des Clients beinhaltet, entgegen. Die

91 Prototypischer Entwurf einer SOA 77 Referenz, d.h. die Empfängeradresse ist dabei z.b. mittels WS-Addressing (replyto) im Header der SOAP-Nachricht zu hinterlegen. Ist hingegen die Empfängeradresse konstant, kann eine Referenz (URI) im zweiten Service, d.h. Callback-Service fest verankert werden. Nach der Ausführung des WS-BPEL- Prozesses sendet der Callback-Service das Ergebnis an die Empfängeradresse des Callback-Handler zurück (siehe Abbildung 23). Abbildung 23: Sequenzdiagramm - Callback -Interaktionsmuster Hierbei ist zu beachten, dass Einwegoperationen (one-way-operationen) alleine gesehen nur ein Fire & Forget -Interaktionsmuster unterstützen und keine Antwort oder Fehlermeldung erwarten. Somit existiert in einem WSDL-Dokument für eine Einwegoperationen nur ein input -Element jedoch kein output - Element oder ein separates, optionales fault -Element. Um den Client (Servicenutzer) im Falle eines Fehlers trotzdem über einen Fehler und dessen Fehlerart zu informieren, werden diese Informationen als zusätzliche Übergabeparameter (hier: Fault und FaultMessage ) definiert. Nach der Rücksendung der Ergebnisse, d.h. der Übergabeparameter des WS-BPEL-Prozesses mittels eines Callback-Services, sind die Übergabeparameter Fault und FaultMessage vom Callback-Handler des Clients hinsichtlich eines eventuellen Fehlers und der Fehlerart zu analysieren. Wie bereits beschrieben, unterstützt WS-BPEL im Standard nur das Callback - Interaktionsmuster und kein Polling -Interaktionsmuster zur Abbildung einer asynchronen Kommunikation. So besteht innerhalb des WS-BPEL-Prozesses keine Möglichkeit, alle drei erforderlichen synchronen Operationen, zur Initiierung des Prozesses, zur Überprüfung des Prozessstatus und zur Ermittlung des Prozesserbnisses, nach dem Polling -Interaktionsmuster zur Verfügung zu

92 Prototypischer Entwurf einer SOA 78 stellen, wobei die Steuerung der Operationen vom Servicenutzer und nicht vom WS-BPEL-Prozess erfolgt. Des Weiteren besteht z.b. bei der Initiierung des WS-BPEL-Prozesses mithilfe der hier verwendeten WS-BPEL-Prozess-Engine (siehe Kapitel 6.1) keine standardisierte Möglichkeit, die erzeugte ID der Prozessinstanz als Antwortobjekt zurückzugeben, um somit den Status der Operation zu überwachen, zu bestimmen, wann die Operation abgeschlossen wurde und das Ergebnis abzurufen. Somit unterscheiden sich WS-BPEL-Prozesse, die technologisch Web Services darstellen, hinsichtlich der technologischen Umsetzung der Interaktionsmuster einer asynchronen Kommunikation von z.b. JAX-WS-Web-Services 178, die das Fire & Forget -, Polling - und Callback - Interaktionsmuster standardmäßig unterstützten (siehe Kapitel 4.3.1). Das Polling -Interaktionsmuster ist jedoch hinsichtlich einer vereinfachten Funktionsweise erforderlich, da dieses Interaktionsmuster innerhalb der Web- Anwendung contact, einer CRM-Lösung der Firma Lufthansa Systems AS GmbH, zur asynchronen Kommunikation genutzt wird, indem der Prozessstatus eines inittierten Prozesses geprüft und dem Benutzer angezeigt wird. Diese Web-Anwendung stellt dabei einen potentiellen Servicenutzer des Services LsyasQuotationCostingElectricityBPELProcess dar. Damit der WS-BPEL- Prozess einer Angebotskalkulation Strom innerhalb der Web-Anwendung genutzt werden kann, ohne einen komplexen Callback-Handler zu implementieren, soll die Möglichkeit geboten werden, den Prozessstatus des initiierten WS- BPEL-Prozesses anhand der dazugehörigen Aufrufparameter abzufragen. Zur Abfrage des Prozessstatus soll dabei das JMX-basierte Management Framework des ESB genutzt werden, indem die entsprechende Funktionalität mithilfe eines Web Services (hier: LsyasBPELProcessMonitoringService) zur Verfügung gestellt wird. Dieser Service ermittelt dabei aufgrund des Namens des WS-BPEL-Prozesses und der dazugehörigen Aufrufparameter den Prozess und den dazugehörigen Prozessstatus. Zur Abbildung des Services LsyasB- PELProcessMonitoringService ist eine MBean zu kapseln, die einen direkten Zugriff auf die WS-BPEL-Prozess-Datenbank der WS-BPEL-Engine ermöglicht 178 JAX-WS (Java API for XML - Web Services) ist eine Java API zum Erstellen und Konsumieren von Web Services.

93 Prototypischer Entwurf einer SOA 79 (siehe Abbildung 24). MBeans repräsentieren innerhalb einer JMX-Architektur die eigentlichen überwachbaren Ressourcen, wobei für jede MBean eine Management Schnittstelle definiert ist, die am MBean-Server zur Verfügung steht. Abbildung 24: Sequenzdiagramm - Polling -Interaktionsmuster mit JMX-Service Die Initiierung des WS-BPEL-Prozesses erfolgt somit für beide Interaktionsmuster Polling und Callback mithilfe einer Einwegoperation. Um während des Prozessverlaufs anhand der Aufrufsemantik des WS-BPEL-Prozesses zu überprüfen, ob eine asynchrone Antwort mittels Callback -Interaktionsmuster erwartet wird, ist mithife eines zusätzlichen Aufrufparameters (hier: responeasync) des WS-BPEL-Prozesses das Callback -Interaktionsmuster der asynchronen Kommunikation festzulegen und innerhalb des WS-BPEL-Prozesses zu prüfen. Neben den Polling - und Callback -Interaktionsmustern zur asynchronen Kommunikation soll innerhalb dieses Prototyps durch den Einsatz eines ESB die Möglichkeit eines asynchronen Nachrichtenaustauschs mittels einer MOM analysiert werden. Hierdurch soll die zeitliche und örtliche Entkopplung derservices sowie die zuverlässige Zustellung einer Nachricht ermöglicht werden. Unabhängig davon, ob der Empfänger (Dienst) gerade erreichbar ist oder nicht, wird die Nachricht in einer zuverlässigen Message Queue gespeichert. Anschließend wird die Nachricht der Message Queue an den Empfänger weitergeleitet. Zur Ansteuerung der MOM innerhalb des ESB soll die herstellerunabhän-

94 Prototypischer Entwurf einer SOA 80 gige Programmierschnittstelle JMS genutzt werden. Zur Abbildung einer asynchronen Kommunikation mittels einer Message Queue innerhalb des Geschäftsprozesses einer Angebotskalkulation ist dem Benutzer bei der Erfassung der Stammdaten über eine Web-Anwendung die Möglichkeit zu bieten, eine -Benachrichtigung über den erfolgreichen oder nicht erfolgreichen Prozessverlauf in Anspruch zu nehmen. Innerhalb des WS-BPEL-Prozesses ist zu prüfen, ob eine -Benachrichtigung erfolgen soll. Falls eine - Benachrichtigung erwünscht ist, wird eine TextMessage mit Informationen ü- ber den Zählpunkt, der ID der Kalkulationsversion, der -Adresse des Empfängers und ein Kennzeichen über den erfolgreichen oder nicht erfolgreichen Prozessdurchlauf an eine JMS Message Queue gesendet. Diese Message Queue ist im Sinne einer Punkt-zu-Punkt-Verbindung einem Empfänger, d.h. einer Message Driven Bean 179 zuzuordnen (siehe Abbildung 25). Falls eine Nachricht von der Message Queue zugesendet wurde, ist diese zu verarbeiten und eine -Benachrichtigung an die angegebene -Adresse zu senden. Anhand des Kennzeichens über den erfolgreichen oder nicht erfolgreichen Prozessdurchlauf wird der Benutzer informiert, ob die Kalkulationsversion erfolgreich erstellt werden konnte oder nicht. Falls eine Kalkulationsversion erstellt werden konnte, sind die Identifikationsnummern des Geschäftspartners, des Zählpunktes und der erstellten Kalkulationsversion anzugeben. Abbildung 25: Sequenzdiagramm - JMS Message Queue 179 Eine Message Driven Bean ist eine standardisierte Komponente innerhalb eines Java-EE- Servers (Java Enterprise Edition).

95 Prototypischer Entwurf einer SOA 81 Zusammenfassend stellt der Orchestrierungsdienst zwei Services (hier: Lsyas- QuotationCostingElectricity_AsyncService und LsyasQuotationCostingElectricity_CallbackService) mit jeweils einer Einwegoperationen (hier: createquotationcostingelectricityasync und QuotationCostingElectricityCallback) zur asynchronen Kommunikation zur Verfügung. Der Service LsyasQuotationCostingElectricity_AsyncService beinhaltet dabei die Eingabeparameter (hier: LsyasQuotationCostingElectricityInput ) in der Nachricht createquotationcostingelectricityrequest. Der Service LsyasQuotationCostingElectricity_CallbackService beinhaltet die Ausgabeparameter (hier: createquotation- CostingElectricityResponse) in der Nachricht LsyasQuotationCostingElectricityOutput. Eine Servicebeschreibung ist der Anlage B zu entnehmen User Interfaces User Interfaces (UIs) stellen Benutzerschnittstellen dar, um mit den Funktionalitäten von Anwendungen bzw. Services zu interagieren. Für die Abbildung des Geschäftsprozesses Angebotskalkulation Strom sind UIs für die Erfassung, Übersicht/Auswahl und Anzeige der Ergebnisse einer Angebotskalkulationsversion Strom mittels Struts zur Verfügung zu stellen. Struts ist ein Java Open- Source-Framework für die Präsentations- und Steuerungsschicht von Webanwendungen. Struts ist zu verwenden, da die bestehende Web-Anwendung contact der Lufthansa Systems AS GmbH als potentieller Servicenutzer des Prozesses mittels Struts implementiert ist und die hier entwickelten UIs möglichst einfach in die bestehende Webanwendung übernommen werden sollen. Im Folgenden werden die benötigten Parameter und deren Datentypen der UIs definiert. Zudem wird das entsprechende Layout dargestellt. Das UI für die Erfassung einer Angebotskalkulationsversion soll im Rahmen des zu erstellenden Prototyps wesentliche Eingabeparameter einer Angebotskalkulation Strom bereitstellen. Diese sind in Tabelle 5 näher spezifiziert.

96 Prototypischer Entwurf einer SOA 82 User Interface: Anlegen Angebotskalkulationsversion Strom (QuotationCostingProcess) Parameter Parametertyp Mussfeld Datentyp Darstellung Format Beispiel Stammdaten Angebotskalkulation Strom Datei Lastgang Eingabeparameter ja String File - Profil_XXX.csv Geschäftspartner Eingabeparameter ja String Textfeld Zählpunkt Eingabeparameter ja String Textfeld Beginn Lieferung Eingabeparameter ja String Textfeld MM.DD.YYYY Ende Lieferung Eingabeparameter ja String Textfeld MM.DD.YYYY Bindefrist Eingabeparameter ja String Textfeld MM.DD.YYYY * Befreit = 9 / Stromsteuerstufe Eingabeparameter ja String Dropdown - Regelsatz = 0 Kundengruppe Eingabeparameter ja String Dropdown - BA / BG Währungsschlüssel Eingabeparameter ja String Dropdown - EUR BAFA-Bescheid Eingabeparameter nein Boolean Checkbox - aktiviert = true KWKG-Ermäßigt Eingabeparameter nein Boolean Checkbox - aktiviert = true NNE Mess- und Vorsorgungsspannung Eingabeparameter nein Boolean Checkbox - aktiviert = true NNE Messkosten inkl. Eingabeparameter nein Boolean Checkbox - aktiviert = true NNE Messpunkt Eingabeparameter nein Boolean Checkbox - aktiviert = true Lieferung ohne NNE Eingabeparameter nein Boolean Checkbox - aktiviert = true gemessener Lastgang Eingabeparameter nein Boolean Checkbox - aktiviert = true Benachrichtigung -Adresse Eingabeparameter nein String Textfeld - Benachrichtigung Eingabeparameter nein Boolean Checkbox - aktiviert = true * max. 14 Tage in der Zukunft Tabelle 5: Parameter UI, Erfassung Angebotskalkulationsversion Nachdem die Eingabeparameter bestimmt wurden, ist das Layout zu definieren. Hierbei sind die Eingabeparameter in die Blöcke Stammdaten Angebotskalkulation Strom und -Benachrichtigung zu unterteilen. Nach einer Eingabe der Parameter kann eine Kalkulationsversion mithilfe des Buttons Anlegen gestartet werden. Bei einer nicht korrekten oder unvollständigen Eingabe sind entsprechende Fehlermeldungen im unteren Bildschirmbereich anzuzeigen (siehe Abbildung 26). Abbildung 26: Layout UI; Erfassung Angebotskalkulationsversion

97 Prototypischer Entwurf einer SOA 83 Falls der Benutzer eine -Benachrichtigung erwünscht, wird diese an die angegebene -Adresse gesendet. Hierbei wird der Benutzer informiert, ob die Kalkulationsversion für den Zählpunkt erfolgreich erstellt werden konnte o- der nicht. Bei einer erfolgreichen Erstellung werden die Identifikationsnummern des Geschäftspartners, des Zählpunktes und der neu erstellten Kalkulationsversion mit gesendet, anhand derer der Benutzer die Kalkulationsversion selektieren kann. Das UI zur Übersicht/Auswahl von Angebotskalkulationsversionen soll dem Benutzer anhand des Geschäftspartners, des Zählpunktes und des Zeitraums der Lieferung die Kalkulationsversionen anzeigen. Anhand derer kann der Benutzer eine einzelne Kalkulationsversion zur detaillierten Anzeige, d.h. zur Anzeige der Kalkulationsergebnisse selektieren oder eine einzelne Kalkulationsversion löschen. Die Parameter sind in der Tabelle 6 spezifiziert. User Interface: Übersicht/Auswahl Angebotskalkulationsversion Strom (QuotationCostingList) Parameter Parametertyp Mussfeld Datentyp Darstellung Format Beispiel Suchmaske Angebotskalkulation Strom Geschäftspartner Eingabeparameter ja String Textfeld Zählpunkt Eingabeparameter nein String Textfeld Beginn Lieferung von Eingabeparameter ja String Textfeld MM.DD.YYYY Beginn Lieferung bis Eingabeparameter ja String Textfeld MM.DD.YYYY Liste Kalkulationsversionen Strom Kalkulationsversion ID Anzeigeparameter - String Textfeld - 9 Zählpunkt Anzeigeparameter - String Textfeld Lieferung von Anzeigeparameter - String Textfeld MM.DD.YYYY Lieferung bis Anzeigeparameter - String Textfeld MM.DD.YYYY Bindefrist Anzeigeparameter - String Textfeld MM.DD.YYYY Angebot zug. Anzeigeparameter - Boolean Checkbox - zugeordnet = true Erstellungsdatum Anzeigeparameter - String Textfeld MM.DD.YYYY Ersteller Anzeigeparameter - String Textfeld - Becke Tabelle 6: Parameter UI, Übersicht/Auswahl Angebotskalkulationsversion Falls kein Zählpunkt vorgegeben wird, sind alle Kalkulationsversionen zu dem Geschäftspartner und dem Zeitraum der Lieferung anzuzeigen. Bei einer nicht korrekten oder unvollständigen Eingabe in der Suchmaske sind die Fehlermeldungen im unteren Bildschirmbereich anzuzeigen. Um eine Kalkulationsversion zur Anzeige der Kalkulationsergebnisse zu selektieren oder die komplette Kalkulationsversion zu löschen, sind diese Funktionen zur Verfügung zu stellen. In der Abbildung 27 ist das Layout des UI Übersicht/Auswahl Angebotskalkulationsversion Strom dargestellt.

98 Prototypischer Entwurf einer SOA 84 Abbildung 27: Layout UI; Übersicht/Auswahl Angebotskalkulationsversion Nachdem eine Kalkulationsversion gelöscht wurde, wird die Liste Kalkulationsversionen Strom automatisch aktualisiert. Bei der Selektion einer Kalkulationsversion zur Ansicht der Kalkulationsergebnisse erfolgt eine automatische Weiterleitung zum UI Anzeige Ergebnis Angebotskalkulationsversion. Die Parameter und das Layout des UIs zur Anzeige der Ergebnisse einer Angebotskalkulationsversion sind aufgrund des Umfangs der Anlage C zu entnehmen. 5.3 Anwendungs- und Systemarchitektur Im Mittelpunkt der konzipierten Anwendungs- und Systemarchitektur steht ein ESB (JBI Service Container) als Integrationsinfrastruktur, mit dem eine Entkopplung von Funktionalität und Technologie sowie eine entsprechende Integration gewährleistet werden soll. Hierzu werden die hier definierten Services mittels standardisierter Binding Components SOAP/HTTP und JMS adaptiert und Unterschiede in den Nachrichtenformaten oder Transportprotokollen mithilfe eines NMR als zentraler Nachrichtenbus überbrückt. Die Geschäftslogik des Geschäftsprozesses zur Angebotskalkulation wird mittels einer WS-BPEL- Service Engine bereitgestellt, indem die Services gemäß dem definierten Geschäftsprozess orchestriert werden. Dieser Orchestrierungsdienst wird von einer Web-Anwendung (Client) konsumiert und innerhalb dieser zur Ausführung angeboten. Des Weiteren wird zur Überwachung des Prozessstatus eine MBean des Management Frameworks als Service zur Verfügung gestellt, die ebenfalls vom Client konsumiert werden kann. In Abbildung 28 ist die Architektur der Anwendungsintegration vereinfacht dargestellt.

99 Prototypischer Entwurf einer SOA 85 Abbildung 28: Design der Anwendungsintegration Um einen Überblick über die physische Hardware- und Softwareumgebung und die Verteilung der Komponenten zu vermitteln, wird die Architektur anhand eines Verteilungsdiagramms modelliert. Ein Verteilungsdiagramm (deployment diagram) ist ein grafisches Implementierungsdiagramm zum Abbilden von Laufzeitstrukturen. Es beschreibt die Verteilung von Softwarekomponenten auf Hardwareeinheiten, die auch als Knoten bezeichnet werden. Auf ihrer Basis werden Entscheidungen über eventuell anzuschaffende Hard- und Softwarekomponenten getroffen. 180 In Abbildung 29 wird das Verteilungsdiagramm für den zu realisierenden Prototyp dargestellt. Die Benutzerinteraktionen erfolgen mithilfe einer client workstation, die einen PC darstellt, mit dessen Hilfe die Dienste des Prototyps in Anspruch genommen werden können. Hierbei kann der Benutzer die Web-Anwendung mithilfe eines Web Browsers aufrufen. Die Web-Anwendung beruht auf dem Open-Source Framework Struts, die einem Java EE-konformen Applikationsserver als Laufzeitumgebung nutzt. Die Services zur Abbildung des Geschäftsprozesses nutzen ebenfalls einen Java EE-konformen Applikationsserver als Laufzeitumgebung. Die Services kapseln hierbei Daten und Funktionalitäten aus einem SAP-System und einer sepa- 180 Vgl. [Kech06], S

100 Prototypischer Entwurf einer SOA 86 raten Datenbank. Für die Übermittlung einer Benachrichtigung per ist des Weiteren eine Anbindung an einen SMTP-Server erforderlich. Die Services werden mittels der Prozessbeschreibungssprache WS-BPEL zu Geschäftsprozessen orchestriert und mithilfe einer WS-BPEL-Service-Engine ausgeführt. Um eine Entkopplung von Funktionalität und Technologie sowie eine Integration zu gewährleisten, wird ein ESB (JBI Service Container) als Integrationsinfrastruktur genutzt. Dieser ist in die drei Bestandteile NMR, Component Framework und Management Framework zu unterteilen. Abbildung 29: Verteilungsdiagramm

101 Prototypische Implementierung einer SOA 87 6 Prototypische Implementierung einer SOA Im Folgenden wird die Implementierung der User-Interfaces (Application Frontends), Prozessschicht und Basisschicht einer SOA unter Verwendung eines ESB erläutert. Hierbei wird der im Kapitel 5.1 definierte Geschäftsprozess einer Angebotskalkulation Strom als Prototyp implementiert. Der Prototyp zeigt dabei die technologische Umsetzung einer SOA für einen EVU auf. 6.1 Integrations- und Technologieplattform JBI beschreibt und standardisiert den Aufbau einer verteilten, plattform- und technikunabhängigen Integrationsinfrastruktur einer SOA und soll als Basis zur Umsetzung dienen. Zurzeit existieren zwei JBI-Implementierungen mit einem zufriedenstellenden Reifegrad. Zum einen ist aus der Referenzimplementierung der JBI-Spezifikation ein Open-Source-Projekt der SUN-Microsystems mit dem Namen openesb entstanden. Zum anderen ist in diesem Kontext der ServiceMix Enterprise Service Bus der Apache Foundation zu nennen, der ebenfalls auf dem JBI-Standard beruht. Die Unterschiede der ESB-Funktionalitäten sind dabei sehr gering, da durch den JBI-Standard die Komponenten des ESB austauschbar sind und gemeinsame Service Engines und Binding Components e- xistieren. Ein wesentlicher Vorteil des openesb im Gegensatz zum Service- Mix ist die direkte Administration des JBI-Systems, mithilfe des Centralized Administration Server (CAS), der direkt im openesb integriert ist. Des Weiteren steht mit NetBeans IDE 181 eine auf den openesb abgestimmte, übersichtliche und gut strukturierte Entwicklungsumgebung zur Verfügung, die bei einem komplexen JBI-System sehr hilfreich ist und bei dem ServiceMix ESB in dieser Art nicht vorhanden ist. Obwohl auch die Möglichkeit existiert, den openesb in Verbindung mit verschiedenen Anwendungsservern, wie z.b. JBoss, oder BEA WebLogic zu nutzen, ist der Anwendungsserver Glassfish stark integriert. Dieser Anwen- 181 NetBeans IDE ist eine Open Source Entwicklungsumgebung von Sun Microsystems.

102 Prototypische Implementierung einer SOA 88 dungsserver beinhaltet standardmäßig eine WS-BPEL-Engine, welche die in NetBeans modellierten Prozesse direkt ausführt. Die technologische Umsetzung basiert somit maßgeblich auf Grundlage der Open-Source-Projekte Glassfish V2, OpenESB V2, NetBeans IDE 6.1 und der Datenbank MySQL. Eine Beschreibung der Systemkonfiguration ist der Anlage D zu entnehmen. 6.2 Services Unter Verwendung der Programmiersprache Java werden die in Kapitel definierten Basis-Services und der JMX-Service LsyasBPELProcessMonitoring als stateless Session Beans implementiert und mittels JAX-WS 182 als Web Services publiziert. Dies bedeutet, dass Funktionalitäten einer erstellten Session Bean als Web Service zur Verfügung gestellt werden, deren Schnittstelle mittels WSDL beschrieben wird. Dieses Verfahren wird auch als Bottom-up- Entwicklungsansatz beschrieben. Ein Top-down-Entwicklungsansatz hingegen beschreibt die Entwicklung eines Web Services ausgehend von einer vorher definierten WSDL-Datei. Die NetBeans IDE stellt für beide Entwicklungsansätze Assistenten (Wizards) bereit, die den Benutzer durch alle notwendigen Schritte führt, um aus einer stateless Session Bean einen Web Service zu erzeugen. Hierbei wird für die Serviceimplementierung eine Bean, d.h. eine Web-Service-Bean mit der Annotation erzeugt. Anhand der optionalen werden nur die annotierten Methoden als Operationen in die WSDL-Datei übernommen. Wenn keine Methode annotiert ist, werden alle Methoden als Web- Service-Operationen angeboten. So bietet z.b. der Web Service LsyasPremiseService die Methode calculatepremisevalue des Interfaces LsyasRemise- Local als Web-Service-Operation an (siehe Abbildung 30). 182 JAX-WS (Java API for XML - Web Services) ist eine Java API zum Erstellen und Konsumieren von Web Services.

103 Prototypische Implementierung einer SOA 89 Abbildung 30: Web-Service-Bean des Web Services LsyasPremiseService Technische Einzelheiten des Web Services, wie z.b. die optimierte Übertragung binärer Daten mittels MTOM oder das zu verwendende Übertragungsprotokoll, werden in der Web Service Configuration der NetBeans IDE, d.h. im Binding- Element festgelegt, indem die entsprechenden Parameter gesetzt werden. Für diesen Prototyp wird innerhalb der Web Service Configuration der Services Lsyas-LoadCourseService und LsyasPurchasePriceService eine optimierte Übertragung binärer Daten mittels MTOM aktiviert. Dies wird in Abbildung 29 anhand des Services LsyasLoadCourseService exemplarisch dargestellt. Abbildung 31: Web Service MTOM Konfiguration LsyasLoadCourseService Hierdurch werden automatisch die notwendigen Einstellungen gemäß der MTOM Serialization Policy Assertion (WS-MTOMPolicy) 183 im Binding- Element der WSDL-Datei vorgenommen, um somit eine Übertragung mittels MTOM zu gewährleisten. Das verwendete Kommunikationsprotokoll der in Kapitel definierten Basis- Services und des JMX-Services LsyasBPELProcessMonitoring stellt SOAP und das verwendete Übertragungsprotokoll HTTP dar. Diese Services sind so- 183 Für weitere Informationen über MTOM Serialization Policy Assertion : W3C (Hrsg.): MTOM Serialization Policy Assertion (WS-MTOMPolicy) Version 1.0.

104 Prototypische Implementierung einer SOA 90 mit abschließend mithilfe eines SOAP/HTTP-Binding des ESB zu adaptieren. Das Kommunikationsprotokoll des Services Lsyas NotificationService stellt hingegen JMS dar. Dieser Service wird als Message-Driven-Bean (MDB) implementiert. Eine MDB stellt eine spezielle Form einer Enterprise Java Bean (EJB) für die Verarbeitung von Nachrichten in einem Nachrichtensystem dar. Eine EJB wird durch die in welcher der Name und entsprechende Eigenschaften festgelegt werden, zu einer MDB (siehe Abbildung 32). Abbildung 32: Message-Driven Bean Lsyas NotificationService Dabei enthält die MDB eine onmessage -Methode, welche automatisch beim Eintreffen einer Nachricht (hier: TextMessage) im Queue der MOM aufgerufen wird und die Verarbeitung der Nachricht übernimmt, indem eine - Benachrichtigung an die angegebene -Adresse gesendet wird. Die Beschreibung der Schnittstelle des JMS-Services erfolgt, wie bei Web Services, mithilfe einer WSDL-Datei, um den Service abstrakt und plattformunabhängig zu beschreiben. Somit lässt sich der Service problemlos in den ESB integrieren. Der abstrakte und konkrete Teil der WSDL-Datei ist dabei manuell zu erstellen, da ein Web Service nur auf Basis einer stateless Session Bean erstellt werden kann und somit keine API, wie z.b. mittels JAX-WS, existiert. In der WSDL-Datei Lsyas NotificationWSDL.wsdl ist der PortType und somit die am Service aufrufbare Operation notification definiert (siehe Abbildung 33). Abbildung 33: Schnittstelle des Services Lsyas NotificationService

105 Prototypische Implementierung einer SOA 91 Die eigentliche Struktur der Input-Nachricht wird dabei durch den komplexen Datentyp emainotificationmessage definiert. Dieser komplexe Datentyp ist innerhalb des XML-Schemas Lsyas NotificationSchema.xsd anhand der entsprechenden Nachrichtenelemente konkretisiert (siehe Abbildung 34). Abbildung 34: Input-Nachricht Lsyas NotificationService Mithilfe des Binding-Elements erfolgt die Festlegung an das Kommunikationsprotokoll JMS. Hierzu ist innerhalb des JMS-Bindings die Zuordnung der im konkreten Teil definierten Operation und Input-Nachricht festzulegen. In Abbildung 35 ist das JMS-Binding dargestellt. Abbildung 35: Binding-Element Lsyas NotificationService Mithilfe des Service-Elements innerhalb der WSDL-Datei erfolgt die Gruppierung des Endpunkts zu einer Schnittstelle. Hier ist die JMS-Verbindung mittels URL, Benutzername und Passwort zu definieren (siehe Abbildung 36). Abbildung 36: Service-Element Lsyas NotificationService

106 Prototypische Implementierung einer SOA 92 Der JMS-Service Lsyas NotificationService lässt sich somit abschließend über die hier definierte WSDL-Datei und mithilfe eines JMS-Binding in die Integrationsinfrastruktur des ESB integrieren. 6.3 Prozess-Orchestrierung Die somit zur Verfügung stehenden Services, Basis-Services und JMS-Service, sind mithilfe der Prozessbeschreibungssprache WS-BPEL zu dem Geschäftsprozess Angebotskalkulation Strom zu orchestrieren. Des Weiteren ist der Service LsyasPurchasePriceAsyncBPELProcess zur Abbildung des Prozessschrittes Individualbepreisung durchführen innerhalb eines asynchronen WS- BPEL-Prozesses zu kapseln und mithilfe eines Wait -Elements eine Benutzerinteraktion zu simulieren. Im weiteren Verlauf wird maßgeblich auf die Implementierung des WS-BPEL-Prozesses zur Darstellung des Geschäftsprozess Angebotskalkulation Strom eingegangen. Die Schnittstelle des Orchestrierungsdienstes LsyasQuotationCostingElectricityBPELProcess ist mithilfe einer WSDL-Datei zu definieren. Der abstrakte und konkrete Teil der WSDL-Datei ist dabei manuell darzulegen. Hierbei ist zu beachten, dass der Orchestrierungsdienst eine asynchrone Kommunikation mittels zweier Einwegoperationen unterstützten soll (siehe Kapitel 5.2.2), die zusammen eine Request-Response-Operation darstellen. Somit sind die Services LsyasQuotationCostingElectricity_AsyncService zum Aufruf des Prozesses (Request) und LsyasQuotationCostingElectricity_CallbackService zum möglichen Callback (Response) zur Verfügung zu stellen. In der WSDL-Datei LsyasQuotationCostingElectricity.wsdl sind die entsprechenden PortTypes, d.h. die Services mit den dazugehörigen Operationen definiert (siehe Abbildung 37). Abbildung 37: Schnittstellen LsyasQuotationCostingElectricityBPELProcess

107 Prototypische Implementierung einer SOA 93 Die Strukturen der Input- und Output-Nachrichten werden dabei durch die komplexen Datentypen LsyasQuotationCostingElectrictyInput und LsyasQuotationCostingElectrictyOutput definiert. Diese komplexen Datentypen sind innerhalb des XML-Schemas LsyasQuotationCostingElectricitySchema.xsd anhand der Nachrichtenelemente konkretisiert. In Abbildung 38 sind die Nachrichtenelemente der komplexen Datentypen LsyasQuotationCostingElectrictyInput und LsyasQuotationCostingElectrictyOutput dargestellt. Abbildung 38: Input-/Output-Nachricht LsyasQuotationCostingElectricity- BPELProcess Die Festlegung an das Kommunikationsprotokoll SOAP erfolgt mithilfe des Binding-Elements und die Gruppierung der Endpunkte zu den entsprechenden Schnittstellen geschieht mithilfe des Service-Elements der WSDL-Datei. Da innerhalb des WS-BPEL-Prozesses LsyasQuotationCostingElectricityB- PELProcess ein asynchroner Aufruf des Services LsyasPurchasePriceAsyncBPELProcess zur manuellen Bepreisung realisiert werden soll, ist eine a- synchron eintreffende Antwort der korrekten Prozessinstanz zuzuordnen. Hierzu erfolgt in WS-BPEL eine Abbildung von Informationen aus den Nachrichten auf eine konkrete Prozessinstanz mithilfe sogenannter Korrelationsmengen

108 Prototypische Implementierung einer SOA 94 (Correlation Sets) 184, wobei für einen Prozess, je nach Sicht, mehrere Korrelationsmengen existieren können. Eine Korrelationsmenge enthält dabei Informationen, die einen Prozess eindeutig identifizieren. Dies ermöglicht eine Konversationen mit mehreren Partnern, indem Anwendungslogik, welche die Nachrichten der Konversationen dem jeweiligen Geschäftsprozess zuweist, genutzt wird. Hierzu sind in der WSDL-Datei des Orchestrierungsdienstes LsyasQuotation- CostingElectricityBPELProcess zusätzliche Merkmale, sogenannte Properties für eine Korrelationsmenge zu definieren. Anhand einer oder mehrerer Properties erfolgt innerhalb einer Korrelationsmenge eine eindeutige Zuordnung zur Prozessinstanz. Um eine Beziehung zwischen der hier definierten Property correlatorprop" und dem Nachrichteninhalt zur eindeutigen Identifizierung des Prozesses herzustellen, ist die Verwendung des propertyalias -Elements notwendig (siehe Abbildung 39). Abbildung 39: Property-Element LsyasQuotationCostingElectricity- BPELProcess Die eindeutige Identifizierung des Prozesses erfolgt hierbei über einen zusammengesetzten Parameter correlationasync, der aus Zählernummer und sekundengenauer Prozesszeit besteht. Dieser Parameter wird dem asynchronen Service LsyasPurchasePriceAsyncBPELProcess zur Individualbepreisung als Inputparameter zugewiesen und nach erfolgreicher Ausführung wieder vom Service zurückgegeben. Anschließend kann die Property correlatorprop" innerhalb der hier definierten Korrelationsmenge correlatorpurchasepriceasync" des WS-BPEL-Prozesses genutzt werden (siehe Abbildung 40). 184 WS-BPEL 2.0 spezifiziert nicht die Nutzung von WS-Addressing. Grundsätzlich kann zur I- dentifizierung eines WS-BPEL-Prozesses auch WS-Addressing als Alternative zu Korrelationsmengen genutzt werden.

109 Prototypische Implementierung einer SOA 95 Abbildung 40: Korrelationsmenge LsyasQuotationCostingElectricity- BPELProcess Um die Korrelationsmenge correlatorpurchasepriceasync" innerhalb des Prozessverlaufes mit Werten zu füllen, muss innerhalb der invoke - und receive - Aktivität des WS-BPEL-Prozesses ein correlation -Element vorhanden sein. Falls hierbei initiate= yes angegeben ist, wird die aktuelle Korrelationsmenge mit neuen Werten überschrieben, unabhängig davon, ob es bereits vorher initialisiert wurde. In Abbildung 40 ist beispielhaft das correlation -Element innerhalb der invoke -Aktivität des Services LsyasPurchasePriceAsyncBPELProcess zur Individualbepreisung dargestellt. Abbildung 41: Korrelationselement LsyasQuotationCostingElectricity- BPELProcess Somit erfolgt eine eindeutige Zuordnung des asynchronen Services LsyasPurchasePriceAsyncBPELProcess zu dem Service LsyasQuotationCostingElectricityBPELProcess. Da der Service LsyasQuotationCostingElectricityBPELProcess zur Übertragung von Binärdaten ebenfalls MTOM nutzen soll, sind die notwendigen MTOM-Policy-Einstellungen gemäß der MTOM Serialization Policy Assertion (WS-MTOMPolicy) 185 im Binding-Element der WSDL-Datei vorzunehmen. Im Gegensatz zu einer automatischen Generierung von Web Services und einer WSDL-Datei mittels JAX-WS auf Basis von stateless Session Beans steht für eine Web Service Definition auf Basis eines WS-BPEL-Prozesses keine Web Service Configuration innerhalb der NetBeans IDE zur Verfügung. Somit sind 185 Für weitere Informationen über MTOM Serialization Policy Assertion : W3C (Hrsg.): MTOM Serialization Policy Assertion (WS-MTOMPolicy) Version 1.0.

110 Prototypische Implementierung einer SOA 96 die MTOM-Policy-Einstellungen manuell in der WSDL-Datei vorzugeben, um somit eine Übertragung mittels MTOM zu gewährleisten (siehe Abbildung 42). Abbildung 42: MTOM Konfiguration LsyasQuotationCostingElectricity- BPELProcess Innerhalb des Policy-Elements der WSDL-Datei wird hierbei auf den XML- Namensraum der MTOM-Spezifikation verwiesen. Die eigentliche Zuweisung zur MTOM-Spezifikation erfolgt innerhalb des Binding-Elements, indem ein Verweis auf die Policy erfolgt. Somit wird festgelegt, dass für alle Binärdaten innerhalb des Binding-Elements MTOM zu nutzen ist. Nach der Definition der WSDL-Datei und somit der Schnittstelle des Services kann der Geschäftsprozess einer Angebotskalkulation modelliert werden. Der WS-BPEL-Prozess muss hierbei nicht in XML geschrieben werden, sondern kann über das grafische Modellierungswerkzeug der Net Beans IDE erstellt werden. Der modellierte WS-BPEL-Prozess Angebotskalkulation Strom ist dabei der Anlage D zu entnehmen. Die grafische Modellierung orientiert sich an BPMN und ermöglicht eine automatisierte WS-BPEL-Code-Generierung. Hierzu können in der Design-Ansicht der Net Beans IDE die benötigten WS-BPEL Sprachelemente per drag&drop innerhalb des WS-BPEL-Dokuments platziert werden. Hierdurch wird automatisch der WS-BPEL-Code erzeugt, welcher in der sog. Source-Ansicht ersichtlich ist und dort weiter modifiziert werden kann. Zunächst wird die Input-Nachricht LsyasQuotationCostingElectrictyInput, die innerhalb der WSDL-Datei definiert ist, dem WS-BPEL-Prozess über einen

111 Prototypische Implementierung einer SOA 97 PartnerLink als Receive-Element zugewiesen. Die Output-Nachricht Lsyas- QuotationCostingElectrictyOutput der WSDL definiert das Invoke-Element des Callback-Services. Diese Elemente definieren somit ein asynchrones Request- Response- Aufrufmuster des Prozesses gegenüber einer aufrufenden Instanz. Im Anschluss an das Receive-Element folgen die elementaren und strukturierten Aktivitäten zur Prozessflusssteuerung gemäß des in Kapitel 5.1 analysierten Geschäftprozesses einer Angebotskalkulation Strom. Die benötigten Services werden mittels partnerlinks eingebunden. Beim Anlegen eines partnerlinks erfolgt die Zuweisung unter Verwendung der URL des Services. Daraufhin wird eine zusätzliche WSDL-Datei angelegt, welche den Zusatz <ServiceName>Wrapper.wsdl enthält. Innerhalb dieser wird der partnerlink definiert. In Abbildung 43 ist exemplarisch die WSDL-Datei LsyasPremiseWrapper.wsdl dargestellt, in der die Partnerrolle des Services LsyasPremiseService festgelegt ist. Abbildung 43: Partner-Link des Services LsyasPremiseService Anschließend können die von den Services zur Verfügung gestellten Operationen mithilfe von invoke -Aktivitäten aufgerufen werden, indem die partner- Links adressiert werden. Um die Input- und Output-Nachrichten der aufgerufenen Services in den WS-BPEL-Prozess einzubinden, können diese innerhalb von assign -Aktiväten anderen Services zugewiesen werden. Die Zuordnung der Nachrichten erfolgt dabei innerhalb der Mapper-Ansicht des grafischen Modellierungswerkzeugs der Net Beans IDE. In der Abbildung 44 ist exemplarisch die Zuordnung der Output-Nachricht des Services LysasMeteringPointService zur Input-Nachricht des Services LsyasPremiseService dargestellt.

112 Prototypische Implementierung einer SOA 98 Abbildung 44: Assign-Aktivität LsyasMeteringPointService Des Weiteren können innerhalb dieser Mapper-Ansicht X-Path-Ausdrücke für strukturierte Aktivitäten, wie z.b. if-then-else oder foreach, grafisch beschrieben werden. Mithilfe von if-then-else -Aktivitäten werden innerhalb dieses Prozesses Prozessflusssteuerungen festgelegt, indem definiert wird, ob und welche Services ausgeführt werden sollen. So wird abhängig von der prognostizierten Absatzmenge zur Laufzeit entschieden, ob die Bepreisung automatisiert nach sog. Terminpreiskurven (HPFC) oder individuell durch einen Beschaffungsmitarbeiter durchführt wird. Des Weiteren wird mithilfe einer if-thenelse -Aktivität zur Laufzeit geprüft, ob eine -Benachrichtung mithilfe des Services Lsyas NotificationService erfolgen soll und ob eine asynchrone Antwort (Callback) vom Servicenutzer (Client) des Prozesses gewünscht ist. ForEach -Ativitäten werden innerhalb des Prozesses genutzt, um über Elemente einer Liste innerhalb einer Input- und Output-Nachricht zu iterieren. Hierzu wird während einer foreach -Aktivität ein sog. Counter eingesetzt, der im Vorfeld die Länge einer Liste erfasst und somit die Anzahl der notwendigen Iterationen bestimmt. Falls zur Laufzeit innerhalb des WS-BEPL-Prozesses ein Fehler auftritt, wird dieser durch die Realisierung einer allgemeinen Fehlerbehandlung innerhalb eines catchall -Elements abgefangen. Hierbei wird, falls erforderlich, eine E- mail-benachrichtigung über die nicht erfolgreiche Erstellung einer Angebotskalkulation an den Benutzer und eine asynchrone Antwort in Form einer Fehlermeldung an den Servicenutzer gesendet. Um für eine spätere Fehleranalyse oder einer allgemeinen Prozesskontrolle die Prozessschritte innerhalb des WS- BPEL-Prozesses nachvollziehen zu können, werden diese in einer automatisch erstellten Protokolldatei der WS-BPEL-Server-Engine protokolliert. Hierzu wird den Prozessschritten unter der sog. Logging-Ansicht innerhalb des grafischen

113 Prototypische Implementierung einer SOA 99 Modellierungswerkzeuges der NetBeans IDE ein entsprechender Log-Datei- Eintrag definiert, wodurch innerhalb des WS-BPEL-Dokuments ein sog. Trace - Element erzeugt wird. Somit werden zu den Prozessschritten zur Laufzeit Log- Datei-Einträge in die Protokolldatei (Log-Datei) des Anwendungsservers geschrieben, wodurch eine effiziente Fehleranalyse oder Prozesskontrolle ermöglicht wird. Abschließend wird der erstellte WS-BPEL-Prozess in einem sog. WS-BPEL- Modul als Java Archiv (JAR) gekapselt und als sog. Composite Application auf dem Anwendungsserver zur Verfügung gestellt. Dieser Prozess kann somit zur Laufzeit mithilfe der WS-BPEL-Server Engine ausgeführt werden. Die Einbindung der orchestrierten Services und des WS-BPEL-Moduls innerhalb des JBI- Containers ist der Anlage D zu entnehmen. 6.4 User Interfaces User Interfaces (UIs) stellen, wie bereits im Kapitel erläutert, Benutzerschnittstellen dar, um mit den Funktionalitäten von Anwendungen oder Services zu interagieren und repräsentieren somit Application Frontends einer SOA. Diese werden mithilfe des Java Open-Source-Framework Struts für die Präsentations- und Steuerungsschicht von Webanwendungen implementiert. Gemäß des Model-View-Controller (MVC, Modell/Präsentation/Steuerung ) Designpattern verwendet Struts die drei folgenden Hauptkomponenten, um somit eine Trennung von Präsentation, Steuerung und Modell zu erreichen: Präsentation: Servlets in Form von JavaServer Pages (JSP). Steuerung: Schnittstelle zwischen Präsentation und Anwendungslogik. Wird durch eine Action repräsentiert, die Daten beschafft und aktualisiert. Modell: Datenhaltung und Validierung in Action-Forms. Eine Action- Form stellt eine Java Bean dar, welche die benötigten Daten für die Action und die JSP enthält. So zählen zu jeder Action eine Action-Form und ein Action-Objekt.

114 Prototypische Implementierung einer SOA 100 Die eigentliche Konfiguration erfolgt zentral über eine ActionServlet, indem alle Komponenten miteinander verknüpft werden, damit diese miteinander agieren können. Die Konfiguration des ActionServlets geschieht in einer XML-Datei ( struts-config.xml ), die bei jedem Start des Frameworks eingelesen wird. In Abbildung 45 sind die JSPs, Actions und FormBeans für den hier erstellten Prototyp contactenergy dargestellt. Abbildung 45: Struts Komponenten - Prototyp contactenergy Das Servlet Login repräsentiert eine Benutzeranmeldung. In der dazugehörigen Action (LoginAction) ist für einen Produktivbetrieb eine Komponente zur Benutzer-Authentifizierung und Benutzer-Authorisierung einzubinden. Nach der erfolgreichen Anmeldung erfolgt die automatische Weiterleitung zum Servlet WelcomeContactEnergy, in dem die Funktionalitäten der Web-Anwendung in einer Übersicht dargestellt werden. Möchte ein Benutzer eine neue Angebotskalkulationsversion erfassen, erfolgt mithilfe des entsprechenden Links eine Weiterleitung zum Servlet QuotationCostingProcess, das dem UI Erfassung Angebotskalkulationsversion entspricht. Möchte sich der Benutzer hingegen eine existierende Angebotskalkulationsversion anzeigen lassen, erfolgt mithilfe des entsprechenden Links eine Weiterleitung zum Servlet Quotation- CostingList. Dieses Servlet entspricht dem UI Übersicht/Auswahl Angebotskalkulationsversion. Bei der Auswahl einer Angebotskalkulationsversion zur Detailansicht gelangt der Benutzer automatisch zum Servlet Quotation- CostingResult, welches das UI Anzeige Ergebnis Angebotskalkulationsversion repräsentiert. Actions stellen die Schnittstelle zwischen Präsentation und Anwendungslogik dar. Somit werden mithilfe von Actions die Web Services aufgerufen. Die benö-

115 Prototypische Implementierung einer SOA 101 tigten Parameter für den Aufruf einer Web Service Operation werden dabei aus dem ActionForm-Objekt gelesen. Falls es sich nicht um eine Einwegoperation handelt, werden anschließend die Ergebnisse von der Action ausgewertet und die Werte im ActionForm-Objekt abgelegt. Um das Zusammenspiel zwischen Struts-Anwendung und Aufruf einer Web Service Operation zu verdeutlichen, wird in Abbildung 46 das implementierte Szenario Erstellung einer Angebotskalkulationsversion ohne Callback unter Verwendung der Einwegoperation, d.h. des Services QuotationCostingElectricity_AsyncService des Orchestrierungsservices LsyasQuotationCostingElectricityBPEL dargestellt. Abbildung 46: Erstellung einer Angebotskalkulationsversion ohne Callback Innerhalb der Action QuotationCostingProcessAction wird die von der Superklasse org.apache.struts.action überschriebene execute -Methode aufgerufen, die den Web Service - Aufruf kapselt. Die Actions QuotationCostingProcessAction, QuotationCostingListAction und QuotationCostingResultAction dienen innerhalb dieses Prototyps als Web- Service-Clients, welche Operationen der Services LsyasQuotationCostingElectricityBPEL und LsyasCostingVersionDataService konsumieren. In

116 Prototypische Implementierung einer SOA 102 Abbildung 47 werden die aufgerufenen Service-Operationen innerhalb der Actions dargestellt. 186 Abbildung 47: Zuordnung Actions und Web Service Operationen Innerhalb der Action QuotationCostingResultAction wird je nach Benutzerinteraktion das Ergebnis einer ausgewählten Angebotskalkulationsversion aus der Datenbank gelesen oder die ausgewählte Angebotskalkulationsversion aus der Datenbank gelöscht. Diese Action leitet dabei nicht von der Superklasse org.apache.struts.action, sondern von der Klasse org.apache.struts.dispatch- Action ab. Somit können innerhalb der Action QuotationCostingResultAction nicht nur eine execute -Methode, sondern je nach Anwendungsfall unterschiedliche Web-Service-Operationen zum Anzeigen oder zum Löschen einer Angebotskalkulationsversion aufgerufen werden. Auf der Clientseite wird der gewünschte Web-Service anhand einer URI adressiert und mittels JAX-WS ein lokales Proxy-Objekt erzeugt, welches die Schnittstelle des Web Services darstellt. Bei der Generierung eines Proxies zur Laufzeit wird der URI für den Web Service Aufruf aus dem port -Element der WSDL-Datei gelesen. Um eine Referenz auf die Service-Klassen zu erhalten, wird die Factory-Methode Service.create() benutzt. Somit lassen sich über die Service-Klassen die Endpoint-Interfaces des Web Services mit der get-port - Methode ermitteln und die Web-Service-Operationen ausführen. In Abbildung 186 Das Polling-Interaktionsmuster wird bereits in der Web-Anwendung contact der Lufthansa Systems AS GmbH als möglicher Servicenutzer umgesetzt. Bei einer Produktivsetzung innerhalb dieser Web-Anwendung ist der Service LsyasBPELProcessMonitoring zu konsumieren, um den Prozessstatus zu überprüfen. Auf die Umsetzung eines Callback-Handlers innerhalb dieses Prototyps wurde aufgrund einer zunehmenden Komplexität bewusst verzichtet.

117 Prototypische Implementierung einer SOA wird der Aufruf der Factory-Methode und der get-port -Methode innerhalb der Action QuotationCostingProcessAction dargestellt. Abbildung 48: JAX-WS-Client QuotationCostingProcessAction Die Action-Klasse führt dabei den Methodenaufruf an dem Proxy-Objekt aus, als wäre der Web Service lokal verfügbar. Im Hintergrund sendet das JAX-WS Runtime System den Aufruf von dem Proxy-Objekt an den Web Service weiter. Dieser führt dabei den in Kapitel 6.3 implementierten und bereit gestellten WS- BPEL-Prozess einer Angebotskalkulation Strom aus.

118 Bewertung Bewertung Nachdem die allgemeinen Konzepte einer serviceorientierten Architektur in Kapitel 4 dargestellt wurden und in den nachfolgenden Kapiteln ein prototypischer Entwurf sowie eine prototypische Implementierung einer serviceorientierten Architektur anhand eines Geschäftsprozesses eines EVU vorgenommen wurden, erfolgt in diesem Kapitel eine Bewertung. Hierbei wird zuerst eine Bewertung zur Einführung einer SOA für ein EVU anhand der in Kapitel 2.3 definierten Minimalanforderungen an eine IT-Architektur durchgeführt. Des Weiteren wird die hier verwendete Integrations- und Technologieplattform zur prototypischen Umsetzung hinsichtlich einer produktiven Einsetzbarkeit bewertet. Für die Bewertungen werden Erfahrungen bei der Realisierung des Prototyps verwendet. 7.1 Serviceorientierte Anwendungsintegration für ein EVU Zur Bewältigung der in Kapitel 2.2 definierten Herausforderungen für ein EVU bedarf es eines wandlungsfähigen und flexiblen IT-Architekturkonzeptes. Dieses sollte hierzu die in Kapitel 2.3 definierten Minimalanforderungen an eine IT- Architektur für ein EVU erfüllen. Das technologieunabhängige Architekturkonzept einer SOA, wie im Kapitel 4 beschrieben, stellt hierbei einen Ansatz zur Entwicklung einer flexiblen, agilen und effektiven Systemarchitektur dar. Diese soll eine flexiblere Anwendungsintegration und Anpassung der Geschäftsprozesse durch Services ermöglichen, als die bisher traditionellen, monolithischen Applikationen und Systeme einer heterogenen IT-Landschaft. Im Folgenden wird das Architekturkonzept einer SOA anhand der im Kapitel 2.3 definierten Minimalanforderungen bewertet: Integration: Die Basiseigenschaften von Web Service reichen grundsätzlich für eine Integration aus. Die Flexibilität einer SOA wird jedoch dann beschränkt, wenn eine Integration per Punkt-zu-Punkt-Verbindung zwischen Serviceanbieter und Servicenutzer realisiert wird. Die Anwendung eines ESB als Integrationsinfrastruktur führt zu einer weiteren Entkopplung von Serviceanbieter und Servicenutzer. So kann ein Dienst mit-

119 Bewertung 105 tels geeigneter Binding-Components ausgetauscht werden, ohne dass andere Systemteile betroffen sind. Ein ESB stellt dabei zentrale Dienste für die Serviceentwicklung, -publikation sowie -nutzung zur Verfügung und übersetzt Datenformate und Kommunikationsprotokolle, wie z.b. SOAP/HTTP oder JMS, in gemeinsame Formate und Protokolle auf Serviceebene. Der Aufbau einer Integrationsinfrastruktur ist dabei grundsätzlich vergleichbar mit typischen EAI-Lösungen. So bietet ein ESB i.d.r. die gleichen Funktionalitäten wie ein EAI-Broker, wobei die Funktionalitäten unabhängig voneinander und verteilt implementiert werden können. Ein EAI-System mit einem zentralen EAI-Broker (Hub&Spoke- Architektur) ist jedoch eher zentralistisch ausgerichtet, wohingegen ein ESB eher für eine Verteilung ausgelegt ist und eine lose Kopplung der Dienste ermöglicht. Die Komplexität eines ESB ist dabei mit einem EAI- Broker vergleichbar. Angesichts einer Reihe unterschiedlicher heterogener Systeme und Anwendungen innerhalb eines EVUs und unternehmensübergreifend ist die Integration weitgehend zu standardisieren. JBI bietet dabei die Möglichkeit, eine plattformübergreifende standardisierte Integrationsinfrastruktur aufzubauen. Durch den Einsatz proprietärer Anwendungsadapter, wie z.b. für ein SAP-System, besteht jedoch die Gefahr einer möglichen Hersteller- und Plattformabhängigkeit, wie bei klassichen EAI-Lösungen. Dies ist durch geeignete Wrapper-Technologien zu vermeiden, indem entsprechende Backend-Funktionalitäten mittels Wrapper-Technologien als Web Services publiziert werden. Die Schnittstelle eines Wrapper- Objektes, muss dabei nicht zwangsläufig dieselbe Struktur aufweisen, wie die Datentransferobjekte des Backend-Systems, wodurch Unzulänglichkeiten in den Schnittstellen ausgeglichen werden können. Jedoch erhöhen Wrapper-Objekte durch die Einführung einer weiteren Schicht die Komplexität des Gesamtsystems und die Erstellung und Pflege dieser Wrapper-Objekte bringen einen hohen Aufwand mit sich. Dies ist bei der Einführung einer hersteller- und plattformunabhängigen Architektur, welche durch die Einführung einer SOA erreicht werden soll, zu berücksichtigen.

120 Bewertung 106 Durch die Verwendung einer MOM als Bestandteil eines ESB, die asynchrones Messaging, Publish/Subscribe und Store-and-Forward unterstützt, ist es möglich, eine zuverlässige Kommunikation zwischen lose gekoppelter Diensten innerhalb einer SOA zu erreichen. Die Ansteuerung einer MOM kann dabei u.a mit dem Standard JMS erfolgen. Die Kombination von Web Services und einer MOM innerhalb eines ESB stellt eine ideale Basis für den Aufbau einer SOA dar. Eine JMX-basierte Managementkomonente stellt des Weiteren grundsätzliche standardisierte Funktionalitäten für das Betreiben einer SOA zur Verfügung. Hierzu zählen u.a. das Deployment und Update von Prozessen und Services, die Überwachung von Aktivitäten, Start und Stop von Servern sowie Prozesse und Services oder das Ändern und Umlenken von Nachrichten. Hierzu bedarf es jedoch eines klar definierten JMX- Service-Portfolios. Zusammenfassend ist ein ESB eine Integrationsinfrastruktur, die eine verteilte, lose gekoppelte und flexible Integration sowohl unternehmensintern als auch unternehmensübergreifend ermöglicht und ausbaufähig sowie wartbar ist. Darauf aufbauend können Dienste implementiert werden, die logisch abgrenzbare Funktionalität kapseln. Somit sind eine diskriminierungsfreie Anwendungsintegration sowie eine höhere Vernetzung aller Markteilnehmer mithilfe eines ESB abzubilden. Entkopplung von Funktionalität und Technologie: Funktionale Dienste sollen ohne großen Migrationsaufwand ausgetauscht werden und nicht von einer speziellen proprietären Technologie abhängig sein. Dies erfordert einen hohen Grad der Standardisierung. Services, die technologisch mittels Web Services umgesetzt werden, besitzen eine einheitliche Schnittstellenbeschreibung wie WSDL und kommunizieren über einheitliche Protokolle, wie z.b. SOAP als Kommunikationsprotokoll sowie z.b. HTTP als Transportprotokoll. Nur durch die Verwendung offener und verbreiteter Industriestandards kann eine Interoperabilität innerhalb der Gesamtarchitektur eines EVUs erreicht werden. Anhand einer funktiona-

121 Bewertung 107 len Abstraktion einer mittels WSDL beschriebenen Schnittstelle werden dem Servicenutzer Betriebssystem, Programmiersprache und Implementierungsdetails des Dienstes verborgen. So kann die Implementierung eines Services ohne notwendige Anpassung seitens des Servicenutzers verändert werden, solange die entsprechende Schnittstelle von den Veränderungen nicht betroffen ist. Somit reduzieren sich die Entwicklungsund Wartungskosten einer Anwendungsintegration durch die Einführung einer SOA, indem standardisierte Web Services unterschiedlicher Marktteilnehmer einfach mithilfe einer einheitlich definierten Serviceschnittstelle in die IT-Infrastruktur des EVUs eingebunden werden können. Wiederverwendbarkeit: Der Grad an Generalisierung bzw. Spezialisierung eines Services bestimmt maßgeblich seine Wiederverwendbarkeit durch unterschiedliche Nutzer. Der Spezialisierungsgrad eines Services kann durch seinen Anwendungskontext gegeben sein. So ist z.b. ein Service zur Prämissenbewertung in weniger Geschäftsprozessen einsetzbar als ein Service, der z.b. die Geschäftsentität Geschäftspartner bearbeitet und liest. Der Service einer Prämissenbewertung beinhaltet prozessspezifische Fachfunktionen, welche die Wiederwendbarkeit negativ beeinflussen. Die Wiedervervendbarkeit lässt sich ebenso durch ein fachliches und technisches Servicedesign beeinflussen. Das vorgestellte Meet-in-themiddle Vorgehensmodell beginnt bei dem Geschäftsprozess und führt zu einem fachlichen Servicedesign, bei dem Services einen Prozessschritt abbilden und eine an Geschäftskonzepten orientierte Servicegranularität aufweisen. Diese Services verfügen somit über grob granulare Schnittstellen, welche die Wahrscheinlichkeit erhöhen, dass Services von zukünftigen Servicenutzern angewandt werden können. Ein technisches Servicedesign kann durch die Verwendung verbreiteter Standards, wie Web Service Standards, und durch die Unterstützung unterschiedlicher Interaktionsmuster, wie z.b. Callback und Polling, die Wiederverwendung von unterschiedlichen Servicenutzern erhöhen.

122 Bewertung 108 Im Rahmen dieser Arbeit kann die Wiederverwendung von Services und somit die damit verbundenen Einsparungen hinsichtlich der Entwicklungskosten und folgender Wartungskosten nicht eindeutig beurteilt werden, da eine mögliche serviceorientierte Architektur prototypisch umgesetzt wurde und die Wiederverwendung erst in den nachfolgenden Jahren im produktiven Einsatz als Nutzen sichtbar wird. Flexibilität: Ein entscheidender Punkt für eine SOA und deren Flexibilität ist die Ausrichtung an die Geschäftsprozesse. Durch die Kapselung von Funktionalität in voneinander unabhängigen Diensten können ausgehend von Geschäftsprozessen, unabhängige neue Dienste schnell eingeführt und existierende Dienste schnell an neue Anforderungen angepasst werden. Services unterschiedlicher Serviceschichten (siehe Kapitel 4.2.1) können aufgrund veränderter Geschäftsbedingungen flexibel zu neuen Services (Business-Services) in der Vermittlungsschicht kombiniert und zu einer Prozessbeschreibungssprache orchestriert werden. Hierzu erfolgt möglichst eine Modellierung mittels BPMN aus dessen Beschreibung die Prozessbeschreibungssprache WS-BPEL generiert wird. Durch eine grafische Modellierung und der daraus resultierenden Orchestrierung von Services können Geschäftsprozesse, die wiederum Services darstellen, schnell erstellt und geändert werden. Dies führt zu einer höheren Flexibilität in der Abbildung von Geschäftsprozessen als bei einer klassischen Programmierung und kann einen entscheidenden Wettbewerbsvorteil realisieren, indem die Kosten für die Entwicklung und Wartung von Prozesen in der IT erheblich gesenkt werden. Eine grafische Orchestrierung ist daher einer klassischen Programmierung von Prozessen vorzuziehen. Der Einsatz einer Standard Prozessbeschreibungssprache wie WS-BPEL bietet hierbei den Vorteil einer breiten Industrieunterstützung, sowie, wie in dieser Arbeit dargestellt, ausgereifte Produkte, so dass nicht zu erwarten ist, dass diese Prozessbeschreibungssprache vom Markt verschwindet oder lediglich ein kurzfristiger Trend ist. Als negativer Punkt an WS-BPEL ist eine mangelnde Unterstützung des Polling -Interaktionsmusters zu nennen. So sieht WS- BPEL nur eine standardisierte Unterstützung des Callback-

123 Bewertung 109 Interaktionsmusters zur asynchronen Kommunikation mithilfe von zwei Einwegoperationen vor. Zur Abfrage des Prozessstatus oder des Prozessergebnisses ist eine zusätzliche manuelle Implementierung, wie z.b. eines JMX-Services, erforderlich. Dies erhöht die Komplexität und den Entwicklungsaufwand zur Umsetzung des Polling-Interaktionsmusters. Demzufolge sollte das Polling -Interaktionsmuster nur in Ausnahmefällen für WS-BPEL-Prozesse eingesetzt werden. Stattdessen sollte hierbei die asynchrone Kommunikation primär mit einer MOM oder dem Callback -Interaktionsmuster umgesetzt werden. So eignet sich eine MOM innerhalb eines ESB insbesondere für eine einfache Abbildung einer a- synchronen Kommunikation. Als weiterer negativer Punkt an WS-BPEL ist die bislang kaum praxiserprobte Benutzerinteraktion mittels BPEL4People und WS-HT und die damit notwendige Eigenentwicklung zu nennen. Außerdem ist zu beachten, dass die Modellierung von WS- BPEL-Prozessen aufgrund von notwendigen technischen Wissens in z.b. Web Services nicht für Business-Analysten der Fachbereiche geeignet ist. Somit sind Geschäftsprozesse zuerst von Business-Analysten mittels BPMN zu definieren und anschließend von Entwicklern mittels WS-BPEL umzusetzen. Trotzdem ist WS-BPEL für die Umsetzung von lang laufenden und schnell anpassbaren Geschäftsprozessen vorteilhaft, wobei deren Komplexität und Einschränkungen berücksichtigt werden müssen. Eine mögliche Flexibilität einer SOA durch die Kapselung von Funktionalität in voneinander unabhängigen Diensten bedeutet auch, dass verteilte langläufige Transaktionen über mehrere Services möglichst vermieden und Services atomar, isoliert sowie grobgranular geschnitten werden sollten. Dies ist darin begründet, dass derzeit kein einfaches Transaktionsverfahren für Web Services (siehe Kapitel 4.3.2) existiert. Somit kann eine Transaktionssicherheit nach ACID-Eigenschaften über langläufige Geschäftsprozesse nicht gewährleistet werden. Sollte aus fachlicher Sicht der Aufruf mehrerer Services in einer verteilten Transaktion unumgänglich sein, so sind, trotz einiger Schwachstellen insbesondere bei der Kompensation von Services (siehe 4.3.2), standardisierte Transaktionsverfahren, wie z.b. WS-TX, zu wählen oder kompensatorische Services

124 Bewertung 110 zu entwerfen und einzubinden. Eine eindeutige Bewertung der WS-TX Spezifikation konnte in dieser Arbeit nicht vorgenommen werden, da der hier verwendete Geschäftsprozess Angebotskalkulation Strom keine verteilte Transaktionssicherheit über mehrere Serviceaufrufe hinweg erfordert. Insgesamt lässt sich festhalten, dass SOA als Architekturkonzept und eine Umsetzung mittels Web Services und einem ESB als Integrationsinfrastruktur eine geeignete flexible Architektur für ein EVU darstellt, wobei bekannte Konzepte einer EAI, wie eine MOM, verwendet werden sollten. Jedoch ist zu beachten, dass Flexibilität eine Einarbeitung in die Grundlagen und Architekturkonzepte sowie ein methodisches, systematisches Vorgehen erfordert, um die Möglichkeiten des Architekturkonzepts voll auszuschöpfen. So sind durchgängige Geschäftsprozesse zu definieren, falls diese noch nicht vorliegen, und Services in der entsprechenden Granularität festzulegen. Des Weiteren sind zur Wiederverwendung bestehender Anwendungslogik teilweise aufwändige Analysen bestehender Backend-Funktionalitäten, Anwendungen und bereits existierende Services notwendig. Die technologische Umsetzung führt zu der Einführung einer weiteren Abstraktionsebene, indem bestehende Anwendungslogik als Web Service publiziert wird. Dabei ist die Performance unbedingt bereits im Design der Services zu beachten, da ein Parsen von XML-Dokumenten zeit- und ressourcenintensiv ist. Des Weiteren erfordert die Entwicklung von Services unter Berücksichtigung der entsprechenden Standards sowie die Nutzung von WS- BPEL und die Einführung eines ESB eine anfangs hohe Einarbeitung. Dies ist bei einer Einführung zu berücksichtigen. 7.2 Integrations- und Technologieplattform - Sun openesb Die technologische Umsetzung des Prototyps basiert maßgeblich auf Grundlage der Open-Source-Projekte Glassfish V2, openesb V2 und NetBeans IDE 6.1. Abgesehen von fast 100 Partnern ist Sun Microsystems der Hauptsponsor dieser Open-Source-Projekte. Glassfish, openesb und NetBeans IDE sind dabei eng miteinander gekoppelt und können mithilfe eines SUN Java EE 5 Tools Bundle für die Plattformen Windows, Solaris, Linux oder Ma-

125 Bewertung 111 cosx installiert werden (siehe Anhang D). Die Installation ist mithilfe des vorgefertigten Installationsprogramms ohne Probleme durchführbar. Zur Erlernbarkeit stehen Tutorials 187 zur Verfügung, welche die ersten Schritte in der Entwicklung von Web-Services und WS-BPEL-Projekten sowie den Umgang mit dem openesb erläutern. Des Weiteren können weitergehende Fragen und Probleme in einem Forum 188 gepostet werden. Ziel des openesb ist es, über JBI-konforme Service-Container eine ESB- Implementierung zu ermöglichen. Hierzu können JBI-konforme-Container erstellt und mittels JMX über einen zentralen Administrationsserver verwaltet werden. Zur Nutzung des openesb als Integrationsinfrastruktur stehen zahlreiche standardisierte JBI-Komponententypen 189, d.h. Service Engines, wie z.b. WS-BPEL, XLST oder JavaEE, sowie Binding Components für z.b. HTTP, JMS oder FTP zur Verfügung. Des Weiteren können auch Binding-Components für CORBA, DCOM, MQSeries oder SAP-Systeme genutzt werden. Zur nachrichtenorientierten Kommunikation stellt der openesb einen Normalized Message Router (NMR) gemäß dem JBI-Standard zur Verfügung. Hierdurch wird a- synchrones Messaging, Publish/Subscribe und Store-and-Forward unterstützt, wodurch eine zuverlässige Kommunikation zwischen lose gekoppelten Diensten innerhalb einer SOA ermöglicht wird. Für die Entwicklung und Administration stellt die NetBeans IDE zahlreiche Funktionen zur Verfügung. So können mithilfe des Composite Application Service Assembly (CASA) Editor Service Endpunkte und JBI-Module innerhalb eines JBI-Containers per Drag&Drop verbunden und konfiguriert werden. Eine Konfiguration anhand des Prototyps ist der Anlage F zu entnehmen. Des Weiteren steht ein JBI-Manager, der in dem Server-Manager integriert ist, zur einfachen Steuerung des Lifecycles der JBI-Komponenten innerhalb der NetBeans IDE zur Verfügung (siehe Abbildung 49). 187 Erhältlich unter: 188 Aufrufbar unter: 189 Übersicht aller derzeit verfügbaren Komponenten:

126 Bewertung 112 Abbildung 49: NetBeans openesb JBI-Manager Die Strukturierung der Entwicklung von Web Services und WS-BPEL- Prozessen gemäß der im Rahmen dieser Arbeit verwendeten Web-Service- Standards ist innerhalb der NetBeans IDE schlüssig und wird durch umfangreiche Editor-Unterstützung erleichtert. So ist es möglich, XML-Dokumente über verschiedene Ansichten (Source-, Design- und Schema-View) zu manipulieren. Des Weiteren stehen für die Entwicklung von WS-BPEL-Prozessen die Ansichten Source, Design, Mapper und Logging zur Verfügung. So können z.b. innerhalb der Design -Ansicht WS-BPEL-Prozesse gemäß der BPMN modelliert und innerhalb der Mapper -Ansicht komplexe X-Path-Ausdrücke ohne tiefgehende XML-Kenntnisse erstellt werden. Die in dieser Arbeit verwendeten WS-*-Standards konnten ohne Probleme in der hier genutzten Integrations- und Technologieplattform angewandt werden. Eine Bewertung zur konfigurativen Tool-Unterstützung der WS-TX Spezifikation kann im Rahmen dieser Arbeit nicht beantwortet werden, da für den hier analysierten Geschäftsprozess Angebotskalkulation Strom keine verteilte Transaktionen benötigt wurde. Für die Beschreibung der Endpunkte innerhalb des openesb wird grundsätzlich WSDL verwendet. Oftmals können WSDL-Dateien, wie z.b. mittels JAX- WS, innerhalb der NetBeans IDE generiert werden. Leider ist die Generierung einer WSDL-Datei, wie z.b. für WS-BPEL-Prozesse, nicht immer möglich. Dies erfordert tiefgehende Kenntnisse in der WSDL-Beschreibung. Hier unterstützt die NetBeans IDE den Benutzer durch geeignete Wizards, die durch alle wesentlichen Schritte für die Erstellung einer WSDL-Datei führen. Als eher unkomfortabel wird die Ausgabe von Fehlern in der Design-Ansicht von WS-BPEL-

127 Bewertung 113 Prozessen gesehen. Hier werden nur allgemeine Hinweise zur Fehlersituation angezeigt. Eine genaue Analyse kann nur in der Source -Ansicht erfolgen. Auch auftretende Fehler zur Laufzeit werden teilweise nur sehr allgemein beschrieben, was eine Fehlersuche erheblich erschwert. Des Weiteren handelt es sich um eine sehr komplexe Integrations- und Technologieplattform, die eine gewisse Einarbeitung erfordert. Der Glassfish Anwendungsserver bildet eine Laufzeitumgebung. Obwohl auch die Möglichkeit existiert, den openesb in Verbindung mit verschiedenen Anwendungsservern, wie z.b. JBoss, oder BEA WebLogic zu nutzen, ist der Anwendungsserver Glassfish stark integriert. So können auf dem Anwendungsserver EJB und Web Anwendungen ausgeführt werden, auf die mithilfe der Java EE Service Engine des openesb problemlos zugegriffen werden kann. Eine Nutzung des openesb ohne den Glassfish Anwendungsserver ist durch die Verwendung des openesb for Java SE Distribution möglich. Jedoch sind die auf den Glassfish abgestimmten Komponententypen, d.h. Service Engines und Binding Components, nicht ohne zusätzliche manuelle Installationen und weiterer Konfiguration nutzbar. Dies erschwert die Nutzung des openesb ohne den Glassfish Anwendungsserver erheblich. Abschließend lässt sich jedoch festhalten, dass die Open-Source-Projekte Glassfish V2, openesb V2 und NetBeans IDE 6.1 einen ausgereiften Eindruck machen und sich auch zur Entwicklung einer SOA unter Produktivbedingungen eignen. Dies gilt insbeondere, falls noch keine Integrations- und Technologieplattform zur Umsetzung einer SOA vorliegt, da alle notwendigen Komponenten in einem Tool-Bundle angeboten werden. Jedoch sind die Komponenten so eng miteinander gekoppelt, dass eine Entkopplung des openesb, im Gegensatz zur Einführung eines anderen JBI-konformen ESB, wie z.b. Apache ServiceMix, zu erheblichen Mehraufwand führen kann.

128 Zusammenfassung und Ausblick Zusammenfassung und Ausblick Der erwartete Erkenntnisgewinn dieser Arbeit liegt in der Bewertung der Einsetzbarkeit des Architekturkonzepts einer SOA zur Anwendungsintegration in der Energiewirtschaft. Hierzu wurde der Geschäftsprozess Angebotskalkulation Strom gemäß einer SOA analysiert und mithilfe der Open-Source-Projekte Glassfish V2, openesb V2 und NetBeans IDE 6.1 implementiert. Konkret konnte erarbeitet werden, dass die Umsetzung einer SOA den gestiegenen Anforderungen zur Abbildung von flexiblen, sich schnell ändernden Geschäftsprozessen in der Informationstechnologie gerecht werden kann. Offene Standards ermöglichen eine hersteller- und plattformunabhängige Integration. Jedoch ist grundsätzlich zu beachten, dass die Umsetzung einer SOA ein methodisches, systematisches Vorgehen erfordert. Anhand der prototypischen Analyse und Implementierung des Geschäftsprozesses Angebotskalkulation Strom konnte dabei nachgewiesen werden, dass das Architekturkonzept einer SOA die im Abschnitt 2.3 definierten Minimalanforderungen an eine IT-Architektur für ein EVU erfüllt. Fachliche Geschäftsfunktionen der Energiewirtschaft, wie eine Prämissenbewertung, können als Dienste angeboten werden. Somit können lose gekoppelte Services zu Geschäftsprozessen, wie einer Angebotskalkulation Strom, flexibel mittels WS-BPEL orchestriert werden. Dies gewährleistet die Möglichkeit, schneller auf Innovationen und Wettbewerber reagieren zu können. Des Weiteren stellt ein ESB als Integrationsinfrastruktur die Kompatibilität und die Kommunikationsfähigkeit innerhalb einer SOA sicher. Somit können lose gekoppelte Services von verschiedenen Akteuren des Energiemarktes relativ einfach an die Integrationsinfrastruktur angeschlossen werden. Hierbei ist es wichtig, dass für die technische und fachliche Standardisierung offene, plattformunabhängige und verbreitete Industriestandards verwendet werden. Die geschäftsprozessorientierte Serviceidentifikation und das entsprechende Servicedesign von Services stellt eine große Herausforderung dar, denn es müssen sowohl unternehmensinterne als auch allgemeine, unternehmensüber-

129 Zusammenfassung und Ausblick 115 greifende Bedürfnisse verschiedener Akteure berücksichtigt werden. Für ein Servicedesign sind dabei Richtlinien hinsichtlich Interoperabilität, Granularität und Transaktionssicherheit festzulegen. Des Weiteren ist ein Vorgehensmodell für die Entwicklkung von Services auf Basis bestehender Backend- Funktionalitäten zu berücksichtigen. Um die Wiederverwendung von Services durch unterschiedliche Servicenutzer zu erhöhen, sind unterschiedliche Interaktionsmuster, wie z.b. Callback und Polling, zu berücksichtigen. Das hier beschriebene Vorgehen zur Serviceidentifikation, die Richlinien zum Servicedesign und die Klassifizierung von Services sind für die Entwicklung weiterer Services innerhalb eines EVUs zu übertragen. Somit ist ein Serviceportfolio für fachliche Geschäftsfunktionen der Energiewirtschaft aufzubauen. Eine konkrete Implementierung um eine SOA umzusetzen, stellen Web Services dar. Web Services sind in einem Netzwerk typischerweise über das Kommunikationsprotokoll SOAP erreichbar, wobei sich das Übertragungsprotokoll HTTP als Standard für die Übertragung von SOAP-Nachrichten durchgesetzt hat, wobei auch eine Übertragung mittels JMS oder anderen Übertragunsprotokollen möglich ist. Die Schnittstelle eines Web Services wird in einer WSDL- Datei beschrieben. Zur Orchestrierung von Web Services zu einem Geschäftsprozess hat sich die Prozessbeschreibungssprache WS-BPEL als De-facto- Standard durchgesetzt. WS-BPEL kann u.a. aufgrund einer fachlichen Modellierung eines Geschäftsprozesses in BPMN erzeugt werden. BPMN lässt Business-Analysten, IT-Entwicklern und anderen involvierten Personen ein gemeinsames Verständnis für Architektur, Gestaltung und Anwendung von Geschäftsprozessen entwickeln. WS-BPEL ist aufgrund notwendigen technischen Wissens in z.b. Web Services nicht für Business-Analysten der Fachbereiche geeignet. Somit sind Geschäftsprozesse von Business-Analysten mittels BPMN zu definieren und von Entwicklern mittels WS-BPEL umzusetzen. Derzeit existiert kein einfaches Transaktionsverfahren für verteilte langlaufende Web Services. Somit sollten Services möglichst atomar, isoliert und grobgranular geschnitten und verteilte langläufige Transaktionen über mehrere Services möglichst vermieden werden. Sollte aus fachlicher Sicht der Aufruf mehrerer Services in einer verteilten Transaktion unumgänglich sein, so sind,

130 Zusammenfassung und Ausblick 116 trotz einiger Schwachstellen, insbesondere bei der Kompensation von Services (siehe 4.3.2), standardisierte Transaktionsverfahren, wie WS-TX, zu wählen oder kompensatorische Services zu entwerfen und einzubinden. Eine Kompensation mittels kompensatorischer Serviceaufrufe entspricht dabei dem standardisierten Vorgehen innerhab von WS-BPEL. JBI bietet die Möglichkeit, eine plattformübergreifende standardisierte Integrationsinfrastruktur aufzubauen. Die Kommunikation innerhalb des ESB erfolgt dabei nachrichtenorientiert, wobei Unterschiede in den Nachrichtenformaten oder Transportprotokollen, wie z.b. von SOAP/HTTP nach JMS, mithilfe des ESB überbrückt werden können. Die Verwendung einer MOM als Bestandteil eines ESB, die asynchrones Messaging, Publish/Subscribe und Store-and-Forward unterstützt, ermöglicht eine zuverlässige Kommunikation zwischen lose gekoppelten Diensten innerhalb einer SOA. Des Weiteren stehen entsprechende A- dapter (Binding-Components) für verbreitete Standards wie SOAP/HTTP und JMS zur Verfügung. Bei dem Aufbau eines ESB besteht jedoch durch den Einsatz proprietärer Anwendungsadapter, wie z.b. für ein SAP-System, die Gefahr einer möglichen Hersteller- und Plattformabhängigkeit, wie bei klassichen EAI- Brokern. Im Gegensatz wird durch die Verwendung von Wrapper-Objekten, die Komplexität des Gesamtsystems durch eine weitere Schicht erhöht und Erstellung und Pflege von Wrapper-Objekten verursachen einen entsprechenden Aufwand. Dies ist bei der Einführung einer hersteller- und plattformunabhängigen Architektur, die mit einer SOA erreicht werden soll, zu berücksichtigen. Die hier eingesetzte Integrations- und Technologieplattform, welche für die Implementierung einer SOA eingesetzt wurde, weist keine gravierenden Schwächen auf. Auch konnten keine abweichenden Implementierungen der im Rahmen dieser Arbeit verwendeteten Web-Service-Standards festgestellt werden. Des Weiteren basiert der openesb auf der JBI-Spezifikation, welche einen Standard für Integrationsplattformen definiert. Hierbei bleibt jedoch in Zukunft genau zu beobachten, inwieweit verschiedene Softwarehersteller, wie z.b. IBM oder SAP, diese Spezifikation in deren Produkten umsetzen, um eine möglichst große Verbereitung dieses Standards zu ermöglichen. Zurzeit bieten viele Softwarehersteller proprietäre Lösungen an, die eine Migration ohne weitgehende

131 Zusammenfassung und Ausblick 117 Modifikation unmöglich gestalten. Dies beinhaltet ebenfalls die noch unzureichende Unterstützung der Standards BPEL4People und WS-HT für eine Benutzerinteraktion innerhalb von WS-BPEL. So spezifizieren z.b. SAP und IBM den Standard WS-BPEL, allerdings implementiert IBM diesen Standard nicht vollständig und erweitert diesen um eigene Konzepte zur Benutzerinteraktion und SAP wartet mit einer proprietären Lösung namens Guided Procedures auf, die nicht dem Standard WS-BPEL unterliegt. Eine standardisierte Umsetzung für eine SOA ist unumgänglich, um nicht in eine Hersteller- oder Plattformabhängigkeit zu geraten, die eigentlich mittels SOA umgangen werden soll. So muss im Vorfeld genau analylsiert werden, welche Funktionen innerhalb einer SOA genutzt werden sollen, um Portabilität und somit Flexibilität zu erreichen. Um die Entwicklung der Services und deren Prozessorchestrierung voranzutreiben, sind zunächst provisorische Services, d.h. Mock-Services zu entwickeln und diese zukzessiv entsprechend des Reife- und Fertigstellungsgrades durch produktiv einsetzbare Services zu ersetzten. Hierdurch wird eine bessere Beherrschbarkeit einer SOA erreicht und vereinfacht somit die Einführung. Dies entspricht auch dem Vorgehen für den hier entwickelten Prototyp eines Geschäftsprozesses Angebotskalkulation Strom. Für einen Produktivbertrieb des implementierten Prototyps sind die derzeit eingebunden Mock-Services für die Prozessschritte Zählpunktattribute ermitteln, Absatzprognose ermitteln, Individualbepreisung durchführen und Standardbepreisung durchführen durch reale Services zu ersetzen, welche die Funktionalitäten der Anwendungssysteme kapseln. Die Services können dabei ohne großen Aufwand ausgetauscht werden, da die Schnittstellen der Mock-Services alle benötigten Operationen und Parameter zur Verfügung stellen und somit nur die Adresse (URI) innerhalb des Ports der WSDL-Datei auf eine Bindung für den neuen Service geändert werden muss. Des Weiteren ist für den Prozessschritt Individualbepreisung durchführen eine Benutzerinteraktion mittels BPEL4People und WS-HT oder mittels User-Interfaces, die als Web Services implementiert sind, umzusetzen. Hierbei können User Interfaces durch WS- BPEL aufgerufen werden, wobei der Aufruf einer Benutzerinteraktion allein vom Prozess gesteuert wird.

132 Zusammenfassung und Ausblick 118 Zur allgemeinen Definition von Zuständigkeiten für einzelne Services sind im Weiteren organisatorische Maßnahmen zur Regulierung und Kontrolle einer SOA im Sinne einer SOA-Governance innerhalb des jeweiligen EVUs zu etablieren. Hierbei sind EVU, aufgrund der steigenden Anforderungen, auf entsprechende Konzepte, Methoden und Werkzeuge angewiesen, die bereits während des Entwicklungsprozesses helfen, Sicherheits- und Verfügbarkeitsanforderungen der Services zu berücksichtigen. Die Sicherheit von SOA mittels SAML, XACML und den WS-* Sicherheitsstandards sind im Folgenden genau zu analysieren. Insbesondere die Nutzung unternehmensübergreifender Services verlangt einen besonderen Schutz vor unerlaubtem Zugriff. Neben der Sicherheit unternehmensübergreifender Services sind außerdem besondere Mechanismen für Kommunikation, Abrechnung und Monitoring von SLA zu berücksichtigen. Des Weiteren ist die Einrichtung einer Service-Repository zum Auffinden und dynamischen Binden von Services zur Laufzeit innerhalb eines EVUs voran zu treiben. Hierdurch werden Automatisierungsgrad und Flexibilität in der Abbildung von Geschäftsprozessen weiter erhöht.

133 Literaturverzeichnis 119 Literaturverzeichnis [Allw05] [BaRü07] [CHKT06] [Chap04] [Degn05] [Dun08+] [Erl06] [FaKl07] [Gada05] [HoWo03] Allweyer, T.: Geschäftsprozessmanagement Strategie, Entwurf, Implementierung, Controlling, Bochum Backschat, M., Rücker, B.: Enterprise JavaBeans 3.0, Grundlagen Konzepte- Praxis, 2. Auflage, München Conrad, S., Hasselbrink, W., Koschel, A., Tritsch, R: Enterprise Application Integration Grundlagen, Konzepte, Entwurfsmuster, München Chappell, D.A: Enterprise Service Bus Theory in Practice, Sebastopol Degenring, A.: Enterprise Service Bus Alle Wege führen nach Rom. In JavaSPEKTRUM (Heft 04/2005), S Dunkel, J.; Eberhart, A.; Fischer S.; Kleiner, C; Koschel, A.: System-Architekturen für verteilte Anwendungen, München Erl, T.: Service-Oriented Architecture Concepts, Technology, and Design, Crawfordsville Faulenbach, D., Kloidt, C.: Eckpfeiler einer wertorientierten Vertriebssteuerung. In: Wettbewerbsorientierter Vertrieb in der Energiewirtschaft Kalkulation, Controlling, Beschaffung (Hrsg. Christina Köhler-Schulte), Gadatsch, A.: Grundkurs Geschäftsprozessmanagement Methoden und Werkzeuge für die IT-Praxis, Wiesbaden, Hohpe, G., Woolf, B.: Enterprise Integration Patterns - Designing, Building, and Deploying Messaging Solutions, Boston, 2003.

134 Literaturverzeichnis 120 [HWSD07] [JLSJ07] [Kaib02] Höß, O., Weisbecker, A., Specht, T., Drawehn, J.: Migration zu serviceorientierten Architekturen top-down oder bottom-up? In HMD - Praxis der Wirtschaftsinformatik (Heft 257, Oktober 2007), S Juric, M.B., Loganathan, R., Sarang, P., Jennings, F.: SOA Approach to Integration XML, Web Services, ESB, and BPEL in real SOA projects, Birmingham, Kaib, M.: Enterprise Application Integration - Grundlagen, Integrationsprodukte, Anwendungsbeispiele, Wiesbaden, [Kech06] Kecher, C.: UML 2.0 Das umfassende Handbuch, Bonn [Kell02] [KBS04] [Krup03] [KlKn07] [Lieb07] Keller, W.: Enterprise Application Integration Erfahrungen aus der Praxis, Heidelberg Krafzig, D., Banke, K., Slama, D.: Enterprise SOA - Service- Oriented Architecture Best Practises, Hagerstown Krupinski, A.: Unternehmens-IT für Banken Kursbuch für IT- Management und IT-Architektur, Siegen Klose, K., Knackstedt, R.: Serviceidentifikation für die Produktionsplanung eines mittelständigen Auftragsfertigers. In: HMD - Praxis der Wirtschaftsinformatik (Heft 253, Feb. 2007), S Liebhart, D.: Zwei, die zusammen gehören. In: Computerwoche (Nr. 2, 12. Januar 2007), S [Lint00] Linthicum, D.S.: Enterprise Application Integration, Boston [LMW07] Luhmann, T., Meister, J., Wulff, C.: Serviceorientierte Produktplattform für das Energiemanagementsystem der Zukunft. In: Wirtschaftsinformatik (Heft 49/2007), S

135 Literaturverzeichnis 121 [Lore05] Lorenzelli-Scholz, D.: Service-orientierte Integration mit einem Enterprise Service Bus. In: JavaSPEKTRUM (Heft 06/2005), S [Melz07] Melzer, I.: Service-orientierte Architekturen mit Web Services, 2. Auflage, München [Pere06] [PrAl06] [RHS05] [RLPB07] [RMB01] [ScWi02] [SDLD02] Pereira, J.: EAI: Approaches to Integration, MindTree Consulting, Bangalore Prändl, R., Albert, U.: Übertragung von Massendaten auf Basis von Open-Source-Technologien. In: Informatik OBJEKTspektrum (06/2006), S Richter, J.-P., Haller, H., Schrey, P.: Serviceorientierte Architekturen. In: Informatik Spektrum (17. Oktober 2005), S Reinheimer, S., Lang, F., Purucker, J., Brügmann, H.: 10 Antworten zu SOA. In HMD - Praxis der Wirtschaftsinformatik (Heft 253, Februar 2007), S Ruh, W., Maginnis, F., Brown, W.: Enterprise Application Integration How to successfully plan for EAI (A Wiley Tech Brief), New York Schelp, J., Winter, R.: Enterprise Portals und Enterprise Application Integration Begriffsbestimmung und Integrationskonzeptionen. In: HMD - Praxis der Wirtschaftsinformatik (Heft 225, Juni 2002), S Schmietendorf, A., Dimitrov, E., Lezius, J., Dumke. R.: Enterprise Application Integration Reifegrad, Architektur und Vorgehensweisen. In: HMD - Praxis der Wirtschaftsinformatik (Heft 225, Juni 2002), S

136 Literaturverzeichnis 122 [ThHa07] [TLD07] [Trop05] [Verm07] [Vogl06] [WeOs] [WoMa06] [Zaji07] Thiele, M., Habich, D.: Orchestrierung datenintensiver Prozesse Einsatz von BPEL in der Genexpressionsanalayse, Saarbrücken Thomas, O., Leyking, K., Dreifus, F.: Prozessmodellierung im Kontext serviceorientierter Architekturen. In: HMD - Praxis der Wirtschaftsinformatik (Heft 253, Februar 2007), S Trops, B.: Java Business Integration Die integrative Kraft des Faktischen. In: JavaSpektrum (Heft 05/2005), S Vermeer, O.: Enterprise Service Bus steuert Services - Transparenz für SOA. In ObjektSpektrum (Heft 04/2007), S Vogler, P.: Prozess- und Systemintegration Evolutionäre Weiterentwicklung bestehender Informationssysteme mithilfe von Enterprise Application, Wiesbaden Weber, T., Oswald, A: Web Services in heterogenen Umgebungen. In: JavaSpektrum (Heft 06/2007), S Woods, D., Mattern, T.: Enterprise SOA Designing IT for Business Innovation, Sebastopol, Zajicek, M.: Perspektiven und Handlungsoptionen für EVU zwischen Regulierung und Wettbwerb. In: Wettbewerbsorientierter Vertrieb in der Energiewirtschaft Kalkulation, Controlling, Beschaffung (Hrsg. Christina Köhler-Schulte), 2007.

137 Quellenverzeichnis 123 Quellenverzeichnis [EnWG] Gesetz über die Elektrizitäts- und Gasversorgung (Energiewirtschaftsgesetz - EnWG), Juli 2005, Im Internet: Zugriff IBM und SAP (Hrsg.): WS-BPEL Extension for People BPEL4People, A Joint White Paper by IBM and SAP, Juli 2005, Im Internet: 128.ibm.com/developerworks/webservices/ library/specification/ws-bpel4people/; Zugriff am IBM, SAP, et al. (Hrsg.): Web Services Human Tasks (WS-Human Task), Version 1.0, Juni 2007, Im Internet: com/ibmdl/pub/software/dw/specs/ws-bpel4people/ws- HumanTask_v1.pdf; Zugriff am IBM, SAP, et al. (Hrsg.): WS-BPEL Extension for People (BPEL4People), Version 1.0, Juni 2007, Im Internet: com/ibmdl/pub/software/dw/specs/ws-bpel4people/ BPEL4People_v1.pdf; Zugriff am OASIS (Hrsg.): Members Approve Web Services Business Process Execution Language (WS-BPEL) as OASIS Standard, April 2007, Im Internet: Zugriff am OASIS (Hrsg.): Web Services Business Process Execution Language Version 2.0, April 2007, Im Internet: wsbpel/2.0/os/wsbpel-v2.0-os.html; Zugriff am

138 Quellenverzeichnis 124 OMG (Hrsg): Buisness Process Modeling Notation (BPMN) Specification, Final Adopted Specification, Februar 2006, Im Internet: BPMN%201-0%20Spec% pdf; Zugriff am W3C (Hrsg.): MTOM Serialization Policy Assertion (WS-MTOMPolicy) Version 1.0, November 2006, Im Internet: Submission/WS-MTOMPolicy/; Zugriff am SUN (Hrsg): JSR 208, Java Business Integration (JBI) 1.0, August Im Internet: https://cds.sun.com/is-bin/intershop.enfinity/wfs/ CDS-CDS_JCP-Site/en_US/-/USD/ViewProductDetail-Start? Zugriff am SUN (Hrsg): The Java API for XML-Based Web Services (JAX-WS) 2.1, Mai Im Internet: https://cds.sun.com/is-bin/intershop.enfinity/wfs/cds-cds_jcp-site/en_us/-/usd/viewproduct CDS_JCP; Zugriff am W3C (Hrsg.): Web Services Description Language (WSDL) Version 2.0 Part 2: Message Exchange Patterns, März 2004, Im Internet: Zugriff am

139 Anhang A: Servicebeschreibungen Servicebeschreibung LsyasLoadCourseService Nr.: 1 Bezeichnung: Operation: LsyasLoadCourseService <Basis-Service> getloadcoursedto() Vorbedingungen: Datei Lastgang wurde erfolgreich eingelesen und übermittelt. Nachbedingungen: Profildaten wurden in Monatswerte aggregiert sowie hinsichtlich Winter/Sommer Hochtarif (HT) und Winter/Sommer Niedertarif (NT) unterschieden. Inputparameter: Byte[] Outputparameter: List<LoadCourseDTO> (siehe Anhang B) Funktionalität: Prognostizierte Absatzmengen, d.h. Lanstgänge, die als Viertelstundenwerte vorliegen werden in Monatswerte aggregiert sowie hinsichtlich Winter/Sommer Hochtarif (HT) und Winter/Sommer Niedertarif (NT) unterschieden. Fehlerbehandlung: Falls die Profildaten nicht aggregiert werden können, ist eine Fehlermeldung (Business-Exception) auszugeben. Falls es zu einem technischen Abbruch der Verarbeitung kommt, ist eine Fehlermeldung (System-Exception) auszugeben. Servicebeschreibung LsyasMeteringPointService Nr.: 2 Bezeichnung: Operation: Vorbedingungen: Nachbedingungen: Inputparameter: LsyasMeteringPointService <Basis-Service> getmeteringpoint() Zählpunkt (realer Messpunkt) mit eindeutiger Zählpunktbezeichnung wurde bereits angelegt und liegt zum angefragten Datum vor. Technische Zählpunktattribute wurden ermittelt. Date date (Datum) String meteringcode (eindeutige Zählpunktbezeichnung) Outputparameter: MeteringPointDTO (siehe Anhang B) Funktionalität: Fehlerbehandlung: Anhand einer eindeutigen Zählpunktbezeichnung werden die technischen Zählpunktattribute eines Zählpunktes zu einem vorgegebenen Datum im Abrechnungssystem ermittelt. Hinweis: Mock-Implementierung Falls der Zählpunkt nicht ermittelt werden konnte, ist eine Fehlermeldung (Business-Exception) auszugeben. Falls es zu einem technischen Abbruch der Verarbeitung kommt, ist eine Fehlermeldung (System-Exception) auszugeben.

140 Anhang A: Servicebeschreibungen 126 Servicebeschreibung LsyasPremiseService Nr.: 3 Bezeichnung: Operation: Vorbedingungen: Nachbedingungen: Inputparameter: LsyasPremiseService <Basis-Service> calculatepremisevalue() Sämtliche für die Prämissenverwaltung relevanten Daten (z.b. Netznutzungsentgelte und Stromsteuerstufe) liegen im Backend-System vor und sind vom Vertriebscontrolling für den Kalkulationszeitraum gepflegt. Kostenermittlung aus Prämissen ist abgeschlossen. AuthDTO authdto String user String password MasterDataDTO masterdatadto (siehe Anhang B) List<LoadCourseDTO> LoadCourseDTO (siehe Anhang B) MeteringPointDTO meteringpointdto (siehe Anhang B) Outputparameter: List<PremiseValueDTO> (siehe Anhang B) Funktionalität: Fehlerbehandlung: Backend- Funktionalität: Libraries: Die Prämissenbewertung bzw. die Kostenermittlung der Prämissen findet pro Zählpunkt auf Basis der hinterlegten Tabelleneinträge im Backend-System statt. Falls die Prämissen nicht ermittelt werden können, ist eine Fehlermeldung (Business-Exception) auszugeben. Falls es zu einem technischen Abbruch der Verarbeitung kommt, ist eine Fehlermeldung (System-Exception) auszugeben. SAP-System (LSYAS VIVA01); Funktionsbaustein: KALKULATION_PRAEMISSEN sapjco.jar Servicebeschreibung LsyasPurchasePriceService Nr.: 4 Bezeichnung: Operation: Vorbedingungen: Nachbedingungen: LsyasPurchasePriceService <Basis-Service> getpurchasepricepower() Datei Lastgang wurde erfolgreich eingelesen und übermittelt und eine Terminpreiskurve (Hourly Price Forward Curve - HPFC) liegt als Grundlage vor. Bepreisung der prognostizierten Absatzmenge für den Angebotszeitraum anhand einer Terminpreiskurve (Hourly Price Forward Curve - HPFC). Byte[] Inputparameter: Outputparameter: List<PurchasePriceDTO> (siehe Anhang B) Funktionalität: Fehlerbehandlung: Die Bepreisung der prognostizierten Absatzmenge für den Angebotszeitraum wird anhand einer Terminpreiskurve (HPFC) vorgenommen. Hinweis: Mock-Implementierung Falls die Bepreisung nicht durchgeführt werden konnte, ist eine Fehlermeldung (Business-Exception) auszugeben. Falls es zu einem technischen Abbruch der Verarbeitung kommt, ist eine Fehlermeldung (System-Exception) auszugeben.

141 Anhang A: Servicebeschreibungen 127 Servicebeschreibung LsyasPurchasePriceAsyncBPELProcess Nr.: 5 Bezeichnung: LsyasPurchasePriceAsyncBPELProcess <Orchestrierungsservice> Services LsyasPurchasePriceServiceAsynchonousRequest getpurchasepriceelectricitybyemployeerequest() (one-way- LsyasPurchasePriceServiceAsynchonousCallback Operationen): getpurchasepriceelectricitybyemployeeresponse() Vorbedingungen: Der eingebundene Service liegt vor und die dazugehörigen Vorbedingungen sind zur Laufzeit oder früher erfüllt. Nachbedingungen: Individuelle, d.h. manuelle Bepreisung der prognostizierten Absatzmenge für den Angebotszeitraum. Request Operation: Byte[] Callback Operation: ProcessOwner List<PurchasePriceDTO> (siehe Anhang B) Funktionalität: Die Bepreisung der prognostizierten Absatzmenge für den Angebotszeitraum wird individuell, d.h. manuell durch eine Benutzerinteraktion vorgenommen. Hierzu erfolgt eine asynchrone Kommunikation mittels Callback-Handler. Hinweis: Mock-Implementierung; Simulierung der Benutzerinteraktion durch die Kapselung des Services LsyasPurchasePriceService und des Elements <Wait>. Fehlerbehandlung: - Orchestrierte LsyasPurchasePriceService (Nr.5) Services: Servicebeschreibung LsyasQuotationCalculationService Nr.: 6 Bezeichnung: Operation: LsyasQuotationCalculationService <Basis-Service> calculatequotationresult() Vorbedingungen: Sämtliche für die Kalkulation relevanten Daten liegen vor. Nachbedingungen: Kosten- und Erlösermittlung für die Angebotskalkulation ist abgeschlossen. Inputparameter: AuthDTO authdto String user String password List<PremiseValueDTO> premisevaluedto List<LoadCourseDTO> loadcoursedto (siehe Anhang B) List<PurchasePriceDTO> purchasepricedto (siehe Anhang B) Outputparameter: CalculationResultDTO (siehe Anhang B) Funktionalität: Kosten- und Erlösermittlung für die Angebotskalkulation wird für den Angebotszeitraum durchgeführt. Fehlerbehandlung: Falls die Kalkulation nicht durchgeführt werden kann, ist eine Fehlermeldung (Business-Exception) auszugeben. Falls es zu einem technischen Abbruch der Verarbeitung kommt, ist eine Fehlermeldung (System-Exception) auszugeben Backend- SAP-System (LSYAS VIVA01); Funktionalität: Funktionsbaustein: KALKULATION_STROM Libraries: sapjco.jar

142 Anhang A: Servicebeschreibungen 128 Servicebeschreibung LsyasCostingVersionElectricityDataService Nr.: 7 Bezeichnung: Anlegeoperation: LsyasCostingVersionElectricityDataService <Basis-Service> createcostingversion() Vorbedingungen: Entitäten, d.h. die einzelnen Objekte einer Kalkulationsversion liegen vor. Nachbedingungen: Kalkulationsversion ist unter einer eindeutigen ID gespeichert worden. Inputparameter: Masterdata masterdata (siehe Anhang B) CalculationResultDTO (siehe Anhang B) MeteringPointDTO meteringpointdto (siehe Anhang B) List<PremiseValueDTO> premisevaluedto List<LoadCourseDTO> loadcoursedto (siehe Anhang B) List<PurchasePriceDTO> purchasepricedto (siehe Anhang B) Outputparameter: int calculationversionid Funktionalität: Kalkulationsversion wird fortlaufend unter einer eindeutigen ID gespeichert. Fehlerbehandlung: Falls die Kalkulationsversion nicht komplett gespeichert werden kann, sind bereits gespeicherte Entitäten wieder aus der Datenbank zu entfernen (transaktionales Verhalten). Des Weiteren ist eine Fehlermeldung auszugeben. Falls es zu einem technischen Abbruch der Verarbeitung kommt, ist eine Fehlermeldung (DataBase-Exception) auszugeben. Löschoperation: removecostingversionbyid () Vorbedingungen: Kalkulationsversion liegt unter der angegebenen ID vor und ist noch keinem Angebot zugeordnet worden. Nachbedingungen: Kalkulationsversion ist aus der Datenbank gelöscht worden. Inputparameter: int calculationversionid Outputparameter: - Funktionalität: Kalkulationsversion wird aus der Datenbank gelöscht Fehlerbehandlung: Falls noch keine Kalkulationsversion unter der angegebenen ID vorliegt oder diese bereits einem Angebot zugeordnet worden ist, wird eine Fehlermeldung ausgegeben. Falls es zu einem technischen Abbruch der Verarbeitung kommt, ist eine Fehlermeldung (DataBase-Exception) auszugeben Updateoperation: updatecostingversionstatetoassigned() Vorbedingungen: Kalkulationsversion liegt unter der angegebenen ID vor Nachbedingungen: Satus der Kalkulationsversion wurde auf 1 (=Angebot zugeordnet) geändert. Inputparameter: int calculationversionid Outputparameter: - Funktionalität: Status einer Kalkulationsversion wird auf Angebot zugeordnet (1) geändert. Fehlerbehandlung: Falls noch keine Kalkulationsversion unter der angegebenen ID vorliegt, wird eine Fehlermeldung ausgegeben. Falls es zu einem technischen Abbruch der Verarbeitung kommt, ist eine Fehlermeldung (DataBase-Exception) auszugeben.

143 Anhang A: Servicebeschreibungen 129 Nr.: Bezeichnung: 7 (Fortsetzung) LsyasCostingVersionElectricityDataService <Basis-Service> Leseoperationen: findallcostingversionmasterdata() findcostingversionmasterdatabybusinesspartnermeteringpoint AndDate(int businesspartner, int meteringpoint, Date delivery StartFrom, Date deliverystartto) findcostingversionmasterdatabyid(int calculationversionid) findcostingversioncalculationresultbyid(int calculationversionid) findcostingversionmeteringpointbyid(int calculationversionid) findcostingversionpurchasepricebyid(int calculationversionid) findcostingversionpremisevaluebyid(int calculationversionid) findcostingversionloadcoursebyid(int calculationversionid) Vorbedingungen: Kalkulationsversion liegt unter der angegebenen ID bzw. den angegebenen Suchparametern vor Nachbedingungen: Entität, d.h. das einzelne Objekt einer Kalkulationsversion wurde aus der Datenbank gelesen. Inputparameter: Siehe Zeile Leseoperationen Outputparameter: MasterData = masterdata (siehe Anhang B) CalculationResult = calculationresult (siehe Anhang B) MeteringPoint = meteringpoint (siehe Anhang B) PurchasePrice = purchaseprice (siehe Anhang B) PremiseValue = premisevalue (siehe Anhang B) LoadCourse = loadcourse (siehe Anhang B) Funktionalität: Kalkulationsversion wird aus der Datenbank gelöscht Fehlerbehandlung: Falls noch keine Kalkulationsversion unter der angegebenen ID vorliegt, wird eine Fehlermeldung ausgegeben. Falls es zu einem technischen Abbruch der Verarbeitung kommt, ist eine Fehlermeldung (DataBase-Exception) auszugeben. Libraries: javaee.jar; hibernate-entitymanager.jar; mysqlconnector-java.jar

144 Anhang A: Servicebeschreibungen 130 Servicebeschreibung Lsyas NotificationService Nr.: 8 Bezeichnung: Operation: Vorbedingungen: Nachbedingungen: Inputparameter: Output ( ): Lsyas NotificationService <JMS-Service> notification() Die entsprechende Message Queue liegt bereits vor. Eine entsprechende -Benachrichtigung wurde an die angegebne -Adresse gesendet. String address ( -Adresse) String calculationversionid (Kalkulationsversion ID) String state (Status; 0 = erfolgreich erstellt) String meteringpoint (Zählpunkt) Int BusinessPartner (Geschäftspartner) Positive Benachrichtigung: Ihre angeforderte Kalkulationsversion für Geschäftspartner <businesspartner> und dem Zählpunkt <meteringpoint> ist unter der Nummer <calculationversionid> erstellt worden. Sie können diese ab sofort in Ihrer contact Anwendung aufrufen. Mit freundlichen Grüßen Ihr Administrator Negative Benachrichtigung: Ihre angeforderte Kalkulationsversion für Geschäftspartner <businesspartner> und dem Zählpunkt <meteringpoint> konnte nicht erstellt werden. Bitte korrigieren Sie Ihre Eingaben und versuchen Sie es erneut. Falls Sie diese erneut erhalten, wenden Sie sich bitte an Ihren IT-Provider. Mit freundlichen Grüßen Ihr Administrator Funktionalität: Über einen Point-to-Point-Channel wird eine sog. Message Queue aufgebaut, die Nachrichten für eine -Benachrichtigung enthält. Diese wird von einer Message Driven Bean abgefragt und anhand des Status eine positive oder negative Benachrichtigung an die angegebene -Adresse gesendet. Fehlerbehandlung: - JMS: Destination: NotificationBean DestinationType: Queue MessageType: TextMessage textpart: notificationmessage

145 Anhang A: Servicebeschreibungen 131 Servicebeschreibung LsyasQuotationCostingElectricityBPELProcess Nr.: 9 Bezeichnung: Services (one-way- Operationen): Vorbedingungen: Nachbedingungen: Request Operation: Callback Operation: Funktionalität: LsyasQuotationCostingElectricityBPELProcess <Orchestrierungsservice> QuotationCostingElectricity_AsyncService createquotationcostingelectricityrequest() QuotationCostingElectricity_CallbackService createquotationcostingelectricityresponse() Die eingebundenen Services liegen vor und die dazugehörigen Vorbedingungen sind zur Laufzeit oder früher erfüllt. Eine Kalkulationsversion wurde erfolgreich erstellt und kann einem Angebot zugeordnet werden. String client (Mandant) Int businesspartner (Geschäftspartner) String loadcoursefilename (Datei Lastgang) Byte[] filedata (Binärdaten der eingelesenen CSV-Datei) String meteringpoint (Zählpunkt) String segment (Kundengruppe) Date deliverystart (Beginn Lieferung) Date deliveryend (Ende Lieferung) Date commitmentdate (Bindefrist) String currencykey (Währungsschlüssel) Boolean flageeg_bafa (BAFA-Bescheid) Boolean flagkwkg (KWKG-Ermäßigt) String electricitytaxgrade (Stromsteuerstufe) Boolean flagmeteringvoltagelikesupplyvoltage (Messspannung = Versorgungsspannung Boolean flagmeteringpointoperatorlikenetworkoperator (Messstellenbetreiber = Netzbetreiber) Boolean flagmeshednetwork (Vermaschtes Netz oder Sammelschiene) Boolean flagenergydeliverynne (Lieferung ohne NNE) Boolean flagloadcoursemeasured (gemessener Lastgang) String user (Benutzer) String password (Passwort) Boolean Notification ( -Benachrichtigung) String user address ( -Adresse des Benutzers) Boolean responseasync (Callback) String callbackid (Eindeutige Zuordnung für einen Callback) String callbackid (Eindeutige Zuordnung des Callbacks) String processowner (Prozesseigentümer) Int businesspartner (Geschäftspartner) String meteringpoint (Zählpunkt) String calculationversionid (Kalkulationsversion ID) Boolean fault (Fehler) String faultmessage (Fehlermeldung; Typ und Text) Eine Angebotskalkulationsversion Strom wird gemäß des Geschäftsprozesses Angebotskalkulation Strom asynchron erstellt. Hierzu werden die u.g. Services zu einem Geschäftsprozess orchestriert. Falls das Kennzeichen Notification gesetzt ist, wird an die angegeben -Adresse eine gesendet, die den Benutzer über den positiven oder negativen Prozessausgang informiert. Falls das Kennzeichen responseasync auf true gesetzt ist, erfolgt mithilfe des zweiten Services QuotationCostingElectricity_ CallbackService eine asynchrone Antwort (Callback).

146 Anhang A: Servicebeschreibungen 132 Fehlerbehandlung: Nr.: Bezeichnung: Orchestrierte Services: Die Fehlerbehandlung erfolgt in einem CatchAll-Element. Je nachdem ob die Kennzeichen Notification und responseasync gesetzt sind, erfolgt eine Weiterleitung des Fehlers. Ob es sich bei der Rückmeldung um einen Fehler handelt, ist bei der Verarbeitung vom Client (Servicenutzer) zu prüfen. 10 (Fortsetzung) LsyasQuotationCostingElectricityBPELProcess <Orchestrierungsservice> LsyasLoadCourseService (Nr. 1) LsyasMeteringPointService (Nr. 2) LsyasPremiseService (Nr. 3) LsyasPurchasePriceService (Nr. 4) LsyasPurchasePriceAsyncBPELProcess (Nr. 5) LsyasQuotationCalculationService (Nr. 6) LsyasCostingVersionElectricityDataService (Nr. 7) Lsyas NotificationService (Nr. 8) Servicebeschreibung LsyasBPELProcessMonitoring Nr.: 10 Bezeichnung: Operation: Vorbedingungen: Nachbedingungen: Inputparameter: Outputparameter: Funktionalität: Fehlerbehandlung: JMX MBean: Libraries: LsyasBPELProcessMonitoring <JMX-Service> getprocessstatusbyprocessvariable() Der JMX-Server steht zur Verfügung und der WS-BPEL-Process ist zur Überwachung freigegeben (Monitoring enabled). Der entsprechende Prozess und der dazugehörige aktuelle Prozessstatus wurden erfolgreich ermittelt. String bpelprocessname Beispiel: {http://enterprise.netbeans.org/bpel/lsyasquotationcosting ElectricityBPEL/LsyasQuotationCostingElectricityBPELProcess} LsyasQuotationCostingElectricityBPELProcess String variablename Beispiel: ProcessOwner String variablevalue Beispiel: Becke String (Prozessstatus) Anhand der Inputparameter wird der dazugehörige WS-BPEL-Prozess ermittelt und der entsprechende Prozessstatus ausgegeben. COMPLETED: Erfolgreich abgeschlossen FAULTED: Ein unbehandelter Fehler ist aufgetreten. RUNNING: Verarbeitung läuft noch. SUSPENDED: Verarbeitung wurde suspendiert. TERMINATED: Verarbeitung wurde abgebrochen. Falls der Prozess zu den dazugehörigen Inputparametern mehrmals existiert, wird der aktuellste Prozess (Start) ermittelt. Falls der Prozess nicht ermittelt werden konnte, ist eine Fehlermeldung (Business-Exception) auszugeben. Falls der JMX-Server nicht erreichbar ist oder der WS-BPEL-Prozess nicht zur Überwachung freigegeben ist, ist eine Fehlermeldung (System-Exception) auszugeben. BPELManagementServiceFactory.getBPELManagementServiceRemote (jmxhostname, jmxport, jmxusername, jmxpwd) common-util.jar; jbi-admin-common.jar; jbi.jar; bpelmonitor-api.jar; bpelmonitor-tool.jar

147 Anhang B: Datenbankdesign 133 Anhang B: Datenbankdesign Datenbankdesign Angebotskalkulationsversion Strom :

148 Anhang C: Interface-Beschreibungen 134 Anhang C: Interface-Beschreibungen Layout UI; Erfassung Angebotskalkulationsversion Parameter UI, Erfassung Angebotskalkulationsversion: User Interface: Anlegen Angebotskalkulationsversion Strom (QuotationCostingProcess) Parameter Parametertyp Mussfeld Datentyp Darstellung Format Beispiel Stammdaten Angebotskalkulation Strom Datei Lastgang Eingabeparameter ja String File - Profil_XXX.csv Geschäftspartner Eingabeparameter ja String Textfeld Zählpunkt Eingabeparameter ja String Textfeld Beginn Lieferung Eingabeparameter ja String Textfeld MM.DD.YYYY Ende Lieferung Eingabeparameter ja String Textfeld MM.DD.YYYY Bindefrist Eingabeparameter ja String Textfeld MM.DD.YYYY * Befreit = 9 / Stromsteuerstufe Eingabeparameter ja String Dropdown - Regelsatz = 0 Kundengruppe Eingabeparameter ja String Dropdown - BA / BG Währungsschlüssel Eingabeparameter ja String Dropdown - EUR BAFA-Bescheid Eingabeparameter nein Boolean Checkbox - aktiviert = true KWKG-Ermäßigt Eingabeparameter nein Boolean Checkbox - aktiviert = true NNE Mess- und Vorsorgungsspannung Eingabeparameter nein Boolean Checkbox - aktiviert = true NNE Messkosten inkl. Eingabeparameter nein Boolean Checkbox - aktiviert = true NNE Messpunkt Eingabeparameter nein Boolean Checkbox - aktiviert = true Lieferung ohne NNE Eingabeparameter nein Boolean Checkbox - aktiviert = true gemessener Lastgang Eingabeparameter nein Boolean Checkbox - aktiviert = true Benachrichtigung -Adresse Eingabeparameter nein String Textfeld - Benachrichtigung Eingabeparameter nein Boolean Checkbox - aktiviert = true * max. 14 Tage in der Zukunft

149 Anhang C: Interface-Beschreibungen 135 Layout UI; Übersicht/Auswahl Angebotskalkulationsversion: Parameter UI, Übersicht/Auswahl Angebotskalkulationsversion: User Interface: Übersicht/Auswahl Angebotskalkulationsversion Strom (QuotationCostingList) Parameter Parametertyp Mussfeld Datentyp Darstellung Format Beispiel Suchmaske Angebotskalkulation Strom Geschäftspartner Eingabeparameter ja String Textfeld Zählpunkt Eingabeparameter nein String Textfeld Beginn Lieferung von Eingabeparameter ja String Textfeld MM.DD.YYYY Beginn Lieferung bis Eingabeparameter ja String Textfeld MM.DD.YYYY Liste Kalkulationsversionen Strom Kalkulationsversion ID Anzeigeparameter - String Textfeld - 9 Zählpunkt Anzeigeparameter - String Textfeld Lieferung von Anzeigeparameter - String Textfeld MM.DD.YYYY Lieferung bis Anzeigeparameter - String Textfeld MM.DD.YYYY Bindefrist Anzeigeparameter - String Textfeld MM.DD.YYYY Angebot zug. Anzeigeparameter - Boolean Checkbox - zugeordnet = true Erstellungsdatum Anzeigeparameter - String Textfeld MM.DD.YYYY Ersteller Anzeigeparameter - String Textfeld - Becke

150 Anhang C: Interface-Beschreibungen 136 Layout UI; Anzeige Ergebnis Angebotskalkulationsversion:

151 Anhang C: Interface-Beschreibungen 137 Parameter UI; Anzeige Ergebnis Angebotskalkulationsversion: User Interface: Anzeige Ergebnisse Angebotskalkulationsversion Strom (QuotationCostingResult) Parameter Parametertyp Mussfeld Datentyp Darstellung Format Beispiel Stammdaten Angebotskalkulation Strom Kalkulationsversion ID Anzeigeparameter - String Textfeld - 9 Datei Lastgang Anzeigeparameter - String File - Profil_ Zählpunkt Anzeigeparameter - String Textfeld Beginn Lieferung Anzeigeparameter - String Textfeld MM.DD.YYYY Ende Lieferung Anzeigeparameter - String Textfeld MM.DD.YYYY Bindefrist Anzeigeparameter - String Textfeld MM.DD.YYYY Stromsteuerstufe Anzeigeparameter - String Dropdown - Regelsatz = "9" Kundengruppe Anzeigeparameter - String Dropdown - BA Währungsschlüssel Anzeigeparameter - String Dropdown - EUR BAFA-Bescheid Anzeigeparameter - Boolean Checkbox - aktiviert = true KWKG-Ermäßigt Anzeigeparameter - Boolean Checkbox - aktiviert = true NNE Mess- und Vorsorgungsspannung Anzeigeparameter - Boolean Checkbox - aktiviert = true NNE Messkosten inkl. Anzeigeparameter - Boolean Checkbox - aktiviert = true NNE Messpunkt Anzeigeparameter - Boolean Checkbox - aktiviert = true Lieferung ohne NNE Anzeigeparameter - Boolean Checkbox - aktiviert = true gemessener Lastgang Anzeigeparameter - Boolean Checkbox - aktiviert = true Ersteller Anzeigeparameter - String Textfeld - Becke Angebot zug. Anzeigeparameter - Boolean Checkbox - zugeordnet = true Ergebnisse Angebotskalkulation Strom Gesamtverbrauch (KWh) Anzeigeparameter - String Textfeld #,###,## ,00 Ergebnisse Angebotskalkulation Strom - Bezugskosten Bezugskosten Anzeigeparameter - String Textfeld #,###,## ,01 Bindefristzuschlag Anzeigeparameter - String Textfeld #,###,##0.00 0,00 Dienstleistungsentgelt Anzeigeparameter - String Textfeld #,###,## ,30 Flexibilitätszuschlag Anzeigeparameter - String Textfeld #,###,##0.00 0,00 Ergebnisse Angebotskalkulation Strom - Gesetzliche Abgaben KWKG Betrag Anzeigeparameter - String Textfeld #,###,## ,01 Steuern (absolut) Anzeigeparameter - String Textfeld #,###,## ,30 EEG-Kosten Anzeigeparameter - String Textfeld #,###,## ,30 KA Sondertarif Anzeigeparameter - String Textfeld #,###,##0.00 0,00 KA HT Anzeigeparameter - String Textfeld #,###,##0.00 0,00 KA NT Anzeigeparameter - String Textfeld #,###,##0.00 0,00 KA Gesamt Anzeigeparameter - String Textfeld #,###,##0.00 0,00 Ergebnisse Angebotskalkulation Strom - Netznutzungsentgelte Arbeitspreis Anzeigeparameter - String Textfeld #,###,##0.00 0,00 Leistungspreis Anzeigeparameter - String Textfeld #,###,##0.00 0,00 Abrechnungspreis Anzeigeparameter - String Textfeld #,###,##0.00 0,00 KA Sondertarif Anzeigeparameter - String Textfeld #,###,##0.00 0,00 Messpreis Anzeigeparameter - String Textfeld #,###,##0.00 0,00 Grundpreis Anzeigeparameter - String Textfeld #,###,##0.00 0,00 NNE Gesamt (absolut) Anzeigeparameter - String Textfeld #,###,##0.00 0,00 Ergebnisse Angebotskalkulation Strom - Mindesterlösberechnung Kosten ges. Anzeigeparameter - String Textfeld #,###,## ,24 Mindest DB (absolut) Anzeigeparameter - String Textfeld #,###,## ,80 Mindesterlös (absolut) Anzeigeparameter - String Textfeld #,###,## ,04 Ergebnisse Angebotskalkulation Strom - Umsatzpositionen Verkaufserlös (absolut) Anzeigeparameter - String Textfeld #,###,##0.00 0,00 Formatierung: #,###,##0.00 = Locale.GERMAN

152 Anhang D: Systemkonfiguration 138 Anhang D: Systemkonfiguration Programm Version MySQL MySQL Server Version community-nt via NetBeans IDE 6.1 (Build ) Glassfish V2 UR2 OpenESB V2 (zuzüglich Update http-binding; httpbc.jar) Java 1.5.0_16; Java HotSpot(TM) Client VM 1.5.0_16-b02 MS Windows XP Version 5.1 running on x86 Die Programme NetBeans IDE, Glassfish, und OpenESB sind mithilfe des SUN Java EE 5 Tools Bundle netbeans-6.1-ml-windows.exe zu installieren. Die entsprechenden Programme, Libraries und Source-Dateien des Prototyps, exklusive der eingebundenen SAP Funktionsbausteine, befinden sich auf der anliegenden CD, die dem Anhang G zu entnehmen ist. Externe Libraries SAP JCo JBI Monitoring MySQL Hibernate3 Bezeichnung (inkl. entsprechender Abhängigkeiten) sapjco.jar sapjcorfc.dll librfc32.dll bpelmonitor-api.jar bpelmonitor-tool.jar common-util.jar jbi.jar jbi-admin-common.jar mysql-connector-java bin.jar ant jar antlr jar asm.jar asm-attrs.jar c3p jar cglib jar commons-collections jar commons-logging jar concurrent jar dom4j jar ehcache jar hibernate3.jar hibernate-annotations.jar hibernate-commons-annotations.jar hibernate-entitymanager.jar javassist.jar junit-4.4.jar log4j jar

153 Anhang E: WS-BPEL Angebotskalkulation Strom 139 Anhang E: WS-BPEL Angebotskalkulation Strom

154 Anhang F: JBI Container Angebotskalkulation Strom 140 Anhang F: JBI Container Angebotskalkulation Strom

Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management

Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management Inauguraldissertation zur Erlangung des akademischen Grades eines Doktors

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

EAI. Integration. EAI Version 0.9 1

EAI. Integration. EAI Version 0.9 1 EAI Enterprise Application Integration EAI Version 0.9 1 Heterogene Informationssysteme KIS DRG Grouper Stand-alone Anwendung (Windows) PACS Client-Server Anwendung (Java, LINUX, Caché) QM-System Client-Server

Mehr

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA Hauptseminar Management von Softwaresystemen Techniken der System-Integration EAI, Middleware, SOA, CORBA Betreuerin: Referent: Ulrike Hammerschall Alexey Krivoborodov Agenda Motivation Arten der Verteilung

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Leistung schafft Vertrauen

Leistung schafft Vertrauen SOA Hintergrund und Praxis visionäre Praxis oder praxisnahe Vision Toni Gasser Integration Services 27. Oktober 2010 Leistung schafft Vertrauen Private Banking Investment Banking Asset Management Seite

Mehr

Was NetWeaver wirklich bietet

Was NetWeaver wirklich bietet Was NetWeaver wirklich bietet Erschienen in der Computerwoche 03/2007 Von Dr. Carl Winter, REALTECH AG Welche SAP Produkt-Versionen und SAP Releases gehören und passen zusammen. Welche sind die aktuellen

Mehr

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA E-Gov Fokus Geschäftsprozesse und SOA 31. August 2007 Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA Im Vortrag werden die Vor- und Nachteile von Geschäftsprozessen in der öffentlichen

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE PROZESSE INTEGRIEREN leicht gemacht DURCH TransConnect Geschäftsprozesse ableiten mit der Universal Worklist (UWL) Integrationsszenarien effektiver verwalten und transportieren Optimierte Personalverwaltung

Mehr

Service Oriented Architectures

Service Oriented Architectures Service Oriented Architectures Einführung in die Integration verschiedener Anwendungssysteme - Problematik und allgemeine Architektur Julia Weisheitel (WI5773) Inhalt Überblick Probleme und Entscheidungen

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Entwicklung von Serviceangeboten) 1 Agenda Einsatzbereiche von Web Service basierten Angeboten Übersicht zur Java-System Application

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203 Mehr als alter Wein in neuen Schläuchen 199 1 Problematik eines uneinheitlichen Verständnisses der SOA... 201 2 SOA als unternehmensweites Architekturkonzept........... 203 3 Struktur einer SOA..................................

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Wer zählt wann mit wem?

Wer zählt wann mit wem? Pressemitteilung Velbert, 8. Juni 2010 Elektronischer Datenaustausch im Messwesen Wer zählt wann mit wem? Kleine und mittlere Energieversorger, besonders Stadtwerke, stehen mit den Neuerungen im Energiemarkt

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

Service. Was ist eine Enterprise Service Architecture und wie reagiert SAP. Warum Monitoring in ZENOS, was monitort die XI?

Service. Was ist eine Enterprise Service Architecture und wie reagiert SAP. Warum Monitoring in ZENOS, was monitort die XI? Service Was ist eine Enterprise Service Architecture und wie reagiert SAP Allgemeine Definition Was gehört in ZENOS (Service-Layer)? Business Logik ZENOS als Provider für SAP-based Services (ESA/SOA) Warum

Mehr

Klausur Verteilte Systeme Was versteht man unter verteilte Systeme

Klausur Verteilte Systeme Was versteht man unter verteilte Systeme Was versteht man unter verteilte Systeme Ein Verteiltes System ist ein System in dem Hardware- und Softwarekomponenten, die sich auf miteinander vernetzten Computern befinden miteinander kommunizieren

Mehr

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SO A Fraunhofer-Institut für Softwareund Systemtechnik ISST Dr. Ulrich Springer Dr. Bernhard Holtkamp Dortmund, 20.01.2009

Mehr

Curret Topics in BPM and EA

Curret Topics in BPM and EA Curret Topics in BPM and EA IV WS 2011 Introduction Competence Center EA/Dr.-Ing. Marten Schönherr 1 Agenda Ausgangssituation Komplexität, technische und fachliche Heterogenität Argumentation Terminologie

Mehr

Vorgehensmodelle und webbasierte Technologien zur Integration von Systemen zur Unterstützung der Collaboration in Communities

Vorgehensmodelle und webbasierte Technologien zur Integration von Systemen zur Unterstützung der Collaboration in Communities Synopsis I Vorgehensmodelle und webbasierte Technologien zur Integration von Systemen zur Unterstützung der Collaboration in Communities Abschlussarbeit zur Erlangung des Grades Master of Science (MSc)

Mehr

SOAP Simple Object Access Protocol

SOAP Simple Object Access Protocol Informatikseminar Tobias Briel Überblick 1. Einführung - was ist? 2. Middlewaretechnologie 3. Aufbau von Nachrichten 4. Vergleiche 5. Beispielanwendung 6. Zusammenfassung 1 Einführung was ist Soap? neue

Mehr

Standardsoftware II. Klassifikation Schnittstellen

Standardsoftware II. Klassifikation Schnittstellen Standardsoftware II Schnittstellen zu ERP-Systemen Schnittstellen-1 Klassifikation Schnittstellen datenorientierte funktionale objektorientierte Schnittstellen-2 Was zeichnet eine Schnittstelle aus? Merkmale

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Sicherheitsaspekte in Service Orientierten Architekturen. Eike Falkenberg Sommersemester 2006 Anwendungen I

Sicherheitsaspekte in Service Orientierten Architekturen. Eike Falkenberg Sommersemester 2006 Anwendungen I Sicherheitsaspekte in Service Orientierten Architekturen Eike Falkenberg Sommersemester 2006 Anwendungen I Agenda SOA? Web Services? Sicherheitsrisiko Web Services Web Services & Sicherheit Sichere SOAs

Mehr

Enterprise Portale & Enterprise Application Integration

Enterprise Portale & Enterprise Application Integration EP & - & Enterprise Application Integration Jörg Streibhardt Technische Universität Dresden EP & 21. Januar 2005 / Seminar Rechnernetze Gliederung Enterprise Application Integration EP & - EP & & Enterprise

Mehr

Inhaltsverzeichnis. Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach

Inhaltsverzeichnis. Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach sverzeichnis Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach Integration Architecture Blueprint Leitfaden zur Konstruktion

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Wrapper und Konnektoren geht die Rechnung auf?

Wrapper und Konnektoren geht die Rechnung auf? Wrapper und Konnektoren geht die Rechnung auf? Klaudia Hergula DaimlerChrysler AG Forschung und Technologie Wissensaustausch / Austauschgruppe (FTK/A) HPC 0516, Epplestr. 225, D-70546 Stuttgart klaudia.hergula@daimlerchrysler.com

Mehr

SOA mit.net: Vom Geschäftsprozess zur Lösung

SOA mit.net: Vom Geschäftsprozess zur Lösung SOA mit.net: Vom Geschäftsprozess zur Lösung Manfred Steyer Aktuelles Buch.Net 4.0 Update ISBN 978-3866454439 http://tinyurl.com/net4update 1 Kontakt [www] www.softwarearchitekt.at [mail] Manfred.Steyer@SoftwareArchitekt.at

Mehr

Smart Energy. Von der reaktiven Kundenverwaltung zum proaktiven Kundenmanagement. Bearbeitet von Christian Aichele

Smart Energy. Von der reaktiven Kundenverwaltung zum proaktiven Kundenmanagement. Bearbeitet von Christian Aichele Smart Energy Von der reaktiven Kundenverwaltung zum proaktiven Kundenmanagement Bearbeitet von Christian Aichele 1. Auflage 2012. Taschenbuch. xxiii, 273 S. Paperback ISBN 978 3 8348 1570 5 Format (B x

Mehr

Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant

<Insert Picture Here> Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant Oracle Business Process Analysis Suite Gert Schüßler Principal Sales Consultant 1 Geschäftsprozesse Zerlegung am Beispiel Kreditvergabe Antrag aufnehmen Antrag erfassen Schufa Kunden

Mehr

Middleware. Host. Versuch einer Einleitung. dumme Terminals stellen Ausgaben dar und nehmen Eingaben an

Middleware. Host. Versuch einer Einleitung. dumme Terminals stellen Ausgaben dar und nehmen Eingaben an Middleware Versuch einer Einleitung Host dumme Terminals stellen Ausgaben dar und nehmen Eingaben an Mainframe enthält vollständige Anwendung Typ. COBOL, C Mainframe contd.! Nachteile! Mainframe ist teuer

Mehr

SAP Support On Demand - IBMs kombiniertes Service-Angebot für SAP Hosting und SAP Application Management Services (AMS)

SAP Support On Demand - IBMs kombiniertes Service-Angebot für SAP Hosting und SAP Application Management Services (AMS) (IGS) SAP Support On Demand - IBMs kombiniertes Service-Angebot für SAP Hosting und SAP Application Services (AMS) Martin Kadner, Product Manager SAP Hosting, GTS Klaus F. Kriesinger, Client Services Executive,

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Prozessorientierte Integration von Anwendungssystemen WS 2015 FWP-Fach für Bachelor Wirtschaftsinformatik

Prozessorientierte Integration von Anwendungssystemen WS 2015 FWP-Fach für Bachelor Wirtschaftsinformatik Prozessorientierte Integration von Anwendungssystemen WS 2015 FWP-Fach für Bachelor Wirtschaftsinformatik Prof. Dr. Torsten Zimmer, Hochschule München Motivation für Integrationsplattformen Nach einer

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

Basistechnologien: Web-Services

Basistechnologien: Web-Services Alexander Rudolf Cloud-Computing Seminar Hochschule Mannheim WS0910 1/29 Basistechnologien: Web-Services Alexander Rudolf Hochschule Mannheim Fakultät für Informatik alexander.rudolf@stud.hs-mannheim.de

Mehr

Das Zusammenspiel von mysap ERP, SAP NetWeaver und der ESOA

Das Zusammenspiel von mysap ERP, SAP NetWeaver und der ESOA Das Zusammenspiel von mysap ERP, SAP NetWeaver und der ESOA Erschienen in der E3 04/2007 Von Dr. Carl Winter, REALTECH AG Wer im Umfeld von SAP Systemlandschaften über mysap ERP 2005 spricht, landet schnell

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft der

Mehr

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Frank Kargl Torsten Illmann Michael Weber Verteilte Systeme Universität Ulm {frank.kargl torsten.illmann weber} @informatik.uni-ulm.de

Mehr

Von SAP R/3 zu mysap ERP und NetWeaver

Von SAP R/3 zu mysap ERP und NetWeaver Von SAP R/3 zu mysap ERP und NetWeaver Bremerhaven 06.05.2006 T4T Bremerhaven 1 Inhaltsverzeichnis 1. Motivation für SAP NetWeaver 2. SAP R/3 mysap ERP und SAP Business Suite 3. Application Platform T4T

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

Service Oriented Architecture. IM-Briefing 2008 4. Dezember 2008

Service Oriented Architecture. IM-Briefing 2008 4. Dezember 2008 Service Oriented Architecture IM-Briefing 2008 4. Dezember 2008 Agenda Begrüssung Was ist SOA Herkunft Player Modell Komponenten Zusammenfassung Diskussion Seite 1 Was ist SOA? Herkunft Der Begriff serviceorientierte

Mehr

SOA Starter Kit Einführungsstrategien und Einstiegspunkte

SOA Starter Kit Einführungsstrategien und Einstiegspunkte SOA Starter Kit Einführungsstrategien und Einstiegspunkte Benjamin Brunner Berater OPITZ CONSULTING Bad Homburg GmbH SOA Starter Kit Seite 1 Agenda Wer sollte eine SOA nutzen? Welche Ziele kann eine SOA

Mehr

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor auf Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

J2EEKurs. J2EE eine Plattform für betriebliche Anwendungen. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.

J2EEKurs. J2EE eine Plattform für betriebliche Anwendungen. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10. J2EE eine Plattform für betriebliche Anwendungen Universität Freiburg, Germany Sommercampus, Freiburg, Germany, 10.-14.10.2005 Plattform Betriebliche Anwendung J2EE Kontrahenten J2EE im Überblick Was ist

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Geschäftsstrategie und SOA - ein Thema für den Mittelstand? Prof. Dr. Gunther Piller

Geschäftsstrategie und SOA - ein Thema für den Mittelstand? Prof. Dr. Gunther Piller Geschäftsstrategie und SOA - ein Thema für den Mittelstand? Prof. Dr. Gunther Piller Aktuelles 2 Langfristige strategische IT- Planung existiert [im Mittelstand] in vielen Fällen nicht Bitkom: IuK im Mittelstand,

Mehr

5. Übung zur Vorlesung Service-orientierte Architekturen

5. Übung zur Vorlesung Service-orientierte Architekturen 5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter

Mehr

Software-Architekturen für das E-Business

Software-Architekturen für das E-Business Sebastian Herden Jorge Marx Gömez Claus Rautenstrauch Andre Zwanziger Software-Architekturen für das E-Business Enterprise-Application-Integration mit verteilten Systemen Mit 60 Abbildungen 4y Springer

Mehr

Von 0 auf SOA in 10 Schritten. Stefan Tilkov innoq stefan.tilkov@innoq.com

Von 0 auf SOA in 10 Schritten. Stefan Tilkov innoq stefan.tilkov@innoq.com Von 0 auf SOA in 10 Schritten Stefan Tilkov innoq stefan.tilkov@innoq.com 1 Stefan Tilkov Geschäftsführer und Principal Consultant, innoq Deutschland GmbH Fokus auf SOA, Web-Services, REST SOA-Editor InfoQ.com

Mehr

R016 Beilage 5: SOA-Glossar

R016 Beilage 5: SOA-Glossar Eidgenössisches Finanzdepartement EFD Informatiksteuerungsorgan des Bundes ISB R016 Beilage 5: SOA-Glossar Ausgabedatum: 2015-02-25 Version: 2.01 Status: Genehmigt Ersetzt: 2.0 Verbindlichkeit: Weisung

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Java Web Services in der Praxis

Java Web Services in der Praxis Java Web Services in der Praxis Realisierung einer SOA mit WSIT, Metro und Policies von Andreas Holubek, Oliver Heuser 1. Auflage Java Web Services in der Praxis Holubek / Heuser schnell und portofrei

Mehr

Einführung in WebServices

Einführung in WebServices Einführung in WebServices Grundlagen und Praxis von WebServices Seminarleiterin: Dipl.-Ing. Mahbouba Gharbi Folie 1 / 34 Zielsetzung und Voraussetzungen Zielsetzung Nutzen von WebServices kennenlernen

Mehr

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de Vorlesung Grundlagen betrieblicher Informationssysteme Prof. Dr. Hans Czap Email: Hans.Czap@uni-trier.de - II - 1 - Inhalt Kap. 1 Ziele der Datenbanktheorie Kap. 2 Datenmodellierung und Datenbankentwurf

Mehr

Verteilte Systemarchitekturen

Verteilte Systemarchitekturen Verteilte Systemarchitekturen Proseminar im WS 09/10 Prof. Sergei Gorlatch, Philipp Kegel, Alexander Ploß Parallele und verteilte Systeme, Westfälische Wilhelms-Universität Münster 17. Juli 2009 Inhalte

Mehr

SOA und Prozessmanagement: Herausforderung und aktuelle Arbeiten

SOA und Prozessmanagement: Herausforderung und aktuelle Arbeiten SOA Prozessmanagement: Herausforderung aktuelle Arbeiten Projekt-Kurzvorstellung beim Gründungstreffen des EMISA-Arbeitskreises Entwicklung agiler, prozessorientierter Informationssysteme Reiner Siebert,

Mehr

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg COMMON OBJECT REQUEST BROKER ARCHITECTURE Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg Gliederung Motivation Was ist CORBA? Object Management Architecture (OMA ) Interface Definition Language

Mehr

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis

Mehr

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen IN-Q-My Title Company (Name) / 1 Agenda Firmenübersicht ebusiness Evolution InQMy Application Server Architektur Zusammenfassung

Mehr

OSS/J als Basis für Enterprise Application Integration

OSS/J als Basis für Enterprise Application Integration OSS/J als Basis für Enterprise Application Integration Geschäftsprozessgesteuerte EAI im Telekommunikationsbereich r A business of PwC Agenda OSS-Architekturen als Integrationsherausforderung OSS/J als

Mehr

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

SECTINO. Security for Inter-Organizational Workflows

SECTINO. Security for Inter-Organizational Workflows SECTINO Security for Inter-Organizational Workflows Framework zur Modellierung und Realsisierung sicherheitskritischer organisationsübergreifender Workflows Kooperation Research Group Quality Engineering

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Abbildung 3-1: Clients und Server C+S

Abbildung 3-1: Clients und Server C+S Abbildung 3-1: Clients und Server C+S Abbildung 3-2: Interaktions-koordinations-arten Abbildung 3-3: Zuverlässige Nachrichtenübertragung a) durch individuell quittierte Nachrichten b) durch Quittierung

Mehr

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Konzeption und prototypische Implementierung eines Knowledge-Servers mit Adaptern zur Integration

Mehr

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel VS12 Slide 1 Verteilte Systeme Vorlesung 12 Sebastian Iwanowski FH Wedel Mögliche Plattformen für Web Services VS12 Slide 2 VS12 Slide 3 Java-Software für verteilte Systeme J2EE: Java 2 Enterprise Edition

Mehr

Workflow Management: Workflow (1)

Workflow Management: Workflow (1) Workflow Management: Workflow (1) Abgrenzung: Geschäftsprozeß Vorgang (Aktivität) Arbeitsablauf (Workflow) Arbeitsschritt (Work Item) Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut

Mehr

Business Process Management und Enterprise Service Bus

Business Process Management und Enterprise Service Bus Business Process Management und Enterprise Service Bus Gegner oder doch eine gute Ergänzung? Author: Date: Markus Demolsky Soreco International 08. November 2010 Vortragender Warum über Integration nachdenken?

Mehr

Geschäftsprozessmodellierung essmodellierung mit BPEL

Geschäftsprozessmodellierung essmodellierung mit BPEL Geschäftsprozessmodellierung essmodellierung mit BPEL Autor: Stefan Berntheisel Datum: 8. Januar 2010 Stefan Berntheisel Hochschule RheinMain Fachseminar WS 09/10 Agenda Grundlagen Business Process Execution

Mehr

Voraussetzungen für die betriebswirtschaftliche SOA-Einführung

Voraussetzungen für die betriebswirtschaftliche SOA-Einführung Wissenschaftliche Beiträge aus dem Tectum-Verlag 49 Voraussetzungen für die betriebswirtschaftliche SOA-Einführung von Bastian de Hesselle 1. Auflage Voraussetzungen für die betriebswirtschaftliche SOA-Einführung

Mehr

Enterprise Application Integration

Enterprise Application Integration 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Wolfgang Keller Enterprise Application Integration Erfahrungen aus

Mehr

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm Web Services Boto Bako Inhaltsverzeichnis 1.Einführung und Motivation...3 2.Verwendete Standards...4 2.1.SOAP...5 2.2.WSDL...6

Mehr

Sun ONE. Sun Open Net Environment. Architektur für Web-Services on Demand. Dr. Rainer Eschrich rainer.eschrich@sun.com

Sun ONE. Sun Open Net Environment. Architektur für Web-Services on Demand. Dr. Rainer Eschrich rainer.eschrich@sun.com Sun ONE Sun Open Net Environment Dr. Rainer Eschrich rainer.eschrich@sun.com Architektur für Web-Services on Demand Sun ONE Vision Wie kann Software dem Kunden helfen? Kostenreduktion: Wie? In dem man

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

CRONOS CRM Online for OS

CRONOS CRM Online for OS www.osram-os.com CRONOS CRM Online for OS B. Blanz, S. Eichinger 08.09.2014 Regensburg Light is OSRAM Customer Relationship Management Online for OS Page 1. Vorstellung des Projekts CRONOS 04 2. Anforderungsanalyse

Mehr

Attraktive Spielideen mit Social Experience auf Basis der Community Gaming-Plattform in FOCUS Bingo

Attraktive Spielideen mit Social Experience auf Basis der Community Gaming-Plattform in FOCUS Bingo Mit dem Online-Spieleangebot Bingo wird das Lotteriespiel zum Community-Erlebnis Attraktive Spielideen mit Social Experience auf Basis der Community Gaming-Plattform in FOCUS Bingo Online-Bingo 1 Die steigende

Mehr

XML in der betrieblichen Praxis

XML in der betrieblichen Praxis Klaus Turowski, Klement J. Fellner (Hrsg.) XML in der betrieblichen Praxis Standards, Möglichkeiten, Praxisbeispiele Ги dpunkt.verlag Inhaltsverzeichnis 1 XML/EDI-Standardisierung: Ein Überblick 1 1.1

Mehr

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Block Verteilte Systeme und Middleware 1. Beschreiben Sie die Entwicklung verteilter Systeme von einer Zentralisierung bis zu Peer-to-Peer. Nicht

Mehr

Business Rules und SOA. Parallelen und Synergien

Business Rules und SOA. Parallelen und Synergien Business Rules und SOA Parallelen und Synergien White Paper Januar 2008 Innovations Software Technology GmbH, 2008. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von

Mehr

PRODATIS CONSULTING AG. Folie 1

PRODATIS CONSULTING AG. Folie 1 Folie 1 Führend im Gartner Magic Quadranten für verteilte, interagierende SOA Projekte Oracle ist weltweit auf Rang 1 auf dem Markt der Enterprise Service Bus Suiten (ESB) für SOA Software 2010 26,3 %

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Technik der SAP-Anbindung Christian Aigner Team Entwicklung, Kranzberg

Technik der SAP-Anbindung Christian Aigner Team Entwicklung, Kranzberg Christian Aigner Team Entwicklung, Kranzberg Inhalt Schnell- und Kürzestübersicht über SAP Architektur Inhalt, Login, Session SapGUI Workbench,Editor,Explorer Mechanismen Die Gemeinsamkeiten: nutzbare

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

ITSM Infoday 2013. Mit Business Process Service Management zu mehr Flexibilität, Transparenz und Stabilität. Peter Brückler

ITSM Infoday 2013. Mit Business Process Service Management zu mehr Flexibilität, Transparenz und Stabilität. Peter Brückler ITSM Infoday 2013 Mit Business Process Management zu mehr Flexibilität, Transparenz und Stabilität Peter Brückler Copyright 2013 NTT DATA EMEA Ltd. Agenda Der Druck auf Unternehmen Business Process Management

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

Web Services T-Systems GS Darmstadt

Web Services T-Systems GS Darmstadt T-Systems GS Darmstadt Optional: Präsentationstitel Verfasser, Dr. A. Heck, Projekt, T-Systems weitere Angaben Datum, 23.10.2002, Seite Seite 1 1 Übersicht 1. Unternehmensdarstellung T-Systems 2. Definition

Mehr