Serviceorientierte Architekturen: Vom Konzept zum Einsatz in der Praxis

Serviceorientierte Architekturen: Vom Konzept zum Einsatz in der Praxis Roger Heutschi, Dr. Christine Legner, Prof. Dr. Hubert Österle Institut für Wirtschaftsinformatik Universität St. Gallen Müller-Friedberg-Str. 8 CH-9000 St. Gallen christine.legner@unisg.ch ccbn3.iwi.unisg.ch Konferenz DW2006: SOA: Konzept & Praxis Fact Sheet zum Beitrag „Serviceorientierte Architekturen – Christine Legner 21.9.2006 Seite 2 vom Konzept zum Einsatz in der Praxis“ Universität Universität St. Gallen Institut für Wirtschaftinformatik Forschungsgebiet Geschäftsarchitekturen des Informations- zeitalters / Business Engineering / Business Networking Forschungsprojekt Titel Competence Center Business Networking 3 (CC BN3) Forschungsprojekt seit CC BN3 seit 2004, Vorgängerprojekte seit 1995 Anzahl Mitarbeiter Lehrstuhl 15 Anzahl Mitarbeiter Projekt 7 Öffentliche Förderung - (bei entspr. gefördertem Projekt, z.B. DFG, SNF) Beteiligte Unternehmen Degussa AG, ETA SA, Fraport AG, LBA, Migros, SAP AG, T-Com © CC BN3 / IWI-HSG Konferenz DW2006: SOA: Konzept & Praxis Zielsetzung und Forschungsmethodik des Beitrags Christine Legner 21.9.2006 Seite 3 – Zielsetzung: • SOA-Begriffsverständnis aus Sicht der Theorie herleiten • SOA-Umsetzungen in der Praxis diesem SOA-Begriffsverständnis gegenüberstellen – Ergebnisse: • SOA-Architekturmodell (Architekturebenen, Gestaltungs- komponenten und definierte Designprinzipien) • Einordnung von 4 Fallstudien anhand des Architekturmodells • Ableitung von verschiedenen SOA -Einsatzszenarien in der Praxis (mit unterschiedlichen Treibern, Zielen, Potenzialen und Massnahmen) – Forschungsmethodik: • Literaturanalyse • qualitative Fallstudienforschung © CC BN3 / IWI-HSG Konferenz DW2006: SOA: Konzept & Praxis Agenda Christine Legner 21.9.2006 Seite 4 – SOA-Architekturmodell – Überblick über die Fallstudien – Einordnung der SOA-Umsetzungen im Architekturmodell – Einsatzszenarien für SOA – Zusammenfassung und Ausblick © CC BN3 / IWI-HSG Konferenz DW2006: SOA: Konzept & Praxis SOA-Begriffsverständnis [W304; Oa05; Zy02] Christine Legner 21.9.2006 Seite 5 – Services stellen abstrakte Software-Elemente bzw. Schnittstellen dar, die anderen Applikationen unter Nutzung von verbreiteten Standards stabile, wieder verwendbare Software-Funktionalität auf einer anwendungsorientierten, fachlichen Granularitätsstufe anbieten. – Eine SOA ist eine mehrschichtige, verteilte Informationssystem (IS)-Architektur, die Teile der Applikationsarchitektur als Services kapselt und dabei eine Reihe von Designprinzipien berücksichtigt. © CC BN3 / IWI-HSG Konferenz DW2006: SOA: Konzept & Praxis SOA-Architekturmodell Christine Legner 21.9.2006 Seite 6 Anwendungsbezogene Sicht Anwendungsneutrale Sicht (fachliche Anwendungslogik) (Integrationsmechanismen) Desktop- Benutzer- unterstützt imple- Portal- / CA- Portal mentiert integration aktivität Plattform nutzt Workflow- imple- Workflow Prozess- führt aus Workflow mentiert Management integration aktivität System nutzt beschreibt Services Service- enthält Service- nutzt Service spezifikation verzeichnis kommuniziert beschreibt verweist über auf Middleware- bietet dienste nutzt Applikations- definiert Service- Nachricht domäne schnittstelle nutzt implementiert / Anwendungs- nutzt Applikations- gruppiert Applikation bietet system schnittstelle © CC BN3 / IWI-HSG Konferenz DW2006: SOA: Konzept & Praxis Aus der Literatur lassen sich vier Gruppen von Service- Christine Legner 21.9.2006 Seite 7 Designprinzipien ableiten – Schnittstellenorientierung • Abstraktion von der Serviceimplementierung • Umfassende technische und fachliche Servicespezifikation • Stabile, gemanagte Servicekontrakte – Interoperabilität • Technische Schnittstellenstandardisierung • Fachliche Schnittstellenstandardisierung • Verwendung offener und verbreiteter Industriestandards – Autonomie und Modularität • Hohe Servicekohäsion und schwache logische Kopplung • Lose gekoppelte Kommunikation – Bedarfsorientierung • An Geschäftskonzepten orientierte, grobe Servicegranularität • Generalisierung der Serviceleistung © CC BN3 / IWI-HSG Konferenz DW2006: SOA: Konzept & Praxis Backup: Herleitung der SOA-Designprinzipien Christine Legner 21.9.2006 Seite 8 [KWS05] [BJK02] [NL04.

Serviceorientierte Architekturen: Vom Konzept zum Einsatz in der Praxis Roger Heutschi, Christine Legner, Hubert Österle Institut für Wirtschaftsinformatik Universität St. Gallen Müller-Friedberg-Strasse 8 9000 St. Gallen Roger.Heutschi@unisg.ch Christine.Legner@unisg.ch Hubert.Oesterle@unisg.ch Abstract: Serviceorientierte Architekturen (SOA) werden gegenwärtig als Ansatz für eine einfachere und flexiblere inner- und zwischenbetriebliche Integration hete- rogener Anwendungssysteme diskutiert. Dieser Beitrag entwickelt ein SOA- Architekturmodell und untersucht seine Ausprägung in vier Praxisbeispielen. Er identifiziert aus den Fallstudien ausserdem typische Architekturtreiber, Einsatzzie- le, Nutzenpotenziale und Architekturmassnahmen einer SOA-Umsetzung in der Praxis.1 1 Einleitung Obwohl das Konzept serviceorientierter Architekturen (SOA) seit ca. zwei Jahren inten- siv diskutiert wird und die grossen Softwarehersteller ihre Lösungen daran ausrichten, sind die Erfahrungen mit der Umsetzung in den Unternehmen noch beschränkt [WKW05; Mo05]. Angesichts der Mächtigkeit des Konzeptes stellt sich aus Sicht der Unternehmen die Fragen, welchen Neuigkeitsgrad gegenüber herkömmlichen Architek- turansätzen eine SOA bietet, für welche Problemstellungen sich ihr Einsatz eignet oder welche Fähigkeiten und Architekturmanagement-Massnahmen eine SOA innerhalb des IT-Bereichs erfordert [Ha05, 10;Qu04]. 1 Diese Arbeit entstand im Rahmen des Kompetenzzentrums Business Networking 3 des Instituts für Wirt- schaftsinformatik der HSG (Universität St. Gallen) als Teil des Forschungsprogrammes Business Enginee- ring HSG. Ziel dieses Beitrags ist, die SOA-Konzepte aus Sicht der Wissenschaft den ersten Pra- xiserfahrungen bei SOA-Umsetzung gegenüberzustellen. Dazu arbeitet der Beitrag zu- nächst das SOA-Begriffsverständnis aus der Literatur auf und entwickelt daraus ein Architekturmodell, das SOA anhand von Architekturebenen, Gestaltungskomponenten und definierter Designprinzipien beschreibt (Kap. 2). Er stellt dem Architekturmodell vier SOA-Umsetzungen aus der Praxis gegenüber und identifiziert als Ergebnis Treiber, Ziele, Nutzenpotenziale und Architekturmassnahmen einer SOA (Kap. 3). Der Beitrag verwendet als Forschungsansatz die qualitative Fallstudienforschung (vgl. Yi94). Die Erhebung und Strukturierung der Fallstudien basiert auf der Projektmethode Business Engineering Case Studies (PROMET BECS) von [SÖ04]. Die Fallstudien wurden 2005 anhand von Literatur- und Dokumentenanalysen sowie persönlichen Inte- views erhoben und sind separat dokumentiert. 2 Architekturmodell Architekturen unterstützen die Realisierung physischer oder logischer Systeme, indem sie die grundlegenden Strukturen ihrer Systemkomponenten und ihre Beziehungen zu- einander beschreiben sowie Richtlinien für ihr Design und ihre Weiterentwicklung geben [SG96]. Das im Rahmen dieser Arbeit verwendete Begriffsverständnis einer SOA orien- tiert sich an den Definitionen von [W304; Oa05; Zy02]: Services stellen abstrakte Software-Elemente bzw. Schnittstellen dar, die anderen Appli- kationen unter Nutzung von verbreiteten Standards stabile, wieder verwendbare Soft- ware-Funktionalität auf einer anwendungsorientierten, fachlichen Granularitätsstufe anbieten. Eine SOA ist eine mehrschichtige, verteilte Informationssystem (IS)-Architektur, die Teile der Applikationsarchitektur als Services kapselt und dabei eine Reihe von Design- prinzipien berücksichtigt. Die Literatur ist sich über die grundlegenden Architekturkom- ponenten in einer SOA weitgehend einig. Die Meinungen bezüglich der wesentlichen SOA-Designprinzipien sind aber geteilt. 2.1 SOA-Architekturkomponenten SOA erweitert bestehende Ansätze zur Gestaltung von Informationssystemen wie bspw. Client/Server- oder komponentenorientierte Architekturen (vgl. Hasselbring 2006, S. 49, Mertens 2004, S. 315). Im folgenden werden die Architekturkomponenten einer SOA (s. Abb. 1) in einem Architekturmodell eingeordnet, das auf den Modellen von [Vo04; Sc04; Er05] basiert. Es beschreibt eine SOA als mehrschichtige Integrationsarchitektur, welche die fachliche Prozessarchitektur mit der Applikationsarchitektur verbindet, und unterscheidet folgende Ebenen: 2 • Die Ebene Anwendungssystem umfasst betriebliche Anwendungssysteme, die Ap- plikationsfunktionen und Datensammlungen implementieren [Vo04]. Sie repräsen- tiert in diesem Modell die Ressourcensicht, welche die im IS vorhandene, poten- ziell zur Unterstützung betrieblicher Aktivitäten nutzbare, fachliche Funktionalität betrachtet. • Services strukturieren und kapseln die auf Ebene Anwendungssystem vorhandenen Daten und Funktionen nach den Anforderungen systemübergreifender Prozesse und bilden eine organisationsweit standardisierte Schnittstellen- und Kommuni- kationsschicht [Er05]. Services kommunizieren über Nachrichten und werden durch Servicespezifikationen technisch und fachlich beschrieben. Servicespezifika- tionen werden an zentraler Stelle, in einem Serviceverzeichnis, veröffentlicht, über das potenzielle Nutzer geeignete Services identifizieren können. Applikations- domänen gruppieren architekturweit fachlich zusammengehörige Funktionen und Daten möglichst redundanzfrei und kapseln sie über Services nach aussen [Sc04]. Der Zugriff der Serviceschnittstellen auf die Funktionalität der Ebene Anwen- dungssystem erfolgt dabei unter Nutzung von Middlewarediensten zur Funktions-, Daten- oder Präsentationsintegration. Solche Middlewaredienste stellen bspw. App- lication Server oder Message Broker zur Verfügung [Al03]. • Die Ablaufsteuerung eines rollen- und applikationsübergreifenden Geschäfts- prozesses ist Gegenstand der Ebene Workflowintegration. Im Rahmen einer Workflowintegration ist die Ablauflogik des Integrationssystems in Form eines ausführbaren Prozessmodells – eines Workflows – definiert. Ein Workflow stellt zur Ausführungszeit einen automatisierten (Teil-) Prozess dar, der Dokumente, In- formationen oder Aufgaben anhand bestimmter Regeln von einer bearbeitenden Ressource zur nächsten weiterleitet [WF99]. •Die Ebene Desktopintegration bringt die zur Erfüllung von Aufgaben notwendigen betrieblichen Anwendungen an einem Arbeitsplatz zusammen. Sie stellt die Sicht- weise einer Mitarbeiter- bzw. Benutzerrolle in den Vordergrund. Portale oder Composite Applications (CA) stellen die heute typische Form der Desktop- integration dar. Für den Steuer- und Datenfluss zwischen Arbeitsschritten einer desktopintegrierten Applikation verwendet [Vo04], den Begriff Taskflow. Bei der Beschreibung der Ebenen unterscheidet das Modell in Anlehnung an [Sc04], eine anwendungsbezogene Sicht und eine anwendungsneutrale Sicht. Die anwendungs- bezogene Sicht konzentriert sich auf Architekturkomponenten, die fachliche Logik um- setzen (Applikationslogik, Workflows etc.). Die anwendungsneutrale Sicht beschreibt Integrationsmechanismen und Infrastrukturkomponenten ohne unmittelbaren fachlichen Bezug, die Dienste und Protokolle zur Implementierung der Systemintegration bereitstel- len. 2 Ein detaillierteres Modell mit ausführlicher Beschreibung der Ebenen, Architekturkomponenten und ihrer Beziehungen zueinander findet sich in [Sc06].