Vortragsausarbeitung. WSDL und UDDI. Werner Gaulke. Wintersemester 2006/07

Transkript

1 Praxisprojekt Modellgetriebene Entwicklung von Web-Anwendungen Fachgebiet Interaktive Systeme Wintersemester 2006/07 Vortragsausarbeitung WSDL und UDDI Werner Gaulke Wintersemester 2006/07 Universität Duisburg-Essen Abteilung für Informatik und angewandte Kognitionswissenschaft Arbeitsgruppe Interaktive Systeme Prof.Dr.-Ing. J. Ziegler betreut durch: Eike Lang Dipl. Inform.

2 Inhaltsverzeichnis 1 Einleitung 1 2 WSDL Über die Notwendigkeit einer Beschreibungssprache Was ist WSDL - Definition WSDL - Aufbau Das types-element Das message-element Das porttype-element Das binding-element Das port-element Das service-element WSDL Prinzip: Abstrakt zu Konkret WSDL Dokumente erstellen WSDL Vor- und Nachteile UDDI Über das Finden von Web Services Definition von UDDI Vergleich UDDI und WS Inspection Anforderungen an den Aufbau der UDDI UDDI Aufbau UDDI Datenmodell Aufbau businessentity businessservice bindingtemplate tmodel Überblick über das UDDI Datenmodell UDDI API Teile der UDDI API Charakteristik einer UDDI Suchanfrage UDDI Vor- und Nachteile Fazit 18 5 Literaturverzeichnis 19 i

3 1 Einleitung Web Services sind auf dem Vormarsch - unbemerkt von den Nutzern. Dies ist gewollt, denn Web Services arbeiten im Hintergrund. Web Services sind nicht direkt vom Benutzer ansprechbar, sie besitzen keine Benutzeroberfläche. Ihre Aufgabe besteht darin, eine Schnittstelle bereitzustellen, die Informationen oder Dienste offeriert. Diese Schnittstelle kann auf verschiedene Arten angesprochen und die übermittelten Daten genutzt werden. Ob es sich dabei um eine Desktop Anwendung oder Web Applikation handelt, ist hierbei egal. WSDL und UDDI spielen eine zentrale Rolle bei der Verwendung von Web Services. WSDL stellt eine Beschreibung des Web Services zur Verfügung, die das Nutzen des Services erlaubt. Es werden keine Detailinformationen oder Sourcecode des Services benötigt. Dies macht die automatisierte Nutzung erst möglich. Damit Web Services genutzt werden können, müssen sie gefunden werden. Es gibt verschiedene Methoden und Wege, um einen Service bekannt zu machen. UDDI ist einer davon. In der folgenden Ausarbeitung wird die Funktionsweise und der Aufbau von UDDI und WSDL näher gebrach, auch wird ein Blick auf die Verwendung in der Praxis geworfen. 1

4 2 WSDL 2.1 Über die Notwendigkeit einer Beschreibungssprache Das Konzept der Web Services ist auf kein Datenformat, Übertragungsformate oder eine Programmiersprache festgelegt. Jedes Format bringt Vor- und Nachteile mit sich. Die Wahl der Sprachen und Formate soll also frei bleiben, damit das Einsatzsspektrum sich nicht verkleinert. Damit dies erreicht werden kann muss sichergestellt werden, dass jeder Service eine Schnittstelle besitzt. Diese Schnittstelle muss so gestaltet werden, dass sie der Realisierung des Services keine Beschränkungen auferlegt. Weiterhin soll sich die Beschreibung nicht auf ein Format oder Protokoll festlegen. Eine Beschreibungssprache für Web Services muss also folgende Richtlinien einhalten: Keine Festlegung auf eine Programmiersprache Keine Festlegung auf ein Übertragungsprotokoll Keine Festlegung auf ein Datenformat Beschreibungsform in Maschinenlesbarer Form 2.2 Was ist WSDL - Denition WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. [4] WSDL steht für Web Service Description Language. Es ist ein Standard des W3C 1 zur Beschreibung von Netzwerkdiensten - in diesem Fall Web Services. Version 2.0 des Standards ist aktuell in Entwicklung. WSDL Beschreibungen werden in XML formuliert und bilden ein abstraktes Modell des Web Services. Operationen und Nachrichten werden abstrakt beschrieben. Erst bei einer konkreteren Betrachtungsweise werden diese Operationen und Nachrichten mit existierenden Protokollen und Formaten verbunden. Die Unterteilung in abstrakte und konkrete Sicht und die Verwendung von XML machen WSDL sehr flexibel. Dank XML können einfach weitere Namesräume eingebunden werden, welche die Sprache um 1 World Wide Web Consortium 2

