Veröffentlichen und finden Sie UDDI-tModels mit JAXR und WSDL

Stellen Sie sich vor, Sie sind ein Reisebüro und buchen häufig Kreuzfahrturlaube. Um Ihren Kunden die Wahl zu bieten, müssen Sie eine aktuelle Liste exotischer Ziele führen. In der Vergangenheit hätten Sie diese Informationen sammeln können, indem Sie Verzeichnisse von Kreuzfahrtunternehmen abgerufen, die Website der einzelnen Unternehmen überprüft oder Kreuzfahrtunternehmen angerufen haben, um herauszufinden, welche Städte ihre Unternehmen bedienten.

Mit Webdiensten können Sie solche Listen automatisch erstellen und verwalten. Diese Bequemlichkeit ist mit zwei Anforderungen verbunden: Erstens müssen Kreuzfahrtunternehmen zustimmen, bei der Veröffentlichung ihrer Ziele eine gemeinsame Webdienstschnittstelle zu verwenden. Zweitens muss jedes Unternehmen diese Schnittstelle implementieren und ihre Implementierung in Webdienstregistern registrieren. Wenn diese Anforderungen erfüllt sind, können Sie Webdienstregister konsultieren, alle Instanzen von Kreuzfahrtzieldiensten ermitteln, jeden Dienst aufrufen und Ihre Masterliste für Kreuzfahrtziele erstellen.

Das Muster, alle Implementierungen einer Webdienstschnittstelle zu finden und möglicherweise diese Dienstinstanzen aufzurufen, erweist sich auch in anderen Kontexten als nützlich. Portal-Websites basieren weiterhin auf der manuellen oder halbmanuellen Zusammenstellung von Nachrichtenartikeln, Fahrzeuginventaren, verfügbaren Hotelzimmern oder Sitzplätzen von Fluggesellschaften. Selbst beim elektronischen Datenaustausch geht diese Automatisierung häufig zu Lasten einer langwierigen und teuren Systemintegration. Zu den größten Motivationen für den Aufbau von Webdiensten gehört der Wunsch, diese mühsamen Aufgaben zum Sammeln von Informationen zu automatisieren. Dieser Artikel enthält ein Beispiel dafür, wie UDDI-Registrierungen (Universal Description, Discovery and Integration), die Java-API für XML-Registrierungen (JAXR) und die Web Services Description Language (WSDL) zusammenarbeiten, um diese Automatisierung zu initiieren.

Verwenden Sie Ihre WSDL erneut

Derzeit arbeiten mehrere Branchengruppen daran, Standards für Webdienstschnittstellen zu definieren. Beispiele sind die Open Travel Alliance für Reisen, das Star Consortium für den Automobileinzelhandel und RosettaNet für das Supply Chain Management. Viele dieser Gruppen verwenden einen Community-orientierten Prozess und stellen ihre Spezifikationen jedem für Kommentare zur Verfügung.

Die realen Schnittstellenspezifikationen sollen umfassend und recht komplex sein. Um die Befolgung dieses Artikels zu vereinfachen, verwende ich eine einfache Schnittstellendefinition für den Beispiel-Webdienst für Kreuzfahrtschiffe. Diese Schnittstelle bietet nur eine einzige Methode. Wenn diese Methode aufgerufen wird, wird eine Liste der Ziele erstellt, die ein Kreuzfahrtunternehmen bedient. Hier ist diese Schnittstelle in Java:

öffentliche Schnittstelle CruiseService {public String [] cruiseDestinations (); }}

Da Webdienste darauf abzielen, programmiersprachenneutral zu bleiben, müssen wir diese Schnittstellendefinition in ein Format konvertieren, das nicht an Java gebunden ist. WSDL definiert eine Dokumentstruktur, die zur Beschreibung von Webdienstschnittstellen mit XML-Datenelementen geeignet ist. In meiner vorherigen Spalte " Webdienste" wurde gezeigt, wie Entwicklungstools wie Open Source Apache Axis eine Java-Schnittstelle in ein WSDL-Dokument konvertieren.

