Reza Noroozi. Modellgetriebene Entwicklung aller SOA-Schichten

Reza Noroozi Modellgetriebene Entwicklung aller SOA-Schichten Diplomarbeit eingereicht im Rahmen der Diplomprüfung im Studiengang Angewandte Informatik am Department Informatik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg Betreuender Prüfer : Prof. Dr. rer. nat. Jörg Raasch Zweitgutachter : Prof. Dr. Olaf Zukunft Abgegeben am 04. Januar 2008

Reza Noroozi Thema der Diplomarbeit Modellgetriebene Entwicklung aller SOA Schichten Stichworte Modelgetriebene Softwareentwicklung, modellgetriebene Architektur, Modellierung, serviceorientierte Architektur, Webservice Kurzzusammenfassung Diese Diplomarbeit beschreibt einen Ansatz, Schichten einer SOA mit Hilfe von Methoden der modellgetriebene Softwareentwicklung zu realisieren. Dabei wird definiert welche der Schichten sich modellgetrieben entwickeln lassen. Hierzu werden die Opensource Werkzeuge AndroMDA und openarchitectureware, die der Unterstützung von modellgetriebener Softwareentwicklung dienen, auf ihre Praxistauglichkeit evaluiert. Als Ergebnis der Untersuchung soll beurteilt werden, welches Werkzeug für die Umsetzung des im Rahmen dieser Arbeit zu entwickelnden Konzepts am zweckmäßigsten ist. Dieses Werkzeug wird schließlich verwendet um einen Prototypen zu realisieren. Reza Noroozi Title of the paper Model driven development of all SOA Layers Keywords Model driven software development, model driven architecture, modelling, service-oriented architecture, web service Abstract This thesis describes a concept of how to develop layers of a Service Orientated Software Architecture with the help of methods of model driven Software Development. In this context it will be defined which of these layers can be developed in a model driven way. Therefore, it will be evaluated how practically useful the tools AndroMDA and openarchitectureware are, which are for the support of model driven architecture. The result of the evaluation will be, to choose the tool that is most efficient in the frame of the concept that is to be developed in this paper. Finally, this tool will be used to realise a prototype.

Inhaltsverzeichnis Inhaltsverzeichnis... I Abbildungsverzeichnis... IV Tabellenverzeichnis... VI Abkürzungsverzeichnis...VII 1 Einleitung...9 1.1 Motivation...10 1.2 Ziel der Arbeit...11 1.3 Kapitelbeschreibung...12 2 Grundlagen der MDA/MDSD...14 2.1 Einführung...14 2.2 Motivation und Ziele der MDA...15 2.3 Modellierung...17 2.3.1 Metamodelle...17 2.3.2 UML Profile...18 2.4 Modelle der MDA...19 2.4.1 Computation Independent Model...20 2.4.2 Platform Independent Model...21 2.4.3 Platform Model...21 2.4.4 Platform Specific Model...22 2.4.5 Platform Specific Implementation...23 2.5 Transformation...23 2.5.1 Transformationsarten...24 2.5.2 Re-Enginering...25 2.5.3 Templatebasierte Transformation...26 3 Serviceorientierte Architektur...28 3.1 Einführung...28 3.2 Kernidee einer SOA...29 3.2.1 Geschäftsprozesse...29 3.2.2 Drei Rollen einer SOA...30 3.3 SOA Schichten...31 3.3.1 Präsentationsschicht...32 3.3.2 Orchestrierungsschicht...33

II 3.3.3 Serviceschicht...33 3.3.4 Integration Architecture-Schicht...33 3.3.5 Applikationsschicht...34 3.4 Web Service...34 3.4.1 SOAP...34 3.4.2 WSDL...34 3.4.3 UDDI...34 3.5 Fazit...35 4 Vergleichbare Arbeiten...36 4.1 Ansätze aus der Literatur...36 4.2 Softwaretechnische Lösungen...37 5 MDSD Werkzeuge...38 5.1 Überblick...38 5.2 Anforderungsanalyse...38 5.2.1 Modellierungskriterien...42 5.2.2 Transformationskriterien...43 5.2.3 IDE Integrationskriterien...44 5.2.4 Dokumentation...45 5.2.5 Übersicht der Anforderungen...45 5.3 openarchitectureware...46 5.3.1 Einführung...46 5.3.2 Architektur...46 5.3.3 Modellierung...47 5.3.4 Modeltransformation...48 5.3.5 IDE Integration...48 5.3.6 Dokumentation...49 5.4 AndroMDA...50 5.4.1 Einführung...50 5.4.2 Architektur...50 5.4.3 Modellierung...53 5.4.4 Modelltransformation...53 5.4.5 IDE Integration...54 5.4.6 Dokumentation...55 5.5 Evaluierung...55 6 Analyse...61 6.1 Technische Voraussetzung...61 6.1.1 Realisierungsmöglichkeit einer SOA...61 6.1.2 Feststellung des Umfangs für den Prototypen...62 6.2 Zielplattform...63

III 6.2.1 Zielplattform...63 6.2.2 Benötigte Tools...66 Eclipse und oaw...66 Modellierungswerkzeug...66 Applikationsserver...67 Apache Axis2...67 7 Fallstudie...68 7.1 Bildjournalismus...68 7.2 Servicemodellierung...70 7.2.1 SuchService...70 7.2.2 Orchestrierungsschicht...72 7.3 Clientanwendung...73 7.3.1 Anwendungsfälle...73 7.3.2 Metamodell der Anwendung...74 7.3.3 Businessobjektmodell...75 7.3.4 Präsentationsschicht...76 7.3.5 Serviceschicht...81 7.4 Codeanalyse...82 7.4.1 Übersicht...82 8 Fazit...84 8.1 Zusammenfassung der Ergebnisse...84 8.2 Ausblick...86 Anhang I: Metriken...88 Literaturverzeichnis...92

IV Abbildungsverzeichnis Abbildung 2-1 Entwicklung der Programmiersprachen...16 Abbildung 2-2 offizielle Grafik der MDA...16 Abbildung 2-3 Meta-Ebenen der OMG...17 Abbildung 2-4 Tagged-Value Notation...18 Abbildung 2-5 Generierungsinfrastruktur nach MDA...19 Abbildung 2-6 Formalisierungsbeispiel...20 Abbildung 2-7 CIM Beispiel...21 Abbildung 2-8 PIM Beispiel...21 Abbildung 2-9 Schematische Darstellung einer MDA-Transformation...22 Abbildung 2-10 Beispiel PSM...22 Abbildung 2-11 generiertes PSI (SQL)...23 Abbildung 2-12 generiertes PSI (Java)...23 Abbildung 2-13 Transformationsvarianten M2M und M2T...24 Abbildung 2-14 Transformationsarten...25 Abbildung 2-15 xpand der openarchitectureware...27 Abbildung 2-16 Ausgabeartefakt...27 Abbildung 3-1 Die drei Rollen der Webservices...31 Abbildung 3-2 Die Bestandteile des SOA-Modells nach [LIEBHART 2007]...32 Abbildung 5-1 Generator Frameworks der oaw...47 Abbildung 5-2 xpand mit Code-Highlithing- und Vervollständigungsmechanismus...49 Abbildung 5-3 AndroMDA Architektur...51 Abbildung 5-4 Screenshot Android...55 Abbildung 5-5 Architekturentwurf auf Basis der AndroMDA Cartridges...58 Abbildung 5-6 Architekturentwurf auf Basis der oaw Cartridge (EJB)...58 Abbildung 6-1 Mögliche SOA Realisierung auf Basis von Opensource Produkten...62 Abbildung 6-2 Zielarchitektur des Prototyps...64 Abbildung 6-3 JSF Komponentebaum...66 Abbildung 7-1 SOA des Fallstudie...70 Abbildung 7-2 Klassendiagram SuchService...71 Abbildung 7-3 Ausgabeartefakt...72