5 2 WSDL weitere Beschreibungselemente erweitert. Damit hebt sich WSDL von herkömmlichen Interface Definition Languages ab, die in der Regel auf eine Programmiersprache beschränkt sind. 2.3 WSDL - Aufbau Ein WSDL Dokument beschreibt die verwendeten Datentypen, definiert Operation, Nachrichten und bindet das Ganze schließlich an konkrete Formate und Protokolle. Da die einzelnen Teile der Beschreibung aufeinander aufbauen ist das Dokument in sechs Teile unterteilt: types - Definiert die verwendeten Datentypen. message - Definiert die zu übertragenden Nachrichten abstrakt. porttype - Die porttyes setzen sich aus abstrakten Operationen zusammen und definieren damit eine abstrakte Schnittstelle. binding - Das binding verknüpft die abstrakte Schnittstelle an ein konkretes Datenformat und Protokoll. port - Das port-element weist einem binding-element eine konkrete Adresse zu. service - Bildet die nach außen zugänglichen Elemente eines Service durch mehrere Ports. Die einzelnen Elemente besitzen jeweils einzigartige Schlüssel (unique Keys), welche als Attribut im Namen des Elements angegeben sind. Die Schlüssel erlauben eindeutige Zuordnung der Bestandteile zueinander, ohne dass diese sich in einer Datei befinden müssen. Im Folgenden werden die einzelnen Elemente im Detail betrachtet Das types-element Mit dem types-element werden die verwendeten Datentypen definiert. Die definierten Datentypen werden bei der Nachrichtenübertragung verwendet. Mit dieser Möglichkeit können beliebige Strukturen eingeführt werden. Dies ermöglicht eine Unabhängigkeit, welche bei einem Set vordefinierter Typen nicht gegeben wäre. Zur Definition werden XML Schemata (XSD) verwendet. XSD ist Plattformunabhängig und definiert komplexe Datentypen mit Rückgriff auf vorhandene primitive Typen. Wesentliches Merkmal für die Verwendung von XSD ist hier, dass auch nicht XML Datentypen definiert werden können. Das Ergebnis der XSD Definition muss also nicht zwingend XML sein. Es kann allerdings vorkommen, dass die Möglichkeiten der XSD Definiton nicht ausreichen. Es gibt also Datentypen, die nicht mittels XSD ausgedrückt 3

6 2 WSDL werden können. Für diesen Fall besteht die Möglichkeit andere Grammatiken zur Typdefinition einzubinden. Dies geschieht über ein extensibility Element innerhalb der types Definition. 1 <w s d l : t y p e s> Listing 2.1: types 2 <xsd: schema targetnamespace=" URI "> 3 <! XSD T y p d e f i n i t i o n > 4 </ xsd: schema> 5 <! e x t e n s i b i l i t y Element f ü r weitere Grammatiken > 6 </ w s d l : t y p e s> Das message-element Im message-element werden die Nachrichten gebildet, mit denen ein Service kommuniziert. Die Definition erfolgt auf einer abstrakten Ebene. Das message Element ist damit losgelöst von konkreten Datentypen zu betrachten, was es allgemeingültig hält. Die Bindung an ein konkretes Format erfolgt später. Die Nachrichten selbst bestehen aus mehreren Teilen, den sogenannten part-elementen. In den einzelnen part-elementen der Nachricht wird angebeben, um welchen Datentyp es sich handelt. Auch hier wird wieder auf XSD zurückgegriffen. Neben den bereits in XSD definierten Datentypen, können auch die im types-element eingeführten verwendet werden. Dazu enthält das parts-element die Attribute element und type. Im Attribut element können die im types-element definierten Datentypen verwendet werden. Im Attribut type werden in XSD vorhandene Typen angegeben (z.b. XSD:String) Listing 2.2: message 1 <wsdl:message name=" namedernachricht "> 2 <w s d l : p a r t name=" bezeichnerdesparts " element=" XSD:Name " type=" XSD:Typ " /> 3 </ wsdl:message> Das porttype-element Das porttype-element ist eine Definition der Operationen. Die Operationen verwenden die zuvor eingeführten message-elemente. Die Definition befindet sich, wie beim message-element, auf einer abstrakten Ebene. Diese Operationen werden später an konkrete Formate gebunden. Auch wenn diese Art der Definition umständlich erscheint, erlaubt sie ein einfaches Wiederverwenden und Wiederbinden an beliebige Formate. Operationen bestehen aus Eingabe, Ausgabe und optional Fehlernachrichten. Die Ein- 4

7 2 WSDL und Ausgabenachrichten verweisen auf ein zuvor definiertes message-element und definieren damit das Nachrichenformat. Die Reihenfolge der Nachrichten legt ein primitives Transaktionsmuster fest: in One-way: Der Client sendet eine Eingabenachricht an den Service. in-out Request-response: Der Service bekommt eine Eingabenachricht und sendet eine Antwort an den Client. out-in Solicit-response: Service sendet eine Nachricht an den Client, die dieser beantwortet. out Notification: Der Service sendet eine Ausgabenachricht. Listing 2.3: porttype 1 <wsdl:porttype name=" portname "> 2 <wsdl:operation name=" operationname "> 3 <wsdl:input message=" messagename " /> 4 <wsdl:output message=" messagename " /> 5 <w s d l : f a u l t message=" messagename " /> 6 </ wsdl:operation> 7 </ wsdl:porttype> Das binding-element Das binding-element überführt die bisher abstrakten Definitionen in eine konkrete Form. Daten- und Protokollformat für Nachrichten und Operationen werden bestimmt. Die Wahl der Nachrichtenformates und Protokollle ist frei. In WSDL ist SOAP 2 als Nachrichtenformat und http 3 als Übertragungsprotokoll vordefiniert, es besteht aber die Möglichkeit beliebige Formate einzubinden. Ist ein Format gewählt, müssen die einzelnen Bestandteile der Operationen damit verbunden werden. Eine Bindung besitzt einen eindeutigen Namen und wird an ein porttype-element gebunden. Es sind mehrere Bindungen für ein porttype-element möglich. Dies erlaubt die Definition von mehreren Protokollen und Formaten für eine Operation. Im binding-element wird die zu übertragende abstrakte Operation mit Namen angegeben und mit Angabe des entsprechenden konkreten Elements des Datenformats an dieses gebunden. Ebenso werden die In-, Out- und Fehlernachrichten angegeben und mit dem entsprechdenden konkreten Gegenstück gebunden. Das Listing 2.4 bindet an das SOAP und HTTP Protokoll. Listing 2.4: binding 1 <wsdl:binding name=" bindingname " type=" t n s : p o r t T y p "> 2 Simple Object Access Protocol 3 Hypertext Transfer Protocol 5

