Richtlinie: Web-Services entwickeln
Diese Richtlinie beschreibt, wie Web-Services mittels der Modellierumgebung RAD 6.0 erkannt, erstellt, getestet, implementiert und publiziert werden.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

RAD 6.0 stellt eine umfangreiche Gruppe von Tools zum Erkennen, Erstellen, Testen, Implementieren und Publizieren von Web-Services bereit. Sie erlauben die Entwicklung von Web-Services auf der Basis der neuesten Standards und unterstützen die Implementierung in mehreren Laufzeitumgebungen. Außerdem stellen die Tools viele Assistenten bereit, die die unterschiedlichen Entwicklungsstrategien unterstützen und vereinfachen. Dieses Dokument beschreibt die verschiedenen von RAD 6.0 bereitgestellten Strategien zur Entwicklung eines Web-Service und erörtert die Aspekte, die bei der Entwicklung bezüglich der Web-Service-Implementierung und der Interoperabilität beachtet werden müssen.

Entwicklungsstrategien

Die Web-Services-Assistenten in RAD 6.0 ermöglichen das Erstellen eines Web-Service mittels einer Top-down-Strategie oder mittels einer Bottom-up-Strategie. Die Top-down-Entwicklung erlaubt es Ihnen, ein WSDL-Dokument (Web Services Description Language) als Ausgangsbasis zu verwenden und entweder eine Skeleton-Java-Bean oder eine Skeleton-EJB (Enterprise JavaBean) zu generieren, mit der ein Web-Service erstellt werden kann. Die Bottom-up-Entwicklung erlaubt es Ihnen, einen Web-Service aus einer vorhandenen Java-Bean, EJB, DADX-Datei (Document Access Definition Extender), einem URL (Uniform Resource Locator) oder einer ISD-Datei (Web Service Deployment Descriptor) zu erstellen. Abbildung 1 zeigt die von RAD 6.0 unterstützten Strategien zum Erstellen von Web-Services.

Strategien zum Erstellen von Web-Services in RAD 6.0

Abbildung 1 - Strategien zum Erstellen von Web-Services in RAD 6.0

Während der Erstellung eines Web-Service bietet der Assistent wahlweise folgende Möglichkeiten:

  • Test des Web-Service, sobald er mit dem Tool Web Services Explorer erstellt wurde.
  • Generierung eines Client-Proxy, der in Clientanwendungen für den Zugriff auf den Web-Service verwendet werden kann.
  • Test eines Client-Proxy mit dem Tool Universal Test Client (UTC) oder mit einer JSP-Beispielanwendung, die vom Tool generiert wird.
  • Publizieren des Web-Service in einer UDDI-Registry (Universal Description, Discovery and Integration) mit dem Tool Web Services Explorer.

Web-Services, die in RAD 6.0 entwickelt werden, müssen in einem Web- oder EJB-Projekt erstellt worden sein und Arbeitsergebnisse enthalten, die mit folgenden Standards übereinstimmen:

  • Web Services Definition Language (WSDL) Version 1.1
  • Simple Object Access Protocol (SOAP) Version 1.1 (einschließlich der Implementierungen von Apache SOAP 2.2 und 2.3)
  • Universal Description, Discovery and Integration (UDDI) Version 2.0
  • Web Services Inspection Language (WSIL) Version 1.0
  • Java API for XML-based Remote Procedure Call (JAX-RPC), auch als JSR-101 bekannt
  • JSR-109 und JSR-921 (mit Implementierung von Enterprise Web Services)
  • Web Services Interoperability (WS-I) Basic Profile 1.0 (optionale Konformität)
  • WS-Security

Nähere Informationen zu diesen Themen finden Sie unter "Konzepte: Web-Services für J2EE".

Top-down-Entwicklung

