Fachstudie. Vergleich von Enterprise-Service-Repositories. Marcus May Markus Krötz Truong-An Nguyen

Transkript

1 Universität Stuttgart Institut für Architektur von Anwendungssystemen Universitätsstraße Stuttgart Fachstudie Marcus May Markus Krötz Truong-An Nguyen Prüfer: Prof. Dr. Frank Leymann Betreuer: Zhilei Ma, Oliver Kopp Stand: 26. Juni 2008

2 Inhaltsverzeichnis 1 Einleitung Aufgabenstellung der Fachstudie Definition SOA Standards Vorstellung der vorhandenen Produkte auf dem Markt Kommerzielle Lösungen Nicht-kommerzielle Lösungen Bewertung Kriterien Bewertungsmodell Installation der Produkte Oracle Service Registry IBM WebSphere Service Registry and Repository IONA Artix Registry/Repository Genauere Betrachtung der Produkte Oracle Service Registry WebSphere Service Registry and Repository IONA Artix Registry/Repository Vergleichsmatrix Fazit 92 A Anhang 93 Seite 2 von 93

3 1 Einleitung 1.1 Aufgabenstellung der Fachstudie In einer serviceorientierten Architektur übernimmt die Speicherung und Verwaltung von Artefakten, wie Web Services, BPEL-Prozesse, Policies, XML-Dokumente oder sonstige Resourcen, eine immer bedeutendere Rolle. Die Verwaltung von SOA-Artefakten erfolgt in sogenannten Enterprise Service Repositories, die in der Regel aus zwei verschiedenen Komponenten bestehen: einem Repository zur Versionsverwaltung der Artefakte und einer Registry, in der zusätzliche Informationen und Metadaten zu den Artefakten abgelegt und abgefragt werden können. Auf dem Markt gibt es derzeit ein Dutzend verschiedener kommerzieller und nicht-kommerzieller Repositories mit unterschiedlichen Stärken und Schwächen. Im Rahmen dieser Fachstudie werden drei Enterprise Service Repositories näher betrachtet, auf diverse Kriterien hin überprüft und miteinander verglichen die OracleAS Service Registry, die WebSphere Service Registry and Repository und die IONA Artix Registry/Repository. 1.2 Definition SOA Eine serviceorientierte Architektur (SOA) beruht auf der losen Kopplung wiederverwendbarer Softwarebausteine (Services), die gewisse Standards erfüllen. Applikationen sollen sich dadurch an geänderte Anforderungen leichter und schneller anpassen lassen. Eine SOA strukturiert Anwendungssoftware doch auch Infrastrukturprogramme, Entwicklungs- und Verwaltungswerkzeuge müssen darauf abgestimmt sein. Die Verbindung zu den geschäftlichen Konzepten und Abläufen ist dabei essentiell. Hersteller und Berater haben bereits einiges vorgelegt und mittlerweile befassen sich auch viele Anwender mit der neuen Architektur. [http: // 1.3 Standards Da so gut wie alle Produkte einen oder gleich mehrere der folgenden Standards implementieren bzw. konform zu diesen sind, ist im Folgenden eine kurze Beschreibung gegeben. UDDI UDDI (Universal Description, Discovery and Integration) ist eine auf Initiative von IBM, Ariba und Microsoft standardisierte Registrierungstelle zum Beschreiben von Diensten, Auffinden von Geschäften und Integrieren von Geschäftsdiensten. Ein Unternehmen kann dabei drei verschiedene Arten von Informationen in einer UDDI-Registrierungsstelle registrieren: sogenannte White Pages, Yellow Pages und Green Pages. Die Spezifikation selbst kennt die Einteilung der Informationen in diese drei Arten nicht, allerdings ist sie in der Literatur weit verbreitet und gibt einen guten Überblick darüber, welche Informationen UDDI speichern kann. In den White Pages sind Kontaktinformationen über eine Firma zu finden, z.b. der Name, die Adresse, Ansprechpartner und eindeutige Bezeichner, wie europäische Umsatzsteuer-Identifikationsnummern. Mit diesen Informationen kann ein Web Service anhand einer Firma aufgefunden werden. In den Yellow Pages werden Web Services verschiedenen Taxonomien zugeordnet. Mit dieser Information kann ein Web Service anhand seiner Kategorisierung (z.b. produzierendes Gewerbe oder Autoverkäufer ) gefunden werden. Und in den Green Pages finden sich technische Informationen, die das Verhalten und weitere technische Details eines Web Services beschreiben. Zu diesen Informationen gehören Verweise auf Gruppierungsinformationen von Web Services, sowie Seite 3 von 93

4 Hinweise, wo die Web Services zu finden sind. Die UDDI-Spezifikation beschreibt mehrere APIs, wobei nur zwei richtig bekannt sind: die Abfrage-API (Inquiry API) und die Veröffentlichungs-API (Publication API). Daneben gibt es noch weitere, optionale APIs (Security Policy API, Custody and Ownership Transfer API, Subscription API und Value Set API). Über die Abfrage-API können Informationen über Unternehmen, deren Dienste, sowie die Spezifikationen dieser Dienste abgefragt werden. Die Abfrage-API verwendet keine Authentifizierung und kann damit über das HTTP realisiert werden. Mithilfe der Veröffentlichungs-API können Informationen in die UDDI-Registrierungsstelle eingetragen, modifziert und aktualisiert werden. Alle Funktionen dieser API verwenden einen authentifizierten Zugriff und werden über HTTPS realisiert. Vor dem UDDI-Projekt gab es keinen industrieweiten Ansatz über das Auffinden und Veröffentlichen von Produkten und Web Services über Unternehmensgrenzen hinweg. Die erste Version von UDDI wurde im August 2000 fertig gestellt. Im Mai 2003 und Februar 2005 wurden die UDDI 2- und UDDI 3-Spezifikationen von OASIS als Standard freigegeben. Die aktuelle Spezifikation von UDDI wurde am 19. Oktober 2004 in der Version veröffentlicht. ebxml Electronic Business XML (ebxml) ist eine 1999 gemeinsam von der UN/CEFACT und OASIS gestartete Initiative. Es wurde ein Kommitee, bestehend aus Repräsentanten beider Organisationen, zur Koordination der Bemühungen gegründet. Im Zeitraum vom November 1999 bis zum Mai 2001 fanden vierteljährliche Treffen der Arbeitsgruppen statt. Danach wurden die Ergebnisse des Kommitees in einer abschließenden Versammlung von beiden Organisationen unterzeichnet und die Verantwortlichkeiten für die Weiterentwicklung der Teilergebnisse aufgeteilt. Die Ergebnisse des Kommitees stellen die folgenden 5 Datenspezifikationsebenen mit den zugehörigen XML-Standards dar: Geschäftsabläufe (Business processes) Vereinbarungen über Zusammenarbeitsprotokolle (Collaboration protocol agreements) Kernkomponenten zur neutralen Beschreibung der Begrifflichkeiten (Core data components) Datentransfer (Messaging) Registries und Repositories (Registries and repositories) Das Ziel von ebxml bestand darin, für den Austausch von Informationen im Bereich Electronic Business einen weltweit konsistenten Einsatz von XML zu ermöglichen. Das soll die Zusammenarbeit zwischen Unternehmen vereinfachen. Dazu spezifiziert ebxml eine Architektur, ein Vorgehen und Methoden, um globales Electronic Business in einem Unternehmen erfolgreich umzusetzten. EDIFACT EDIFACT (United Nations Electronic Data Interchange For Administration, Commerce and Transport) ist ein branchenübergreifender, internationaler Standard für das Format elektronischer Daten im Geschäftsverkehr. EDIFACT ist einer von mehreren internationalen EDI-Standards. Verantwortlich für den EDIFACT-Standard ist eine UN- Einrichtung namens CEFACT, die der UNECE angegliedert ist. Die verschiedenen EDI- FACT-Versionen nennt man Verzeichnisse. Diese EDIFACT-Verzeichnisse werden regelmäßig überarbeitet, um neue EDIFACT-Nachrichten aufzunehmen oder bestehende zu aktualisieren. Grundlegendes Standardisierungskonzept von EDIFACT ist, dass es einheitliche Nachrichtentypen gibt, deren englische Bezeichnung United Nations Standard Seite 4 von 93

5 Message (UNSM) lautet. In sogenannten Subsets können die Nachrichtentypen branchenspezifisch tiefer in ihren Ausprägungen spezifiziert werden. Jede Nachricht besteht aus einem Umschlag (engl. envelope), den man sich als ein Briefkuvert vorstellen kann. In diesem Umschlag stehen jeweils vereinbarte Codenummern für Absender und Empfänger, sowie Nachrichteninhalt, Zeiten zur Rückverfolgung und Prüfelemente. Eine Nachricht selbst besteht aus Segmenten, Datenelementgruppen und Datenelementen. [ wikipedia.org/wiki/edifact] 1.4 Vorstellung der vorhandenen Produkte auf dem Markt Die auf dem Markt vorhandenen Lösungen wurden in kommerzielle und nicht-kommerzielle Produkte eingeteilt Kommerzielle Lösungen Folgende kommerziellen Produkte wurden gefunden: BEA AquaLogic Registry Repository aqualogic/registry repository/ CentraSite HP Systinet SOA Registry/Repository content.jsp?zn=bto &cp= %5e IONA Artix Registry/Repository repository/ Semantion Registry and Repository Oracle Service Registry Sun Java Enterprise System WebSphere Service Registry and Repository Webswell SOA Registry content&task=section&id=41 &Itemid=83 SOA Software Workbench workbench/ Amberpoint SOA Management System repository.shtml Seite 5 von 93

6 TIBCO ActiveMatrix Registry activematrix registry/default.jsp Nicht-kommerzielle Lösungen Folgende nicht-kommerziellen Produkte wurden gefunden: Mule Galaxy WSO2 Registry ebxml Registry/Repository juddi ebxml Registry/Repository Sun s Service Registry Für eine nähere Betrachtung der Funktionalität wurden drei Produkte ausgewählt, die Oracle Service Registry, das WebSphere Service Registry and Respository und das IONA Artix Registry/Repository. Auf die Evaluierung einer nicht-kommerziellen Lösung wurde verzichtet, da alle Produkte zwar nett aussehen, aber eine unzureichende Funktionalität besonders im Bereich der Versionsverwaltung, der Taxonomieverwaltung und im Praxiseinsatz aufwiesen. Oracle Die OracleAS Service Registry ist eine vollständig zum OASIS UDDI V3 -Standard konforme Implementierung einer UDDI-Registry. Sie ist einfach zu benutzen und es lassen sich Services dem Standard entsprechend publizieren und auffinden. Außerdem können mit ihr die üblichen Web-Service-Artefakte (XML, WSDL und XSLT) verwaltet werden. Zu den besonders interessanten Features des Produktes zählen die Benachrichtigung, der Veröffentlichungsprozess sowie die außerordentlich gute programmatische Erweiterbarkeit. Sie bietet zwar nicht die Vielfalt an unterstützten Artefakten, wie sie andere Produkte bieten, und auch keine Möglichkeit, den Inhalt der Artefakten selbst bei der Suche zu berücksichtigen. Allerdings lässt sich dieses Manko selbst nachrüsten. Damit stellt sie ein ausgezeichnetes und unverzichtbares Werkzeug für das Management jeder größeren SOA dar. WebSphere Service Registry and Repository IBM WebSphere Service Registry and Repository (WSRR) ist ein leistungsfähiges Werkzeug, mit dem die Management- und Governanceprozesse eines Kunden deutlich verbessert werden können. WSRR erlaubt, Services und damit verbundene Metadaten über alle Phasen einer SOA hinweg zu veröffentlichen und unterstützt zudem die Integration anderer Standard-Registries. Die leistungsfähigen Funktionen von WebSphere Service Registry and Repository machen das Produkt zu einer komfortablen Lösung in der SOA: Seite 6 von 93

7 Veröffentlichungs- und Suchfunktionen für mehr Transparenz und Wiederverwendung Flexibel einsetzbare Funktionen für den dynamischen und effizienten Zugriff auf Serviceinformationen während der Laufzeit Managementfunktionen für Richtlinien, Klassifizierungen, Versionssteuerung und Servicenutzung Governancefunktionen für den gesamten Lebenszyklus der Services, um deren Dynamik und Zweckmäßigkeit für das Unternehmen dauerhaft zu erhalten IONA Artix Registry/Repository Das Artix Registry/Repository ist die Lösung eines der führenden Anbieter von Software im Bereich der SOA, IONA Technologies, und Bestandteil der IONA Artix Advanced SOA Infrastructure Suite. Ende 2007 kündigte die DZ Bank (Deutsche Zentral-Genossenschaftsbank) den Einsatz des Artix Registry/Repository an. Das Produkt wurde vor allem wegen seiner Governance-Fähigkeiten, mit dem ein modellierter Geschäftsprozess auf seinen gültigen Einsatz hin überprüft werden kann, und seiner praxisnahen Ausrichtung ausgewählt. Außerdem unterscheidet sich Artix im Bereich der Benutzungsoberflächen recht stark von den Konkurrenzprodukten, weil der Client als Eclipse-Plugin realisiert wurde. Seite 7 von 93

8 2 Bewertung 2.1 Kriterien Im Folgenden werden die Kriterien kurz erläutert, die zur Bewertung der getesteten Produkte herangezogen wurden. Dabei werden sowohl die Anforderungen an ein Repository betrachtet, d.h. wie gut und komfortabel das Produkt Artefakte und Metadaten versionieren kann, als auch die Anforderungen an eine Registry, also die Art und Weise, wie Artefakte abgespeichert und ausgelesen werden können, wie sie miteinander verknüpft oder Beziehungen zwischen Artefakten modelliert werden können oder welche Lifecycle-Methoden angeboten werden. Benutzeroberflächen Dieses Kriterium beschreibt die Art der zur Verfügung stehenden Interaktionsmöglichkeiten, um mit dem Repository und der Registry arbeiten zu können. Es wird zwischen drei verschiedenen Oberflächentypen unterschieden: Weboberflächen, Plugins oder Tools. Weboberflächen ermöglichen die Steuerung des Produkts über einen Standardbrowser. Mit Plugins sind Erweiterungen für diverse Entwicklungswerkzeuge gemeint, in die das Produkt eingebettet werden kann. Beispiele wären Plugins für Eclipse oder Netbeans, die einen uneingeschränkten Zugriff auf das Repository bieten. Tools sind alle weiteren Benutzeroberflächen, wie eigenständige Programme, Hilfswerkzeuge oder ähnliches. Versionsverwaltung der Artefakte Die Versionsverwaltung der Artefakte beschreibt das Versionierungskonzept für Artefakte im Repository. Darunter fallen bestimmte Fragestellungen: Wird eine solches Versionierungskonzept, wie z.b. lineare Versionierung oder Multi- Dimension-Versionierung, für Artefakte angeboten? Lässt die Versionierung es zu, alte Versionen wieder herzustellen? Können Versionen als veraltet gekennzeichnet werden? Wird beim Auslesen einer veralteten Version eines Artefakts eine Referenz auf die neuere Version mit ausgegeben? Können ganze Konfigurationen zusammengestellt werden, also ein Paket von Artefakten, wobei die Version eines jeweiligen Artefakts festgelegt ist? Versionsverwaltung der Metadaten Die Versionsverwaltung der Metadaten beschreibt das Versionierungskonzept für Metadaten im Repository. Darunter fallen die selben Fragestellungen wie für das Versionierungskonzept der Artefakte, sofern ein entsprechendes Konzept für Metadaten vorhanden ist. Änderungsrückverfolgbarkeit Die Änderungsrückverfolgbarkeit beschreibt die Möglichkeiten der Protokollierung von Änderungen am Datenbestand des Repositories. Folgende Punkte werden näher betrachtet: welche Informationen über Benutzeraktivitäten werden gespeichert? Ist z.b. nur der Benutzername und das Änderungsdatum zu sehen, oder werden auch detaillierte Informationen über die geänderten Datensätze bereitgestellt? Kann der Grad der Protokollierung eingestellt werden, also kann festgelegt werden, welche einzelnen Aktivitäten protokolliert werden sollen und welche nicht? In welchen Datenformaten stehen die Protokollierungsdateien zur Verfügung? Werden sie als HTML-Dokument, XML- Dokument, Freitext oder in anderen Formaten bereitgestellt? Datenmodell Das Datenmodell beschreibt, welche Artefakte im Repository abgelegt werden können. Darunter fallen folgende Fragen: Welche Kategorien von Artefakten werden unterstützt und sind standardmäßig vorhanden? Gibt es spezielle Importmöglichkeiten für einzelne Artefakte, z.b. einen WSDL- oder BPEL-Importer? Wird der Inhalt bestimmter Dateiformate, z.b. von XML-Dokumenten, automatisch für die Suche zugänglich gemacht? Seite 8 von 93

9 Erweiterbarkeit Das Kriterium beschreibt die Erweiterbarkeit der Metadatenklassen. Folgende Punkte werden hierfür herangezogen: welche vorgefertigten Klassen gibt es? Gibt es beispielsweise eine Metadatenklassen, die einen Webservice oder einen BPEL-Prozess repräsentiert? Können eigene Metadatenklassen definiert werden, z.b. für einen Message- Broker? Taxonomien Taxonomien beschreibt die zur Verfügung stehenden Kategorien für Metadaten und Artefakte. Folgende Fragestellungen spielen dabei eine Rolle: welche Taxonomien sind standardmäßig definiert? Können bestehende Taxonomien verändert und gelöscht werden? Können neue Taxonomien hinzugefügt werden? Metadatenverwaltung Das Kriterium beschreibt die Möglichkeiten der Metadatenverwaltung. Darunter fallen folgende Fragestellungen: Welche standardmäßigen Metadaten gibt es? Können neue Metadaten definiert werden? Datenspeicherung Die Datenspeicherung beschreibt, wie das Produkt seine Datenbestände abspeichert. Dabei werden drei Typen unterschieden: Die Speicherung der Daten unter Verwendung einer XML-Datenbank, die Speicherung der Daten in einer normalen Datenbank und alternativ die Speicherung der Daten ohne die Verwendung von Datenbanken. Governance Das Kriterium beschreibt die Möglichkeiten der Governancefunktionalitäten. Als SOA-Governance (auch als Service Governance bezeichnet) werden die Aktivitäten, Entscheidungen, Rollen und Verantwortlichkeiten (Zuweisung von Rollen zu Aktivitäten oder Entscheidungen) zur Regulierung und Kontrolle einer serviceorientierten Architektur (SOA) bezeichnet. Ziel von SOA Governance ist es, das Service-Business-Alignment zu stärken oder Strategien durch Service-Denken zu ermöglichen. SOA-Governance kann auf verschiedenen Ebenen betrachtet werden: der Lebenszyklus eines Services; die Komposition von Services; Services im Service-Ökosystem innerhalb von Unternehmensnetzwerken oder dem Internet. Folgende Punkte werden näher betrachtet: Kann die Governance überprüft werden? Ermöglicht das Produkt in diesem Zusammenhang auch die Definition und Durchsetzung von Runtime-Richtlinien? Abfragen Abfragen beschreibt die Möglichkeit, Informationen über Metadaten und Artefakte auszulesen oder neue Informationen in den Datenbestand einzutragen. Die folgenden Fragestellungen beschäftigen sich mit diesem Kriterium: Welche Werkzeuge werden für die Datenabfrage angeboten? Gibt es dafür beispielsweise eine Weboberfläche, ein externes Hilfswerkzeug oder können über eine externe Schnittstelle per Java oder einer anderen Sprache Abfragen abgesetzt werden? Welche Abfragestandards wie z.b. XQuery oder XPath werden vom Produkt unterstützt? Welche Informationen über die Metadaten und Artefakte lassen sich überhaupt auslesen? Kann die Prozessstruktur eines BPEL-Prozesses ausgelesen werden? Kann nachvollzogen werden, welche BPEL-Prozesse bestimmte Port- Types oder Variablentypen verwenden? Seite 9 von 93

10 Beziehung von Artefakten Das Kriterium beschreibt die Verwaltung von Beziehungen zwischen Artefakten. Darunter fallen folgende Fragestellungen: Ist es möglich, Beziehungen zwischen Artefakten zu verwalten? Können Beziehungen selbst definiert werden? Welche Arten von Abhängigkeiten können spezifiert werden und was ist ihre genaue Semantik, also kann z.b. ein Artefakt Vater von, Kind von oder verwendet von einem anderen werden? Wie können die Abhängigkeiten visualisiert werden? Gibt es dafür nur tabellarische oder textuelle Auflistungen oder können diese Abhängigkeiten auch grafisch angezeigt werden? Bis zu welcher Tiefe werden diese Abhängigkeiten dann dargestellt? Wird beispielsweise angezeigt, dass A von B und weiterhin auch B von C und D abhängig ist? Werden bestehende Abhängigkeiten automatisch beim Importieren von Artefakten (z.b. beim Import eines BPEL-Prozesses oder XML-Dokuments) erkannt und abgespeichert? Gibt es auch eine manuelle Möglichkeit zur Bestimmung von Abhängigkeiten? Benutzerverwaltung Das Kriterium beschreibt die Funktionalität der Benutzerverwaltung. Folgende Aspekte gehören dazu: können neue Benutzer angelegt werden? Gibt es eine Art Rollenkonzept? Welche Rollen können angelegt werden? Können bestimmte Artefakte nur für einzelne Benutzer oder Rollen zugänglich gemacht werden? Lifecylemanagement Lifecyclemanagement beschreibt die Möglichkeiten, den SOA-Lebenszyklus eines Artefakts zu steuern. Folgende Punkte werden näher betrachtet: Kann der Benutzer den Lebenszyklus steuern? Welche standardmäßigen Lebenszyklen gibt es? Können neue Lebenszyklen hinzugefügt werden? Können mögliche Übergänge vom einem zum anderen Lebenszyklus festgelegt werden? Zweckmäßigkeit Die Zweckmäßigkeit beschreibt, in welchem Umfang das Produkt für die intendierte Nutzung maßgeschneidert ist. Folgende Fragen beschäftigen sich damit: sind die notwendigen Kategorien für die Modellierung von Unternehmen, Webservices und BPEL- Prozessen bereits vordefiniert? Gibt es Hilfsfunktionen, sogenannte Wizards, die das Hinzufügen von Webservices und BPEL-Prozessen erleichtern und notwendige Kategorisierungen und Verknüpfungen soweit wie möglich automatisch übernehmen? Kontaktinformationen Das Kriterium beschreibt, in wie weit Kontaktinformationen zu Artefakten und Metadaten hinzugefügt werden können. Die folgenden Fragestellungen befassen sich mit dieser Thematik: können Kontaktinformationen zu Artefakten und Metadaten hinzugefügt werden? Welche Arten von Kontaktinformationen, also z.b. Name, adresse oder Telefonnummer, sind dies? Benachrichtigungen Das Kriterium beschreibt die Möglichkeiten der Benachrichtigung von Benutzern bei Änderungen des Datenbestands. Dazu gehören folgende Punkte: können Benutzer benachrichtigt werden, wenn sich Artefakte und Metadaten ändern? Wie kann sich ein Benutzer auf eine solche Änderungsbenachrichtigung registrieren? Welche Änderungen werden dem Benutzer mitgeteilt, z.b. der Eintrag neuer Metadaten, neue Versionen eines Artefakts, Veränderungen des Lebenszyklus-Status, etc.? Standards Standards beschreiben die Unterstützung gewisser Standardsprachen oder -mechanismen. Darunter fallen folgende Aspekte: unterstützt das Produkt die Anbindung von UDDI? Welche Versionen von UDDI werden unterstützt? Wird ebxml unterstützt? Wird JAXR unterstützt? Welche weiteren Standards werden unterstützt? Seite 10 von 93

11 Unterstützung von Single Sign-On Das Kriterium beschreibt die Unterstützung von Single Sign On. Dabei wird betrachtet, ob eine Anbindung an den firmeneigenen Authentifizierungsdienst möglich ist, so dass der Benutzer nicht unnötig viele Passwörter eingeben muss. Dokumentation Dokumentation beschreibt die Qualität der zur Verfügung stehenden Dokumentation. Dazu gehören folgende Punkte: welche Dokumentationen sind für das Produkt vorhanden? In welchen Sprachen sind diese Dokumente verfasst? Gibt es eine Beschreibung für eventuelle APIs, die extern genutzt werden können? Sind alle Handbücher dem subjektiven Empfinden nach verständlich, so dass keine weiteren Dokumente und Hilfen notwendig sind? Bedienbarkeit Das Kriterium beschreibt die Bedienbarkeit der Produkts. Folgende sehr subjektive Fragestellungen beschäftigen sich damit: wie einfach ist das Produkt zu bedienen? Welche Vorkenntnisse sind für die Nutzung des Produktes notwendig, also ist ein entsprechendes Fachwissen über UDDI, XPath, etc. notwendig? Bietet das Program ausreichend Hilfefunktionen an? Sind eventuelle grafische Oberflächen übersichtlich und nicht überfüllt? Sind wichtige Funktionen versteckt oder nur sehr schwer oder sehr kompliziert zu erreichen oder zu bedienen? Lizenz Das Kriterium beschreibt die zur Verfügung stehenden Lizenzmodelle, mit denen das Produkt vertrieben wird. Folgende Fragen spielen dabei eine Rolle: welche Versionen und Lizenzen des Produktes gibt es? Gibt es beispielsweise eine spezielle Community-Edition für nichtkommerzielle Zwecke? Wie teuer sind die einzelnen Lizenzen? Seite 11 von 93

12 2.2 Bewertungsmodell Für jedes Kriterium wird eine bestimmte Bewertung vergeben, die angibt, wie gut das Produkt die Anforderungen an das Kriterium erfüllt. Die Bedeutung der einzelnen Bewertungen werden im Folgenden erläutert: (++) Das Produkt erfüllt die Anforderungen an das Kriterium vollständig und besitzt darüber hinaus noch zusätzliche, wertvolle Funktionen. Der Gesamteindruck hinsichtlich dieses Kriteriums ist sehr zufriedenstellend. (+) Das Produkt erfüllt die Anforderungen an das Kriterium. Möglicherweise gibt es an der einen oder anderen Stelle noch Verbesserungsmöglichkeiten oder kleinere Mängel, aber das Produkt macht in diesem Kriterium einen guten Gesamteindruck. ( ) Das Produkt erfüllt die Anforderungen an das Kriterium nur teilweise. Einige Aspekte sind ordentlich gelöst, wohingegen andere erkennbare Mängel aufweisen. ( ) Das Produkt erfüllt die Anforderungen nur ansatzweise. Der Gesamteindruck hinsichtlich des Kriteriums ist äußerst mangelhaft. (n.v.) Das Produkt konnte hinsichtlich des Kriteriums nicht evaluiert werden. Die Funktionalität wird nicht bereitgestellt oder zumindest nicht in einem Rahmen, der für eine Bewertung ausreichend wäre. Seite 12 von 93

13 3 Installation der Produkte 3.1 Oracle Service Registry Unterstützt Betriebssysteme: Windows 2000 Windows 2003 Windows XP Windows Vista Linux Unterstützte Applikationsserver: Oracle Application Server 10g R3 ( ) OC4J Standalone 10g R3 ( ) Oracle Application Server 10g R2 ( ) OC4J 10g R2 ( ) Unterstütze Datenbanken: Oracle 9i und neuer Oracle Lite 10g MSSQL 2005 DB2 8.0 und neuer Sybase ASE 12.5 und neuer Vorraussetzungen: Sun JDK (1.4.2 oder 5.0) Einer der unterstützten Applikationsserver Eine der unterstützten Datenbanken Seite 13 von 93

14 Konfiguration des Testsystems: Hardware AMD Athlon nvidia nforce4 Chipsatz 1GB Arbeitsspeicher (2x512MB DDR-400, Dual-channel) Software Windows XP mit SP2 JDK 5.0 (Version 14) Oracle Database 10g Express Edition (Release ) Oracle Containers for J2EE (OC4J) 10g Release 3 (Release ) Oracle Service Registry (Release ) Seite 14 von 93

15 Installation Oracle Database 10g Express Edition : Installationsdauer: 4min 1. Schritt 2. Schritt Seite 15 von 93

16 3. Schritt 4. Schritt Seite 16 von 93

18 7. Schritt Installation OC4J Standalone 10g R3 : Installationsdauer: 3min 1. Umgebungsvariable JAVA HOME auf das JDK-Verzeichnis setzen. 2. Umgebungsvariable OC4J JVM ARGS auf -Xmx1024m -Doc4j.userThreads=true -XX:MaxPermSize=128m setzen, damit OC4J vernünftig läuft. 3. Datei oc4j extended zip nach c:\oc4j entpacken. 4. Umgebungsvariable ORACLE HOME mittels SET ORACLE HOME=Pfad in der Komandozeile auf das OC4J-Verzeichnis setzen. Vorsicht: Wenn diese Umgebungsvariable in Windows gesetzt wird, dann startet die Datenbank nicht mehr. Andererseits muss diese Umgebungsvariable aber gesetzt werden, damit OC4J startet. 5. Beim ersten Start von OC4J muss man den Benutzer oc4jadmin mit einem beliebigen Passwort angelegen. 6. Standardmäßig ist der Applikationsserver unter zu erreichen. Seite 18 von 93

19 Installation Oracle Service Registry : Installationsdauer: 15min 1. Schritt 2. Schritt Seite 19 von 93

27 17. Schritt Seite 27 von 93

28 Installation für den Approval-Prozess Zuerst muss die Discovery-Registry installiert werden: 1. Schritt 2. Schritt Seite 28 von 93

29 3. Die restlichen Schritte sind analog zur bereits beschriebenen Installation der Oracle Service Registry. 4. Schritt: Stoppen Sie den Applikationsserver. 5. Schritt: Zum Erzeugen eines Zertifikates führen Sie in der Konsole die folgenden Befehle aus: cd <OC4J_HOME>/j2ee/home/keystore keytool -genkey -keyalg RSA -alias oracle -keystore keystore -storepass password 6. Schritt: Sie müssen in der Datei <OC4J_HOME>\j2ee\home\config\default-web-site.xml dem web-app -Tag das Attribut shared="true" hinzufügen. 7. Schritt: Kopieren Sie...\default-web-site.xml nach...\secure-web-site.xml. 8. Schritt: Sie müssen in der Datei..\secure-web-site.xml dem web-site -Tag das Attribut secure="true" hinzufügen und das port -Attribut auf z.b setzen. Nun fügen Sie dem Inhalt des web-site -Tag folgendes hinzu: <ssl-config keystore="<oc4j_home>/j2ee/home/keystore" keystore-password="password"/> 9. Schritt: Fügen Sie dem Inhalt des application-server -Tag in der Datei...\server.xml Folgendes hinzu: <web-site path="./secure-web-site.xml" /> 10. Schritt: Zum Importieren des Zertifikates führen Sie in der Konsole die folgenden Befehle aus: cd <oracle_install_dir> keytool -export -file oracle.crt -alias oracle -keystore <OC4J_HOME>/j2ee/home/keystore -storepass password PStoreTool.bat add -certfile oracle.crt -alias oracle -config <oracle_install_dir>/conf/clientconf.xml Seite 29 von 93

30 Danach kann die Publication-Registry installiert werden: 1. Schritt 2. Schritt 3. Schritt: Die restlichen Schritte sind analog zur bereits beschriebenen Installation der Seite 30 von 93

31 Oracle Service Registry. Stellen Sie sicher, dass Sie andere Parameter für die Datenbank und den Applikationsserver verwenden. 4. Schritt: Exportieren Sie das Zertifikat der Discovery-Registry in einem Browser. Dieses müssen Sie bei der Installation der Publication-Registry angeben. 5. Schritt: Fügen Sie dem Inhalt des httpspreferences -Tags in der Datei ORACLE_HOME\j2ee\ registry\applications\registrypub\registrypub\conf\oracle-servletconf.xml folgendes hinzu: <checkservercertificate>false</checkservercertificate> Seite 31 von 93

32 Zusammenfassung der Installation: Installationsinformationen Installationsdatei(en) OracleXEUniv.exe, oc4j extended zip, oracle-service-registry jar insgesamt 387MB Installierte Produkte Oracle Database 10g Express Edition, OC4J Standalone 10g R3, Oracle Service Registry Installationsdauer 22min Grafische Installation Ja, bis auf OC4J Anzahl der Dialoge insgesamt 24 (bei Normalinstallation) Anzahl der notwendigen Neustarts Keine Seite 32 von 93

33 3.2 IBM WebSphere Service Registry and Repository Unterstützt Betriebssysteme: AIX V5.3 Windows 2003 Solaris 10 Red Hat Enterprise Linux AS 4.0 SuSE Linux Enterprise Server 9.0 HPUX on PA-RISC z/os V1.7 Unterstützte Applikationsserver: WebSphere Application Server V6.0.2, (Fix Pack 11 oder neuer) WebSphere Application Server Network Deployment V6.0.2, (Fix Pack 11 oder neuer) Unterstütze Datenbanken: IBM DB2 Universal Database Enterprise Server Edition V8.2, (Fix Pack 5 oder neuer) Oracle Database 10g Enterprise Edition Release 2 Vorraussetzungen: 2 GB RAM Arbeitsspeicher 1,5 GB freier Speicherplatz Einer der unterstützten Applikationsserver Eine der unterstützten Datenbanken Varianten Websphere Application Server und Datenbank Server auf dem gleichen Rechner (Standard) Websphere Application Server und Datenbank Server auf zwei verschiedenen Rechnern Standalone oder verteilter Websphere Application Server Seite 33 von 93

34 Konfiguration des Testsystems: Hardware Intel Centrino Duo T2300 1,66GHz 1,5 GB Arbeitsspeicher Software Windows XP mit SP2 IBM WebSphere Application Server - ND, DB2 Express-C Websphere Service Registry und Repository Seite 34 von 93

35 Installation DB2 Express-C : Installationsdauer: 15min 1. Schritt 2. Schritt Seite 35 von 93

39 9. Schritt Installation Websphere Application Server 6.0 : Installationsdauer: 20min 1. Schritt Seite 39 von 93

48 18. Schritt Installation Websphere Application Server FixPak 15 : Installationsdauer: 30min 1. Schritt Datei WAS\6.0-WS-WAS-WinX32-RP zip nach WAS Verzeichnis (c:\program Files\IBM\WebSphere \AppServer) entpacken. 2. Schritt Ausführen der Datei WAS Verzeichnis\updateinstaller\update.exe Seite 48 von 93

52 9. Schritt 10. Schritt 11. Schritt Wiederholen der Schritte von 1 bis 8 für die Dateien was6025.zip und WS-WAS- WinX32-FP zip Seite 52 von 93

53 Installation IBM WebSphere Service Registry and Repository : 20min Installationsdauer: 1. Schritt 2. Schritt Seite 53 von 93

55 5. Schritt 6. Schritt Implementierungsscript ausführen: Installationsdauer: 25min Zur Implementierung von WSRR muss das Script installall ausgeführt werden, das sich im Unterverzeichnis install des WSRR-Installationspfads befindet, zum Beispiel C:\Program Files\IBM\WebSphereServiceRegistry\install. Dadurch werden die Anwendungen RXMeta und ServiceRegistry implementiert und alle notwendigen Ressourcen erstellt. Das Script installall sollte über die Eingabeaufforderung aufgerufen werden. Das Implementierungsscript wird wie folgt ausgeführt: Seite 55 von 93

56 installall -db-password fachstudie -db-user ngtruongan -was-home "C:/Program Files/IBM/WebSphere/AppServer" -db-home "C:/Program Files/IBM/SQLLIB" -was-profile Fachstudie Seite 56 von 93

57 Zusammenfassung der Installation: Installationsinformationen Installationsdatei(en) db2exc 950 WIN x86.zip, wasnd601.zip, 6.0-WS-WAS-WinX32-RP zip, was6025.zip, WS-WAS-WinX32-FP zip, C146UML.zip insgesamt 1985MB Installierte Produkte DB2 Express-C 9.5, Websphere Application Server ND, , Websphere Service Registry und Repository Installationsdauer Grafische Installation Anzahl der Dialoge insgesamt 57 (bei Normalinstallation) Anzahl der notwendigen Neustarts Keine 110min Ja, bis auf die Ausführung des Implementierungsscriptes Seite 57 von 93

58 3.3 IONA Artix Registry/Repository Unterstützte Betriebssysteme: Windows XP SP2 Linux Solaris 10 (außer Artix Client) AIX 5.2 (außer Artix Client) HP UX 11i (außer Artix Client) Unterstütze Datenbanken: Derby (wird standardmäßig installiert) Oracle 10g PostgreSQL 8.2 Vorraussetzungen: 1 GB RAM Arbeitsspeicher MB freier Speicherplatz Varianten: Server, Client und Datenbank auf dem gleichen Rechner (Standard) Server und Datenbank auf dem gleichen, Client auf einem anderen Rechner Server, Client und Datenbank auf drei verschiedenen Rechnern Seite 58 von 93

59 Installation IONA Artix Registry/Repository : Installationsdauer: 5 Minuten Bei der Installation des Servers wird der Administrator Admin mit dem Passwort admin angelegt. Das Repository ist standardmäßig über die Adresse erreichbar. 1. Schritt 2. Schritt Seite 59 von 93

64 Zusammenfassung der Installation: Installationsinformationen Installationsdatei(en) ArtixRR 1.5 windows.exe, 219 MB Installierte Produkte Artix Client, Artix Server, Derby Database Installationsdauer 4 Minuten Grafische Installation Ja Anzahl der Dialoge 10 (bei Normalinstallation) Anzahl der notwendigen Neustarts Keine Seite 64 von 93

65 4 Genauere Betrachtung der Produkte 4.1 Oracle Service Registry Backup (+) Dem zuständigen Administrator wird ein grafisches Werkzeug angeboten mit Hilfe dessen er den Datenbestand der Registry auf dem Dateisystem sichern kann. Auch das entsprechenden Werkzeug zur Wiederherstellung angefertigter Backups ist vorhanden. Eine fortgeschrittene, automatisierte Backupstrategie ist leider nicht vorhanden. Hier ist auf jeden Fall noch Verbesserungspotential vorhanden. Benutzeroberflächen ( ) Zur Interaktion stehen Weboberflächen zur Verfügung. Diese sind in zwei verschiedene Nutzungsperspektiven unterteilt, eine Business Service Control - und eine Registry Control - Perspektive. Die Business Service Control -Perspektive richtet sich an die bzgl. UDDI unerfahrenen Nutzer. Sie bietet für jeden Arbeitsschritt wie etwa das Hinzufügen eines neuen Webservices gut strukturierte und sehr intuitive Wizards an. Die Registry Control -Perspektive richtet sich eher an die bzgl. UDDI erfahrenen Nutzer und Administratoren der Registry. Es existiert die Möglichkeit, die Registry in die IDE JDeveloper zu integrieren. Mittels JDeveloper können dann Artefakte gesucht, Artefakte hinzugefügt, Artefakte verändert und WSDL- Artefakte dazu genutzt werden, um Clients zu generieren. In ähnlicher Weise ist es auch möglich, die Registry mit dem Tool Web Services Explorer in Eclipse einzubinden. Dazu ist entweder die Web-Tools- oder die J2EE-Variante von Eclipse nötig. Versionsverwaltung der Artefakte (+) Die Artefakte selbst werden nicht in der Registry gespeichert, nur eine URI auf deren Lokation. Daher lässt sich der UDDI-Struktur, welche das Artefakt repräsentiert, lediglich eine Version mittels einer Taxonomie zuweisen. Im Folgenden sind die Beschreibungsmöglichkeiten eines WSDL-Services aufgelistet. Diese lassen sich jedoch nach Belieben verändern oder durch eigene Taxonomien erweitern. WSDL-Service Service-Eigenschaften: Name (Freitext) Beschreibung (Freitext) Verwendungszweck (Freitext) Schlüsselwörter (Schlüssel-Wert-Paare im Freitext) Zertifizierung: (Zertifiziert Nicht Anwendbar In Arbeit Unbekannt) Datum der Veröffentlichung (Freitext) Version (Freitext) Meilenstein (Freitext) WSDL-Service Interface-Eigenschaften: Seite 65 von 93

66 Local name: durch die WSDL schon vorgegeben (ISub) Beschreibung (Freitext) Verwendungszweck (Freitext) Schlüsselwörter (Schlüssel-Wert-Paare im Freitext) Status: (Beta Abgelehnt Veraltet Stabil Unbekannt) WS-Standard-Konformität: (WS-I Basic Profile 1.0 WS-I Basic Profile 1.1 Unbekannt) WSDL-Service Endpoint-Eigenschaften: Zugangspunkt: URL des WS (Freitext) Verwendungszweck (Freitext) Schlüsselwörter (Schlüssel-Wert-Paare im Freitext) WS-Standard-Konformität: (WS-I Basic Profile 1.0 WS-I Basic Profile 1.1 Unbekannt) Verfügbarkeit: (Verfügbar Abgesetzt Nicht Verfügbar Unbekannt) Status: (In Wartung Testbetrieb Nicht funktionsfähig Funktionsfähig Unbekannt) Alte Versionen lassen sich nicht wiederherstellen. Durch eine entsprechende Taxonomie lässt sich ein Artefakt als veraltet kennzeichnen. Zusätzlich lässt sich eine Referenz auf das neue Artefakt setzten, welches das alte ersetzt. Versionsverwaltung der Metadaten (n.v.) Änderungsrückverfolgbarkeit ( ) Wenn die Registry so konfiguriert ist, dass der Approval -Prozess genutzt werden kann, wird zu jedem Artefakt eine Approval -Historie gespeichert. Dadurch ist ersichtlich, wer ein Artefakt verändert und wann er das getan hat. Der alte Zustand des Artefakts ist allerdings nicht wieder abrufbar. Es werden lediglich die Kommentare, die die Personen hinsichtlich des Vorgangs gemacht haben, in dem betreffenden Vorgang angezeigt. Je nachdem wie präzise dieser Kommentar war, lässt sich mehr oder weniger gut auf den vorherigen Zustand des Artefakts schließen. Datenmodell ( ) Da das Produkt wie der Name schon sagt lediglich eine Registry ist, wird hier nur beschrieben, welche Metadaten-Typen (UDDI-Struktur, die das Artefakt beschreibt) angelegt werden können. Vordefinierte Metadaten-Typen, für die auch entsprechende Wizards existieren: WSDL Services Providers Endpoints Interfaces Seite 66 von 93

67 Policies XML Dokumente XSLT Transformationen XSD Dokumente Services Resources In der Registry lassen sich ausschließlich UDDI-Strukturen und keine Artefakte direkt erstellen. Allerdings lassen sich Verweise in Form von URIs auf vorhandene Artefakte definieren. Aus diesem Grund kann die Suche auch nicht den Inhalt der Artefakte berücksichtigen. Erweiterbarkeit (+) Es existieren die folgenden vordefinierten Metadatenklassen: WSDL Services Providers Endpoints Interfaces Policies XML Dokumente XSLT Transformationen XSD Dokumente Services Resources Alle diese Metadatenklassen lassen sich durch weitere, eigens definierte Taxonomien verfeinern. Auch die Weboberfläche lässt sich dahingehend anpassen, dass die neuen Taxonomien bei der Suche, Erstellung und Änderung der Artefakte mit einbezogen werden. Dadurch lässt sich z.b. eine neuer Service definieren, der als BPEL-Service gekennzeichnet und mit weiteren BPELspezifischen Parametern beschrieben werden kann. Außerdem kann mit Hilfe der Entwicklerdokumentation die Registry selbst um Funktionalität erweitert werden. Seite 67 von 93

68 Taxonomien (++) Es gibt zwei unterschiedliche Arten von Taxonomien, die so genannten checked - und unchecked -Taxonomien. unchecked -Taxonomien Durch das Hinzufügen einer solchen Taxonomie lässt sich ein Artefakt markieren, z.b. bekommt ein Artefakte eine Anschrift. Der Wert, welcher in dieser Taxonomie gesetzt wird, wird von der Registry nicht validiert. Es kann also beliebiger Text eingegeben werden. checked -Taxonomien Durch das Hinzufügen einer solchen Taxonomie lässt sich ein Artefakt ebenfalls markieren. Im Unterschied zu einer unchecked -Taxonomie wird allerdings um bei dem obigen Beispiel zu bleiben die Anschrift von der Registry validiert. Dazu muss entweder eine Implementatierung in Java erstellt werden oder aber man nutzt im Voraus definierte Werte. Für eine checked -Taxonomie mit vordefinierten Werten bietet die Registry bereits eine Implementierung an, welche den eingegebenen Wert gegen die gültigen Werte validiert. Es existiert bereits eine Vielzahl vordefinierter Taxonomien um Webservices sowie deren Anbieter zu beschreiben. Außerdem lassen sich die vorhandenen Taxonomien beliebig anpassen und erweitern. Es ist auch möglich, eigene Taxonomien zu erstellen und in die Weboberfläche der Registry zu integrieren. Metadatenverwaltung (+) Es existiert ein breit gefächertes Angebot an durch UDDI vordefinierte Metadaten (siehe auch Kriterium Erweiterbarkeit). Außerdem lassen sich beliebig viele Taxonomien hinzufügen und in die Registry integrieren. Jede Taxonomie, die der Registry hinzugefügt wird, ist auch in der Abfrageschnittstelle verfügbar. Datenspeicherung ( ) Es werden ausschließlich UDDI-Strukturen in der Datenbank gespeichert. Das Produkt ist lediglich eine Registry und kein Repository. Ein Repository mit entsprechender Versionsverwaltung der Artefakte lässt sich allerdings leicht hinzufügen, da jedes Artefakt eine URI auf dessen physische Lokation speichern kann. Hier könnte man auch eine URI auf ein Dokumentenverwaltungssystem angeben. Governancefunktionen (+) Die Durchsetzung einer SOA-Governance ist durch den Approval-Process möglich. Zum einen lassen sich alle Änderungen in der Registry durch einen anderen Benutzer (Approver) kontrollieren. Das bedeutet, dass an den Approver ein Approval-Request geschickt wird, der alle Änderungen in der Registry enthält. Diese Request kann der Approver dann entweder akzeptieren und die Änderungen werden in der Discovery-Registry aufgenommen oder er kann ihn mit einer Begründung an den Requestor ablehnen. Zum anderen können noch automatische Approver implementiert werden, die die Requests sowie möglicherweise vorhandene Artefakte gegen entsprechende Regeln validieren. Seite 68 von 93

69 Abfragen ( ) Suchanfragen können über die Weboberfläche und durch dritte Programme, welche UDDI verwenden, an die Registry geschickt werden. Die Syntax dieser Suchanfragen ist durch den UDDI- Standard spezifiziert. Die Weboberfläche bietet sehr komfortable Masken an, um Suchanfragen zu formulieren. Zur Suche können alle in der Registry existierende Taxonomien verwendet werden. Als Antwort erhält der Benutzer eine Liste mit den Artefakten, die den Suchparametern entsprachen. Da die Registry die eigentlichen Dokumente nicht speichert, sondern nur die den Dokumenten entsprechenden Artefakte erzeugt, kann bei der Suche der Inhalt der Dokumente nicht berücksichtigt werden. Nachdem ein Artefakt gefunden wurde, können alle zu dem Artefakt vorhandenen Informationen abgefragt werden, soweit der Benutzer dazu berechtigt ist. Beziehung von Artefakten (+) Es können die folgenden Referenzen auf andere Artefakte mit einem Artefakt assoziiert werden. Zuordnung einer WS-Policy Abhängigkeit von einem Endpoint Abhängigkeit von einem Interface Abhängigkeit von einem Provider Abhängigkeit von einer Resource Diese stellt eine beliebige Datei dar. Abhängigkeit von einem Service Abhängigkeit von einem WSDL Service Abhängigkeit von einer XML-Datei Abhängigkeit von einer XSD-Datei Abhängigkeit von einer XSLT-Datei Die Referenz wird bei dem referenzierenden und dem referenzierten Artefakt angezeigt. Benutzerverwaltung (++) Der Administrator kann über die Registry Control neue Benutzer sowie Gruppen anlegen. Außerdem können sich Benutzer selbst an der Registry anmelden, falls dies gewünscht ist. Rechte können dann entweder an einzelne Benutzer oder an komplette Gruppen vergeben werden. Dadurch können Artefakte nur bestimmten Benutzern oder Gruppen zugänglich gemacht werden. Allen Artefakten lassen sich Berechtigungen zuordnen. Dies geschieht indem man dem Artefakt einen oder mehrere Benutzer bzw. Gruppen zuordnet. In dieser Zuordnung lässt sich außerdem konfigurieren, ob das Artefakt gefunden, angezeigt, verändert und gelöscht werden darf und ob Kindartefakte erstellt werden dürfen. Wenn dem Artefakt keine Berechtigungen zugeordnet sind, darf das Artefakt zwar jeder finden und anzeigen, aber nur vom Besitzer verändert werden. Es existiert ein Mechanismus, mit dem ein Benutzer ein Artefakt in den Besitz eines anderen Benutzers bringen kann. Seite 69 von 93

70 Lifecycle-Management (+) Lifecycle-Management ist prinzipiell mit den Taxonomien sowie Staging von mehreren Registries und einem angepassten Genehmigungsprozess (Approval) möglich. Dadurch werden aus einer Staging Registry (Master) bestimmte Artefakte durch die Intervention eines weiteren Menschen in das Discovery Registry übernommen (repliziert). Nur diese so genannte Discovery Registry wird von den Kunden benutzt, um Informationen über die Artefakte zu erhalten. Es können sogar komplette Registryhierarchien aufgebaut werden. Dadurch kann der Genehmigungsprozess sehr detailliert und entsprechend den Vorgängen im Unternehmen modelliert werden. Abbildung 1: Der Oracle-Genehmigungsprozess Es existieren zwar die nötigen Taxonimien, um den aktuellen Zustand eines Artefakts zu modellieren, aber es ist kein expliziter Lebenszyklus definiert. Zweckmäßigkeit (+) Das Produkt ermöglicht entsprechend dem UDDI-Standard die Modellierung von Unternehmen, Webservices, allgemeinen Services, XML-Dokumenten, XSD-Dokumenten, XSLT-Transformationen, Endpoints, Interfaces, Webservice-Richtlinien (Policies) und allgemeinen Dokumenten. Zur Erstellung dieser Artefakte existieren in der Weboberfläche gut strukturierte und leicht zu bedienende Wizards. Zum Hinzufügen existiert ein Wizard, der die zugehörige WSDL-Datei untersucht und entsprechend dem UDDI-Standard alle notwendigen Artefakte korrekt erzeugt. Leider existiert keine vordefinierte Taxonomie und daher auch kein Wizard für das Hinzufügen von BPEL-Prozessen. Dank der ausführlichen Entwicklerdokumentation sollte es aber möglich sein, die Registry um diese Funktionalität zu erweitern. Seite 70 von 93

71 Kontaktinformationen ( ) Nur dem Artefakt Anbieter 1 können Personen direkt zugeordnet werden. Zu jeder Person kann der Name, die Funktion, eine Beschreibung, die -Adresse und die Telefonnummer gespeichert werden. Außerdem lassen sich einem Artefakt noch ein Name, eine Beschreibung, eine Homepage und beliebig viele Schlüssel-Wert-Paare zuordnen. Benachrichtigungen (++) Die Registry bietet umfassenden Möglichkeiten zur Benachrichtigung an. Es ist eine Benachrichtigung per implementiert. Diese schickt dem Benutzer, wenn er sich auf ein Artefakt angemeldet hat (dies ist über die Weboberfläche möglich), in durch den Benutzer definierten Intervallen s über den aktuellen Zustand des Artefaktes. Der Aufbau dieser s lässt sich durch eine XSLT-Transformation den konkreten Wünschen der Benutzer entsprechend anpassen. Eine Benachrichtigung wird immer dann generiert, wenn sich der Zustand des Artefaktes geändert hat. Außer der Benachrichtigung per lassen sich noch andere Module entwickeln und in die Registry integrieren, die z.b. bei einer Veränderung eines Artefaktes beliebigen Java-Code ausführt. Damit lässt sich beispielsweise eine Applikation automatisch über einen geänderten Endpoint eines Services informieren. Alternativ dazu könnte die Applikation aber auch den Endpoint jedes Mal in der Registry abfragen. Standards (+) Das Produkt unterstützt UDDI V2 und UDDI V3. Unterstützung von Single Sign-On (++) Die Registry kann an das Microsoft Active Directory, sowie an das Oracle Internet Directory oder an ein LDAP -Verzeichnis angebunden werden. Dokumentation (++) Im Produkt selbst ist eine Online-Hilfe integriert. Außerdem liegt dem Produkt eine ausführliche Dokumentation bei. Diese beschreibt nicht nur die Installation und die Benutzung des Produkts, sondern enthält auch ausführliche Erklärungen zur programmatischen Erweiterung der Registry und zum Entwickeln andere Anwendungen, die mit der Registry arbeiten. Desweiteren findet sich im Forum von Oracle auf fast jedes Problem eine Lösung. Bedienbarkeit (++) Die Business Service Control -Perspektive erleichtert den Einstieg enorm. Es lassen sich alle relevanten Artefakte mittels Wizards hinzufügen. Auch die Suche nach Artefakten ist sehr einfach gestaltet. Außerdem ist in das Produkt noch eine Online-Hilfe integriert. Die Weboberfläche wirkt sehr aufgeräumt, ist wohl strukturiert und alle Funktionen sind leicht zu finden. Für die Bedienung ist keinerlei Fachwissen erforderlich. 1 Provider Seite 71 von 93

72 Lizenz (+) So lange das Produkt noch nicht lizenziert ist, lassen sich nur eine begrenzte Anzahl an Artefakten hinzufügen. Ansonsten bietet das Produkt allerdings die volle Funktionalität der lizenzierten Version. Außerdem arbeitet das Produkt mit der Community-Edition der Oracle-Datenbank und mit der von Oracle für Entwickler freien Version des Applicationservers OC4J zusammen. Daher lässt sich das Produkt beliebig lange und umfassend testen. Welche Kosten für den produktiven Einsatz der Registry entstehen, konnte nicht bestimmt werden, da dazu die Einzelpreise der entsprechenden Datenbank, des Applicationserver und der Registry selbst erst bei Oracle erfragt werden müssen. Oracle bietet hier leider keine Richtpreise an. Außerdem ist der Preis von der gewählten Konfiguration abhängig. Seite 72 von 93

73 4.2 WebSphere Service Registry and Repository Benutzeroberflächen (+) Zur Interaktion stehen einfache und überschaubare Weboberflächen zur Verfügung. Diese sind in zwei verschiedene Nutzungsperspektiven unterteilt, eine Administrator - und eine Benutzer -Perspektive. Beide Perspektive sind sehr ähnlich und spiegeln die entsprechende Rolle des Benutzers wider. In der Administrator -Perspektive können Medadaten, Ontologien und Klassifizierungsysteme importiert und exportiert werden. Weiterhin existiert die Möglichkeit, das System in Eclipse einzubinden. Dort können dann Artefakte gesucht, Artefakte hinzugefügt, Artefakte verändert und in die Entwicklungsprojekte importieren werden. Versionsverwaltung der Artefakte ( ) Die Einstellung der Version ist nur beim Importieren eines neuen Artefakts möglich. Anschließend gibt es keine Möglichkeit mehr, die Version zu ändern. Eine Verwaltung der Versionsnummerierung oder automatische Erhöhung der Versionsnummern gibt es nicht. Das Versionsfeld ist eine einfache Zeichenfolge mit freiem Format. Beim Importieren eines Artefakt, das schon in WSRR vorhanden ist, kann eine neue Versionsnummer eingegeben werden. Versionsverwaltung der Metadaten (n.v.) Änderungsrückverfolgbarkeit ( ) Für jedes Artefakt wird gespeichert, welcher Benutzer wann die letzten Änderungen durchgeführt hat. Leider bietet WSRR keine Änderungshistorie oder detailiertere Informationen, z.b. welche Daten genau verändert wurden, an. Datenmodell (+) Mit Hilfe von Wizards können im WSRR folgende Artefakte abgelegt werden: WSDL Dokumente XSD Dokumente XML Dokumente Service Policies SCA-Integrationsmodule Andere Dokumente Leider gibt es keine Unterstützung für BPEL Prozesse. Außer bei anderen Dokumenten und XML-Dokumenten gruppiert WSRR Artefakte beim Importieren in logische Ableitungen, wie PortType, Port, usw. Die Menge von logischen Ableitungen umfasst das Datenmodell der WSRR. Es können Elemente wie PortTypes, Ports, WSDL-Nachrichten, XSD-ComplexTypes und XSD-SimpleTypes gruppiert werden. Diese Elemente können auch Eigenschaften, Beziehungen und Klassifizierungen besitzen. Seite 73 von 93

74 Erweiterbarkeit (++) WSRR unterstützt die folgenden Metadaten-Typen WSDL XSD WS-Policy SCDL Konzepte Konzepte sind Entitäten in der Registry, die mit WSRR-Standarddokumenttypen, wie z.b. WSDL und XSD, nicht dargestellt werden können. Konzepte werden gemäß einer benutzerdefinierten Ontologie erstellt und klassifiziert und sind versionierbar. Diese Metadaten-Typen und ihre Entitäten, die logische Ableitungen, lassen sich durch weitere benutzerdefinierte Metadaten-Typen wie Eigenschaften, Beziehungen und Klassifikationen verfeinern. Auch die Weboberfläche, das Eclipse-Plugin und die API lassen sich dahingehend anpassen, dass die neuen, benutzerdefinierten Metadata-Typen bei der Suche, Erstellung und Änderung der Artefakte mit einbezogen werden. Taxonomien (+) Mit Hilfe von Taxonomien lassen sich Artefakte in WSRR organisieren, kategorisieren und suchen. Die Klassifizierungssysteme werden mit der Web Ontology Language (OWL) definiert. Nur ein Administrator kann ein neues Klassifizierungssystem laden. Ein vorhandenes Klassifizierungssystem kann in der Web UI zwar gelöscht werden, aber es gibt keine Möglichkeit, ein neues zu erstellen oder ein vorhandenes zu verändern. Metadatenverwaltung (+) Viele beliebigen Klassifizierungen lassen sich hinzufügen und in die Registry integrieren. Jede Taxonomie, die der Registry hinzugefügt wurde, ist auch in der Abfrageschnittstelle verfügbar. Mit Konzepten können auch beliebige Informationen definiert werden (siehe auch Kriterium Erweiterbarkeit). Datenspeicherung (++) Die Daten von WSRR werden in einer normalen Datenbank abgespeichert. WSRR arbeitet mit einer DB2- oder Oracle-Datenbank. Beim Importieren von WSDL-, XSD-, WS-Policy und SCA-Dokumenten werden die Artefakte geparst und ihre Entitäten ( logische Ableitungen ) in verschiedene Tabellen abgespeichert. Darum ist es mit WSRR auch möglich, nach einem bestimmten Inhalt eines Dokuments, wie z.b. einem WSDL-PortType, zu suchen. Governancefunktionen (++) WSRR ermöglicht die Governance von Service-Metadaten durch die folgenden Mechanismen: Definition und Durchsetzung von Service-Lebenszyklus für regulierte Objekte Seite 74 von 93

75 Validierung und Benachrichtigung bei Änderung der Lebenszykluszustände Definition und Durchsetzung von Sicherheitsrichtlinien Governance API Abfragen (+) Suchanfragen können über die Weboberfläche, durch das Eclipse-Plugin, oder die Abfrageschnittstelle API gestellt werden. Ein komfortabler Abfrageassistent in der Weboberfläche und im Ecplise-Plugin bietet mehrere Abfragen je nach Dokumentyp an. Zur Suche können alle im System existierenden Klassifizierungen verwendet werden. Als Antwort erhält der Benutzer eine Liste der Artefakte, die den Suchparametern entsprachen. Allerdings unterstützt der Assistent im Gegensatz zur Abfrageschnittstelle keine XPath-Ausdrücke. Nachdem ein Artefakt gefunden wurde, können alle zu dem Artefakt vorhandenen Informationen abgefragt werden, soweit der Benutzer dazu berechtigt ist. Beziehung von Artefakten (++) Beim Importieren von Artefakten werden folgende Beziehungen automatisch erkannt: Verweis von abgeleiteter Entität auf ihr Quellendokument WSDL- oder XSD-Dokument zu importiertem XSD-Dokument WSDL- oder XSD-Dokument zu eingeschlossenem XSD-Dokument WSDL- oder XSD-Dokument zu definiertem XSD-Dokument WSDL-Dokument zu importiertem WSDL-Dokument Verweis von Entität auf Klassifizierung Beziehung von Entität zu Vorgänger Verweis von nicht abgeleiteter Entität auf ihre Schablone WSDL-Service zu WSDL-Port WSDL-Port zu WSDL-Bindung WSDL-Port zu SOAP-Adresse WSDL-Bindung zu SOAP-Bindung WSDL-Bindung zu WSDL-Porttyp WSDL-Porttyp zu WSDL-Operation WSDL-Operation zu WSDL-Fehlernachricht WSDL-Operation zu WSDL-Eingabenachricht WSDL-Operation zu WSDL-Ausgabenachricht Seite 75 von 93

76 WSDL-Nachricht zu WSDL-Teil WSDL-Teil zu XSD-Typ WSDL-Teil zu XSD-Elementdeklaration Verweis von SCA-Integrationsmodulentität auf SCA-Importdokument Verweis von Integrationsmodulentität auf SCA-Exportdokument Verweis von SCA-Integrationsmodulentität auf XML-Schemadefinitionsdokument Verweis von SCA-Integrationsmodulentität auf WSDL-Dokument Verweis von SCA-Integrationsmodulentität auf SCA-Moduldokument SCA-Modul zu SCA-Importentität SCA-Modul zu SCA-Exportentität Verweis von SCA-Import- oder Exportentität auf SCA-Schnittstelle SCA-Importentität zu SCA-Importbindung SCA-Exportentität zu SCA-Exportbindung Verweis von SCA-Importbindungsentität auf SCA-Exportbindungsentität Bindung von SCA-Web-Serviceimport zu WSDL-Port Verweise von SCA-WSDL-Porttyp auf WSDL-Porttyp Verweis von komplexem XSD-Typ auf ein lokales Attribut Mit Hilfe des Beziehungsassistenten kann der Benutzer eine Beziehungen zwischen einem oder mehreren ausgewählten Objekten definieren, so dass z.b. ein Konzept eine Beziehung mit einem Service besitzen kann. Im WSRR heißt eine benutzerdefinierte Beziehung angepasste Beziehung. Die Registerkarte Wirkungsanalyse bietet die Möglichkeit zur Analyse der Abhängigkeiten an. Benutzerverwaltung (+) WSRR verwendet den Sicherheitsmechanismus und die Benutzerverwaltung des WebSphere Application Servers. Die Sicherheitsrollen und die Berechtigungen sind im Deployment Descriptor definiert. Die WSRR ist von der Sicherheit des WAS abhängig, d.h. die globale Sicherheit des WAS muss aktiviert sein. Ist dies nicht der Fall, findet keine Authentifizierung bei der Anmeldung statt. Die J2EE-Sicherheits-Rollen des WAS können eingeschränkt verwendet werden, wenn man zur Laufzeit Zugang zur WSRR bekommt. Man kann die Berechtigung den verschiedenen Rollen zuordnen. Seite 76 von 93

77 Lifecycle-Management (++) Ein Benutzer kann in WSRR ein Servicebeschreibungsartefakt (ein Konzept oder ein Dokument) zum Durchlaufen eines Governancelebenszyklus auswählen. WSRR unterstützt nur eine einzige Lebenszyklusdefinition, die aber mehrere Lebenszyklen enthalten kann. Jede Lebenszyklusdefinition kann über eine Reihe von benannten Anfangsübergängen verfügen. Anhand dieser Übergänge lässt sich feststellen, welcher Lebenszyklus innerhalb der Definition gerade durchlaufen wird. Ein Lebenszyklus lässt sich manuell oder am bestens mit dem Tool IBM WebSphere Integration Developer definieren. Durch Ausführen des Skripts updatelifecycledefinition.jacl wird der Lebenszyklus in WSRR geladen. Alle Aktionen, die dazu dienen, die Governance für Artefakte einzurichten oder zu entfernen, werden über die ManageGovernance-Zugriffssteuerung geschützt. Nur Benutzer, die über eine Berechtigung zur Erstellung von Artefakten verfügen, dürfen diese Aktionen ausführen. Der Governancelebenszyklus kann über die Webbenutzerschnittstelle oder über die API eingeleitet werden. Zweckmäßigkeit (++) WSRR bietet sowohl Registry- als auch Repository-Funktionalität in einem Werkzeug an, das die Abfrage und Änderung aller Daten beider Verzeichnistypen über eine Web-Oberfläche, einer definierten API oder einem Eclipse Plugin erlaubt. IBM hat mit dem WebSphere Registry & Repository (WSRR) seine Vision eines Werkzeugs für eine SOA-Governance konsequent umgesetzt. Im WSRR können alle denkbaren Dokumententypen und Service-Metadaten abgelegt und nach Governance-Prinzipien durch den gesamten SOA-Lebenszyklus hindurch verwaltet werden. Kontaktinformationen (n.v.) Benachrichtigungen (++) Durch das Einrichten von Subskriptionen kann der Benutzer auf einfache Weise festlegen, welche Objekte überwacht werden sollen und bei welchen Ereignissen oder Übergängen er die Benachrichtigung bekommen möchte. Neben der Benachrichtigung per werden die Nachrichtigen in einer JMS Queue veröffentlicht. Andere Module können diese Queue auslesen und spezifische Aktionen durchführen. Damit lässt sich beispielsweise eine Applikation automatisch über einen geänderten Endpoint eines Services informieren. Standards ( ) IBM hat sich bei der Entwicklung des Produkts gegen UDDI als primären Standard für Zugriffe und das von UDDI vorgegebene Datenmodell entschieden. In Bezug auf die Funktionalität stellt das WSRR eine Übermenge einer UDDI-Registry dar. Mit Hilfe eines WSRR-UDDI- Synchronisationsmoduls kann der Inhalt der WSRR mit UDDI Version 3 synchronisiert werden. Unterstützung von Single Sign-On (++) Die WSRR nutzt die Single-Sign-On- und Sicherheitsfunktionalitäten des WebSphere Application Servers. Seite 77 von 93

78 Dokumentation (+) Die beiliegende Dokumentation des Produktes ( Quick Start Guide ) beschreibt die Installation nur unzureichend. Das Deployment der WSRR auf dem WAS wurde leider gar nicht beschrieben. Allerdings ist das Handbuch auf der IBM Redbook-Seite sehr ausführlich und beschreibt nicht nur die Installation und die Benutzung des Produkts, sondern enthält auch ausführliche Erklärungen für die Verwendung der API, die programmatische Erweiterung der Registry, die Administration und die Integration mit anderen Systemen. Im Produkt selbst ist eine Online- Hilfe integriert. Bedienbarkeit (+) Die Web UI und das Eclipse-Plugin sind sehr einfach, gut strukturiert und erleichtern den Einstieg ernorm. Es lassen sich alle relevanten Artefakte mittels Wizards hinzufügen. Die Suche nach Artefakten ist sehr einfach gestaltet. Außerdem verfügt WSRR über eine Online-Hilfe. Alle Funktionen und Artefakte sind leicht zu finden. Allerdings verwirrt die Umsetzung der Beziehungen etwas, da einige Beziehungen unter dem Punkt zusätzliche Eigenschaften und andere Beziehungen unter dem Punkt Beziehungen zu finden sind. Leider ist es auch nicht möglich, die Benutzer, Rollen und Gruppen über die WSRR-Weboberfläche zu verwalten. Lizenz ( ) Es gibt keine Trial-Version von WSRR zum Herunterladen. Die Trial-Versionen des WebSphere Application Servers und der DB2 befinden sich auf der IBM Webseite, entsprechen aber nicht den Anforderungen der WSRR-Version des IAAS. Dem IAAS selbst steht eine lizenzierte Version des WSRR mit voller Funktionalität zur Verfügung. Die Produkte sind sehr teuer. Die Preise sind von den Prozessor-Value-Units (PUVs), also von den Prozessorkernen der Server, auf denen die Software installiert werden soll, abhängig. Z.B. hat ein Single-Core Xeon Prozessor 100 PUVs. Nachfolgend finden sich die Preise inklusive Mehrwehrtssteuer pro PUV (Stand ): Websphere Application Server IBM WebSphere Application Server Processor Value Unit (PVU) License + SW Subscription & Support 12 Months : 49,79 EUR IBM WebSphere Application Server Network Deployment Processor Value Unit (PVU) License + SW Subscription & Support 12 Months : 186,83 EUR Websphere Service Registry and Repository DB2 IBM WebSphere Service Registry and Repository Processor Value Unit (PVU) License + SW Subscription & Support 12 Months : 420 EUR IBM DB2 Enterprise Server Edition Processor Value Unit (PVU) License + SW Subscription & Support 12 Months 466,68 EUR Seite 78 von 93

79 4.3 IONA Artix Registry/Repository Begriffsklärung IONA Artix Registry/Repository verwendet teilweise unklare oder mehrdeutige Begrifflichkeiten. Vor einer intensiven Betrachtung des Produktes müssen diese Begrifflichkeiten zunächst definiert, bzw. abgegrenzt werden. Für weitere Informationen wird zusätzlich auf das entsprechende Glossar von IONA verwiesen ( Artix ESB Glossary ). Artix Locator Service Ist ein Web Service, der es Endbenutzern eines Services (engl. Consumer) ermöglicht, zur Laufzeit Service Provider Endpoints zu entdecken. Der Locator abstrahiert den physikalischen Ort eines Service Endpoints für eine Client-Applikation, so dass diese nicht die tatsächliche Netzwerkadresse kennen muss. Artix Router Leitet Nachrichten nach bestimmten Regeln um, die in einem Artix Contract definiert sind. So müssen weder der Client noch der Server Endpoint verändert werden, sondern können ganz einfach umgeleitet werden. Assembly Eine logische Menge von SOA-Teilnehmern und Service Providern, die gemeinsam Geschäftsfunktionen realisieren. Container In einem Container können Services eingesetzt (engl. deployed) und verwaltet (engl. managed) werden. Die Verwendung von Container realisiert die Pfadunabhängigkeit von Codestücken. Governance Governance bezeichnet den Prozess der Überprüfung und Durchführung von Regeln in einem SOA-Netzwerk. Implementierung Als Implementierung wird jede Art von ausführbarem Code oder eine Konfiguration bezeichnet, in der Geschäftslogik definiert und ausgeführt wird. BPEL-Skripte oder Java-Bibliotheken sind zum Beispiel Implementierungen. Infrastruktur Eine bestimmte Sammlung von SOA-Teilnehmern, Installationen, Produkten und Containern. Installation Eine physische Maschine, auf der ein Package eingesetzt (engl. deployed) wird. Eine Installation besitzt einen Namen, einen Hostnamen, Angaben über die Platform des Hosts, einen Netzwerkpfad, die gekapselte Infrastruktur und einen Produkttyp. Package Eine Zip- oder Tar-Datei, die eine Assembly beinhaltet. Produkt Ein Produkt ist ein Attribut einer Installation, welches durch den Produktnamen des Anbieters und die Versionsnummer gekennzeichnet ist. Beispiel für das Produkt-Attribut einer Installation wäre der Wert Artix 4.2. Service Contract Wird in einem WSDL-Dokument beschrieben und definiert ein Interface. Entspricht grundsätzlich den Definitionen und Zuordnungen zwischen Elementen und einem WSDL PortType. Seite 79 von 93

80 Benutzeroberflächen (+) Der Artix Registry/Repository Server verfügt ausschließlich über ein Konsolenfenster. Sämtliche Einstellungen, z.b. die Anpassung der Datenbank oder das Ändern des HTTP Listener Ports, müssen über eine Properties-Datei manuell konfiguriert werden. Der Artix Registry/Repository Client besitzt im Gegensatz zu vielen anderen Lösungen auf dem Markt keine Weboberfläche. Dafür wird ein komfortables und übersichtliches Eclipse-Plugin mitgeliefert, mit dem der Benutzer in einer gewohnten Umgebung Anfragen an den Server stellen kann. Das Eclipse-Plugin bietet dem Benutzer drei unterschiedliche Perspectives an, den Artix Repository Explorer, die Artix Repository Governance und die Artix Repository Infrastructure. Eine sogenannte Perspective entspricht dabei einer speziellen Sicht auf den Server. Mit dem Artix Repository Explorer können grundlegende Informationen vom Server abgefragt, neue Artefakte hochgeladen oder Datenbestände verändert werden. Die Artix Repository Governance dient zur Definition verschiedener Policy-Schablonen, Policy-Regeln und deren Zuweisung zu den jeweiligen Produkten. Mit der Artix Repository Infrastructure können Services auf verschiedenen Infrastrukturen eingesetzt (engl. deployed), angehalten und registriert werden. Die Benutzeroberfläche des Clients wurde elegant in die Eclipse-Umgebung eingebettet. Eine Weboberfläche mit vernünftigen Einstellungsmöglichkeiten für den Server wäre wünschenswert. Abbildung 2: Die Artix Repository Infrastructure -Perspective Versionsverwaltung der Artefakte (+) Von folgenden Artefakten kann eine neue Version erzeugt bzw. hinzugefügt werden: Service Providers, Service Consumers, Service-Templates, SOA Interface-Dokumente, Implementierungen, Infrastrukturen, Sonstige Dokumente, Policy-Templates, Regeln, Produkte und Assemblies. Im Normalfall erfolgt das Erstellen einer neuen Version über einen Eintrag im Kontextmenü des jeweiligen Artefakts, ansonsten über den Eclipseeditor. Alle Versionen eines Artefakts existieren Seite 80 von 93

81 parallel, d.h. ist es nicht notwendig, ältere Versionen wiederherzustellen. Alte Versionen werden nicht gesondert als veraltet markiert. Artix besitzt nur ein lineares Versionierungskonzept. Mehrdimensionale Versionierungen sind nicht möglich. Die Angabe einer Version geschieht im Format major.minor.micro.nano.qualifier, wobei bis auf den qualifier alles numerische Werte sein müssen. Eine Versionsangabe besteht mindestens aus dem major -Wert, muss aber nicht alle Elemente enthalten. Gültige Eingaben sind z.b. 1, oder 1.beta. Teilweise fügt Artix automatisch einen Verweis von der älteren auf die neuere Version und umgekehrt hinzu. Allerdings funktioniert dies nicht zuverlässig und sollte immer manuell kontrolliert und gegebenenfalls auch manuell angepasst werden (siehe Abbildung 3). Über die Verwendung von Assemblies ist es mit Artix auch möglich, Konfigurationen zu erstellen. Jede Assembly und damit jede Konfiguration kann aus verschiedenen Versionen der beteiligten Web Services, Consumer, usw. bestehen. Abbildung 3: Ansicht zum Anzeigen und Einfügen von neuen Versionen eines Artefakts Versionsverwaltung der Metadaten (n.v.) Eine Versionsverwaltung speziell für Metadaten ist nicht nicht vorhanden. Neue Versionen von Metadaten können höchstens über eine neue Version des gesamten Artefakts erzeugt werden. Änderungsrückverfolgbarkeit ( ) Für jedes Artefakt wird gespeichert, welcher Benutzer an welchem Datum die letzte Änderung durchgeführt hat. Detailiertere Informationen, z.b. welche Daten genau verändert wurden, oder eine ganze Änderungshistorie bietet Artix leider nicht an. Auch eine Protokollierung in Form einer Logdatei konnte in Artix Registry/Repository ohne die Verwendung von Artix ESB nicht gefunden werden. Hier sollte IONA in jedem Fall nachbessern und Artix zumindest eine Logdatei verpassen. Ohne vernünftige Protokollierung erschwert sich der Einsatz von Artix als Registry und Repository unnötig. Seite 81 von 93

82 Datenmodell ( ) Im Artix Repository können folgende Artefakte abgelegt werden: Service Providers Service Consumers Service Templates BPEL-Prozesse (ausschließlich *.bpr-dateien) SOA Interface Dokumente Service Implementierungen Infrastrukturen Policiy Templates Regeln Produkte Assemblies Installationen Service Containers Sonstige Dokumente Wizards gibt es für WSDL Services, BPEL-Prozesse, Artix Locator Services, Artix Router, Security Services, Policy Templates und Regeln. Dabei bieten die Wizards für WSDL Services auch das Kopieren bestehender Services und das Erstellen eines Services aus einem Template an. Einem Service Template können verschiedene Implementierungen zugeordnet werden (Artix unterstützt die Implementierung von Web Services über C++, JAX-RPC und JAX-WS). Jede Implementierung benutzt wiederum Resourcen (z.b. muss eine Java-Implementierung eines Web Service immer eine JAR-Datei verwenden). Sie werden im Repository als Sonstige Dokumente abgelegt. Einer Instanz eines Web Services können dann Endpunkte und Policies hinzugefügt werden. Beim Importieren und Erstellen von Web Services und Consumer werden diese automatisch der Assembly Unowned zugeordnet. Ein Service und Consumer können nicht ohne zugehörige Assembly bestehen. So umfangreich die Konfigurationsmöglichkeiten beim Einbinden von Web Services sind, so enttäuschend ist die fehlende Unterstützung für XML-, XSD- und XSLT-Dokumente, die nur als Sonstige Dokumente behandelt werden, wenn sie nicht indirekt über einen Web Service importiert werden. Außerdem fehlt ein klares Konzept zum Importieren von Artefakten. Teilweise können Daten über das Kontextmenü der Baumwurzel importiert werden, teilweise wird die Funktion nur im Kontextmenü des entsprechenden Taxonomieknotens angeboten. Seite 82 von 93

83 Abbildung 4: Der Import-Dialog von IONA Artix Registry/Repository Erweiterbarkeit (n.v.) Die vorhandenen Taxonomien wurden bereits unter dem Punkt Datenmodell behandelt. Leider bietet IONA Artix Registry/Repository keine Möglichkeit, die bestehenden Taxonomien zu erweitern, also z.b. eigene Taxonomien für XSD-Dokumente zu erstellen. Taxonomien (n.v.) Das Taxonomienkonzept von IONA Artix Registry/Repository ist nicht mit dem ähnlicher Produkte zu vergleichen. Artix gruppiert WSDL-Dateien, Consumers, Policies oder Rules in einer entsprechenden Baumstruktur, alle anderen Dokumente werden als Sonstige Dokumente angezeigt. Eine richtige Taxonomie, die auch entsprechend erweitert oder verändert werden kann, ist leider nicht vorhanden. Metadatenverwaltung ( ) Artix besitzt zwei Konzepte der Metadatenverwaltung: Tag-Collections und Attributdefinitionen. Tag-Collections sind eine Sammlung von Begriffen unter einem Oberbegriff. Attributdefinitionen sind eine Sammlung von Attributen, wobei ein Attribut aus einer Attributbezeichnung Seite 83 von 93

84 und einem entsprechender Wert besteht. Wichtig im Unterschied zu Attributdefinitionen ist, dass Tags keinen Wert besitzen. Standardmäßig existiert die Tag-Collection Platform mit den Tags HP-UX, AIX, Linux, SunOS und Windows. Einem Artefakt können nun solche Tags zugewiesen werden, z.b. das Tag HP-UX und Windows. Die Definition einer Attributdefinition erfolgt auf absolut gleiche Art und Weise, nur müssen bzw. können bei der Zuweisung eines Attributs zu einem Artefakt noch Werte eingegeben werden. Die Attributdefinition Kontaktinformation, die z.b. aus den Attributen Name, Telefon und besteht, kann also mit dem Inhalt Max Mustermann, und gefüllt werden. Unverständlicherweise können nicht jedem Artefakt Metadaten hinzugefügt werden. Interface- Dokumente und Sonstige Dokumente müssen ohne Metadaten auskommen. Die Metadatenverwaltung ist relativ simpel gehalten. So kann ein Attribut mit beliebig stupiden Werten, Zeichen oder Buchstaben gefüllt werden, weil der Inhalt syntaktisch nicht validiert wird. Eine Auswahlmöglichkeit zwischen verschiedenen vorgegebenen Werten wäre ebenfalls wünschenswert und existiert nicht. Datenspeicherung (+) Die Daten von Artix Registry/Repository werden in einer normalen Datenbank gespeichert. Standardmäßig wird eine Derby-Datenbank verwendet, Artix funktioniert aber auch mit einer Oracle- oder PostgreSQL-Datenbank. Governancefunktionen (++) Artix Registry/Repository verfügt über eine einzigartige Governancefunktion. Aus einer Assembly kann nur dann ein Paket erstellt werden, wenn die Artefakte der Assembly gültig sind, d.h. eine Governanceüberprüfung gültig war. Über einen grafischen Editor kann nicht nur eine Assembly von Grund auf erstellt werden (d.h. indem z.b. Services, Consumer und BPEL-Prozesse auf den Editor gedropt werden), sondern auch Beziehungen zwischen den Artefakten in einer Assembly definiert werden (dies kann größtenteils natürlich auch über textuelle Editoren der jeweiligen Artefakte geschehen). Bei Rechtsklick auf den Editor kann der Menüpunkt Run Governance Rules ausgeführt werden. Mögliche Governancefehler werden dann in der Eclipseumgebung sichtbar angezeigt. Die fehlerhaften Elemente können anschließend behoben und die Assembly einer erneuten Überprüfung unterzogen werden. Abbildung 5 veranschaulicht den grafischen Assemblyeditor mit einer ungültigen Governanceüberprüfung. Abfragen ( ) Es gibt zwei Möglichkeiten, die Registry nach ihrem Inhalt abzufragen. Eine Möglichkeit besteht über die gewöhnliche Eclipsesuche (siehe Abbildung 6). Hier kann das Repository neben der Eclipse typischen Dateisuche auch nach Artefakten durchsucht werden, denen bestimmte Tags zugewiesen wurden. Auch die Suche nach bestimmten Versionen eines Artefakts ist möglich. Allerdings ist diese integrierte Suchmöglichkeit noch stark verbesserungswürdig. Eine vernünftige Suche nach Artefakten ist nicht möglich, wenn man es nicht gerade auf Tags oder Alternativversionen abgesehen hat. Die zweite und weitaus bessere Möglichkeit der Abfrage bieten die UDDI Registries. Artix bietet die Möglichkeit, sehr schnell und unkompliziert eigene UDDI Registries zu erstellen, auf Seite 84 von 93

85 Abbildung 5: Eine fehlerhafte Governance-Überprüfung (siehe rote Markierungen) denen dann verschiedene Artefakte veröffentlich werden können. Leider bietet Artix kein eigenes Werkzeug zum Durchsuchen einer UDDI Registry an. Hierzu müssen externe Programme verwendet werden, die an UDDI Registries Anfragen stellen können. Beziehung von Artefakten ( ) Einige Artefakte bieten die Möglichkeit, gewisse Abhängigkeiten zwischen Dokumenten anzugeben. Eine allgemeine Angabe von Abhängigkeiten oder eine spezielle Semantik wie z.b. wird verwendet von oder implementiert existiert allerdings nicht. Folgende Abhängigkeiten können definiert werden, bzw. werden in der Regel auch automatisch erkannt, validiert und eingetragen: Ein Service Provider, ein Consumer und eine Assembly können eine Implementierung referenzieren Ein Service Provider, ein Consumer und eine Assembly können einen Container referenzieren Ein Service Provider, ein Consumer und eine Assembly können eine Policy referenzieren Seite 85 von 93

86 Abbildung 6: Das Durchsuchen der Registry wurde in die Eclipse-Suche integriert Ein Service Template kann einen Service Contract referenzieren Ein Service Template kann ein Dokument referenzieren Ein Service Template kann eine Implementierung referenzieren Ein Service Contract kann ein Dokument referenzieren Ein Service Contract kann einen Service referenzieren Eine Infrastruktur kann ein Dokument referenzieren Ein Interface-Dokument kann ein erforderliches Dokument referenzieren Ein Produkt kann ein Policy Template referenzieren Ein Produkt kann eine Regel referenzieren Ein Produkt kann ein Dokument referenzieren Ein Policy Template kann ein Produkt referenzieren Ein Policy Template kann ein Dokument referenzieren Eine Regel kann ein Policy Template referenzieren Eine Regel kann ein Dokument referenzieren Eine Assembly kann eine wiederverwendete Instanz referenzieren Eine Assembly kann ein Dokument referenzieren Die Abhängigkeiten der ersten Ebene werden textuell im jeweiligen Eclipseeditor angezeigt. Seite 86 von 93

87 Benutzerverwaltung (+) Die Benutzerverwaltung unterteilt sich in die Bereiche Benutzer, Rollen und Globale Aktionen. IONA Artix Registry/Repository erlaubt das Anlegen von beliebig vielen Benutzern, denen verschiedene Rollen zugewiesen werden können. Standardmäßig werden die Benutzer Administrator und Guest angelegt. Als Rollen gibt es den Infrastructure Developer, den Metadata Developer, den Network Developer, den Policy Developer, den Repository Administrator, den Repository Developer, Everyone und den Repository Viewer. Es können aber auch weitere Rollen erstellt und bestehende Rollen als Subrollen hinzugefügt werden. Eine jede Rolle wird sogenannten Globalen Aktionen zugeordnet, die die eigentlichen Lese- und Schreibrechte beschreiben und festlegen. Eigene oder neue Aktionen können nicht definiert werden, es müssen die vorgefertigten verwendet werden: Infrastructure Creation, Metadata Creation, Network Creation, ObjectACL Change, Password Change, Policy Creation, Repository Read, Security Change und Security Read. Für jedes Artefakt kann über den Punkt Security gesondert angegeben werden, welche Rollen welche Rechte für das Artefakt besitzen. Im Normalfall können hier Lese- und Änderungszugriffe für bestimmte Rollen aktiviert bzw. deaktiviert werden. Insgesamt lässt sich mit der Benutzerverwaltung sehr gut arbeiten. Lediglich eine Verwaltung von Gruppen ist nicht möglich. Lifecycle-Management ( ) Die Lifecycle-Fähigkeiten von Artix Registry/Repository sind sehr eingeschränkt. Artix Registry/Repository erlaubt nur die Definition von Statusnamen mit einem kurzen Beschreibungstext und kommt mit fünf vordefinierte Lebenszyklusstaten, Delivery, Design, Implementation, Operational und Test. Eine eigentliche Logik ist nicht enthalten, selbst Übergänge zwischen den Staten, eine Hierarchie oder eine Art Lifecycle-Workflow können nicht definiert werden. Jedem Artefakt oder Dokument im Repository kann höchstens ein Lebenszyklusstatus zugewiesen werden. Zweckmäßigkeit (+) Abgesehen von einer vernünftigen Protokollierung und einer Serveroberfläche verfügt Artix Registry/Repository über ein großes Potential für den Einsatz in einem Unternehmen. Insbesondere die Kombination von Repository, Governancefunktionen und der Möglichkeit, aus einer gültigen (bezüglich der Governance) Assembly heraus Pakete erstellen und diese direkt in einer Infrastruktur einsetzen (engl. deployen) zu können, ist einzigartig. Die wichtigesten Artefakte, wie WSDL-Dokumente und BPEL-Prozesse werden unterstützt. An der Unterstützung von XMLbzw. XSD-Dokumenten und an einem ausgereifteren und erweiterbaren Taxonomienkonzept muss noch gearbeitet werden. Auch die automatische Erkennung von Abhängigkeiten bedarf noch kleinerer Verbesserungen. Kontaktinformationen (n.v.) Es können zu keinerlei Artefakten oder Metadaten spezielle Kontaktinformationen oder Personen hinzugefügt werden. Höchstens mit der Verwendung von Artixs sogenannten Attribut- Metadaten können Kontaktinformationen nachgebildet werden. Seite 87 von 93

88 Benachrichtigungen (n.v.) Bei Veränderungen des Datenbestandes gibt es keine Möglichkeit, Benutzer oder Administratoren über diese Änderungen in Kenntnis zu setzen. Während ähnliche Produkte hier mit guten Lösungen und Benachrichtigungskonzepten glänzen, schenkt Artix dieser Form der Änderungsverfolgung keine Beachtung. Standards (++) Artix unterstützt die Anbindung an UDDI-Registries. Standardmäßig steht eine UDDI v2- Registry mit dem UDDI Publisher admin zur Verfügung. Relativ komfortabel und einfach lassen sich weitere UDDI v2 oder UDDI v3-registries mit neuen Inquire und Publish URLs definieren (siehe Abbildung 7). Jeder Service kann dann auf einer bestimmten UDDI Registry veröffentlicht (engl. publish) werden (oder diese Veröffentlichung auch zurückgenommen werden). Abbildung 7: Informationsseite der standardmäßig eingerichteten UDDI v2-registry Unterstützung von Single Sign-On (n.v.) Artix Registry/Repository bietet keine Unterstützung von Single Sign-On an, allerdings ist dies durch die Nutzung von Eclipse auch nicht unbedingt notwendig. Dokumentation (++) Die Dokumentation von IONA Artix Registry/Repository ist auf den Seiten von IONA Technologies gut versteckt. Wer sich aber die Mühe macht und die entsprechenden Dateien zusammensucht, kann auf eine ausführliche und mit zahlreichen Beispielen gespickte Dokumentation zurückgreifen. Alle Texte sind übersichtlich gestaltet und gut zu lesen. Neue Begriffe werden an den jeweiligen Stellen kurz erläutert. Ansonsten steht auch ein gesondertes Glossar zur Verfügung. Im Moment sind sämtliche Dokumente leider nur in englischer Sprache verfügbar. Der Übersicht halber ein kurzer Überblick über die vorhandenen Dokumente: Seite 88 von 93