8 2 WSDL 2 <soap:binding s t y l e=" document " t r a n s p o r t=" h t t p : // schemas. xmlsoap. org / soap / http " /> 3 <wsdl:operation name=" operationname "> 4 <s o a p : o p e r a t i o n soapaction=" h t t p : //www. b e i s p i e l. de/ makeoperation " /> 5 <wsdl:input> 6 <soap:body use=" l i t e r a l " /> 7 </ wsdl:input> 8 <wsdl:output> 9 <soap:body use=" l i t e r a l " /> 10 </ wsdl:output> 11 </ wsdl:operation> 12 </ wsdl:binding> Das port-element Ports stellen die Endpunkte eines Services dar, an denen dieser über eine URI aufgerufen werden kann. Ein port-element weist jeder definierten Bindung eine konkrete Adresse zu. Die Ports bilden die Zugriffspunkte, über die ein Service von außen erreichbar ist. Listing 2.5: port 1 <w sdl:port binding=" t n s : o p e r a t i o n D a t e n t y p " name=" name "> 2 <soap:address l o c a t i o n=" h t t p : //www. b e i s p i e l. de/ s e r v i c e " /> 3 </ w s dl:port> Das service-element Das service-element gruppiert zusammenhängende Ports. An dieser Stelle formt sich die Schnittstelle des Services nach außen. Die gruppierten Ports können nicht miteinander kommunizieren. 1 <w s d l : s e r v i c e name=" name "> Listing 2.6: port und service 2 <w sdl:port binding=" t n s : o p e r a t i o n D a t e n t y p " name=" name "> 3 <soap:address l o c a t i o n=" h t t p : //www. b e i s p i e l. de/ s e r v i c e " /> 4 </ w s dl:port> 5 </ w s d l : s e r v i c e> 2.4 WSDL Prinzip: Abstrakt zu Konkret Die Vielseitigkeit von WSDL Beschreibungen wird durch die Trennung des Dokumentes in drei Teile erlangt: Typdefinitionen, Abstrakt und Konkret. 6

9 2 WSDL types message porttype binding port&service Typ-Definitionen Abstrakte Nachrichten und Operationen Konkrete Formate und Protokolle Abbildung 2.1: Unterteilung von WSDL Dokumenten Diese Teilung ermöglicht es Datentypen, Operationen und Nachrichten so zu definieren, dass die Allgemeingültigkeit erhalten bleibt. Diese abstrakten Definitionen sind die Grundlage für die Verknüpfungen mit konkreten Formaten. Bei simplen WSDL Beschreibungen fällt dieser Vorteil nicht direkt auf. Einfache Dokumente benutzen oft nur bereits vorhandene XSD Datentypen und die Nachrichten bestehen in der Regel nur aus einem Parameter. Die abstrakte Definition erscheint Anfangs also unnötig, doch sobald die Definitionen umfangreicher werden, hilft die klare Trennlinie zwischen abstrakt und konkret. Solange abstrakt definiert wird, müssen keine Richtlinien für konkrete Datentypen beachtet werden. Erst wenn die abstrakte Definition in konkrete Formate umgewandelt werden soll, kommen deren Eigenschaften zum Tragen. Die Verwendung konkreter Formate geschieht durch verbinden beider Definitionstypen. Dabei können mehrere Bindungen für ein abstraktes Element erstellt werden. Nutzen mehrerer Übertagungsprotokolle oder Formate benötigt also kein neues WSDL Dokument, sondern lediglich eine weitere Bindung. Der Vorteil dieses Prinzips kommt bei der Spezifikation von Web Services zum Tragen. Die Spezifikation kann so lange rein abstrakt erfolgen bis Daten, Nachrichten und Informationen alle Anforderungen erfüllen. Die Überführung in die gewünschten Formate erfolgt aufbauend auf dieser Grundlage. Die abstrakte Definitionen bilden also eine universelle Grundlage. Damit wird für die Umsetzung jener Grad an Freiheit erreicht, der für Web Services erforderlich ist. 2.5 WSDL Dokumente erstellen Man unterscheidet zwei Vorbedingungen für die Erstellung von WSDL Dokumenten. Entweder wird die Beschreibung von Grund auf entworfen, um einen Web Service zu spezifizieren, oder für einen bereits vorhandenen Service wird ein WSDL Dokument generiert um diesen zu beschreiben. Die Spezifikation eines Web Services von Grund auf, wird als Bottom Up Methode bezeichnet. Hierbei wird eine Web Service Idee in eine WSDL Spezifikation umgesetzt. Diese Spezifikation kann nun dazu dienen, einen Web Service nach diesen Vorgaben zu implementieren. In gängigen Entwicklungsumgebungen sind Tools vorhanden, die aus WSDL Dokumenten Klassengerüste erstellen können. Das Erstellen von WSDL Dokumenten benötigt nicht mehr als einen Texteditor. XML Editoren oder grafische Mo- 7