Die Top-down-Entwicklung ermöglicht es, die abstrakte Definition eines in einem WSDL-Dokument enthaltenen Web-Service zu verwenden und dafür eine konkrete Implementierung zu generieren. (Anmerkung: RAD 6.0 stellt außerdem einen Assistenten zum Erstellen eines WSDL-Dokuments bereit.) Die folgenden zwei Strategien werden unterstützt:

  • Erstellung einer Skeleton-Java-Bean aus einem WSDL-Dokument

    Sie können eine Skeleton-Java-Bean aus einem WSDL-Dokument erstellen und als Web-Service zugänglich machen. Die Methoden der generierten Java-Bean entsprechen den im WSDL-Dokument beschriebenen Operationen und enthalten eine einfache Implementierung, die Sie ersetzen können. Für diese Strategie und das dadurch generierte Arbeitsergebnis gilt Folgendes:

    • Sie können den URI eines WSDL-Dokuments eingeben oder alternativ den eines WSIL- oder HTML-Dokuments, das auf die WSDL-Datei als Quelle für den Web-Service verweist.
    • Die WSDL-Datei muss ein Serviceelement enthalten. Sie können für den entstandenen Web-Service wahlweise auch ein standardisiertes WSDL-Referenzdokument (WSIL-Dokument) generieren.
    • Der generierte Web-Service muss in einem Webprojekt erstellt werden.
  • Erstellung einer Skeleton-EJB aus einem WSDL-Dokument

    Ähnlich wie die oben beschriebene Vorgehensweise ermöglicht diese Strategie, dass eine Skeleton-Stateless-Session-EJB aus einem WSDL-Dokument erstellt und als Web-Service zugänglich gemacht wird. Die Methoden in der EJB entsprechen den Operationen im WSDL-Dokument und enthalten eine einfache Implementierung, die Sie ersetzen können. Für diese Strategie und das dadurch generierte Arbeitsergebnis gilt Folgendes:

    • Diese Strategie kann nur verwendet werden, wenn Sie IBM WebSphere Version 6 als Laufzeitumgebung für den Web-Service verwenden (siehe "Abhängigkeiten bei der Implementierung").
    • Sie können den URI eines WSDL-Dokuments eingeben oder alternativ den eines WSIL- oder HTML-Dokuments, das auf die WSDL-Datei als Quelle für den Web-Service verweist.
    • Die WSDL-Datei muss ein Serviceelement enthalten. Sie können für den entstandenen Web-Service wahlweise auch ein standardisiertes WSDL-Referenzdokument (WSIL-Dokument) generieren.
    • Der generierte Web-Service muss in einem EJB-Projekt erstellt werden. Außerdem wird ein Router-Projekt erstellt, damit der Web-Service Anforderungen über den HTTP-Transport empfangen kann. (Anmerkung: Bei Verwendung dieser Strategie wird der JMS-Transport nicht unterstützt.) Das Router-Projekt kann ein Web- oder EJB-Projekt sein. Es darf nicht dasselbe Projekt sein, in dem der Web-Service enthalten ist, muss aber in derselben EAR-Datei enthalten sein.

Bottom-up-Entwicklung