Wie aus Diskussionslisten zum Webdienst hervorgeht, diskutieren viele Entwickler die bessere Vorgehensweise: Definieren Sie zuerst die Schnittstelle Ihres Webdienstes mit Code, z. B. Java-Code, und konvertieren Sie diesen Code dann in WSDL-Definitionen, oder erstellen Sie zuerst die WSDL-Dokumente und konvertieren Sie diese dann Dokumente zu Java-Code. Das Finden der richtigen Methode hat möglicherweise mehr mit persönlicher Vorliebe zu tun als mit festen Regeln. Ich bevorzuge es, zuerst die Schnittstelle eines Dienstes in Java (oder einer anderen Sprache) zu definieren, da ich finde, dass eine auf Programmiersprachen basierende Definition ein klareres und einfacheres Bild der Funktionen eines Dienstes liefert. WSDL-First-Befürworter haben ebenfalls einen Punkt: Die Konvertierung von Java-Schnittstellen in XML-Strukturen ist keine exakte Wissenschaft und kann Feinheiten einführen, die zu überraschenden Ergebnissen führen.

Unabhängig davon, wie Sie ein WSDL-Dokument erstellen, besteht es aus sechs Elementtypen:

  1. definitions: Das Stammelement des WSDL-Dokuments enthält auch Namensraumdeklarationen und Zielnamen
  2. types: Datentypdefinitionen
  3. message: Nachrichtendefinitionen
  4. portType: eine Reihe von Operationen, die von den von diesen Operationen beschriebenen Diensten bereitgestellt werden
  5. binding: Vom Dienst angebotene Kabelprotokoll- und Nachrichtenformate
  6. service: Ports für die Nutzung des Dienstes, jeder Port möglicherweise mit mehreren Bindungen

Hier ist das gesamte WSDL-Dokument Apache Axis, das basierend auf der CruiseServiceSchnittstelle erstellt wurde. Um es besser lesbar zu machen, habe ich es nach den sechs wichtigsten WSDL-Elementen unterteilt:

  1. definitions (vorangestellt von Dokumentkopf):

  2. types:Dieses Element identifiziert zuerst den XML-Schema-Namespace. Der einzige hier definierte Typ ist ein String-Array für den Rückgabewert unserer Methode. Dieser Wert kann auch sein null. Die Deklaration des komplexen Typs dieses String-Arrays geht der Definition des Typs voraus:

  3. message:Es gibt zwei Nachrichten: eine Antwort und eine Anfrage. Die Antwort bezieht sich auf den Typ mit dem Namen ArrayOf_soapenc_string, der im vorherigen Element deklariert wurde. Da unsere Methode keine Parameter akzeptiert, ist die Anforderungsnachricht leer:

  4. portType:Der einzige hier definierte Porttyp ist benannt CruiseServiceund verarbeitet die zuvor definierten Eingabe- und Ausgabemeldungen:

  5. binding:Dieses WSDL-Dokument deklariert nur eine Dienstbindung. Diese Bindung ermöglicht den Zugriff auf den Dienst über SOAP (Simple Object Access Protocol). Die SOAP-Operation dieser Servicebindung entspricht der einzelnen Methode unserer Schnittstelle cruiseDestinations()und den Eingabe- und Ausgabeparametern dieser Methode:

  6. service:In diesem Abschnitt wird definiert, wo auf die im vorherigen Element definierten Portbindungen des Dienstes tatsächlich zugegriffen wird. In diesem Beispiel gibt es nur einen solchen Servicezugriffspunkt, der eine URL für den SOAP-basierten Port identifiziert:

Während die WSDL-Empfehlung Bindungen für SOAP, HTTP GET und POST sowie MIME (Multipurpose Internet Mail Extensions) definiert, ermöglicht ein WSDL-Dokument die Angabe eines beliebigen Bindungsmechanismus. Sie können beispielsweise einen Dienst definieren, der den Zugriff über die RMI / IIOP-Protokolle (Remote Method Invocation / Internet Inter-ORB Protocol) ermöglicht und den Dienstaufruf im RMI-Stil ermöglicht. Darüber hinaus können Sie Datentyp- und Nachrichtendefinitionen angeben, die nicht an das XML-Schema oder sogar an XML gebunden sind, und sich beispielsweise auf Java-Bytecode verlassen. Oder in einem Dienst sind möglicherweise zahlreiche Zugriffspunkt-URLs aufgeführt. Die erweiterbare Struktur von WSDL bietet diese Flexibilität.

