LösungenWebservicesProfil Webservices

Ein erfolgreiches und innovatives Unternehmen mit mehreren Produktlinien und unterschiedlichen Entwicklungszyklen benötigte eine Methode, um das gesamte Unternehmen über alle Features der neuesten Produktversionen immer auf neuestem Stand zu halten.

Das Produktmanagement-Team bei Altova erstellte eine Datenbank für Produktinformationen, über die die verschiedenen Abteilungen (Verkauf, Support, Buchhaltung usw.) jederzeit Informationen zu jedem beliebigen Altova-Produkt abrufen konnten. Als ideale Methode, um die Daten abteilungsübergreifend überall in der Firma zur Verfügung zu stellen, erwies sich ein Webservice im Firmen-Intranet.

Die Implementierung des Webservice wurde einem Applikationsentwickler übertragen, der als Endbenutzer mit Altova-Tools arbeitet.

Im Rahmen der Projektanalyse wurden sechs Aufgabenpunkte bzw. Fragestellungen ermittelt, die hier nach Schwierigkeitsgrad - vom einfachsten bis zum zeitaufwändigsten - gereiht sind:

F: Welchen Namen soll der Webservice erhalten?

Als Name für den Webservice wurde altovaCatalog gewählt

F: Wo soll der Webservice laufen?

Der Webservice wird in einem hausinternen Serververzeichnis namens /services/altovaCatalog angelegt werden.

F: Wie soll die Client-Kommunikation mit dem Webservice erfolgen?

Die Webservice Client-Applikationen werden SOAP- / RPC-codierte Messages senden und empfangen. Für den Anfang wird die Webservice-Kommunikation mit dem Endbenutzer über einen Webbrowser erfolgen, doch können zu einem späteren Zeitpunkt andere Client-Applikationsarten hinzugefügt werden.

F: Welche Operationen soll der Webservice ausführen?

Es wurden drei Operationen ausgewählt: Abrufen einer Liste von Produktkategorien, Anzeigen einer Liste von Produkten in einer Kategorie und Anzeigen von detaillierten Informationen zu einzelnen Produkten.

F: Welche Parameter werden für die einzelnen Operationen als Input benötigt und was soll als Ergebnis zurückgegeben werden?

Abrufen einer Kategorieliste - dies ist eine Abfrage ohne Parameter, die eine Liste der in der Datenbank definierten Kategorien zurückgibt.

Anzeigen einer Liste innerhalb einer Kategorie - der Input-Parameter ist der Kategoriename, das Ergebnis ist eine Produkttabelle für diese Kategorie.

Anzeigen der Informationen zu einzelnen Produkten - der Input-Parameter ist ein Produkt SKU, die Antwort ist eine in der Datenbank gespeicherte detaillierte Produktbeschreibung.

F: Welche Datentypen oder Datenstrukturen werden von den einzelnen Input- und Output-Parametern benötigt?

Die Datentypen sollen auf der Struktur der bestehenden Datenquelle basieren.

Zum Definieren der Funktionalität des Webservice wurde eine WSDL-Datei benötigt. Diese WSDL-Datei sollte ein Schema enthalten, in dem die Datenstrukturen, die von Webservice-Abfragen und Antworten übergeben werden, identifiziert werden. Mit Hilfe von Altova XMLSpy wurde eine Verbindung zur Datenbank hergestellt, in der die Produktinformationen gespeichert sind und es wurde automatisch ein XML-Schema generiert, welches anschließend für den Webservice optimiert wurde.

Zur Auswahl des RPC Message-Stils mussten die Schema-Komponenten als Typen und nicht als Elemente definiert werden, und die in den SOAP Messages zu übergebenden Parameter mussten in der Schema-Hierarchie als globale Komponenten strukturiert werden. Dies ließ sich in XMLSpy mit wenigen Mausklicks bewerkstelligen.

Schema für die in der Datenbank gespeicherten Produktinformationen, das für den Webservice optimiert wurde