Das Ziel der Bottom-up-Entwicklung besteht darin, eine vorhandene Anwendungskomponente oder Ressource als Web-Service zugänglich zu machen. Die möglichen Strategien werden nachfolgend erläutert.

  • Web-Service aus einer Java-Bean entwickeln

    Diese Strategie erlaubt es, eine vorhandene Java-Bean auszuwählen und ihre Methoden als Web-Service zugänglich zu machen. Folgende Arbeitsergebnisse werden generiert:

    • WSDL-Datei: Diese Datei beschreibt den Web-Service und hat die Dateinamenerweiterung .wsdl. Sie können unter drei WSDL-Stilen wählen (Document/Literal, RPC/Literal und RPC/Encoded). Die Auswirkung jeder Option auf die Interoperabilität wird unter "Konformität mit dem WS-I Basic Profile" erläutert.
    • Service Endpoint Interface (SEI): Diese Java-Schnittstelle definiert die Methoden des Web-Service. Ihr Dateiname hat das Suffix _SEI.
    • Web Service Deployment Descriptor: Die Datei webservices.xml enthält die Implementierungsdetails des Web-Service.
    • JAX-RPC-Zuordnungsdateien: Diese Dateien definieren die Zuordnung zwischen den Java-Elementen des Web-Service und WSDL.
  • Web-Service aus einer EJB erstellen

    Sie können die Methoden einer Stateless-Session-Bean als Web-Service zugänglich machen. Die generierten Arbeitsergebnisse sind ähnlich den Arbeitsergebnissen, die für eine Java-Bean generiert werden, und enthalten eine WSDL-Datei, SEI, Web Service Deployment Descriptor und JAX-RPC-Zuordnungsdateien. Für diese Strategie und das dadurch generierte Arbeitsergebnis gilt Folgendes:

    • Der generierte Web-Service muss in einem EJB-Projekt erstellt werden.
    • Ein Router-Projekt muss erstellt werden, damit der Web-Service Anforderungen von Clients empfangen kann. Bei Verwendung von SOAP over HTTP als Transportmethode erstellen Sie das Router-Projekt als Webprojekt. Andernfalls, falls der Client SOAP over JMS verwendet, erstellen Sie es als EJB-Projekt (der JMS-Router wird in diesem Fall als nachrichtengesteuerte Bean (Message-Driven Bean) implementiert.) Router- und Web-Service-Projekt dürfen nicht übereinstimmen, müssen aber in derselben EAR-Datei enthalten sein.
    • Bei Verwendung der Transportmethode SOAP over JMS müssen Sie in Ihrem Server einen JMS-Provider konfigurieren. Außerdem ist es nicht möglich, den Web-Service mit dem Web Service Explorer zu testen.
  • Web-Service aus einer DADX-Datei erstellen

    Diese Strategie ermöglicht es, DB-Daten, die über DB2 XML Extender oder reguläre SQL-Anweisungen abgerufen werden, in einen Web-Service einzuschließen. Daten, die über DB2 XML Extender abgerufen werden, bestehen aus XML-Dokumenten, die mittels eines DAD-Dokuments (Document Access Definition, Dokumentzugriffsdefinition) einer DB2-Datenbank zugeordnet sind. Der Ausgangspunkt bei dieser Strategie ist eine DADX-Datei, die festlegt, wie ein Web-Service mit Hilfe der durch reguläre SQL-Anweisungen oder in einer DAD-Datei definierten Operationen erstellt wird. Die generierten Arbeitsergebnisse umfassen die Standard-WSDL-Datei, SEI, Web Service Deployment Descriptor und JAX-RPC-Zuordnungsdateien. Für diese Strategie und das dadurch generierte Arbeitsergebnis gilt Folgendes:

    • Diese Strategie kann nur verwendet werden, wenn Sie IBM SOAP als Laufzeitumgebung für den Web-Service verwenden (siehe "Abhängigkeiten bei der Implementierung").
    • Sie können eine DADX-Datei wahlweise aus einer Kombination von einer oder mehreren SQL-Anweisungen, gespeicherten Prozeduren und DAD-Dateien generieren.
    • Die DADX-Datei sollte in einer DADX-Gruppe enthalten sein, die die JDBC-Verbindung und andere Informationen enthält, die von den DADX-Dateien in der Gruppe gemeinsam verwendet werden.
    • Der generierte Web-Service muss in einem Webprojekt erstellt werden.
  • Web-Service aus einem URL erstellen

    Aus dem zugehörigen URL können Sie einen Web-Service erstellen, der direkt auf ein Servlet zugreift, das auf einem fernen Server läuft. Der Assistent bietet Ihnen die Möglichkeit, die Schnittstelle des Servlets in Form von Ports, Operationen und Parametern zu definieren, und er generiert ein WSDL-Dokument, das den erstellten Web-Service beschreibt. Für diese Strategie und das dadurch generierte Arbeitsergebnis gilt Folgendes:

    • Diese Strategie kann nur verwendet werden, wenn Sie IBM SOAP als Laufzeitumgebung für den Web-Service verwenden (siehe "Abhängigkeiten bei der Implementierung").
    • Normalerweise entspricht der Port dem Teil des URL, der den Domänen-/Hostnamen enthält, die Operation entspricht dem Teil mit dem Servlet-Kontextstammverzeichnis und dem URI, und die Parameter entsprechen den Eingabeparametern des Servlets.
    • Der generierte Web-Service muss in einem Webprojekt erstellt werden.
    • Es gibt keinen Web-Service, der implementiert werden muss, weil er vom aktiven URL bereits implementiert wurde.
  • Web-Service aus einer Deployment-Descriptor-Datei (ISD) erstellen

    Bei der Implementierung eines Web-Service werden seine Konfigurations- und Laufzeitattribute in einer Deployment-Descriptor-Datei (ISD) definiert. Diese Datei enthält Informationen zu dem Service, der den Clients von der SOAP-Laufzeitumgebung zur Verfügung gestellt werden sollte, z. B. URI, Methoden, Implementierungsklassen (JavaBeans und EJBs), Serializer und Deserializer. Sie können einen Web-Service aus einer ISD-Datei erstellen, indem Sie diese verfügbaren Informationen verwenden. Dadurch ist es möglich, vorhandene Web-Service-Implementierungen wieder zu verwenden und als neue Web-Services erneut zu implementieren, ohne dass ihre Konfigurations- und Zuordnungsdaten erneut angegeben werden müssen. Für diese Strategie und das dadurch generierte Arbeitsergebnis gilt Folgendes:

    • Diese Strategie kann nur verwendet werden, wenn Sie IBM SOAP als Laufzeitumgebung für den Web-Service verwenden (siehe "Abhängigkeiten bei der Implementierung").
    • Der generierte Web-Service muss in einem Webprojekt erstellt werden.