V Abbildung 7-4 Anwendungsdiagram des Akteurs Redakteure...73 Abbildung 7-5 UML Profile für die Domäne...74 Abbildung 7-6 Geschäftsobjektmodell des Bildergaleriesystems...76 Abbildung 7-7 Dialogverlauf des Bildergaleriesystems...78 Abbildung 7-8 Verwendung von JSF UI Komponenten in einer JSP (login.jsp)...79 Abbildung 7-9 Beispiel JSF Navigationsregel Datei (faces-config.xml)...79 Abbildung 7-10 Session Facade...81 Abbildung 7-11 Ausgabeartefakt...82

VI Tabellenverzeichnis Tabelle 5-1 Übersicht der Bewertungskriterien Modellierung...45 Tabelle 5-2 Übersicht der Bewertungskriterien Transformation...46 Tabelle 5-3 Übersicht der Bewertungskriterien IDE Integration...46 Tabelle 5-4 professionelle Support sowie gute Dokumentation...46 Tabelle 5-5 mitgelieferte Cartridges der AndroMDA...52 Tabelle 5-6 Cartridges...52 Tabelle 5-7 Punktvergabe...56 Tabelle 5-8 Modell- und Modellierungskriterien...57 Tabelle 5-9 Transformationskriterien...57 Tabelle 5-10 IDE Integrationskriterien...57 Tabelle 5-11 Dokumentation und Support...57 Tabelle 7-1 Ressourcen für den Webservice...83

VII Abkürzungsverzeichnis CASE CIM DAO DSL EMF GoF HQL J2EE JSF JSP M2C M2M MDA MDD MDR MDSD MOF MVC oaw OMG OO OOA OOD OOP PIM PM PSI PSM RUP SOA Computer Aided Software-Engineering Computation Independent Model Data Access Object Domain Specific Language Eclipse Modeling Framework Gang of Four (Autoren des Buches Design Pattern) Hibernate Query Language Java 2 Plattform Enterprise Edition Java Server Face Java Server Page Model-To-Code Model-To-Model Model Driven Architecture Model Driven Development Meta Date Repository Model Driven Software Development Meta Object Facility Model View Controller openarchitecturware Object Management Group Objektorienietrung Objektorientierte Analyse Objektorientiertes Design Objektorientierte Analyse Platform Independent Model Platform Model Platform Specific Implementation Platform Specific Model Rational Uniffied Process Serviceorientierte Architektur

VIII SOAP UML WS WSDL XMI XML XUML Simple Object Access Protokol Unified Modeling Language Web-Service Web Service Definition Language XML Metadata Interchange extensible Markup Language Executable UML

1 Einleitung Mit der Überschrift How Systeme will be build beschreibt die Object Management Group (OMG) aus ihrer Sicht, wie sie sich die Systementwicklung künftig mit Hilfe ihrer Initiative zur modellgetrieben Softwareentwicklung, Model Driven Architecture (MDA), vorstellt. Im Mittelpunkt der Entwicklung stehen Modelle, welche ohnehin eine wichtige Rolle bei dem Softwareentwicklungsprozess spielten. Jedoch dienten sie zuvor ausschließlich Dokumentations- und Kommunikationszwecken zwischen den beteiligten Personen in Softwareprojekten. Mit Hilfe des MDA-Ansatzes sollen Modelle nun die zentrale Rolle in den Entwicklungsprozessen übernehmen, indem aus den Modellen Code generiert wird. Dabei soll die Transformation aus Modellen bis zur Code-Ebene mehrstufig geschehen. Hierzu führt die OMG im Kontext von MDA die Begriffe plattformunabhängiges und plattformspezifisches Modell ein. Es handelt sich hierbei um die Trennung der Zugehörigkeit von Fachlichkeit und softwaretechnischer Technologie. Die Isolation der Fachlichkeit von der Technologie soll an erste Stelle dafür sorgen, agile Systeme zu schaffen, die flexibel an den ständigen Technologiewandel anpassbar sind. Die Notwendigkeit einer Lösung zu dieser Thematik erklärt sich durch den asynchronen Lebenszyklus der Fachlichkeit und der Technologie eines Systems. Die Anpassung an neue Technologien verlangt monetäre und zeitliche Ressourcen, die bei der Softwareherstellung nicht unbegrenzt zur Verfügung stehen. Somit kann die MDA bei der Modernisierung eines Systems dafür sorgen, dass nicht alle Teile eines Systems neu entwickelt werden müssen. Dies wird durch die Trennung der Fachlichkeit von der technologischen Spezifikation ermöglicht. In den letzten Jahren wurde die MDA von vielen Kritikern als nicht praxistauglich bezeichnet. Microsoft kritisiert die OMG s MDA auf Grund der Modellierungssprache Unified Modeling Language (UML), welche ebenfalls ein Standard der OMG ist und führt seinen Beitrag zur modelgetriebene Softwareentwicklung unter dem Namen Software- Factories (SF) [GREENFIELD und SHORT 2004] ein. Das SF Projekt wird von Jack

Einleitung 10 Greenfield und Keith Short geleitet, beide waren beim Aufsetzen einiger Spezifikationen bei der OMG beteiligt (vgl. [GRUHN et. al. 2006]). Als Kontra-Argument wird die schlechte Beschreibungsmöglichkeit der Domänen mit UML genannt. Als Lösung definieren sie, dass die Modelle domänenspezifisch, d.h ganz an der konkreten Domäne angepasst sein müssen. Doch die UML wurde in den letzten Jahren weiter entwickelt und bietet seit der MOF2 und UML2 eine Reihe von Erweiterungsmöglichkeiten der Modellierungssprache, der UML, wie etwa Stereotypen und Tagged-Values, die speziell für den MDA-Ansatz konzipiert worden. Nach dem Stand der Entwicklung und Erfahrungen, die mit den MDA-Ansatz in den letzten Jahren gemacht wurden, kann heute davon gesprochen werden, dass die modellgetriebene Softwareentwicklung nicht mehr nur ein Forschungsthema ist, sondern eine mögliche Art und Weise darstellt, wie Software entwickelt werden kann, ganz nach OMG s Vorstellung. Auch in der Praxis hat sich die modellgetriebene Softwareentwicklung bewährt. Hierzu führt die OMG eine Liste [OMG 2007a] von Erfolgsgeschichten von Unternehmen auf, die bereits den MDA-Ansatz in Projekten erfolgreich umgesetzt haben, darunter auch DaimlerChrysler AG. Doch wie reagiert die modellgetriebene Softwareentwicklung gegenwärtig auf aktuelle Herausforderungen in der IT-Branche? Diese Frage bezieht sich auf die heutige IT Globalisierung und das Vermeiden von monolithischen Systemen. Die Serviceorientierte Architektur (SOA) verspricht diese Lücke zu schließen, indem Services zur Verfügung gestellt werden, die betriebsintern und bei Bedarf betriebsübergreifend verwendet werden können und bei einem Technologiewechsel weiterhin bestehen bleiben. Ein Service im Kontext von SOA sollte die Fachlichkeit unterstreichen und keinerlei technologische Informationen beinhalten. Diese können betriebsintern sowie von Geschäftspartnern verwendet werden, auch wenn sie unterschiedliche Plattformen verwenden. Bis Dato gibt es Versuche, die MDA für die Serviceorientierung zu verwenden, wie etwa der Standard der OMG zur Modernisierung von bestehenden Applikationen unter dem Namen Architecture Driven Modernization (ADM). Hier sollen durch den modellgetriebene Ansatz MDA Legacy-System e1 modernisiert werden. Diese Arbeit beschäftig sich mit der Möglichkeit eine SOA bzw. die Schichten einer SOA (Präsentations-, Orchestrierungs-, Serviceschicht und die Entitäten) modellgetrieben zu entwickeln. 1.1 Motivation Es werden bereits Methoden der modellgetriebene Softwareentwicklung verwendet, um Schichten einer SOA zu realisieren. Dabei handelt es sich um die 1 dt.: Altsysteme