Nach Fertigstellung des optimierten Schemas erstellte der Entwickler über die XMLSpy Menüoption Datei / Neu eine neue WSDL-Datei, die er in das Schema einfügte. Als nächstes wurden die Services, Bindings und Operationen mit ihren jeweiligen Inputs und Outputs im XMLSpy WSDL Designer definiert. Die Arbeit erfolgte in der graphischen Ansicht, in der die Struktur des Webservice klar zu erkennen ist, während XMLSpy im Hintergrund automatisch eine WSDL-Datei mit über 175 Zeilen (mehr als 7.000 Bytes) erzeugte, die jederzeit durch Wechseln in die Textansicht überprüft werden konnte.

Mit Hilfe der Kontextmenüs, Eingabehilfen und Drag and Drop-Methode konnten die Komponenten in XMLSpy miteinander verbunden werden, Bearbeitungen konnten direkt im Diagrammfenster und im Fenster "Eigenschaften" vorgenommen werden, so dass die WSDL-Datei direkt im visuellen Editor erstellt werden konnte. Features ließen sich problemlos in jeder beliebigen Sequenz hinzufügen, ohne dass sich der Entwickler mit der mühsamen WSDL-Syntax herumschlagen musste.

Graphische Ansicht der fertigen WSDL-Datei in XMLSpy.

Als nächstes wurde über das XMLSpy-Menü "SOAP" ein SOAP Request der WSDL-Datei für jede der drei Operationen erstellt. Dazu wurden die Operationen einfach aus einer Liste in einem Dialogfeld ausgewählt, der Rest wurde von XMLSpy erledigt. Die SOAP Requests wurden zum späteren Testen und für die Erstellung des Browser-basierten Webservice Clients als XML-Dateien gespeichert.

Nach Lösung aller sechs Aufgabenstellungen, hatte der Entwickler nun eine komplette WSDL-Datei für den Webservice zur Verfügung. Als nächstes wurde Implementierungscode benötigt, der auf einem Webserver kompiliert und zur Verfügung gestellt werden konnte. Zu diesem Zweck startete der Entwickler MapForce und wählte die Option zum Erstellen eines neuen MapForce Webservice-Projekts auf Basis der WSDL-Datei.

Mit Hilfe von MapForce wurden die Tabellen und Felder in der Produktdatenbank auf visuelle Art mit den im XML-Schema der WSDL-Datei definierten Input- und Output-Parametern der einzelnen Webservice-Operationen verbunden. Mit Hilfe der MapForce-Funktionsbibliothek ließen sich mühelos Boole'sche Bedingungen definieren, um einen Parameter in einem Webservice Request einem Feld in der Datenbank, wie z.B. einer Produktkategorie oder einem einzelnen Produkt zuzuordnen.

MapForce Mapping für die Operation getProductsByCategoryID. Die Datenbank wird in der linken oberen Ecke angezeigt, die Input Message in der linken unteren Ecke und die Antwort des Webservice auf der rechten Seite.

Mit Hilfe des integrierten MapForce-Prozessors wurden die Mappings noch während der Erstellung getestet. Dazu musste nur die zuvor in XMLSpy gespeicherte SOAP Request XML-Datei als Input für die Operation zugewiesen werden. Dies erfolgte durch Rechtsklick und Eingabe des Dateipfads im Dialogfeld "Komponenteneinstellungen". Bei Klick auf das MapForce Register "Ausgabe-Vorschau" unterhalb des Mapping-Fensters wurde die Request-Beispieldatei so verarbeitet, als handelte es sich um eine SOAP Message, die Datenbank wurde mit Hilfe der in der Request-Datei enthaltenen Parameter abgefragt und das Ergebnis, die SOAP Response, wurde im XML-Format angezeigt. Dank dieses Verfahrens konnte die Entwicklung enorm beschleunigt werden, da kein Programmquellcode geschrieben, kompiliert oder bereitgestellt werden musste, um die Funktionsfähigkeit einer Webservice-Operation zu testen.