Richtlinien zur Entwicklung

Die folgenden Abschnitte enthalten wichtige Aspekte, die für die Entwicklung eines Web-Service in RAD 6.0 relevant sind. Sie beschreiben die verfügbaren Entwicklungsoptionen auf der Basis der Anforderungen Ihres Web-Service bezüglich Implementierung und WS-I-Konformität.

Abhängigkeiten bei der Implementierung

Die zum Erstellen eines Web-Service verfügbaren Strategien (Top-down oder Bottom-up) sind abhängig von der Laufzeitumgebung, die für die Implementierung vorgesehen ist. RAD 6.0 unterstützt folgende Laufzeitumgebungen für Web-Services:

  • IBM WebSphere Version 6

    Dies ist die Standardlaufzeitumgebung für Web-Services in RAD 6.0 und gleichzeitig die für Produktionszwecke empfohlene Laufzeitumgebung. Sie unterstützt sowohl das JMS- als auch das HTTP-Transportprotokoll und erlaubt den Web-Service-Clients- und -Servern daher entweder über HTTP-Verbindungen oder über JMS-Warteschlangen und -Topics miteinander zu kommunizieren. Wenn über den JMS-Transport auf einen Web-Service zugegriffen werden soll, beachten Sie, dass dieser als Enterprise-Bean implementiert sein muss.

  • IBM SOAP

    Die Laufzeitumgebung IBM SOAP unterstützt die Protokolle Apache SOAP Version 2.2 und 2.3 (siehe "Ressourcen") und war in WebSphere Studio bis einschließlich Version 5.0 die einzige unterstützte Laufzeitumgebung für Web-Services. Sie sollte nur aus Gründen der Abwärtskompatibilität verwendet werden.

  • Apache Axis 1.0

    Diese Laufzeitumgebung unterstützt die SOAP-Implementierung von Apache Axis Version 1.0 (siehe "Ressourcen"). Aufgrund von potenziellen Problemen mit der Web-Service-Interoperabilität (siehe "Problems using Apache Axis 1.0 run-time environment" in der Hilfe (Help Contents) des Tools) wird diese Laufzeitumgebung für Produktionszwecke nicht empfohlen.

Es wird empfohlen, die Laufzeitumgebung IBM WebSphere v5 zu verwenden, sofern nicht speziell eine Apache-SOAP- oder Apache-Axis-Implementierung eingesetzt werden muss. (Andernfalls beachten Sie die damit verbundenen Einschränkungen, die im Abschnitt über die Einschränkungen ("Limitations of Web Services") in der Hilfe ("Help Contents") des Tools erläutert werden.) Tabelle 1 enthält eine Zusammenfassung der Strategien zur Web-Service-Erstellung, die von RAD 6.0 für jede Laufzeitumgebung unterstützt werden.