Einleitung 11 Orchestrierungsschicht, hier werden die Services im Sinne von SOA mit einander zu einem Geschäftsprozess kombiniert. Die Realisierung dieser Schicht wird mit einem Ablaufdiagramm modelliert. Hieraus wird ein textuelles Artefakt generiert, welches mit Hilfe von Workflow-Engines ausgeführt werden kann. Auch bei der Realisierung von Services gibt es Generierungstechniken, die dem Entwickler lästige Routinearbeiten abnehmen. Es besteht, zum Beispiel, mit Apache extensible Interaction System 2 (Axis2) die Möglichkeit, aus einer (Service-) Schnittstellenbeschreibungsdatei (WSDL) Java Code zu generieren (WSDL2Java) oder umgekehrt aus Java WSDL (Java2WSDL) zu generieren. Hier ist das Potential groß, diese modellgetrieben zu entwickeln. Des Weiteren können die modellgetriebenen Softwareentwicklungsmethoden genutzt werden, um den Infrastrukturcode zwischen den Schichten zu generieren. So kann dadurch Entwicklungszeit verkürzt sowie die Qualität einer Anwendung verbessert werden. Die Vorteile der MDA/MDSD können angesichts der eben genannten Fällen helfen, Anwendungen auf Basis einer SOA zu entwickeln. Daher ist es erstrebenswert, hierzu eine Untersuchung zu starten, um herauszufinden, in wie weit sich die Entwicklung einer SOA durch Methoden der modellgetriebene Softwareentwicklung realisieren lässt. 1.2 Ziel der Arbeit Das Ziel dieser Arbeit ist es, ein Konzept zu entwickeln, welches beschreibt, wie mit Hilfe der Methoden der modellgetriebene Softwareentwicklung die Realisierung einer SOA möglich ist. Im Folgenden wird eine Liste der Ziele aufgeführt, die im Rahmen dieser Arbeit angestrebt werden: Grundlagen: Erklärung der grundlegenden Konzepte von modellgetriebener Softwareentwicklung nach OMG s Vorgaben und verwandten Ansätzen. Zudem sollen Grundbegriffe sowie die Kernidee einer SOA geklärt werden. Des Weiteren sollen die SOA Schichten festgelegt und beschrieben werden. Marktanalyse: Vergleich und Bewertung von bestehenden Werkzeugen für modellgetriebene Softwareentwicklung, die sich bereits auf dem Softwaremarkt etabliert haben. Zur Bewertung der Werkzeuge werden einige Anforderungen definiert, an Hand derer das Werkzeug ausgewählt wird, welches für die Umsetzung des Konzepts im Rahmen dieser Arbeit am vorteilhaftesten ist.

Einleitung 12 Konzeption und Realisierung: Bei der Konzeption geht es darum, für die einzelnen SOA-Schichten entsprechende Modelle zu entwerfen. An Hand der entwickelten Modelle soll eine Beispielanwendung modellgetrieben entwickelt werden. Codeanalyse: Eine Codeanalyse dient dazu, mit Hilfe von Code-Metriken zu prüfen, in wie weit die Entwicklung des Prototyps modellgetrieben realisiert wurde und an welchen Stellen eine manuelle Code-Ergänzung stattfand. 1.3 Kapitelbeschreibung Die vorliegende Diplomarbeit gliedert sich wie folgt: Kapitel 2 (Grundlagen der modellgetriebene Softwareentwicklung) gibt einen Überblick über die Motivation und Ziele der MDA sowie über verwandte Ansätze. Kapitel 3 (Serviceorientierte Architektur) beschreibt die Kernidee einer SOA und ihre einzelnen Schichten. Kapitel 4 (Vergleichbare Arbeiten) Hier werden vorhandene Lösungen für modellgetriebene Entwicklung der serviceorientierten Architektur betrachtet und eine methodische Abstraktion dazu definiert. Kapitel 5 (MDSD-Werkzeuge) stellt zwei Werkzeuge zur Unterstützung von Methoden der modellgetriebene Softwareentwicklung vor und evaluiert sie auf ihre Praxistauglichkeit. Kapitel 6 (Analyse) klärt die softwaretechnische Voraussetzung für die Realisierung eines MDA-Projektes. Des Weiteren werden hier Zielplattform und Umfang des Prototyps festgelegt. Kapitel 7 (Fallstudie) In diesem Kapitel werden an Hand eines Beispielszenarios aus dem Bereich Bildjournalismus die erstellten Modelle aus dem vorigen Kapitel verwendet, um eine Applikation auf Basis einer SOA zu erstellten. Ein weiterer Bestandteil dieses Kapitels ist es an Hand von einfachen Softwaremetriken den Anteil des generierten Codes und des manuell entstandenen Code zu untersuchen.

Einleitung 13 Kapitel 8 (Fazit) fasst die Resultate und Erkenntnisse zusammen, die im Rahmen dieser Arbeit erbracht worden sind und gibt eine Szenerie auf die Erweiterungsmöglichkeiten.

2 Grundlagen der MDA/MDSD Der Mensch, das Augenwesen, braucht das Bild - Leonardo da Vinci 2.1 Einführung Die OMG ist ein IT-Konsortium, welches im Jahre 1989 aus elf Mitgliedern gegründet wurde und heute laut [OMG] aus hunderten von Mitgliedern besteht, darunter IBM und Apple, aber auch Endanwender. Sie beschäftigt sich mit der Entwicklung von Standards zur Wiederverwendbarkeit, Portabilität und Interoperabilität von objektorientierten Anwendungen in verteilten und heterogenen Umgebungen. Auch bei der MDA werden diese Ziele verfolgt. Bei dem MDA-Ansatz baut die OMG auf ihren restlichen Standards auf wie bei der Wahl der Modellierungssprache, der UML. Bei der Gewährleistung der Portabilität und Interoperabilität baut die OMG auf die Common Object Request Broker Architecture (CORBA) auf. Die Kernidee dieses Ansatzes ist es Applikationen auf Basis von plattformneutralen Modellen automatisiert zu entwickeln. Um aus ihnen plattformspezifische Modelle oder gar plattformspezifische Implementierung zu erzeugen, dienen Transformatoren, auch Generatoren genannt. Auf diese Weise lassen sich aus einem plattformunabhängigen Modell unterschiedliche plattformspezifische Artefakte erzeugen. Neben dem von OMG vorgeschlagenen Standard (MDA) gibt es im Kontext der modellgetriebene Entwicklung von Software die Model Driven Software Development 1 (MDSD). In [STAHL et. al 2007] wird MDSD als ein 1 dt.: modelgetriebene Softwareentwicklung