10 2 WSDL dellierungstools verfügen natürlich über mehr Komfort. Im Anhang sind einige dieser Tools aufgelistet wie zum Beispiel [8]. Liegt als Grundlage ein bereits implementierter Web Service vor, kann aus diesem die Beschreibung generiert werden. Diese Vorgehensweise wird auch als Top Down Methode bezeichnet. Die Generierung der Dokumente ist über verschiedene Entwicklungstools und Frameworks möglich. Existiert also keine Vorgabe, wie die WSDL Schnittstelle aussehen soll, kann der Service direkt implementiert werden. Die Schnittstelle ergibt sich aus der Implementierung. Beide Ansätze integrieren sich also nahtlos in die Entwicklung, unterstützen und erleichtern diese. Je nach Verwendung wird der Entwurf oder die Verbreitung des Services unterstützt. 2.6 WSDL Vor- und Nachteile Mit WSDL wurde eine mächtige Sprache gewonnen, mit der Web Services beschrieben werden können. ES ergeben sich folgende Vor- und Nachteile: Vorteile: WSDL ist Plattformunabhängig, da es XML als Datenformat verwendet. XML macht es sowohl für die Maschine, als auch für den Menschen lesbar. Mit WSDL existiert eine Beschreibungssprache für Web Service Schnittstellen. Diese Schnittstellenbeschreibung ist Grundlage für Entwicklung und Einsatz der Services. Die Beschreibungen sind miteinander vergleichbar. Services mit identischen Schnittstellen und Operationen können einfach ausgetauscht werden. Eine abstrakte Grundlage erlaubt die Wahl von konkreten Datenformat und Protokoll. Dabei können mehrere konkrete Umsetzungen in einer WSDL Beschreibung angegeben werden. Nachteile: Es stehen nur einfache Interaktionsmuster bei der Definition der abstrakten Operationen im porttype-element zur Verfügung. Bei der Kommunikation ist keine Unterscheidung zwischen synchron oder asynchron möglich. Obwohl verschiedene Protokollverbindungen vorgesehen sind, können diese selbst eine unterschiedliche Semantik besitzen. Es sind keine Quality of Service Mechanismen integriert, welche Datenverlust oder Korruption handhaben. (Das bezieht sich nicht auf das verwendete Übertragungsprotokoll, welches durchaus derartige Mechanismen einsetzen kann) Keine Sicherheit/Verschlüsselung der übertragenen Daten. 8

11 3 UDDI 3.1 Über das Finden von Web Services Mit WSDL ist eine Grundlage vorhanden um Web Services einheitlich zu beschreiben und ohne Implementierungskenntnisse zu nutzen. Die WSDL Beschreibung versorgt den Anwender mit allen Informationen, die für den Einsatz notwendig sind. Doch um einen Service zu nutzen, muss bekannt sein, wo sich dieser befindet. Bei der lokalen Anwendung innerhalb einer Organisation, ist dies kein Problem. Sollen Services jedoch über das World Wide Web genutzt werden, muss eine Möglichkeit existieren Services aufzufinden. Doch nicht nur bereits bekannte Services wollen gefunden werden. Zahlreiche Anbieter machen ihre Services online verfügbar. Damit diese Services genutzt werden können, müssen sie von potenziellen Kunden gefunden werden. Große Organisationen haben genug Mittel um ihre Services bekannt zu machen. Kleine Unternehmen dagegen haben diese Möglichkeiten nicht. Es muss eine Möglichkeit geben das Internet nach existierenden Services zu durchsuchen. Mit herkömmlichen Suchmethoden und Suchmaschinen können keine zufriedenstellenden Ergebnisse erzielt werden. Es werden also Dienste benötigt, die ein gezieltes Suchen nach Web Services und deren Anbieter ermöglichen. WS-Inspection und UDDI sind zwei mögliche Herangehensweisen. Im folgenden werden die Unterschiede zwischen beiden Methoden aufgezeigt. Jedoch wird nur UDDI näher betrachtet und beschrieben. 3.2 Denition von UDDI UDDI steht für Universal Description Discovery & Integration. UDDI ist ein Verzeichnisdienst, der speziell für die dynamischen Aspekte der Katalogisierung von Web Services entworfen wurde. UDDI wird von der OASIS entwickelt, einem Zusammenschluss von Unternehmen, unter anderem von IBM, Microsoft, Oracle und SAP. OASIS steht für Organization for the Advancement of Structured Information Standards und ist eine (nicht gewinnorganisierte) Organisation, welche im E-Business und Web Services eingesetzte Standards entwickelt und vorantreibt. Februar 2005 wurde die, bis heute aktuelle, Version 3 der UDDI Spezifikation ratifiziert. Die UDDI erhebt den Anspruch die Anlaufstelle zu sein, um nach Webservices aller Art zu suchen und die passenden zu finden. 9

