MODELLBASIERTE

REPOSITORY-INTEGRATION:

PRAXISBERICHT DER

DEUTSCHEN TELEKOM

Management) verwaltet, wo Services undApplikationen auf einem abstrakterenLevel als in CEISeR fachlogisch betrachtetwerden. Zusätzlich zu den Informationenaus CEISeR werden beispielsweiseInformationsflüsse zwischen denApplikationen erfasst. Mit den Daten ausCEISeR wird die Konfiguration für dieLaufzeitkomponenten der SOABP generiert(vgl. [Sen08]). Die Daten in Centrasite nut-zen die Enterprise-Architekten für Gover -nance-Themen, wie z. B. das Service-Port -folio-Management. Um eine Verlin kungzwischen der abstrakten Betrachtung ausdem EAM und der Laufzeit-Perspektivevon CEISeR abbilden zu können, werdenMechanismen für die Integration der ver-schiedenen Repositorys benötigt. DieAnforderung besteht darin, strukturierteund stark vernetzte Informationen zu inte-grieren. Diese Informationen steuern unter-schiedliche Quellen unabhängig voneinan-der zu unterschiedlichen Zeiten bei. Ziel istes, zu einem konsistenten Gesamtzustandzu gelangen. Da in großen Organisationenwie der Deutschen Telekom eine heteroge-ne Werkzeug- und Prozess-Landschaftsowie unterschiedliche Verantwortlich -keiten für bestimmte Daten existieren, istweder ein gemeinsamer Modellierungs -editor noch ein gemeinsames Repository

Bei einer „Service Oriented Architecture” (SOA) werden Informationen rund um Services undAnwendungen auf unterschiedlichen Abstraktionsebenen erfasst. Für die Verwaltung derInformationen werden heterogene Repository-Produkte verschiedener Hersteller verwendet.Um diese verteilten Informationen zueinander in Relation setzen und sie synchronisieren zukönnen, benötigt man eine Repository-Integration. Dieser Artikel beschreibt eine Modell-Repository-Integrationsarchitektur der T-Mobile (jetzt Deutsche Telekom), die im Rahmen einergroßen SOA-Infrastruktur entwickelt wurde.

30 31

■ Qualitätsmanagement und Governancevon Modellen

■ Modelltransformation und Konsistenz -prüfung

■ Management großer Modelle

In diesem Artikel erläutern wir nicht dieeinzelnen aufgezählten Punkte (vgl. hierzu[Sen09], [Kim09]), sondern die darüberhinausgehenden Techniken für die Inte -gration heterogener Repository-Produkteauf der Basis von Modellen und derenMeta modellen mit den in CEISeR entwi -ckelten Basis-Technologien.

Anforderung an das MRIFDem Thema „Repository-Integration” mes-sen viele Unternehmen eine hohe Bedeutungzu, weil Metamodelle und die dazugehörigenModelle an unterschiedlichen Stellen verwal-tet werden. Ähnliche Daten, wie wir sie inCEISeR verwalten, werden unter anderenVerantwort lichkeiten und anderenGesichtspunkten mit anderen für diesenZweck geeigneten Repositorys gepflegt.Beispiele für solche Repository-Produkte sind„ARIS” (vgl. [IDS]), „planningIT” (vgl. [Alf])und „Centrasite” (vgl. [Sof]).