Grundlagen der MDA/MDSD 15 Oberbegriff für Techniken bezeichnet, die aus formalen Modellen automatisiert, lauffähige Software erzeugen. MDA ist dem zu Folge eine Standardisierungsinitiative der OMG zum Thema MDSD. Bevor die Motivation und Ziele der MDA beschrieben werden, folgt eine Definition der MDA nach [MDA 2007c]: The MDA is a new way of developing applications and writing specifications, based on a platform-independent model (PIM) of the application or specification's business functionality and behavior. A complete MDA specification consists of a definitive platform-independent base model, plus one or more platform-specific models (PSM) and sets of interface definitions, each describing how the base model is implemented on a different middleware platform. A complete MDA application consists of a definitive PIM, plus one or more PSMs and complete implementations, one on each platform that the application developer decides to support [ ] 2.2 Motivation und Ziele der MDA Mit dem Erkennen der Software-Krise in den 60ern stieg der Bedarf an ingenieurmäßiger Softwareentwicklung. Seither werden ständig Techniken und Methoden entwickelt um der Krise entgegen zu wirken. Unter Softwarekrise ist an erster Stelle die termingerechte Zeiteinhaltung der Softwarelieferung an den Kunden gemeint [RAASCH 1993]. Neben der Termineinhaltung beinhaltet die Krise auch die Missverständnisse zwischen den Fachleuten und den Entwicklern. Dies hat zur Folge, dass das Produkt den Anforderungen des Kunden nicht in allen Punkten entspricht. Laut einer Studie der Standish Group [STANDISHGROUP] über die Erfolgsstatistik von IT- Projekten (Chaos Report) ist seit 1994 die Zahl der gescheiterten Projekte gegenüber dem heutigen Stand deutlich verbessert. [PETRASCH und MEIMBERG 2006] schreibt, dass heute noch lange nicht das Ende der Krise in Sicht ist, da heute noch viele Software- Projekte nicht mit dem zur Verfügung stehenden Budget auskommen. Die historische Betrachtung der Software-Industrie zeigt ein gewisses sich wiederholendes Entwicklungsschema zur Bewältigung der Komplexität auf. Sie wurden immer abstrakter, d.h. sie entwickelte sich immer mehr weg von dem Maschinen Code (vgl. [PETRASCH und MEIMBERG 2006], [GRUHN et. al. 2006]). Die Abbildung 2-1 illustriert die Entwicklung der Programmiersprachen. Zwar wurde durch den Entwicklungsgang der Programmiersprachen die Softwareherstellung leistungsfähiger [PETRASCH und MEIMBERG 2006], die Komplexität der Anwendungen aber stiegen weiterhin. Nach [PETRASCH und MEIMBERG 2006] stehen die Modellierungssprachen, wie etwa MDA, als letzte Stufe in den Abstraktionsleveln.

Grundlagen der MDA/MDSD 16 Abbildung 2-1 Entwicklung der Programmiersprachen Das Ziel, welches die OMG mit der MDA verfolgt, lässt sich aus der offizielle Grafik (siehe Abbildung. 2-2) der MDA erkennen: Im Mittelpunkt der MDA stehen die Spezifikationen der OMG Common warehouse metamodel (CWM), MetaObject Facility (MOF) und die UML. Eine Schicht höher, welche im Bild blau dargestellt ist, stehen Technologien wie CORBA, Web-Services, Java,.NET und XML, welche aus Modellen entstehen. Die äußerste Schicht nennt einige in diesem Kontext wichtige Konzepte des Software-Engineering. Die Pfeile aus dem Kreis heraus stellen die Domänen dar, die modellgetrieben entwickelt werden. Abbildung 2-2 offizielle Grafik der MDA Durch den MDA Ansatz soll die Portabilität, Interoperabilität und Wiederverwendbarkeit gewährleistet bzw. erhöht werden.