Nachdem alle drei Operationen gemappt worden waren, wurde durch Auswahl der MapForce Menüoption "Code generieren" der für die Implementierung benötigte Quellcode automatisch erzeugt. MapForce generiert das gesamte Quellcodeprojekt einschließlich der Build-Dateien in Java oder C# sowie der Deploy- und Undeploy-Skripts für den Webserver.

Der Service sollte auf einem Apache Webserver laufen, daher entschied man sich für die Generierung von Java-Quellcode. Anschließend wurden die von MapForce erstellten ANT Scripts zur Kompilierung und Bereitstellung des Codes ausgeführt.

Sobald der Webservice auf dem Server ausgeführt wurde, musste vor Erstellung des HTTP Client das Deployment getestet werden. Über das XMLSpy-Menü "SOAP" wurden SOAP Requests an den Webservice gesendet und die Antworten wurden überprüft. Auf diese Art lässt sich testen, ob der Webservice selbst - unabhängig von der Client-Applikation - ordnungsgemäß funktioniert.

Das XMLSpy-Menü "SOAP"

Zum Schluss werden mittels der ASP Skriptsprache die Webseiten für die Webservice Client-Schnittstelle erstellt. In XMLSpy wurde schließlich ein XSLT Stylesheet erstellt, um die XML-Antworten des Webservice in ansprechende HTML-Seiten zu transformieren, die im Webbrowser angezeigt werden.

Der fertige Webservice arbeitet folgendermaßen:

• Ein Benutzer öffnet eine URL, die den Webservice nach einer Liste von Kategorien abfragt, die anschließend links oben im Browser-Fenster angezeigt werden.
• Wenn er auf einen Kategorienamen klickt, wird eine Tabelle angezeigt, in der alle Produkte in der Datenbank angezeigt werden, die dieser Kategorie angehören.
• Bei Anklicken eines Produkts in der Tabelle wird von SKU eine Abfrage nach Produktinformationen abgesendet, die anschließend anstelle der Tabelle angezeigt werden.

Browser-Ansicht der Produkte in der Kategorie "Software"

Bald zeigte sich auch ein entscheidender Vorteil der Webservice-Implementierung, als ein Produktmanager zur Beschreibung neuer Funktionen in der neuesten Produkt-Release eine neue Kategorie zur Datenbank hinzufügte. Da die neue Kategorie neue Informationen zur Datenbank hinfügte, die zugrunde liegende Datenstruktur dadurch aber unverändert blieb, und da der Webservice so ausgelegt war, dass bei jeder Ausführung eine Liste der Kategorien abgerufen wird, musste der Webservice nicht adaptiert werden und die neuen Informationen standen sofort firmenweit zur Verfügung.

Browser-Ansicht einer Produktinformationsseite. Beachten Sie die neue Kategorie links oben.

Um den altovaCatalog Webservice online bereitszustellen, sendete der Produktmanager einfach eine E-Mail-Ankündigung an die jeweiligen Abteilungen. Die E-Mail enthielt einen Link zur anfangs angezeigten Produktkategorieliste, über die die Katalogdaten sofort abrufbar waren.

Nähere Informationen dazu, wie Sie mit Hilfe von Altova-Lösungen Ihre eigenen Webservices erstellen können, finden Sie unter den folgenden Links:

• Lesen Sie mehr über Webservice-Funktionen von XMLSpy® 2008 und MapForce® 2008
• Hier sehen Sie eine Flash Demo zur Erstellung von Webservices mit Hilfe von XMLSpy und MapForce
• Lesen Sie unser Whitepaper über Webservices mit dem Titel: Web services: Benefits, challenges, and a unique visual development solution
• Verwenden Sie die Webservice-Funktionen in XMLSpy, um eine Verbindung als Client mit einem bestehenden Webservice herzustellen
• Downloaden Sie jetzt eine kostenlose 30-Tage-Testversion des Altova® MissionKit™ 2008!