Das ARIS-Repository bietet eine Sichtauf die fachlichen Prozesse und die verwen-deten Daten, in deren Kontext Servicesgenutzt werden. Bei der Deutschen Tele -kom wird das planningIT-Repositorygenutzt, um konzernweit Informationender IT-Applikationen zu verwalten. InCentrasite hingegen wird zum Beispiel einEAM-Modell (Enterprise Architecture

Ohne eine einheitliche Repository-Inte -grationsarchitektur wird man schnell mit deraus der Enterprise Application Integration(EAI) bekannten n*m-Problematik beiPunkt-zu-Punkt-Verbin dungen konfrontiert.Durch die Verwendung einer einheitlichenwerkzeuggestützten Architektur wird verhin-dert, dass grundlegende Mechanismen fürjedes Integrationsprojekt redundant entwi -ckelt werden.

Das Modell-Repository-Integrations-FrameworkIm Rahmen der Entwicklung der interna-tionalen SOA-Infrastruktur SOA Back -plane (SOABP) entstand das SOA-Modell-Repository CEISeR (Central EnterpriseIntegration Service Repository). DiesesModell-Repository ist in der Lage, großeMengen von historisierten Daten transak-tional zu verwalten und zu integrieren.

Den von der Anwendungsdomäne unab-hängigen Teil des Modell-Repositorysbezeichnen wir im Folgenden als ModellRepository Integrations Framework(MRIF). Dieses Framework dient alsPlattform für die aus UML2-Klassen -modellen generierten Domänenklassen.Eine Anwendungsdomäne des MRIF istCEISeR, das seit über vier Jahren erfolg-reich historisierte Modelldaten in Formvon über 1.400 Service-Definitionen undüber 2.500 Kommunikationsbeziehungenverwaltet. Mit CEISeR wurden folgendeThemen bereits erfolgreich in der Praxisumsetzt:

schwerpunk t

Marcus Greuel

(E-Mail: Marcus.Greuel@external.telekom.de)

ist freiberuflicher Softwarearchitekt. In den letzten

fünf Jahren hat er die Architektur und Realisierung

der Repository-Integration innerhalb der

Deutschen Telekom maßgeblich vorangetrieben.

Frank Kimmlingen

(E-Mail: Frank.Kimmlingen@telekom.de)

ist Softwareentwickler, Architekt und Projektleiter

im Framework- und Enterprise-Integration-Umfeld

und bringt seit etwa 2003 die modellgetriebene

Softwareentwicklung in verschiedenen SOA-

Umgebungen der T-Mobile voran.

d i e au toren

6/2010

durchsetzbar und sinnvoll. Um dieseAnforderungen zu erfüllen, wurde imRahmen der SOABP für CEISeR ein MRIFentwickelt.

Grundlagen der modellbasier-ten Repository-IntegrationBei der Entwicklung von CEISeR haben wirWert darauf gelegt, möglichst viele Anteiledes Modell-Repositorys aus dem auf UMLbasierenden CEISeR-Metamodell generie-ren zu können. Basierend auf Erfahrungen,die wir in der Vorgänger-SOA-Infra struk -tur von SOABP gemacht haben, wurde dieUML jedoch nicht als Basis eines einheit-lichen Modellierungs werkzeugs ge wählt.

XML-Dateien als Schnittstellefür den DatenaustauschUm Daten in das Modell-Repositoryimportieren oder exportieren zu können,werden XML-Dateien gelesen bzw.geschrieben. Das Format der verschiedenenXML-Dateien wird durch XML-Schema-Dateien beschrieben, die aus dem sogenannten Exchange-Metamodell generiertwerden (siehe Abbildung 1). Diese XML-Dateien beschreiben in einer menschenles-baren Form Modelle, die dem Exchange-Metamodell entsprechen. Um dieLesbarkeit zu gewährleisten, werden IDsund Referenzen von Objekten in einer anProgrammiersprachen wie Java angelehn-ten Form abgebildet.

Java und Subversion als VorbildEinige fundamentale Designentscheidungendes MRIF haben wir den Konzepten derverteilten Softwareentwicklung mit Javaund dem Versionsverwaltungssystem Sub -version entnommen.

Programmiersprachen wie Java implemen-tieren wohl verstandene Mechanismen zumIntegrieren von verteilten, stark vernetztenInformationen zu einem konsistenten

Gesamtbild. Im MRIF werden symbolischeVerknüpfungen anstelle von tech nischenUniversally Unique Identifier (UUIDs) ver-wendet. Durch die Ver wendung von symbo-lischen Verknüp fungen ist die Lesbarkeit derXML-Dateien gegeben. Die Darstellung derVerknüp fungen ist unabhängig von konkre-ten Modellierungswerkzeugen.

Das Konzept der Namespaces wird zurBildung von verteilten Namensräumen undzu Entkoppelung der Vergabe der symboli-schen Namen verwendet. IDs und Re -ferenzen sind zusammengesetzt aus demNamensraum und dem Namen des Objektsund werden Fully Qualified Name (FQN)genannt (siehe Kasten 1). Basierend aufdem Namensraum-Konzept können Be -rechtigungen rekursiv vergeben werden.Auf dem Root-Namens raum darf initialnur der Superuser schreiben. Ein Benutzer,der auf einem Namensraum Schreibrechtebesitzt, darf rekursiv in allen Unter namens -räumen schreiben und an andere BenutzernSchreib rechte vergeben.

Bei der Softwareentwicklung mit Java kön-nen einzelne .java-Dateien unabhängig von-einander von unterschiedlichen Entwicklerngeschrieben werden. Die Referenzen der ver-schiedenen Java-Klassen in den Dateien wer-den über symbolische Verknüpfungen (import[namespace].[Klassenname];) aufgelöst. Erst derCompiler löst die import-Befehle in den .java-Dateien auf und liefert bei fehlenden .java-Dateien entsprechende Fehlermeldungen. ImMRIF erfolgt die Überprüfung der Konsistenz

schwerpunk t

Abb. 1: Die Repository-Architektur.

■ Die Aufwände für die Trennung zwischen internem und externem Datenformat lohnensich und sind vom Aufwand akzeptabel.

■ Modelladapter auf der Basis einer einheitlichen Modell- und Meta modell-Fassade sindder Ausweg aus der n*m-EAI-Problematik bezogen auf Modell-Repositorys.

■ Eine einheitliche Modell- und Meta modell-Fassade ermöglicht die Wiederverwendungvon mächtigen generischen Werkzeugen.

■ Die Modellfragmente (Kompositions beziehung) als kleinste Granularität für denDatenaustausch und die Persistenz haben sich als querschnittliches Konzept bewährt.

■ Der flexible MDSD-Ansatz macht den modellbasierten Ansatz für die Repo sitory-Integration erst praktikabel.

■ Der Einsatz von IDs und Referenzen auf Basis von symbolischen Links hat sich bisherals guter Ansatz erwiesen. In weiterführenden Integrations szenarien muss dieDefinition der ID flexibler gestaltet werden, um z. B. UUIDs von anderen Repositorysbesser zuordnen zu können.

■ Im Umfeld von MDSD und der modellbasierten Entwicklung setzen sich EMF (vgl. [Ste09]) und darauf aufbauende Frameworks als eine Art Industriestandarddurch. Da das GMF nicht direkt kompatibel zu EMF ist, gibt es immer wieder kon-troverse Diskussionen. Um in Zukunft einfacher mit auf EMF basierenden Modellenumgehen zu können, gibt es im MRIF die Um setzung eines EMF-Modell adapters, derin der Lage ist, EMF-Ressourcen zu verarbeiten.

Kasten 1: Erfahrungen mit und Konsequenzen aus der Lösung.

entscheidung ist die Aufteilung der Modellein Modellfragmente, die unteilbare Teil -bäume des Modells sind. Ein Modell -fragment ist die kleinste Granu larität für denDatenaustausch und für die Persistenz. DasKonzept entspricht der Komposi tionsasso -ziation in UML2 zwischen Klassen.

Metamodellbasierte generischeModellfassade für alle beteiligten ModelleUm die modellbasierten Informationen ein-heitlich verwalten zu können, wurde dasGeneric Modeling Framework (GMF) ent-wickelt (siehe Abbildung 2). Die Kon zeptedes GMF sind mit den EMF-Konzepten(vgl. [Ste09]) vergleichbar. Mit GMF istnicht das gleich abgekürzte „EclipseGraphical Modeling Framework” gemeint,sondern die im Rahmen von SOABP ent-wickelte Framework-Lösung.

Durch GMF wird eine einheitliche gene-rische Modell- und Metamodell-Fassadebe reit gestellt (siehe Kasten 1). Die Fassadeenthält:

■ eine einheitliche CRUD-Schnittstelle(Create Read Update Delete) fürModellobjekte

■ eine einheitliche Schnittstelle für dieNavigation durch die Elemente derModelle und die Elemente der dazuge-hörigen Metamodelle

32 33

zwischen dem externen und dem internenDatenformat (siehe Abbildung 1). Durch die-se Trennung ist es möglich, die externeSchnittstelle über mehrere Releases stabil zuhalten. Das externe Format (ExchangeModel) ist hinsichtlich des Austauschs undder Kompatibilität optimiert, wohingegen dasinterne Format (Core Model) Perfor manceund andere technische Aspekte berücksich-tigt. Im MRIF werden aus Metamodellen diedomänenspezifischen Klas sen generiert (hell-blaue Bereiche in Abbil dung 1). Neben denKlassen werden für das Exchange ModellXML Schema (XSD) Dateien generiert, diedie Strukturen der XML-Dateien für denDatenaustausch definieren (siehe Kasten 1).

Metamodell- und modellbasiertInnerhalb des MRIF werden alle Infor -mationen als Modelle mit entsprechendenMetamodellen behandelt. Neben den XSD-Dateien werden ebenfalls alle Modell -implementierungen generiert (ExchangeModel und Core Model). Für die Ge -nerierung wird das openArchi tectureWareFramework (OAW), ein MDSD-Generator-Framework (vgl. [Sta07]), verwendet.Insbesondere sind die transaktionalen undhistorisierten Repositorys spezielle Modell -implementierungen und werden somit eben-falls automatisch aus dem Metamodellerstellt. Eine weitere wichtige Design -

schwerpunk t

Abb. 2: Das Generic Modeling Framework (GMF).

ebenfalls unabhängig vom Zeitpunkt desErfassens. Erst wenn alle Beteiligten ihreInformationen eines Anwendungsfalls beige-steuert haben, muss ein für diesenAnwendungsfall konsistentes Gesamtbildvorhanden sein. Insbesondere das Auflösender symbolischen Verknüpfungen ist erstdann fehlerfrei, wenn alle ihre Informationenbeigesteuert haben. Fehlermeldungen werdenerzeugt, wenn nicht alle Informationen vor-handen sind (vgl. [Kim09]).

Versionsverwaltungssysteme wie Subver -sion bringen Konzepte wie Transaktionen,Historisierung und Branching mit. Übertra-gen auf Modelle bedeutet das, dass Ände-rungen über das MRIF über die Vergabevon Transaktionsnummern erfolgen. UmKonflikte bei konkurrierenden Änderungenerkennen zu können, wurde auf der Basisder Transaktionsnummer ein optimisti-sches Lock-Verfahren implementiert. Ände-rungen, die über das MRIF gemacht wer-den, sind nachvollziehbar, und es istmöglich, auf historische Stände vonModellen zuzugreifen. Differenzen zwi-schen einzelnen Transaktionen können aufObjektebene ausgewertet werden.

Trennung von externem undinternem DatenformatEine Designentscheidung, die bei CEISeRfrüh getroffen wurde, ist die Unter scheidung

6/2010

■ eine einheitliche Transaktions schnitt -stelle

Werkzeuge, die auf der GMF-Modellfassade basierenAuf den Schnittstellen von GMF gibt es eini-ge Werkzeuge, die für die Repository-Integration verwendet werden (sieheAbbildung 1). Für die XML-Dateien desDatenaustauschs existieren Serialisierer undDeserialisierer (Model Reader, ModelWriter), die das XSD-Format des Ex change-Modells verarbeiten können. Die Unter -stützung anderer Formate, zum Beispiel eineImplementierung für Res sourcen des EMF(vgl. [Ste09]), sind denkbar. ModelSynchronizer sind für die Synchronisierungzwischen Modellteilen verantwortlich. EinModell-Transfor ma tions-Framework bildetdie Grundlage zur Erstellung Java-basierter,typsicherer Mo dell-zu-Modell-Transforma -tionen (Model Transformator). WeitereWerkzeuge (nicht in Abbildung 1 dargestellt)erledigen die Validation von Modellteilen(Model Vali dator) und einen Zwei- undDreiwege-Vergleich, dessen Ergebnis wiederein Modell ist (Model Diff).

Repository-ServerNach der Beschreibung der Grundlagen dermodellbasierten Repository-Integration

gehen wir auf darauf aufbauende Server-Komponenten des Repository-Servers ein.(siehe Abbildung 1).

Prozessmodell zur Programmierungdes ServersDas Prozessmodell dient der Program -mierung des Repository-Servers. DerAnwender des Repository-Servers konfigu-riert ein Prozessmodell durch so genannteManifest-XML-Konfigurationsdateien.Durch das Prozessmodell wird die transak-tionsgesteuerte Programmierschnittstelle desServers gebildet (siehe auch Abbildung 3):

■ Ein Prozess fasst eine Menge vonTransaktionen und deren Abhängig -keiten untereinander zusammen.

■ Transaktionen definieren das Modell,den Branch und den Zustand, aufdenen die eingebetteten Tasks arbeiten,und bilden die Klammer für diePersistierung der Änderungen durchdiese Tasks.

■ ModelLocators definieren Teilmengeneines Modells anhand der Datentypen,Daten oder zeitlicher Aspekte.

■ Tasks sind die Funktionsbausteine undkönnen ModelLocator verwenden, umdie Elemente zu identifizieren, aufdenen sie arbeiten. Beispiele für Tasks

sind „Exportiere Elemente in XML”,„Synchronisiere XML-Informationenin Repository” oder „Versorge SOABPmit Service-Konfiguration”.

Job-FrameworkEin Prozess wird vom Job-Framework aus-geführt (siehe Abbildung 4). Durch die Job-Semantik wird die Asynchronität bereitgestellt, die notwendig ist, da die Ausfüh rungder Prozesse oft mehrere Minuten dauernkann. Die Eingabe für die Aus führung einesProzesses besteht aus der Prozessbeschrei -bung (Manifest-XML-Datei) und einerMenge von Eingabe dateien, die prozessiertwerden sollen. Die Ausgabe besteht aus demAusführungs protokoll-Modell und einerMenge von Ausgabe- und Log-Dateien. Jobskönnen sowohl manuell als auch zeitgesteu-ert über den Repository-Web-Service und dasCommand Line Interface (CLI) eingestelltwerden.

Web-Service-InterfaceDer Repository-Server bietet einen generi-schen Web-Service für das Job-Framework an.Dieser bietet Services an, um einen Job ein -zustellen und dessen Status zu erfragen. Wennder Jobstatus-Service als Antwort „e r ledigt”zurückliefert, kann über einen weiterenService das Job-Ergebnis abgeholt werden.

schwerpunk t

Abb. 3: Das Prozessmodell.

ge Repositorys werden zu Test- undEntwicklungszwecken unterstützt. Verteil -tes Arbeiten wird ermöglicht, indemTeamfunktionalität für das Arbeiten mitdem Repository-Server angeboten wird.Die Teamfunktionalität besteht aus demCheckout und Commit von Modell -fragmenten über die ModelLocator, einemDreiwege-Diff auf den editierten Modell -fragmenten und einer Merge-Funktionalitätfür Modellfragmente.

Anbindung von externen Repositorysüber ModelladapterBeliebige externe Repositorys könnendurch das MRIF integriert werden, indemauf der Basis der jeweiligen Program -mierschnittstelle des Herstellers einModell adapter implementiert wird (sieheKasten 1).

Bei der Anbindung des auf CentraSitebasierenden Repositorys für das EAM-Modell wurde z. B. ein JAXR-Modell -

34 35

Shortcut „<Strg>+<Space>” möglich.Durch Modell-Validierung wird das Edi -tieren vor dem eigentlichen Abspeichern imRepository-Server abgesichert. Das gleich-zeitige Verbinden zu mehreren Repository-Servern über das Webservice-Job-Interfaceermöglicht die Integration verschiedenerRepositorys, basierend auf Benutzungs -schnittstellen. Lokale, voll funktionstüchti-

Klienten des Repository-ServersWir beschreiben nun die unterschiedlichenZugangswege der Klienten zu den Datenauf dem Repository-Server.

Dynamischer HTML-ReportDer einfachste Zugang zu den Daten desRepository-Servers erfolgt über eine HTML-Seite. Die HTML-Seite bietet eine einfacheNavigation und Ansicht des Repository-Modells. Über diesen Zugang könnensowohl der letzte Stand als auch beliebigehistorische Stände über die jeweiligeTransaktionsnummer betrachtet werden.Die HTML-Seite ist ein rein lesender dyna-mischer Report, der durch Java Server Pages(JSP) – basierend auf dem Meta modell desRepositorys, verwoben mit einem UI-Modell– generiert wird (siehe Abbildung 1).

Ein auf Eclipse basierender Rich ClientDer Hauptzugang zu den Daten und denProzessmodellen des Repository-Servers istder auf Eclipse RCP (vgl. [Ecl-a]) basieren-de „Xplor” (siehe Abbildung 1). Die ein-heitliche Schnittstelle, auf der dieser arbei-tet, ist die Modellfassade GMF. ZurLaufzeit interpretiert Xplor dasMetamodell und metamodellspezifischeKonfigurationsmodelle. Er bietet Bau m -ansichten von beliebigen Modellen.Querschnittliche Ansichten der Modellewerden über Suchen ermöglicht. Sowohldie Baumansichten als auch die Suchen sindfür jedes Metamodell spezifisch über dieKonfigurationsmodelle einstellbar.

Neben dem Browsen von Modellen istmit Xplor auch das Editieren von Modellenmöglich. In Editoren werden Vorschlags -listen für sinnvolle Werte („ContentAssists”) für das Befüllen von Referenzenzwischen Modellelementen angeboten.Dies ist – wie in der Eclipse-Java-Ent -wicklungsumgebung – über den Tastatur-

schwerpunk t

Abb. 5: Die externe Repository-Erweiterungsarchitektur.

Abb. 4: Das Job-Framework.

6/2010

adapter entwickelt (siehe Abbildung 5rechts unten). Die Datenstruktur des exter-nen Repositorys wird als Metamodellmodelliert. Im Falle von CentraSite ist dasMetamodell das JAXR-Information-Modell, erweitert um die benutzerdefinier-ten RegistryObjects für das EAM. DerModelladapter implementiert die GMF-Modellfassade, wodurch sämtliche aufGMF basierenden Werkzeuge wie gewohnteingesetzt werden können. Im Zusam -menspiel mit der standardmäßigen transak-tionalen- und historisierten datenbank-basierten Modellimplementierung kannsomit ein externes Repository um dieseFähigkeiten erweitert werden. Zusätzlichkann dem externen Repository durch denModelladapter weitere Funktionalität, z. B.Unterstützung von Vererbung und Modell -fragmenten, hinzugefügt werden. DerZugang zu den Daten eines Repository-Produkts wie Centrasite erfolgt über diedort vorhandene Web-Browser-Schnitt -stelle (siehe Abbildung 5 rechts oben).

Repository-IntegrationsszenarienIm Folgenden skizzieren wir einigeSynchronisationsszenarien, die bei der

Deutschen Telekom auf Basis des Frame -works umgesetzt wurden.

Synchronisation externerDatenquellen in einem RepositoryDieses Szenario wurde bei CEISeR realisiert(siehe Abbildung 1). Innerhalb des Repo -sitory-Servers gibt es eine Trennung zwischenExchange Model und Core Model. DerDatenaustausch basiert auf XML-Dateien.Folgende Schritte werden bei der Synchro -nisation automatisiert durchgeführt:

■ Einlesen der Exchange-XML-Dateienin Exchange-Modelle mit dem Ex -change-Metamodell.

■ Transformation der Exchange-Modellein ein temporäres Core-Modell mit demCore-Metamodell über einen speziellerstellten Modell-Transformator, basie-rend auf dem Modell-Transformations-Framework.

■ Auswahl der gewünschten Elemente ausdem temporären Modell mit dem Core-Metamodell über einen Model Locator.

■ Synchronisation der ausgewählten Ele -mente aus dem temporären Modell mitdem Core-Modell über den ModelSynchronizer.

Synchronisation zweier Repositorys mitdemselben MetamodellWie bereits erwähnt, wurde dieses Szenariobei der Anbindung des auf CentraSitebasierenden Repositorys für das EAM-Modell gewählt (siehe Abbildung 5).Folgende Schritte werden bei der Syn -chronisation automatisiert durchgeführt:■ Auswahl der gewünschten Elemente

aus dem Quell-Repository-Modell übereinen ModelLocator.

■ Synchronisation der ausgewähltenElemente mit dem Ziel-Repository-Modell über den Model Synchronizer.

Synchronisation zweier Repositorys mitunterschiedlichem MetamodellDieses Szenario wurde ebenfalls bei derAnbindung des auf CentraSite basierendenRepositorys für das EAM-Modell umge-setzt, um Daten zwischen CEISeR und demEAM-Modell zu synchronisieren (sieheAbbildung 6). Folgende Schritte werden beider Synchronisation automatisiert durchge-führt:

■ Auswahl der gewünschten Elementeaus dem Quell-Repository-Modell übereinen ModelLocator.

■ Transformation der ausgewähltenElemente des Quell-Repository-Mo -dells in ein temporäres Modell mit demMetamodell des Ziel-Repositorys übereinen speziell erstellten Modell-Trans -formator, basierend auf dem Modell-Transformations-Framework.

■ Synchronisation der ausgewähltenElemente aus dem temporären Modellmit dem Ziel-Repository-Modell überden Model Synchronizer.

UI-Integration via XplorDa Xplor auf der GMF-Modellfassade ope-riert und Zugriff auf mehrere Repo sitory-Server hat, ist dieser in der Lage, Ver -knüpfungen von Modellelementen derver schiedenen Modelle und Navigations -mög lichkeiten zwischen diesen anzubieten(z. B. CEISER<->EAM, EAM<->Plan -ningIT). Durch diese Eigenschaften kannder Xplor eine Verwebung der verschiede-nen Modelle zu einem neuen Gesamt -modell auf Benut zungsschnittstellen-Ebenedarstellen. Zusätz lich ist eine Anreicherungvon Modell el e menten um Informationen,die aus anderen Modellen kommen, mög-lich. Dem Benutzer gegenüber erscheint dieDarstellung als ein großes virtuelles

schwerpunk t

Abb. 6: Die Repository-Integrationsarchitektur.

36 37

Modell, in dem er durchgängig durch dieeinzelnen Aspekte browsen kann.

FazitDie fachliche und technische Integrationvon Daten zwischen heterogenen Repo -sitory-Produkten unterschiedlicher Her -steller wird durch ein Modell-Repository-Integrations-Framework ermöglicht. Einsolches Framework stellt sicher, dass dieIntegration einheitlich und konsistenterfolgt, ohne grundlegende Mechanismenfür jedes Integrationsprojekt redundant zuentwickeln. Das Framework muss in derLage sein, grundlegende Aufgaben – wieModell-Synchronisation, -Transformation,-Lesen und -Schreiben – automatisiertdurchzuführen. Die Kernidee bei dem hiervorgestellten modellbasierten Ansatz ist,dass Repositorys über Modelladapter, diealle ein und dieselbe generische Modell -fassade implementieren, angesprochen wer-den. Hierdurch wird die aus der EAIbekannte n*m-Problematik vermieden. AufBasis der Modellfassade können generischeWerkzeuge und ein Repository-Serverimplementiert werden. Die Werkzeuge undder Repository-Server erledigen die grund-legenden Aufgaben der Integration.Zusätzlich kann weitere Funktionalität,wie eine Graph-Ansicht und Teamfunk -tionalität, implementiert werden. ■

schwerpunk t

Literatur & Links

[Alf] Alfabet Homepage, siehe: www.alfabet.de

[Ecl-a] Eclipse, Rich Client Platform, siehe:

http://wiki.eclipse.org/index.php/Rich_Client_Platform

[Ecl-b] Eclipse, Zest: The Eclipse Visualization

Toolkit, siehe: http://www.eclipse.org/gef/zest/

[IDS] IDS Scheer AG Homepage, siehe:

www.ids-scheer.de

[Kim09] F. Kimmlingen, Konsistenz im SOA

Modellrepository bei T-Mobile, in: Java -

SPEKTRUM 06/2009

[Sen08] C. Sensler, A. Karalus, SOA@T-

Mobile – Vollautomatische Service Provisio -

ierung auf dem ESB – Teil 1-3, in: Java

Magazin, 10/2008–12/2008

[Sen09] C. Sensler, A. Karalus, M. Märtens,

Ein Blick hinter die Kulissen: Modell -

repository@T-Mobile, in: JavaSPEKTRUM

01/2009

[Sof] Software AG Homepage, siehe:

www.softwareag.com

[Sta07] T. Stahl, M. Völter, S. Efftinge,

A. Haase, Modellgetriebene Softwareentwick -

lung: Techniken, Engineering, Management,

dpunkt.verlag (2. aktualisierte und erweiterte

Auflage) 2007

[Ste09] D. Steinberg, F. Budinsky, M. Pater -

nostro, E. Merks, Eclipse Modeling

Framework, Addison-Wesley 2009