Grundlagen der MDA/MDSD 17 2.3 Modellierung 2.3.1 Metamodelle Ein Modell nach [IEEE1471] 1 beschreibt oder spezifiziert ein System zu genau einem bestimmten Zweck. Ein Metamodell stellt die Beschreibungsmittel zur Verfügung, um ein Modell beschreiben zu können. Dieses Modell hat nur die Grammatik des Metamodells zur Verfügung. Das Metamodell wiederum ist ebenfalls eine Instanz eines weitern Modells, welches als Metametamodell bezeichnetet wird. Die OMG definiert hierzu die Metaebenen [MOF], welche auch als Meta-Architektur 2 bezeichnet wird. Die Abbildung 2-3 zeigt die einzelnen Ebenen und in welchem Verhältnis sie zu einander stehen. Jede Ebene (M#), mit Ausnahme von M3, ist eine Instanz der oberen Ebene (M#+1) und hat die Beschreibungsmittel, die ihr von oberer Ebene zur Verfügung gestellt werden. Die M3 kann durch ihre eigenen Beschreibungsmittel beschrieben werden. beschreibt instanceof M3 <<MOF-Element>> Class Metametamodell beschreibt instanceof Metamodell M2 <<UML-Metaelement>> Class beschreibt instanceof Modell M1 Person beschreibt instanceof Instanz M0 Reza Noroozi Abbildung 2-3 Meta-Ebenen der OMG 1 Übernommen aus [GRUHN et. al 2006] 2 Zu der Bezeichnung Meta-Architektur äußern sich [PETRASCH und MEIMBERG 2006] wie folgt: [ ] wobei der Begriff Architektur recht überstrapaziert ist hier ist keine Software-Architektur gemeint, sondern die Schichtung der Metaebenen.

Grundlagen der MDA/MDSD 18 2.3.2 UML Profile Mit dem Konzept des UML-Profiles wird ein Standardmechanismus zur Erweiterung des Sprachumfangs vom Metamodel (M2) angeboten. Es gibt bereits einige UML Profiles [OMG 2007b], die von OMG erstellt worden sind und bei Bedarf verwendet werden können. Mit Hilfe eines UML Profiles lässt sich eine Domäne konkreter beschreiben. Die Mechanismen, die bei dem Konzept der UML Erweiterungen eine zentrale Rolle einnehmen sind: Stereotypen, Constraints 1 und TaggedValues 2. Diese werden auch als lightweight Extensions 3 bezeichnet. Ein UML-Profile fasst die lightweight Extensions zusammen, um eine Domäne exakter beschreiben zu können. Bei einem Stereotyp handelt es sich um eine Metamodellklasse, welche beschreibt, wie sie durch andere (Metamodell-)Klassen erweitert werden kann. Nicht nur Klassen können mit Stereotypen versehen werden, sondern auch die Attribute, Operationen sowie Beziehungen. Stereotypen werden in doppelten spitzen Klammern dargestellt. Der Name des Stereotypen fängt mit einem Kleinbuchstabe an. Der Zeit gibt es eine Reihe von Standard Stereotypen (Notation: «stereotypen»). Constraints werden benutzt, um die Semantik eines UML Modellelements präzise zu beschreiben (Notation: laenge: double{<12.0}). Mit Hilfe von Tagged-Values kann die Semantik eines einzelnen Modellelements erweitert werden. Die Abbildung 2-4 zeigt wie ein Tagged-Value in einem Klassendiagramm verwendet wird. Ein Tagged-Value besteht aus einen Namen (Tag) und seinem Wert (Value). Bei der Abbildung 2-4 handelt es sich um ein persitentes Fachobjekt, welches einen Tagged-Value besitzt, um den Namen der Tabelle für die Datenbanktabelle festzustellen. Hier wir der Klassenname gleichzeitig als Tabellenname festgelegt. <<persistent>> Student {namedertabelle = "Student" } Abbildung 2-4 Tagged-Value Notation Im Kapitel 6 (Fallstudie) werden diese Mechanismen an Hand eines praktischen Einsatzes genauer betrachtet. 1 dt.: Bedingung 2 dt.: markierte Werte 3 dt.: leichtgewichtige Erweiterung

Grundlagen der MDA/MDSD 19 2.4 Modelle der MDA Um die Plattformunabhängigkeit zu gewährleisten, wird bei dem MDA-Ansatz die Generierungsinfrastruktur in Abstraktionsebenen aufgeteilt. Aus einem plattformneutralen Modell soll nach [MDA 2003a] durch eine Transformation ein plattformspezifisches Modell automatisiert generiert werden, welches für die untere Ebene und somit für den jeweiligen Generator als Quelleartefakt dient. Daraus wird schließlich das plattformspezifische Modell oder gar die plattformspezifische Implementierung generiert. Die Abbildung 2-5 zeigt die Abstraktionsebenen einer MDA. Die Rechtecke im Bild illustrieren die Modelle der UML und die unterste Ebene die sprachspezifischen Implementierungen (.NET oder Java), welche durch eine Transformation entstanden sind. Die Pfeile in der Grafik stellen die Transformatoren dar. CIM (Fachliche Spezifikation) PIM (Fachliche Spezifikation) T.Net (PSM) J2EE (PSM) T Code/.Net (PSI) Code/Java (PSI) Abbildung 2-5 Generierungsinfrastruktur nach MDA Die Voraussetzung für die Codegenerierung aus Modellen ist die formale Beschreibung des Modells. Die formalisierte Darstellung soll so beschrieben sein, dass der Transformator sie zur weiteren Verarbeitung verwenden kann. Die formale Darstellung des Modells wird im MDA/MDSD Umfeld als textuelles Artefakt dargestellt. Hierfür bietet sich die XML als formales Beschreibungsdokument an, das trotz der einfachen Beschreibungsweise sehr flexibel ist. Die Abbildung 2-6 zeigt exemplarisch eine Darstellungsmöglichkeit eines UML Modells (hier Klassendiagram) durch ein XML Dokument. Das XML Dokument dient schließlich dem Transformator als Eingangsartefakt. Das Resultat der Transformation ist Code in der Programmiersprache Java.

Grundlagen der MDA/MDSD 20 -name Person +getname() : String +setname( name : String ) Transformation <?xml version="1.0" encoding="utf-8"?> <class name="person"> <fieldlist> <field name="name" type="string" visbility="private"/> </fieldlist> <oplist> <operation name="getname" visbility="public" returntype="string"/> <operation name="setname" paramenter="name:string" returntype="void" visbility="public"/> </oplist> </class> XML Transformation public class Person { private String name; public String getname() { return name; } } public void setname(string name) { this.name = name; } Java Abbildung 2-6 Formalisierungsbeispiel Das Formalisierungsbeispiel (siehe Abbildung 2-6) kann gleichzeitig dafür verwendet werden, zur klären, wie aus demselben Modell Programme in unterschiedlichen Sprachen generiert werden können. Die UML Darstellung ist sehr abstrakt dargestellt und beinhaltet Informationen, welche ganz unabhängig von einer bestimmten Programmiersprache sind. Bei der Transformation können plattformspezifische Informationen verwendet werden, um die gewünschte Zielsprache zu generieren. Diese Technik wird im nächsten Abschnitt genauer betrachtet. 2.4.1 Computation Independent Model Bei dem Computation Independent Model (CIM) 1 handelt es sich um ein Modell, welches ein System ohne irgendwelche Details bezüglich der Hard- und Software beschreibt. Die Abbildung 2-7 illustriert ein CIM, welches ein Teil eines Bibliothek-Systems darstellt. Sie zeigt, dass ein Buch aus Kapiteln besteht. Das beinhaltet keinerlei Information über eine konkrete Plattform. Trotzdem sind die für das Verständnis relevanten Informationen hierin enthalten. 1 dt.: Berechnungsunabhängiges Modell

Grundlagen der MDA/MDSD 21 -titel -isbn -autor Buch +gettitel()... bestehaus 1..* -titel Kapitel +gettitle()... Abbildung 2-7 CIM Beispiel 2.4.2 Platform Independent Model Die plattformunabhängige Modellierung der Fachdomäne wird als Platform Independent Model (PIM) 1 bezeichnet. Bei diesem Modell werden nur die fachlichen Aspekte berücksichtigt und dementsprechend modelliert. Nach der MDA Spezifikation (vgl. [MDA 2003a]) sollte ein PIM technologie- und herstellerneutral sein. Das o.g. CIM wird in diesem Abschnitt spezifiziert. Die Abbildung 2-8 zeigt das Modell detaillierter als die CIM-Darstellung. Die Attribute vom Buch und Kapitel werden mit zusätzlichen Informationen dargestellt: der Typ eines Attributs. Eine weiterer Informationsgehalt, welcher im CIM verborgen blieb und hier dargestellt ist, ist die Assoziation zwischen Buch und Kapitel als Komposition und deren Kardialitäten (1:N). <<entity>> Buch -isbn : String -titel : String -autor : String 1..* <<entity>> Kapitel -titel : String Abbildung 2-8 PIM Beispiel 2.4.3 Platform Model Das Platform Model (PM) beschreibt die Spezifikation einer konkreten Plattform (J2EE,.Net), daher ist auch der synonyme Name Plattformdeskriptor oder Platform Description Model (PDM) 2 geläufig. Einfach ausgedrückt ist das PM ein Modell, welches zur Transformation als Quellartefakt neben dem PIM benötig wird, um ein plattformspezifisches Modell zu generieren. Die Abbildung 2-9, angelehnt an [PETRASCH und MEIMBERG 2006], illustriert die MDA Transformation mit PIM und PM als Quellartefakte und dem PSI als Zielartefakt. Nach [PETRASCH und MEIMBERG 2006] 1 dt.: plattformunabhängiges Modell 2 dt.: plattformbeschreibungs Modell

Grundlagen der MDA/MDSD 22 sollen für PM zur Beschreibung der Zielplattform eines Systems Metamodelle oder UML Profile eingesetzt werden. Abbildung 2-9 Schematische Darstellung einer MDA-Transformation 2.4.4 Platform Specific Model Die ideale Realisierung des MDA Ansatzes nach OMG ist ein Platform Specific Model (PSM) 1, ein aus einem PIM transformiertes Modell. Dieses Modell konkretisiert ein PIM mit weiteren Spezifikationen bezüglich einer bestimmten Plattform/Sprache wie etwa J2EE,.Net oder SQL. Die Abbildung 2-9 illustriert ein PSM, welches aus dem PIM (siehe Abbildung 2-10) transformiert wurde. Die Transformation eines Modells in ein anderes wird als Model-To-Model (M2M) Transformation bezeichnet und die Transformation aus einem Modell nach Code wird als Model-To-Code (M2C) oder Model- To-Text Transformation bezeichnet. Hierzu folgt im nächsten Abschnitt eine genaure Beschreibung. Abbildung 2-10 Beispiel PSM 1 dt.: plattformspezifisches Modell

Grundlagen der MDA/MDSD 23 2.4.5 Platform Specific Implementation Der generierte Code aus einem PIM oder PSM wird als Platform Specific Implementation 1 (PSI) bezeichnet, jedoch wird diese Bezeichnung in der MDA Literatur selten verwendet, gebräuchlicher ist die einfache Bezeichnung Code. Die Autoren von [PETRASCH und MEIMBERG 2006] verwenden diese Bezeichnung. Im Rahmen dieser Arbeit werden beide Bezeichnungen verwendet. Im idealen Falle, so schlägt es auch die OMG vor, wird eine PSI aus einem PSM und nicht direkt aus einem PIM generiert. Die Abbildung 2-11 stellt eine PSI dar, welche auf Basis des PSMs aus der Abbildung 2-10 generiert werden könnte. 1 2 3 4 5 6 create table Buch{ isbn VARCHAR(255), title VARCHAR(255), autor VARCHAR(255), primary key (isbn) } Abbildung 2-11 generiertes PSI (SQL) Das Ursprungsmodell (PIM, siehe Abbildung 2-8) kann ganz nach der MDA Paradigma dafür verwendet werden, um eine andere PSI zu generieren, wie Java oder C#. Die Abbildung 2-12 zeigt exemplarisch einen in Java generierten Code. 1 2 3 4 5 public class Buch { public String isbn; public String title; public String autor; } Abbildung 2-12 generiertes PSI (Java) 2.5 Transformation Die Überführung eines Modells, wie etwa PIM, in ein anderes Modell, wie PSM oder PSI, wird als Transformation bezeichnet. Auch die PSI wird als Modell gesehen, auch wenn es sich dabei um ein textuelles Artefakt handelt (vgl. [GRUHN et. al. 2006]). Softwaretechnisch betrachtet handelt es sich bei einen Transformator (auch Generator genannt) um ein Softwarestück, welches in der Lage ist, aus einem importierten Artefakt (Quellartefakt) durch Weiterverarbeitung ein Zielartefakt zu generiert. Bei dem 1 dt.: plattformspezifische Implementierung

Grundlagen der MDA/MDSD 24 generierten Artefakt kann es sich um ein Modell oder Code/Text handeln. Daher wird in [PETRASCH, MEIMBERG 2006] darauf aufmerksam gemacht, dass eine Transformation nicht identisch mit der Code-Generierung ist, da im Kontext der MDA zwischen Model- To-Model 1 (M2M) und Model-To-Code 1 (M2C) unterschieden wird. Bei M2C handelt es sich somit um Code-Generierung. In diesem Abschnitt werden Transformationsarten und Transformationstechnologien vorgestellt. 2.5.1 Transformationsarten Die Abbildung 2-13 stellt die Transformationsvarianten der MDA dar, welche auch als MDA-Pattern in [MDA 2003a] dokumentiert sind. Bei den Rechtecken handelt es sich um Modelle, welche durch Transformation im Bild als breite Pfeile dargestellt in ein anderes Modell überführt werden. Die mit etwas rundlichen Ecken dargestellten Rechtecke mit der Aufschrift Transformation Spezifikation sind Informationen, die der Generator für das Transformieren des Zielartefaktes benötigt (PM). Die MDA schreibt die Anzahl der Abstraktionsebenen nicht vor, daher ist es durchaus denkbar, eine Generierungsinfrastruktur nach dem MDA-Ansatz zu realisieren, die die Transformation nicht nur von PIM PSM PSI macht, sondern auch von PIM PSM PSM PSI. Modell M2M Transformation Specification Modell M2T Transformation Specification public class Student { public String getname(){ return "Reza"; } } Abbildung 2-13 Transformationsvarianten M2M und M2T 1 dt.: Modell-zu-Modell

Grundlagen der MDA/MDSD 25 2.5.2 Re-Enginering Zur Synchronisation von Modellen und Code im Kontext von MDSD wird zwischen drei Arten unterschieden: Forward-, Reverse- und Roundtrip-Engineering. Die einseitige Transformation von Modell zu Code wird als Forward-Engineering bezeichnet und umgekehrt wird somit die Transformation von Code nach Modell als Reverse- Engineering definiert. Als Roundtrip Engineering wird die Möglichkeit bezeichnet, dass nach einer Änderung im Code synchron dazu das Modell angepasst wird und ebenso nach einer Änderung im Modell synchron dazu der Code angepasst wird. Die Abbildung 2-14 illustriert alle drei möglichen Ansätze grafisch. Abbildung 2-14 Transformationsarten Die OMG beschreibt in [MDA 2003a] nur die einseitige Transformation (siehe Abbildung 2-8, MDA Muster). Die Rückgenerierung ist in der Praxis nicht trivial (vlg. [PETRASCH und MEIMBERG 2006], [GRUHN et. al. 2006]). Nach [PETRASCH und MEIMBERG 2006] ist Re-Engineering nur bei Zielartefakten mit manuellen Anteilen ein Problem, das gelöst werden muss. Da in der Praxis die 100%ige Code-Generierung selten ist und da die manuelle Ergänzung betätigt werden muss, besteht bei einem erneuten Generatorlauf das Problem der Überschreibung der manuell implementierten Teile. Zur diesem Problem gibt es zwei Lösungssätze, zum Einen einen Protected Regions 2 im Code, welche bei einer erneuten Generierung nicht überschrieben werden, zum Anderen besteht die Möglichkeit, den manuellen und generierten Code durch separate Dateien zu trennen. Die genannten Lösungskonzepte bezüglich des Re-Engineering 1 dt.: Modell-zu-Code eine allgemeiner Begriff für Code und anderen textuelle Artefakte ist die Bezeichnung Modellzu-Text (M2T) 2 dt.: Geschützte Bereiche

Grundlagen der MDA/MDSD 26 werden an dieser Stelle nicht weiter vertieft, jedoch wird auf die Literaturquellen ([PETRASCH und MEIMBERG 2006] und [GRUHN et. al. 2006]) hingewiesen, welche das Thema etwas ausführlicher behandeln. 2.5.3 Templatebasierte Transformation Bei Templates auch Boilderplates genannt [GRUHN et. al. 2006] handelt es sich um schablonenartige Text-Dokumente, welche aus zwei wesentlichen Teilen bestehen. Zum Einen aus einem Teil, der im Template Dokument fest geschrieben ist und im Zielartefakt ebenso bestehen bleibt, zum Anderen aus einem Teil, der eine Art Platzhalter darstellt. Diese Stellen werden bei einer Transformation durch Informationen ersetzt. Als Ausgangsartefakt dieser Transformation entsteht ein neues Dokument. Die Abbildung 2-15 zeigt solch ein Template-Dokument. Hierbei handelt es sich um ein Template-Engine xpand aus der Sprachfamilie der openarchitectureware (oaw) 1. Dabei kann die Trennung der Platzhalter («...») von dem fest geschriebenen Teilen erkannt werden. Mit Hilfe des Templates (siehe Abbildung 2-15) wird eine Java Klasse inklusive ihrer Getter und Setter-Methoden generiert. An dieser Stelle werden weder Syntax noch die Sprachelemente der xpand vorgestellt. Diese werden im Kapitel 4.3.5. genauer beschrieben. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 «IMPORT metamodel» «EXTENSION template::generatorextensions» «DEFINE main FOR Model» «EXPAND javaclass FOREACH entities()» «ENDDEFINE» «DEFINE javaclass FOR Entity» «FILE name+".java"» { /** * Diplomarbeit-Listing 2-1 * @author R.Noroozi **/ } «ENDFILE» «ENDDEFINE» public class «name» { «FOREACH features AS f» private «f.type.name» «f.name»; public void «f.setter()»(«f.type.name» «f.name») } this.«f.name» = «f.name»; public «f.type.name» «f.getter()»() { return «f.name»; } «ENDFOREACH» 1 oaw ist ein MDA/MDSD-Framework und wird in späteren Kapiteln genauer vorgestellt.

Grundlagen der MDA/MDSD 27 Abbildung 2-15 xpand der openarchitectureware Ein mögliches Zielartefakt, welches mit Hilfe des Templates aus Abbildung 2-16 generiert wurde, könnte so aussehen wie in Abbildung 2-17. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 /** * Diplomarbeit-Listing 2-1 * @author R.Noroozi **/ public class Person { } private String name; public void setname(string name) { this.name = name; } public String getname() { return name; } Abbildung 2-16 Ausgabeartefakt

3 Serviceorientierte Architektur Once you go SOA, everything becomes interoperable - Thomas Erl 1 Dieses Kapitel beschäftigt sich mit den Konzepten der serviceorientierten Architektur. Zunächst wird erörtert, was unter eine SOA zu verstehen ist und welche Rolle Geschäftsprozesse und Services in einer SOA einnehmen. Des Weiteren werden die Schichten einer SOA definiert. 3.1 Einführung Mit Serviceorientierung in Unternehmen wird das Ziel verfolgt, einzelne Anwendungskomponenten mit Schnittstellen zu versehen, die den Dienst sprach- und plattformneutral beschreiben. Dies hat den Vorteil, dass Services betriebsintern sowie bei Bedarf von Geschäftspartnern, somit betriebsübergreifend, verwendet werden können, ganz unabhängig, auf welcher Technologie bzw. Plattform ihr System basiert. So lassen sich durch Realisierung von Services aus Enterprise-Applikationen, die sich weder geografisch noch technisch gleichen, neue dienstorientierte Anwendungen bauen. Dem zu Folge kann es durchaus Fälle geben, bei denen sich einzelne Aktivitäten eines 1 [ERL 2005, S. 59]

Serviceorientierte Architektur 29 Geschäftsprozesses (siehe Abschnitt 2.3.1) aus Services von unterschiedlichen Betriebsanwendungen zusammensetzen. Ein passendes Beispiel 1 für eine SOA ist die Buchung einer Reise inklusive Unterkunft und Miete eines Autos. Hierbei handelt es sich um vier Firmen mit vier unterschiedlichen Anwendungen 2, die wiederum in unterschiedliche Programmiersprachen implementiert sein können oder auch auf unterschiedlichen Betriebssystemen laufen. Hier kann der Reisende trotzdem im Reisebüro die Buchung seines Fluges sowie die Bestellung eines Hotelzimmers vornehmen und gleichzeitig ein Auto mieten. Angelehnt an dieses Beispiel folgt eine Definition der SOA nach [HESS et. al. 2006]: "SOA ist ein Architekturmuster, das den Aufbau einer Anwendungslandschaft aus einzelnen fachlichen, das heißt geschäftsbezogenen Komponenten beschreibt. Diese sind lose gekoppelt, indem sie einander ihre Funktionalität in Form von Services anbieten [ ]" Der Begriff Anwendungslandschaft bezeichnet [HESS et. al. 2006] die Gesamtheit der IT-Anwendungen eines Betriebes mit ihren Vernetzungen und Schnittstellen. In [BIEN 2006] wird erklärt, dass die Idee der SOA nichts Neues, sondern eher das Bestreben einer perfekten Anwendungslandschaft ist, welche bei jedem Projekt angestrebt werden sollte. Dabei unterstreicht er die Fachlichkeit und nicht die Technologie. Das Reisebürobeispiel verdeutlicht ebenso, dass die Geschäftsprozesse der jeweiligen Firma im Vordergrund standen. Ein weiterer Bereich, in dem die Serviceorientierung ihren Einsatz findet, ist die Modernisierung von bestehenden Systemen (Legacy-Systeme) 3. So wird die Neuentwicklung dieser, welche mit Kosten verbunden ist, vermieden. Die Idee hierbei ist es, aus dem Legacy-System Services zur Verfügung zu stellen, die weiterhin in neuer Umgebung verwendet werden können. 3.2 Kernidee einer SOA 3.2.1 Geschäftsprozesse Ein Prozess, welcher dazu beiträgt, ein Unternehmensziel zu erreichen, wird als Geschäftsprozess bezeichnet. Sein Hauptziel ist Wertschöpfung aus wirtschaftlicher Sicht. Er ist in einzelne Aktivitäten zerlegt. Eine Aktivität wiederum kann aus einem oder mehreren Arbeitschritten bestehen. Ein GP hat einen definierten Anfang 1 [RAASCH 2006] 2 Die Anwendungen der beteiligten Unternehmen (Reisebüro, Autovermietung, Fluggesellschaft und Hotel) ist hier gemeint 3 dt.: Altsysteme (bestehende Applikationen)

Serviceorientierte Architektur 30 (Anfangszustand) und ein definiertes Ende (Endzustand). Er befindet sich im Verlauf der Ausführung immer in einem bestimmten Zustand. Ein Zustandswechsel kommt durch ein Ereignis zustande. Die Beendigung einer Aktivität führt zu einem Zustandswechsel. Ein Beispiel für einen Geschäftsprozess wäre die Buchungen einer Flugreise. Die Durchführung eines Geschäftsprozesses muss nicht an einem Stück passieren. In einem bestimmten Zustand kann der Prozess vorerst abgebrochen und später weitergeführt werden. In diesem Zustand kann es sein, dass bestimmte Ressourcen benötigt werden, um den Geschäftsprozess weiterzuführen bzw. abzuschließen. Bei einer Kreditvergabe, wird zum Beispiel immer geprüft, ob der Kunde keinen Schufaeintrag hat. Solange noch keine Antwort da ist, wird der Prozess nicht fortgesetzt. Dieses Beispiel verdeutlicht darüber hinaus, dass es in einem Prozess Unterprozesse geben kann. Bei dem Geschäftsprozess Kreditantrag, wäre z.b. deieschufaprüfung ein Unterprozess. Natürlich kann ein Unterprozess in einem anderen Kontext als eigenständiger Prozess dienen. In einer SOA haben Geschäftsprozesse einen hohen Stellenwert. Die Kombination aus Services kann zu einen Geschäftsprozess führen, wie bei dem Beispiel: Flug- und Hotelzimmerbuchung in ein Reisebüro. Diese Services lassen sich unterschiedlich kombinieren. Im Kontext von SOA wird hier von Orchestrierung gesprochen, welche im Abschnitt 3.2.2 genauer vorgestellt wird. 3.2.2 Drei Rollen einer SOA Die SOA basiert auf der Interaktion zwischen drei Rollen, Service Provider 1, Service Consumer 2 und Service Broker 3. Der Service Provider ist für die Implementierung und Veröffentlichung der Services verantwortlich, ganz unabhängig, ob es sich um Java- Routine oder eine andere Programmiersprache handelt. Wichtig ist hierbei, dass der Dienst eine klar definierte Schnittstelle hat. Darüber hinaus sollte der Dienst im Netz eine eigene eindeutige Adresse besitzen, um vom Außen zugreifbar zu sein. Ein Service Nutzer kann einen bestehenden Service verwenden. Wenn ihm die benötigen Informationen (Schnittstelle und Adresse) bekannt sind, kann er den Dienst direkt nutzen, ist dies nicht der Fall, so muss es über den Service Broker geschehen. Sobald die Informationen vom Broker angekommen sind, kann der Service Nutzer durch einen Request den Nutzungsprozess fortsetzen. Bei einem Service Broker handelt es sich um einen Vermittler zwischen dem Service Anbieter und Nutzer. Er hat zwei Aufgaben, 1 dt.: Service Anbieter 2 dt.: Service Nutzer 3 dt.: Service Vermittler

Serviceorientierte Architektur 31 zum Einen Services, die von Service Provider publiziert werden, entgegenzunehmen und in einen Repository abzulegen, zum Anderen über Suchfunktionen Service Nutzern die Möglichkeit zu geben, ihre gewünschten Services zu finden. Die Nutzung eines Service Brokers ist nur dann wichtig, wenn sich die anderen zwei Rollen nicht kennen. Daher ist ein Service Broker nicht unbedingt notwendig. Die Abbildung 3-1 illustriert die Kommunikation zwischen den einzelnen Webservice Rollen. Dieses Paradigma wird als find, bind and execute bezeichnet [WANG et. al. 2004]. Find Publish Abbildung 3-1 Die drei Rollen der Webservices Das Ziel einer SOA ist es, Services bereit zu stellen, welche von vielen Interessenten benutzt werden können, ganz unabhängig, welche Technologie dahinter steckt. Somit spielt die Interoperabiliät bei einer SOA eine wichtige Rolle. Um diese zu gewährleisten, sind bestimmte Voraussetzungen, wie beispielsweise Standardisierung, zu erfüllen. Diese Voraussetzungen werden im nächsten Abschnitt beschrieben. 3.3 SOA Schichten In diesem Abschnitt werden die Schichten eines SOA-Modells beschrieben. Die Abbildung 3-2 illustriert die SOA Schichten. Hierbei handelt sich um eine verteilte IT- Anwendunglandschaft, welche durch bestimmte Technologien und Standardisierung ihre Dienste in einem heterogenen Umfeld zur Verfügung stellt, ganz im Sinne einer SOA. Die unterste Ebene stellt Hardware, Systeme und Netzwerk dar, auf denen sich die Anwendungen befinden. Die zweite Ebene von unten, als Applications gekennzeichnet, illustrieren die Anwendungen, welche sich an unterschiedlichen Orten

Serviceorientierte Architektur 32 befinden können und auf unterschiedlichen Plattformen (J2EE/.Net) basieren können. In der Service Ebene befinden sich die Services und alles was zu deren Verwaltung benötig wird. Die Orchestrierungsschicht stellt das Zusammenspiel der Services dar, die oberste Ebene schließlich die Präsentationsschicht. Abbildung 3-2 Die Bestandteile des SOA-Modells nach [LIEBHART 2007] In Folge werden die einzelnen Sichten der SOA beschrieben. Die Beschreibungen sind zum Teil an [LIEBHART 2007] angelehnt. Der Autor beschreibt die einzelnen Schichten einer SOA und stellt einige Open-Source Produkte vor mit dessen Hilfe die einzelnen SOA Schichten realisiert werden können. 3.3.1 Präsentationsschicht Die Benutzerschnittstellen einer Anwendung auf Basis von SOA unterscheiden sich nicht von einer gewöhnlichen Applikation. Dabei kann es sich um Client Applikationen (webbasierte und Rich Client) oder Office Applikationen handeln. Jedoch sehen die SOA Blueprints der meisten Hersteller Portlets als User Interface vor [LIEBHART 2007]. Hierzu gibt es den Standard Web Service for Remote Portlets (WSRP). WSRP erweitert den WSDL, um den Service mit Hilfe von Portels darstellen zu können.

Serviceorientierte Architektur 33 3.3.2 Orchestrierungsschicht Als Orchestrierung wird die Kombination einzelner Services bezeichnet, die zusammen die Geschäftsprozesse darstellen. So kann beispielsweise ein orchestrierter Geschäftsprozess aus mehreren Services bestehen und selber als ein Service verwendet werden. Bei der Realisierung einer Orchestrierungsschicht spielt die Modellierung eine wichtige Rolle, hier wird der Prozess mit Hilfe eines Ablaufdiagrames modelliert. Für die Modellierung gibt es spezielle Standards wie Business Process Execution Langauage (BPEL) und entsprechende Werkzeuge. So lassen sich beispielsweise mit Hilfe eines BPEL Tools Geschäftsprozesse modellieren und als BPEL-Datei ablegen. Diese kann dann in eine BPEL Engie geladen und ausgeführt werden [LIEBHART 2007]. Auf diese Weise lassen sich aus modellierten Prozessen Workflows generieren, die dann auf jeder BPEL-fähigen Workflow-Engine ausführbar sind. In [LIEBHART 2007] ist dokumentiert, dass bei einer SOA ausführbare Prozesse (Workflows) und ausführbare Geschäftsregeln neben den standardisierten Services die wichtigste Grundlage bilden. 3.3.3 Serviceschicht Bereits in den vorigen Abschnitten wurde erwähnt, dass die Kernidee einer SOA die Bereitstellung von Services ist und dass diese die Fachlichkeit unterstreichen und plattformneutral sein sollen. Die Idee dabei ist, Dienste einer Anwendung bzw. von Anwendungskomponenten durch standardisierte Schnittstellenbeschreibung, wie etwa WSDL, für Webservices zu publizieren. Die eigentliche Implementierung bleibt somit nach Außen verborgen und ist nur über diese Schnittstellebeschreibung, welche sprachneutral dargestellt ist, ansprechbar. Dieses Paradigma ist in der Informatik bereits ohne SOA unter dem Begriff Information-Hiding verbreitet, wobei dabei nicht die Sprachneutralität im Vordergrund stand, sondern die saubere Art und Weise modulare Anwendungen zu entwickeln. Die Serviceschicht beinhaltet neben den Serviceschnittstellen noch die Specialized Services 1. 3.3.4 Integration Architecture-Schicht Bei dieser Ebene handelt es sich um eine Integrationsinfrastruktur zu Verknüpfung von Diensten, die von Anwendungen zur Verfügung gestellt werden. 1 dt.: spzeialisierte Dienste/Services: Die Specialized Services sind im Kontext dieser Arbeit nicht relevant, daher werden diese nicht behandelt, allerdings kann an diese Stelle auf die Literaturquellen [LIEBHART 2007, S. 101-120 ] hingewiesen werden.