12 3 UDDI WS Inspection UDDI Nutzer Suchen UDDI Suchen Veröffentlichen Dienstanbieter Dienstanbieter Abbildung 3.1: Vergleich UDDI und WS-Inspection nach [1] Vergleich UDDI und WS Inspection UDDI und WS-Inspection sind zwei Möglichkeiten, Web Services zu entdecken. WS- Inspection sucht bei den Dienstanbietern nach verfügbaren Services. Jeder Dienstanbieter stellt einen Zugriffpunkt bereit, auf dem Informationen zu den eigenen angebotenen Services lagern. Die UDDI dagegen sucht nicht bei den Anbietern nach Services. Die UDDI stellt eine Art Schnittstelle zwischen Nutzern und Anbietern dar. Die Anbieter veröffentlichen ihre Services in der UDDI, welche von den Nutzern durchsucht werden. Die UDDI ist also eine zentrale Anlaufstelle zum Auffinden von Web Services, während WS-Inspection dezentral angelegt ist. Im Folgenden richtet sich der Blick auf das UDDI Konzept. 3.3 Anforderungen an den Aufbau der UDDI Die UDDI soll das suchen und finden von Web Services aller Art über eine Standardisierte Schnittstelle ermöglichen. Dabei soll der Zugang zur UDDI für alle Interessierten offen sein. Sowohl Menschen, als auch Maschinen sollen die UDDI verwenden können. Nach einer erfolgreichen Suche in der UDDI, erhält man schließlich die Beschreibung eines passenden Web Services. Dieser Web Service kann nun angesprochen und benutzt werden. Durch das Nutzen der UDDI und deren Ergebnisse in Form von Web Services stellen sich für den professionellen Anwender allerdings einige Fragen. Es stellen sich die Fragen nach Qualität, Abrechnung und Verantwortung über die gefundenen Web Services. Auch die Frage nach rechtlichen Modalitäten der Nutzung stellt sich, denn 10

13 3 UDDI Web Services sind über jegliche Ländergrenzen hinweg nutzbar. Das Bereitstellen fon Informationen über die Serviceanbieter kann einige dieser Fragen beantworten. Unterteilung der UDDI Neben dem reinen Auffinden von Web Services 1 muss die UDDI also auch alle relevanten Informationen über diesen bereitstellen. Um dies zu gewährleisten ist die UDDI in verschiedene Bereiche augeteilt, welche jeweils einen anderen Aspekt abdecken: White Pages: In den White Pages befinden sich Hintergrundinformationen über jene Firmen, die Web Services in die UDDI einstellen. Yellow Pages: Die Yellow Pages ordnet die Web Services nach Geschäftsfeldern an. Green Pages: Die Green Pages beinhalten Beschreibungen der Services, die für den Menschen lesbar sind. Service Type Registration: Maschinenlesbare Form der Web Service Beschreibung. 2 Die Unterteilung in diese Kategorien erlaubt nun Web Services auf drei Arten zu finden: 1. Der Benutzer sucht in den White Pages nach einem Unternehmen. Zu den Unternehmen sind Informationen und alle angebotenen Services gelistet. 2. Der Benutzer sucht in den Yellow Pages nach einem Service für eine spezielle Branche/Geschäftsfeld. Zu jeder Branche werden vorhandene Web Services aufgelistet. Von den gelisteten Services wird auf das Unternehmen verwiesen, dass diese anbietet. 3. Der Benutzer sucht in den Green Pages nach einem Web Service, der seinen Vorstellungen entspricht. Alle Web Services sind hier mit ihren Spezifikationen gelistet. Diese Suche kann auch ohne menschliche Eingriffe von der Maschine selbst erfolgen. Die UDDI erfüllt durch diese Aufteilung also die Anforderung, dass nicht nur über den Service selbst, sondern auch über die Anbieter dahinter informtiert wird. Nutzer der UDDI haben so vielfältige Möglichkeiten den gewünschten Service zu finden. Dabei spielt es keine Rolle, wie genau vorher klar ist, was für ein Service gesucht wird oder ob er von einem bestimmten Unternehmen sein soll. 1 Hinweis: Trotz der Möglichkeit jegliche Dienste zu verwalten, wird hier im speziellen die Bezeichnung Web Service verwendet 2 Green Pages und Service Type Registration verweisen aufeinander. 11