Die Leistung von WSDL geht jedoch zu Lasten einer erhöhten Dokumentenkomplexität. Da viele WSDL-Elemente mehrere Werte annehmen können, kann die WSDL-Definition eines Webdienstes sehr umfangreich werden. Um die Notwendigkeit von Monster-WSDL-Dokumenten zu vermeiden, definiert die WSDL-Empfehlung einen importMechanismus:

Das WSDL- importElementinformationselement ermöglicht die Trennung der verschiedenen Elemente einer Dienstdefinition in unabhängige Dokumente, die nach Bedarf importiert werden können. Diese Technik hilft beim Schreiben klarerer Dienstdefinitionen, indem die Definitionen nach ihrem Abstraktionsgrad getrennt werden, und maximiert die Wiederverwendbarkeit.

Mit dem WSDL- importMechanismus können wir unser Service-WSDL-Dokument in mehrere logische Dokumente aufteilen. Bevor zu sehen , wie das funktioniert, beachten Sie, dass WSDL die importFähigkeit ist nicht ein includeMechanismus; Es ordnet einfach einen Namespace einem WSDL-Dokument zu. Ein Vorwort des Herausgebers in dem aktuellen WSDL Empfehlung Entwurf zeigt , wie die Unterscheidung zwischen importund includeviele Entwickler verwechselt hat:

Wir haben viele, viele Leute getroffen, die verwirrt darüber zu sein scheinen, wie importes funktionieren soll. Die Vorstellung, dass nur eine Beziehung zwischen einem Namespace und einem Ort hergestellt wird, ist anscheinend ziemlich schwer zu verstehen. Insbesondere die Tatsache, dass nichts darüber gesagt wird, was man über den Namespace an dieser Stelle finden kann, scheint sehr verwirrend zu sein.

WSDLs importfunktionieren ähnlich wie ein XML-Schemadokument auf einen Namespace außerhalb dieses Schemas verweisen kann. Sie haben bereits ein Beispiel für diese externe Namespace-Referenz im typesElement unseres WSDL-Dokuments gesehen . Dort haben wir den SOAP-Codierungs-Namespace importiert, damit wir unseren Rückgabearray-Typ mit einem SOAP-Codierungsmechanismus definieren können:

 ... ... 

WSDL's import allows us to split our CruiseService interface into a WSDL document that corresponds to the service's interface definition and another WSDL document corresponding to the service's implementation. Separating interface from implementation lets us reuse the service interface. If cruise companies agree to adhere to the reusable service interface, CruiseService, each company must only publish the implementation portion of their Web service description and declare that implementation's compliance with the CruiseService interface by importing the service interface's namespace. Figure 1 illustrates that process.

Our service interface WSDL document will include the definitions, types, message, portType, and binding elements. The service element, referring to a specific implementation, will form another WSDL document's content. The latter document must also reference the first document's namespace via WSDL's import statement.

Apache Axis's WSDL-generation tool, Java2WSDL, offers command-line parameters for splitting a WSDL definition into a WSDL service interface and implementation-specific WSDL documents. Given the original Java interface, CruiseService, the following command creates the WSDL service interface:

 java org.apache.axis.wsdl.Java2WSDL -o cruise_interface.wsdl -n urn:cruise -S CruiseService -w interface CruiseService 

The -o parameter specifies the output file's name; -n designates the WSDL namespace; -S provides the Web service interface's name; and -w interface signifies our interest in a service interface WSDL.

To create an implementation-specific WSDL, change interface to implementation for the -w option, specify a different output filename, and provide the service implementation's location:

 java org.apache.axis.wsdl.Java2WSDL -o cruise_implementation.wsdl -l //192.168.1.10:8080/axis/servlet/AxisServlet -n urn:cruise -S CruiseService -w implementation CruiseService 

Register WSDL interfaces as UDDI tModels

Je einfacher Sie sich über die Webdienstschnittstelle WSDL informieren können, desto wahrscheinlicher werden Unternehmen kompatible Implementierungen erstellen. Webdienstregister wie UDDI und ebXML erleichtern die Erkennung bekannter Dienste und deren Implementierung. Daher der nächste Schritt: Veröffentlichen Sie das Vorhandensein dieser Schnittstellen-WSDL in Webdienstregistern.