Strategie IBM WebSphere Version 6 IBM SOAP Apache Axis 1.0
Skeleton-JavaBean aus einem WSDL-Dokument erstellen
Ja
Ja
Ja
Skeleton-EJB aus einem WSDL-Dokument erstellen
Ja
Nein
Nein
Web-Service aus einer JavaBean erstellen
Ja
Ja
Ja
Web-Service aus einer EJB erstellen
Ja
Ja
Nein
Web-Service aus einer DADX-Datei erstellen
Nein
Ja
Nein
Web-Service aus einem URL erstellen
Nein
Ja
Nein
Web-Service aus einem Web Service Deployment Descriptor (ISD) erstellen
Nein
Ja
Nein

Tabelle 1 - Unterstützte Strategien für das Erstellen von Web-Services nach Laufzeitumgebung

Konformität mit dem WS-I Basic Profile

Das WS-I Basic Profile (Web Services-Interoperability) ist eine Gruppe von Spezifikationen, die von der Organisation WS-I veröffentlicht wurden, um die Interoperabilität von Web-Services über unterschiedliche Plattformen, Betriebssysteme und Programmiersprachen hinweg zu fördern. Es definiert die Anforderungen bezüglich WSDL und Protokolltransport (SOAP/HTTP), die ein Web-Service erfüllen muss, um mit WS-I konform zu sein. RAD 6.0 umfasst Validierungstools, mit denen geprüft werden kann, ob ein Web-Service mit den Anforderungen des WS-I Basic Profile 1.0 konform ist. Sie können für den Arbeitsbereich oder für das Projekt eine WS-I-Konformitätsstufe (Compliance Level) festlegen (Require, Suggest oder Ignore (Standardeinstellung)), bevor Sie einen Web-Service entwickeln, oder nach der Entwicklung die Validierungstools ausführen.

Es wird empfohlen, Web-Services zu entwickeln, die mit dem WS-I Basic Profile konform sind. Beachten Sie folgende Richtlinien, um dies sicherzustellen.

  • Verwenden Sie als WSDL-Stil Document/literal oder RPC/literal (RPC/encoded ist nicht WS-I-konform)
  • Verwenden Sie SOAP over HTTP als Nachrichten- und Übertragungsprotokoll (SOAP over JMS ist nicht WS-I-konform)
  • Verwenden Sie keine Sicherheitsoptionen für den Web-Service (die digitale XML-Signatur und XML-Verschlüsselung sind nicht WS-I-konform)

Hinweise zu Client-Proxys

  • Es gibt zwei Typen von Client-Proxys, die beim Erstellen eines Web-Service wahlweise generiert werden können:
  • Java-Bean-Proxy

Der Java-Bean-Client-Proxy ermöglicht den Aufruf der Web-Service-Methoden über Fernprozeduraufrufe. Er kann nur dann in einem Clientwebprojekt erstellt werden, wenn als Laufzeitumgebung für den Client IBM SOAP oder Apache Axis 1.0 ausgewählt wurde. Wird als Laufzeitumgebung für den Client hingegen IBM WebSphere Version 6 verwendet, kann er in einem Web-, Java-, EJB- oder Anwendungsclientprojekt erstellt werden.

  • Web Service User-Defined Function (UDF)

Mit dieser Option können Sie für jede Methode des Web-Service, die aufgerufen werden soll, eine DB2 UDF (User-Defined Function) erstellen. Dazu müssen das Paket mit DB2 Web Services Consumer UDF und DB2 XML Extender in der Datenbank installiert sein. Die UDF wird erstellt und zur Datenbankdefinition hinzugefügt, wobei alle zugehörigen Clientarbeitsergebnisse in einem Webprojekt gespeichert werden.

  • Wählen Sie für den Web-Service und den Web-Service-Client ein unterschiedliches EAR aus, um die Wahrscheinlichkeit von Laufzeitfehlern zu reduzieren. Beachten Sie, dass der Client eine andere Anwendung als der Web-Service sein sollte, und dass Web-Services nicht für die Kommunikation zwischen Anwendungen vorgesehen sind.

Ressourcen

Weitere Informationen zu den unten aufgeführten Themen finden Sie unter dem zugehörigen Link.