14 3 UDDI 3.4 UDDI Aufbau UDDI erhebt den Anspruch, ein universeller Verzeichnisdienst zu sein. Diesen Anspruch wird die UDDI gerecht, indem die Verwaltung nicht auf Web Services beschränkt ist. Prinzipiell kann die UDDI alles in ihr Verzeichnis aufnehmen, was über ein einheitliches XML-Datenmodell beschrieben werden kann. Dieses Datenmodell muss alle Fälle abdecken, die während der Verwendung auftreten können. Um die Daten der UDDI nun nutzen zu können, wird eine Schnittstelle benötigt. Diese Schnittstelle soll den Zugriff auf alle Funktionen ermöglichen, die nötig sind um die UDDI effektiv zu nutzen. Der Technische Aufbau der UDDI unterteilt sich also in: 1. UDDI Datenmodell: Das UDDI Datenmodell als XML-Schema. Das Datenmodell erfasst Web Services und darüber hinaus auch weitere Informationen über die Unternehmen/Anbieter der Dienste. Das Datenmodell ist so definiert, dass Verwaltung, Katalogisierung, Kategorisierung und Suche ermöglicht werden. 2. UDDI API: Die UDDI API ist die Schnittstelle für Anwendungen. Diese Schnittstelle ist selbst durch Web Services implementiert. SOAP wird zur Kommunikation genutzt. Die API bietet alle nötigen Funktionen, die zur Kommunikation mit der UDDI nötig sind. Dies sind Funktionen zur Suche, Veröffentlichung und Verwaltung von Verzeichnisdaten. 3.5 UDDI Datenmodell Aufbau Das Datenmodell der UDDI erfasst Informationen rund um Web Services. Neben den rein technischen Details werden auch die Daten festgehalten, die nötig sind, um die in 3.3 beschriebene Unterteilung in vier Bereiche zu ermöglichen. Dazu setzt sich das UDDI Datenmodell aus sechs Elementen zusammen: businessentity - hält Informationen über die Serviceanbieter fest. businessservice - beschreibt einen angebotenen Services eines Anbieters. bindingtemplate - enthält nähere Informationen zu einem Service tmodel - gibt eine technische Beschreibung eines Services an. operationalinfo - beschreibt Relationen zwischen mehreren Serviceanbietern. publisherassertion - verbreitet Informationen über Änderungen in der UDDI. Im Folgenden werden die einzelnen Elemente im Detail betrachtet. 12

15 3 UDDI businessentity Mit dem businessentity-elementwerden Organisationen modelliert. Dazu werden Namen, Beschreibung und Ansprechpartner festgehalten, sowie eine alternative URL, unter der die Beschreibung hinterlegt ist. Das Element businessservices enthält alle von der Organisation angebotenen Dienste. Listing 3.1: Beispiel businessentity 1 <b u s i n e s s E n t i t y businesskey=" U_Business_Key "> 2 <discoveryurls> 3 <discoveryurl usetype=" b u s i n e s s E n t i t y ">h t t p : // b e i s p i e l. de/ s? U_Business_Key</ discoveryurl> 4 </ discoveryurls> 5 <name>s e r v i c e a n b i e t e r XY</name> 6 <d e s c r i p t i o n xml:lang=" en ">Beschreibung der Organisation</ d e s c r i p t i o n> 7 <c o n t a c t s> 8 <c o n t a c t usetype=" Organisation_Kontakt "> 9 <personname>name e i n e r Kontaktperson</personName> 10 < usetype=" Organisation_Kontakt ">E Mail Adresse</ > 11 </ c o n t a c t> 12 </ c o n t a c t s> 13 <b u s i n e s s S e r v i c e s><! Die einzelnen S e r v i c e Elemente ></ b u s i n e s s S e r v i c e s> 14 </ b u s i n e s s E n t i t y> businessservice Das businessservice-element modelliert die von einer Organisation angebotenen Services. Mit einem businessservice-element wird eine Beschreibung eines Dienstes angeboten. Jeder beschriebene Service ist im Business Entity bei den businessservices aufgelistet. Die Beschreibung eines Dienstes definiert eine Art Produkt, welches selbst aus mehreren Services bestehen kann. Es handelt sich also nicht um eine technische, sondern um eine Produktbeschreibung. Für technische Details wird auf das bindingtemplate verwiesen. Listing 3.2: Beispiel businessservice 1 <b u s i n e s s S e r v i c e s e r v i c e K e y=" U_Service_Key " businesskey=" U_Business_Key "> 2 <name>a S e r v i c e</name> 3 <d e s c r i p t i o n xml:lang=" en ">Beschreibung</ d e s c r i p t i o n> 4 <bindingtemplates> 5 <! Binding Template f ü r den s e r v i c e > 6 </ bindingtemplates> 7 </ b u s i n e s s S e r v i c e> 13

