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.
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:
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.
|