16 3 UDDI bindingtemplate Das bindingtemplate gibt nähere Informationen zu einem Service und dessen Verwendung an. Dazu gibt es eine Beschreibung an, wie der Service angesprochen werden kann, sowie eine konrete URL, um den Service aufzurufen. Es ist außerdem ein tmodel- Element enthalten, welches maschinenlesbare Beschreibungen bereithält. Dazu mehr im nächsten Punkt. Das bindingtemplate stellt also die Verbindung zwischen der allgemeinen Beschreibung des Services im Element businessservice mit einer maschinenlesbaren Beschreibung im tmodel her. Zweck dieser Zwischenstufe ist es, einen Zugriffspunkt für den Service anzugeben und zu beschreiben welches Nachrichtenformat verwendet wird. Leser dieser Informationen können anhand der Konditionen entscheiden, ob der Service für die eigene Verwendung akzeptabel ist. Listing 3.3: Beispiel bindingtemplate 1 <bindingtemplate bindingkey=" U_BTemplate_Key " s e r v i c e K e y=" U_Service_Key "> 2 <d e s c r i p t i o n xml:lang=" en ">SOAP binding des S e r v i c e</ d e s c r i p t i o n> 3 <a c c e s s P o i n t URLType=" http ">h t t p : // b e i s p i e l. de:80 / soap</ a c c e s s P o i n t> 4 <t M o d e l I n s t a n c e D e t a i l s> 5 <tmodelinstanceinfo tmodelkey=" U_tModel_Key " /> 6 </ t M o d e l I n s t a n c e D e t a i l s> 7 </ bindingtemplate> tmodel Das tmodel gibt technische Details zu einem Service an. Die Details sind nicht in dem tmodel selbst enthalten, sondern es zeigt auf eine hinterlegte Beschreibungsdatei. Neben dem Verweis auf die Beschreibung wird auch angeben, in welchem Format diese erstellt ist. Dazu wird in der categorybag ein Verweis auf die Spezifikation der verwendeten Beschreibungssprachen hinterlegt. Typischerweise wird WSDL für die Beschreibung verwendet, aber theoretisch ist jede andere Beschreibungssprache ebenfalls möglich. Dies unterstreicht, dass die UDDI nicht nur für Web Services geeignet sein soll. 1 <tmodel tmodelkey=" U_tModel_Key "> 2 <name>name des S e r v i c e s</name> Listing 3.4: Beispiel tmodel 3 <d e s c r i p t i o n xml:lang=" en ">I n t e r f a c e / Beschreibung des S e r v i c e s.</ d e s c r i p t i o n> 4 <overviewdoc> 5 <d e s c r i p t i o n xml:lang=" en ">Beschreibungsdatei des S e r v i c e ( h i e r WSDL)</ d e s c r i p t i o n> 6 <overviewurl>h t t p : //www. b e i s p i e l. de/ tmodels / s e r v i c e. wsdl</ overviewurl> 14

17 3 UDDI 7 </ overviewdoc> 8 <categorybag> 9 <keyedreference tmodelkey=" uuid:c1acf26d d70 39 b756e62ab4 " keyname=" uddi o r g : t y p e s " keyvalue=" wsdlspec " /> 10 </ categorybag> 11 </ tmodel> operationalinfo und publisherassertion Das Element operationalinfo beschreibt Relationen zwischen einzelnen businessentitys in der UDDI. So können Beziehungen zwischen Organisationen und deren Projekten ausgedrückt werden, ohne dass extra neue businessentitys modelliert werden müssen. Publisher Assertion verbreitet Änderungen in der UDDI Überblick über das UDDI Datenmodell Die Elemente des UDDI Datenmodells bilden zusammenhängend eine umfassende Beschreibung der relevanten Informationen über einen Service. Sowohl Serviceanbieter, als auch Services werden so erfasst, dass eine detailierte Suche in der UDDI ermöglicht wird. Die Unternehmen werden als businessentity dargestellt, welches eine Liste von angebotenen Services enthältw. Einzelne Services werden in businessservice beschrieben. Das tmodel gibt schließlich durch eine technische Beschreibung 3 an, wie der Service verwendet werden kann. Anschaulich ist das Ganze in Abbildung 3.2 dargestellt. businessentity tmodel businessservice bindingtemplate Abbildung 3.2: Beziehungen der Elemente im UDDI Datenmodell nach [1] 3.6 UDDI API Die UDDI macht die Daten des Datenmodells nutzbar. Kernbereiche der API sind das pflegen, verwalten und durchsuchen der eingestellten Informationen. Der Zugriff auf 3 bzw. deren Verweis 15

18 3 UDDI die Funktionen wird selbst wieder über einen Web Service realisiert. Die Schnittstellenbeschreibung der UDDI API erfolgt durch WSDL. Es wird also konsequent auf die eingeführten Standards gesetzt Teile der UDDI API Die UDDI API ist in mehrere Elemente aufgeteilt. Jeder Teil erfüllt einen speziellen Aufgabenbereich. Es existieren folgende Teile: Inquiry API: In der Anfrage API sind alle Funktionen und Methoden zur Suche in der UDDI enthalten. Publication API: Die API zur Veröffentlichung bietet Serviceanbietern alle nötigen Funktionen, um Services und Informationen zum Unternehmen einzustellen. Security API: Die Sicherheits API stellt Funktionen zur Autorisierung und Authentifizierung der Benutzer und Serviceeinsteller bereit. Custody Transfer API: Sind mehrere UDDI Server vorhanden (zwecks Redundanz für Sicherheit) ermöglicht diese API Transfer von Daten zwischen den Servern. Subscription API: Erlaubt den Nutzern bestimmte Einträge der API zu abonnieren und bei Änderungen benachrichtigt zu werden. Replication API: Vervielfältigt die Knoten zwischen den UDDI Servern Charakteristik einer UDDI Suchanfrage Selten endet eine Suchanfrage mit dem gewünschten Resultat. Oft müssen die Suchparameter Schritt für Schritt verfeinert werden. Bei der Suche in der UDDI ist dies auch der Fall. Abbildung 3.3 zeigt den typischen Ablauf einer Anfrage an die UDDI. Im ersten Schritt werden mit den angebotenen find Funktionen Suchparameter an die UDDI geschickt, welche Ergebnislisten zurücksendet. Soll nun ein Service oder Unternehmen näher betrachtet werden, können mit den get Funktionen Details angefordert werden. Hat der Suchende sich für einen Service entschieden, kann er aus diesen Details im dritten Schritt den Web Service kontaktieren. 3.7 UDDI Vor- und Nachteile Mit UDDI wurde ein Verzeichnisdienst geschaffen, der eine Verbreitung von Web Services über alle Grenzen hinweg ermöglicht. Ungeachtet, ob der Service von einer großen Organisation oder einem kleinen Unternehmen entwickelt wurde. Vorteile: 16

19 3 UDDI Client UDDI Web Service find(param) Ergebnis 1. Schritt Suchanfrage an die UDDI mit schrittweisem verfeinern der Parameter. get(bindingkey) Servicedaten Aufruf(param) Antwortdaten 2. Schritt Anfordern von Details über den gewählten Service. 3. Schritt Nutzen der Service- Informationen zur Anfrage. Abbildung 3.3: Ablauf der Kommunikation in der UDDI nach [1] Gezielte Suche nach Services wird ermöglicht. Informationen zu Service und Serviceanbietern sind vorhanden. Datenmodell der UDDI erlaubt Informationen über Branche, Service und Organisation. Es werden offene Standards verwendet, welche an neue Anforderungen einfach anzupassen sind. Es sind Funktionen für das Verteilen der UDDI Daten auf andere Server vorhanden um ein stabiles Netz zu garantieren. Nachteile: Die Daten der UDDI müssen gepflegt werden. Es kann immer vorkommen, dass Services nicht mehr erreichbar sind, Firmen vom Markt verschwinden oder ähnliches. Bei offenen UDDIs, die für alle zugänglich sind, kann sich jeder als Unternehmen ausgeben. Niemand garantiert für die Qualität und Erreichbarkeit der Services. 17

20 4 Fazit Durch WSDL und UDDI wurden zwei Mechanismen gewonnen, die maßgeblich an der Verbreitung von Web Services teilhaben. WSDL ermöglicht die Freiheit über jegliche Grenzen von Programmiersprachen, Datenformaten und Protokollen hinweg Web Services so zu beschreiben, dass diese in nahezu jedem Kontext verwendet werden können. Die Beschreibunssprache ist sowohl Maschinen- als auch Menschenlesbar und in XML definiert, was das Verwenden bereits vorhandener Verarbeitungstechnologien ermöglicht. Im Rahmen dieser Ausarbeitung wurde der Aufbau einer WSDL Beschreibung betrachtet. Es wurde gezeigt, aus welchen Elementen ein WSDL Dokument besteht und in welcher Beziehung diese zueinander stehen. Beispiele zu jedem Element geben eine Vorstellung, wie das ganze in der Praxis aussieht. Eine komplette Anleitung, wie WSDL in der Praxis zu nutzen ist, kann diese Ausarbeitung nicht geben, dazu sei auf die ausführlichen W3C Dokumentationen verwiesen [3]. Auch ein Experimentieren mit den Eclipse Web Tools kann sehr aufschlussreich sein. Mit einer mächtigen Beschreibungssprache im Repertoire lag es nahe, diese Beschreibungen zu sammeln und durchsuchbar zu machen. UDDI ist ein Ansatz, wie Web Services in einem Verzeichnis verwaltet werden. Doch reine WSDL Dokumente genügen nicht in der Praxis, Kontextinformationen sind nötig. Das vorgestellte UDDI Datenmodell ist dieser Aufgabe gewachsen, es sammelt alle Informationen, die bei der Suche helfen können. Zusammen mit der API kann effektiv in der UDDI gesucht werden. Auch hier sei darauf hingewiesen, dass diese Ausarbeitung nur einen kleinen Einblick in das Datenmodell und die API geben kann. Für erste Experimente sei der UDDI Browser empfohlen. Die Dokumentation der UDDI [6] gibt detailliert Aufschluss, welche Funktionen wie verwendet werden können. Zusammen mit diesen Grundlagen steht dem effektiven Einsatz dieser Technologien also nichts mehr im Wege. 18

21 5 Literaturverzeichnis [1] W. Dostal, M. Jeckle, I.Melzer, B. Zengler Service-orientierte Architekturen mit Web Services [2] Distributed Systems Concepts and Design 2005, George Coulouris, Jean Dollimore, Tim Kindberg [3] Web Services Working Group [4] WSDL 1.1 Spezifikation [5] OASIS [6] UDDI Spezifikation Version 3 der OASIS. [7] Einfacher online UDDI Browser [8] Eclipse Web Tools Platform 19