1.0 Einführung
2.0 Unterstützte Software und Spezifikationen
3.0 Änderungen seit dem letzten Release
4.0 Bekannte Probleme
4.1 Webservice-Explorer
4.2 Private UDDI-Registrierung
4.3 Interoperabilität mit IBM SOAP-Laufzeit
4.4 Ein WSDL-Dokument aus einer DADX-Datei generieren
4.5 Webtools - JSP-Generator
4.6 Universellen Testclient verwenden
4.7 Mehrfachausgabe ist bei DADX-Webservices in bestimmten Fällen erlaubt
4.8 Vorgabe für JDBC-Treiber gilt nur für Verwendung unter Linux
4.9 DAD-Beispieldateien müssen aktualisiert werden, wenn XML-Extender nicht im Standardverzeichnis installiert ist
4.10 Probleme bei DADX-Webservices
4.11 Unterstützung für die DADX-Generierung
4.12 WSDL-Fehler nach dem Importieren einer Webservice-Datei aus 4.0.x
4.13 Probleme bei der Verwendung der Befehlszeile der Webservices
4.14 Erstellung von Webservices ohne vorhandenen Server
4.15 Beispielanwendung für Webservices generieren
4.16 WSDL-Dateien mit HTTP-Basisauthentifizierung importieren
4.17 Probleme mit der Verwendung der WebSphere v5.0.2-Laufzeit
4.18 Eine DADX-Gruppe mit Datenquelleninformationen einrichten
4.19 Client-Locator mit dem Universellen Testclient laden
4.20 Benutzervorgaben für Ressourcen werden nicht berücksichtigt
4.21 Probleme bei der Verwendung der Apache Axis 1.0-Laufzeit
4.22 Kompilieren des Webservicebeispiels für JSP schlägt fehl
4.23 Problem mit der Webservices-Befehlszeile für Deutsch
4.24 Fehler bei nicht definiertem lokalen Host (localhost)
4.25 Dauerhafte Einschränkungen bei der Verwendung der IBM SOAP-Laufzeit
4.26 Webservice und Client verwenden unterschiedliche Laufzeiten
4.27 Im Assistenten 'Webservice-Client' auf 'Fertig stellen' klicken
4.28 Spickzettel für Webservices
Mit der Funktion der Webservice-Tools können Sie Java-Bean-, Enterprise-Bean- und URL-Webservices aufspüren, erstellen und publizieren. Diese Readme-Datei beschreibt die bekannten Probleme, Einschränkungen und Umgehungen, die mit den folgenden Funktionen der Webservice-Tools zusammenhängen:
- Generieren eines WSDL-Dokuments aus einer Java-Bean, einem DADX-Dokument, einer Enterprise-Bean, einer ISD-Datei und einer URL.
- Generieren eines Java-Proxy oder -Entwurfs aus einem WSDL-Dokument.
- Erstellen und Implementieren eines Webservice aus einer Java-Bean, einem DADX-Dokument, einer Enterprise-Bean oder einer URL.
- Aufspüren und Publizieren von Webservices.
- Generieren einer Beispielwebanwendung aus einem Java-Proxy.
- Fragen zur Interoperabilität.
Der Webservices-Explorer unterstützt die folgenden Webbrowser:
- Microsoft Internet Explorer 6.0 oder höher
- Mozilla 1.2.1 oder höher
Dieses Release der Webservice-Tools generiert Code, der den folgenden Spezifikationen entspricht:
- SOAP (Simple Object Access Protocol) Version 1.1
- UDDI (Universal Description, Discovery, and Integration) Version 2.0
- WSDL (Web Services Definition Language) Version 1.1
- Web Services Inspection Language (WSIL) Version 1.0
Dieses Release der Webservice-Tools unterstützt:
- IBM WebSphere v5.0.2-Webservices-Laufzeit
- Laufzeitumgebungen für IBM SOAP Version 2.2 und Version 2.3
- Apache Axis 1.0-Laufzeit
Wenn Sie die WORF-Testumgebung außerhalb der Workbench mit Mozilla starten, sollte hierzu mindestens die Mozilla-Version 1.3.1 verwendet werden. Die Ausgabe vom Aufruf des Webservices sowie die Beschreibungsdateien werden in älteren Versionen des Mozilla-Browsers möglicherweise nicht korrekt angezeigt.
Die DADX-Laufzeit erfordert den DB2 7.2-Fixpack oder später oder aber DB2 8.1 oder später.
Folgende Funktionen sind neu in den Webservice-Tools in Version 5.1:
- Unterstützung der IBM WebSphere v5.0.2-Webservices-Laufzeit. Hierbei handelt es sich um die strategische IBM Webservice-Laufzeit, die JSR-109 und JAX-RPC unterstützt.
- Unterstützung der Apache Axis v5.0.2-Webservices-Laufzeit. Diese Laufzeit unterstützt JAX-RPC und wurde für Benutzer konzipiert, die die Entwicklung für die offene Apache Axis-Plattform bevorzugen.
- Bereitstellung eines Webservice-Tools für die Befehlszeileneingabe, mit dem der Benutzer Webservices von einer JavaBean-, EJB- oder WSDL-Datei erstellen und die Publizierung von Geschäften und Services auf UDDI-Registrierungen ausführen und widerrufen kann.
- Vollständige Integration des WSDL-Explorers in den Webservice-Explorer.
- Es werden Tools für die Webservice-Anwendungsassemblierung bereitgestellt, unter anderem folgende:
- Webservices-Editor und Webservices-Clienteditor zum Bearbeiten der Implementierungsdeskriptoren für JSR-109 und IBM WebSphere v5.0.2.
- Aktionen in Dialogfenstern zum Aufrufen der Funktion 'EndpointEnabler'.
- Aktionen in Dialogfenstern zum Aufrufen der Funktion 'WebServiceDeploy'.
- Benutzerorientierte Hilfestellung für die Erstellung von WS-I-konformen Webservices anhand von Benutzervorgaben. Der Benutzer kann auswählen, ober der Assistent für Webservices bei der Erstellung von Webservices die WS-I-Konformität erfordern, vorschlagen oder ignorieren soll.
- Generierung und Verwendung von WSIL-Webservice-Verweisdokumenten für einzelne Proxys.
- Benutzerseitige Möglichkeit, die WebSphere v5.0.2-Implementierungsdeskriptoren mit einfachen Sicherheitskonfigurationen zu aktualisieren.
- Unterstützung von SOAP über JMS als Transportmedium für SOAP-Nachrichten, wenn Webservices von EJBs erstellt werden.
- Unterstützung von benutzerdefinierten UDDI-Kategorien.
- Unterstützung der Webservice-Prüfung. Wird diese Vorgabe angegeben, prüft das Tool, ob die Unternehmensanwendung und/oder die in ihr enthaltenen Module eine Gruppe von Regeln einhalten, die die Kompatibilität mit JSR-109 feststellen.
- Bei Verwendung des Webservice-Explorers mit der Privaten UDDI-Registrierung wird das Formular 'Publisherassertionen verwalten' eines Geschäftsknotens in den folgenden Fällen nicht geladen:
- Sie sind nicht bei dem Registrierungsknoten angemeldet, der den Geschäftsknoten enthält.
- Sie sind bei dem Registrierungsknoten angemeldet, der den Geschäftsknoten enthält. Die zum Anmelden bei der betreffenden Registrierung verwendete Benutzer-ID mit dem zugehörigen Kennwort ist jedoch nicht Eigner des Geschäftsknotens.
- Sie können den Webservice-Explorer nicht zum Abfragen oder Publizieren einer UDDI-Registrierung mit aktivierter Basisauthentifizierung verwenden. Ein Beispiel für diese Art von Registrierung ist eine private Registrierung, die mit aktivierter Basisauthentifizierung auf einem Server implementiert ist. Bitte beachten Sie, dass die öffentlichen Registrierungen (IBM, Microsoft, SAP, NTT und XMethods) von diesem Problem nicht betroffen sind.
- Wird im Webservices-Explorer eine erweiterte Suche nach Unternehmen in einer mit einem Cloudscape-Backend konfigurierten privaten WAS-UDII-Registrierung verwendet, und einer oder mehrere Serviceschnittstellen sind als Parameter angegeben, schlägt die Suche fehl und das Statusfenster zeigt Folgendes an:
com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException: Could not list all service providers. ------------------------------------------------------------------------------ Nested exception is:E_fatalError (10500) Serious technical error has occurred while processing the request. : Fault code=Client Fault string=Client Error Fault actor=null Detail=null DispositionReport: ErrCode=E_fatalError ErrInfoText=E_fatalError (10500) Serious technical error has occurred while processing the request.
- Die neue XMethods-Registrierung verfügt über Prozeduren zum Überprüfen von publizierten Webservices, die unzugängliche oder nicht funktionierende Webservices löschen. Wenn Sie nicht möchten, dass ein publizierter Webservice gelöscht wird, stellen Sie sicher, dass alle URL-Verweise innerhalb der WSDL-Dateien im Internet zugänglich sind.
Die SAP UDDI Business Registry gibt einen E_fatalError für eine Suchabfrage für Unternehmen nach Kategorie mit 'findQualifier' gleich 'combineCategoryBags' (tModelKey gleich UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2) zurück. Die folgende Fehlernachricht wird im Statusfenster angezeigt. Dieses Problem besteht nur bei der SAP UDDI Business Registry.
com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException: Could not list all service providers. ------------------------------------------------------------------------------ Nested exception is:A serious technical error has occurred while processing the request. : Fault code=Client Fault string=UDDI Error Fault actor=null Detail=null DispositionReport: ErrCode=E_fatalError ErrInfoText=A serious technical error has occurred while processing the request. at com.ibm.uddi4j.wsdl.client.UDDIWSDLProxy.findAllServiceProviders(UDDIWSDLProxy.java:1626) at FindBusWithQualifier.main(FindBusWithQualifier.java:35)
- Von der SAP UDDI Business Registry zurückgegebene Publisherassertionsberichte enthalten keinen Status. Dies hat zur Folge, dass die Publisherassertion-Statusspalte des Formulars 'Publisherassertionen verwalten' im Webservice-Explorer in von SAP zurückgegebenen Berichten leer bleibt. Dieses Problem besteht nur bei der SAP UDDI Business Registry.
- Wenn Sie versuchen, ein Geschäft, einen Service oder eine Serviceschnittstelle auf einer XMethods UDDI-Registrierung zu publizieren, wird eine Fehlermeldung angezeigt, die auf einen SSL-Handshake-Fehler hinweist. Dies ist ein bekanntes Problem, das von IBM und XMethods untersucht wird.
- Publisherassertionen der Privaten UDDI-Registrierung sind möglicherweise für alle Geschäfte in der Registrierung sichtbar. Für ein Geschäft sind möglicherweise Publisherassertionen sichtbar, die dem Geschäft selbst zugeordnet sind. Der Schlüssel des Geschäfts entspricht beispielsweise weder den 'from'-Schlüsseln noch den 'to'-Schlüsseln der Publisherassertionen.
- Wenn die UDDI-Registrierung für den Einheitentest mit dem Cloudscape-Datenbank-Backend konfiguriert wird, führen UDDI-Methoden für die Suche nach Namen Suchvorgänge standardmäßig unter Beachtung der Groß-/Kleinschreibung aus. Dies richtet sich gegen die UDDI-Spezifikation und ist eine Einschränkung.
- Die Private UDDI-Registrierung sollte nur mit dem Cloudscape-Backend für grundlegende Testzwecke konfiguriert werden (d. h. dieses Backend sollte nicht für Generierungsarbeiten verwendet werden, da zur Zeit Schwierigkeiten mit Aktionen wie komplexen Abfragen auftreten). Weitere Informationen zur privaten Registrierung finden Sie in der Dokumentation zur Netzwerkimplementierung im WAS V5-InfoCenter.
- Nach der Erstellung oder Aktualisierung einer auf Cloudscape basierenden UDDI-Registrierung für den Einheitentest unter Linux wird möglicherweise eine Warnung mit hoher Priorität (Red Warning) in der Serverkonsole mit folgendem Inhalt angezeigt:
Cloudscape (instance <uuid>) is attempting to boot the database <UDDI DB location> even though Cloudscape (instance <uuid>) may still be active. Only one instance of Cloudscape should boot a database at a time. Severe and non-recoverable corruption can result and may have already occurred.
(Cloudscape (exemplar-<uuid>) versucht, die Datenbank <UDDI DB-position> zu booten, obwohl Cloudscape (exemplar-<uuid>) möglicherweise noch aktiv ist. Es sollte jeweils immer nur eine Instanz von Cloudscape eine Datenbank laden. Es können schwer wiegende und nicht rückgängig zu machende Schaden verursacht werden und sind eventuell bereits eingetreten.)
Bei dieser Warnung handelt es sich um einen falschen Alarm. Weitere Informationen stehen (in englischer Sprache) unter folgender Adresse bereit:
http://www-1.ibm.com/support/docview.wss?rs=636&context=SSCVRP&q=&uid=swg21051601&loc=en_US&cs=utf-8&lang=en+en
- Bei der Verwendung der IBM SOAP-Laufzeit kann das Generieren von WSDL mit komplexen Parametern Probleme mit Microsoft-Tools verursachen, die WSDL verwenden. Microsoft-Tools verarbeiten include-Anweisungen nicht korrekt, sodass das Integrieren von XSD-Schemata in generiertes WSDL eventuell erforderlich ist. Wählen Sie dazu folgende Optionen aus:
Fenster > Benutzervorgaben > Webservices > Codegenerierung > Inline-Schema verwenden.Bei der Verwendung der IBM SOAP-Laufzeit besitzt der Webservice-Assistent nun vollständig die Fähigkeit, zusätzlich zu den normalen typbasierten Zuordnungen elementbasierte Zuordnungen zu generieren, sofern das Markierungsfeld 'Elementbasierte Zuordnung aktivieren' aktiviert ist. Im Hauptmenü von WSAD befindet sich dieses Markierungsfeld in der folgenden Benutzervorgabenseite:
Fenster > Benutzervorgaben > Webservices > Codegenerierung.Ist diese Benutzervorgabe nicht aktiviert (was standardmäßig der Fall ist), kooperiert die Apache/IBM SOAP-Laufzeit unter Umständen nicht mit den Webservice-Laufzeiten anderer Softwareanbieter, die Nachrichten versenden, deren Elemente nicht über 'xsi:type'-Eigenschaften verfügen. Webservice-Laufzeiten anderer Softwareanbieter befolgen verschiedene Verfahren über die Einschließung von xsi:type-Eigenschaften. Einige Anbieter schließen die Eigenschaften ein. Einige Anbieter schließen die Eigenschaften nie ein. Einige Anbieter bieten eine Konfigurationsauswahl an. Einige lassen xsi:types für bestimmte Typen, wie z. B. Arrays, aus.
Der typische, von der IBM/Apache SOAP-Laufzeit generierte Fehler ist:
targetException=java.lang.IllegalArgumentException: No Deserializer found to deserialize a ':MyElement' using encoding style 'http://schemas.xmlsoap.org/soap/encoding/'.
Sind elementbasierte Zuordnungen aktiviert, werden diese wie folgt generiert:
- in die Implementierungsdeskriptor-Datei für Bottom-up-Java-Bean-/EJB-Szenarios und WSDL-Gerüstszenarios
- in den Proxy in Clientszenarios
Elementbasierte Zuordnungen haben folgendes Format:
<isd:map
encodingStyle="encoding style"
xmlns:x="some-namespace"
qname="x:some-local-name"
xml2JavaClassName="some-deserializer-class-name"/>Elementbasierte Zuordnungen werden generiert für:
- alle in wsdl:message-Eingaben definierten Komponenten.
- alle in wsdl:message-Ausgaben definierten Komponenten, jedoch nur für Gerüst- und Proxyszenarios.
- alle Stammelemente oder lokalen Elemente in komplexen Typen, auf die von Komponenten der WSDL-Datei verwiesen wird.
Der WSAD-Webservice-Assistent folgt den SOAP- und XSD-Spezifikationen, um zu ermitteln, ob der Elementname in einer elementbasierten Zuordnung qualifiziert (d. h. mit Namensbereich) oder unqualifiziert sein soll.
Der WSAD-Webservice-Assistent befolgt folgende Regeln zur Entscheidung zwischen qualifizierten und unqualifizierten Elementnamen:
- Komponentennamen in WSDL erzeugen unqualifizierte Namen.
- Stammelemente in XSD erzeugen qualifizierte Namen.
- Lokale Elemente in XSD erzeugen unqualifizierte Namen, wenn das Schema elementFormDefault="unqualified" angibt. Dies ist gleichzeitig die Standardeinstellung, wenn das Schema nicht über ein Attribut elementFormDefault verfügt.
- Lokale Elemente in XSD erzeugen qualifizierte Namen, wenn das Schema elementFormDefault="qualified" angibt.
Einige Laufzeiten generieren in SOAP-Nachrichten unqualifizierte Elemente trotz eines Schemas, das die Verwendung von qualifizierten Elementen über das XSD-Schema-Attribut 'elementFormDefault' angibt. In solchen Fällen muss die WSDL oder XSD eines Services manuell bearbeitet werden und elementFormDefault in 'unqualified' geändert werden.
Dies ist ein Beispiel für eine qualifizierte, elementbasierte Zuordnung ohne Namensbereich:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x=""
qname="x:name"
xml2JavaClassName="org.apache.soap.encoding.soapenc.StringDeserializer"/>Dies ist ein Beispiel für eine qualifizierte, elementbasierte Zuordnung mit Namensbereich:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x="http://www.ibm.com/"
qname="x:name"
xml2JavaClassName="org.apache.soap.encoding.soapenc.StringDeserializer"/>Bitte beachten Sie, dass jeweils nur eine elementbasierte Zuordnung für einen Elementnamen generiert wird. Das heißt, wenn das Schema denselben Elementnamen mehrfach, jedoch mit unterschiedlichen Typen, verwendet, wird nur eines der Elemente (nach dem Zufallsprinzip) als Basis für eine elementbasierte Zuordnung ausgewählt. Die anderen identisch benannten Elemente verschiedener Typen können nicht entserialisiert werden. Das gilt auch, wenn das Schema für ein Element und eine WSDL-Komponente denselben Namen verwendet.
- Wenn Sie mit einer Service-Bean beginnen, die ein Array von Map oder ein Array von Hashtable zurückgibt, und die Option 'elementbasierte Zuordnung' aktiviert ist, ordnet der generierte SOAP-Proxy den Rückgabetyp nicht korrekt zu einer java.lang.String[] zu. Während der Laufzeit wird eine ClassCastException auftreten. Sie umgehen dieses Problem, indem Sie den Webservice-Clientassistent mit der neu erstellten WSDL ausführen und den SOAP-Proxy erneut in das Clientprojekt generieren.
- Zur Verbesserung der Interoperabilität mit Webservices von Microsoft wurde die DADX-Laufzeit aktualisiert, sodass Webservices für Dokumentstil generiert werden können. Verwenden Sie zur Aktivierung dieser Funktion den DADX-Konfigurationsassistent und öffnen Sie die Eigenschaftenseite einer zu verwendenden DADX-Gruppe. Stellen Sie sicher, dass das Eingabefeld für Dokumentstil im unteren Bereich der Eigenschaftenseite auf 'wahr' gesetzt ist.
- Das Generieren eines Java-Proxy für DADX-Aufrufoperationen mit mehreren Ausgabeparametern wird nicht unterstützt.
- Beim Erstellen eines DADX-Webservice wird gelegentlich die Nachricht 'IWAB0177E Fehler beim Generieren von WSDL aus einer DADX-Datei.' angezeigt. In den meisten Fällen deutet diese Nachricht auf ein Datenbankproblem hin. Lesen Sie dazu die detaillierten Informationen des Serverkonsolenprotokolls. Prüfen Sie darüber hinaus Folgendes:
- Die DAD-Dateien (*.dad) müssen sich im DADX-Gruppenverzeichnis befinden. Auf diese Weise werden DAD-Dateien von der WORF-Laufzeit positioniert.
- Wenn Sie versuchen, eine DAD-Datei aus einer RDB-zu-XML-Zuordnung (.rmx) zu generieren, müssen Sie sicherstellen, dass sich die DAD-Datei im gleichen Ordner wie die DADX-Datei befindet.
- Das DADX-Schema verwendet den WSDL-Dokumentbefehl nicht weiter für die Dokumentation, sondern dieser Befehl ist nun ein Teil des DADX-Schemas. Dies kann zu Problemen bei der Gültigkeitsprüfung von DADX-Dateien führen, für die keine Migration zur Verwendung des aktualisierten Schemas erfolgt ist. Wenn Ihre alte DADX-Datei z. B. folgende XML enthält:
<wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
Provides queries for part order information at myco.com.
</wsdl:documentation>dann würde der neue Dokumenteintrag wie folgt lauten:
<documentation>
Provides queries for part order information at myco.com.
</documentation>
Wird der Universelle Testclient aus dem Webservice-Assistenten gestartet, ist die JNDI-Provider-URL auf den standardmäßigen WebSphere V5-Port 2809 gesetzt. Wenn Sie einen WebSphere V4-Server verwenden oder die Portnummer geändert haben, können Sie das JNDI-Verzeichnis nicht durchsuchen. Versuchen Sie, auf das JNDI-Verzeichnis zuzugreifen, erhalten Sie folgende Fehlermeldung:
IWAD0403E JNDI-Baumstruktur konnte nicht erstellt werden: CORBA.COMM_FAILURE beim Auflösen des Anfangsverweises=WsnNameService (IWAD0403E Could not construct the JNDI tree: Caught CORBA.COMM_FAILURE when resolving initial reference=WsnNameService)Sie können das Problem wie folgt umgehen:
- Doppelklicken Sie auf den Server, den Sie gegenwärtig verwenden. Dadurch werden die Servereigenschaften angezeigt.
- Klicken Sie auf die Registerkarte für Anschlüsse.
- Kopieren Sie den Orb-Bootstrap-Port.
- Öffnen Sie im Universellen Testclient das JNDI-Eigenschaftenfenster.
- Fügen Sie den Bootstrap-Port in das Texteingabefeld der Provider-URL.
Normalerweise werden mehrfache Ausgaben in einem Webservice von unseren Tools nicht unterstützt. Bei DADX-Webservices sind mehrfache Ausgaben jedoch erlaubt, wenn die Option Gruppeneigenschaft 'Dokumentstil verwenden' auf wahr gesetzt ist. Wenn Dokumentstil auf wahr gesetzt ist, werden mehrfache Ausgaben zu einem einzigen XML-Dokument kombiniert.
Zu den Webservice-Benutzervorgaben (Fenster > Benutzervorgaben > Webservices) wurde eine neue Kategorie namens JDBC-Treiber hinzugefügt. Obwohl diese Benutzervorgabe für alle Plattformen bereitgestellt wird, ist ihre Verwendung nur für Linux bestimmt. Unter Linux kann es schwierig sein, die Adresse der JAR-Datei mit den JDBC-Treibern zu ermitteln. Deshalb wurde diese Benutzervorgabenseite hinzugefügt, sodass angegeben werden kann, welche JAR-Datei verwendet werden soll. Aktuell verwendet nur der DADX-Gültigkeitscode diese JAR-Dateiinformationen.
Die DAD-Dateien im Verzeichnis WS_installationsverzeichnis\wstools\eclipse\plugins\com.ibm.etools.webservice_<version>\samples\DADX_examples müssen geändert werden, um Ihre Systemkonfiguration zu reflektieren.
Im oberen Bereich der Datei befindet sich eine Zeile ähnlich der folgenden:
<!DOCTYPE DAD SYSTEM "c:\dxx\dtd\dad.dtd">
Wurde der XML-Extender in eine andere Speicherposition geladen als c:\dxx, muss diese Zeichenfolge aktualisiert werden, damit die aktuelle Speicherposition reflektiert wird. Dies gilt auch für Linux-Maschinen, bei denen die Speicherposition üblicherweise /usr/IBMdb2xml lautet.
- Auf der Seite für die Eigenschaften der Webservice-DADX-Gruppe im Assistenten für Webservices treten Änderungen möglicherweise sofort in Kraft. Daher wurde empfohlen, dass Änderungen an den Eigenschaften der DADX-Gruppe im Assistenten für die DADX-Gruppenkonfiguration durchgeführt werden.
- Nachdem Sie eine DADX-Datei bearbeitet und geprüft haben, wird eventuell in Sicht 'Tasks' eine Nachricht mit dem Inhalt angezeigt, dass das Projekt neu erstellt werden muss. In diesem Fall müssen Sie auf mit der rechten Maustaste auf das Projekt klicken und anschließend auf Projekt erneut erstellen klicken. Gegebenenfalls ist muss dieser Vorgang ein zweites Mal ausgeführt werden, damit die Nachricht aus der Sicht 'Tasks' verschwindet.
Im Assistent für die DADX-Generierung sind zwar benutzerdefinierte Funktionen aufgelistet, jedoch besteht zum gegenwärtigen Zeitpunkt keine Unterstützung für die Generierung von DADX auf der Grundlage benutzerdefinierter Funktionen. Unterstützung ist nur für die DADX-Generierung von DAD-Dateien, gespeicherten Prozeduren und SQL-Anweisungen verfügbar. Bei Auswahl einer UDF wird eine einfache DADX-Entwurfsdatei (Skeletondatei) generiert.
Nachdem Sie eine Webservice-Datei aus 4.0.x importiert haben, werden möglicherweise die folgenden Fehlernachrichten angezeigt:
Fehler Im Teil 'result' ist ein ungültiger Wert 'anyElement' für den Typ definiert. Typendeklarationen müssen sich auf gültige Werte in einem Schema beziehen.
Fehler Im Teil 'return' ist ein ungültiger Wert 'findPatientResult' für das Element definiert. Elementdeklarationen müssen sich auf gültige Werte in einem Schema beziehen.
Fehler Im Teil 'response' ist ein ungültiger Wert 'findPatientResponse' für das Element definiert. Elementdeklarationen müssen sich auf gültige Werte in einem Schema beziehen.Sie können das Problem wie folgt umgehen:
- Löschen Sie die WSDL-Dateien.
- Generieren Sie die Webservice neu, indem Sie den Assistenten 'Webservices' erneut ausführen.
- Option 'FileNStoPkg': Die Option '-fileNStoPkg' für den Befehl 'WSDL2WebService' in der Befehlszeile funktioniert gegenwärtig nicht. Bitte verwenden Sie die Option '-NStoPkg' und schreiben Sie jede Zuordnung in der Befehlszeile aus. Eine andere Möglichkeit ist, den Webservice-Assistenten zu verwenden, wenn eine Zuordnung zwischen Namensbereichen und Paketen erforderlich ist.
- Verzeichnisname mit Leerzeichen: Vermeiden Sie die Ausführung von 'WSDL2WebService' aus einem Verzeichnis, dessen Name ein Leerzeichen enthält. Andernfalls wird die generierte Datei 'compile.bat' (bzw. 'compile.sh' unter Linux) nicht kompiliert.
- Client-Implementierungsdeskriptoren und WSDL-Dateien: Nach der Ausführung von 'Bean2WebService', 'EJB2WebService' und 'WSDL2WebService' befinden sich die clientseitigen Implementierungsdeskriptoren ('webservicesclient.xml', 'ibm-webservicesclient-bnd.xmi', 'ibm-webservicesclient-ext.xmi' und '_mapping.xml') in Verzeichnis /META-INF der Clientseite. Falls eine verwaltete Clientanwendung erstellt werden soll, sollte die folgende Vorgehensweise befolgt werden:
- Um den verwalteten Client in Form eines EJB- oder J2EE-Anwendungsclient auszuführen, müssen alle Implementierungsdeskriptoren unter META-INF des Archivs gepackt werden und zuzüglich die WSDL der Serviceseite (unter WEB-INF/wsdl, sofern sich der Service im Web-Container befindet, oder unter META-INF/wsdl, wenn sich der Service im EJB-Container befindet) in das Verzeichnis META-INF/wsdl des Client-Projekts kopiert werden.
- Um den verwalteten Client innerhalb des Web-Containers auszuführen, müssen alle Implementierungsdeskriptoren in WEB-INF des Clientarchivs gepackt werden (normalerweise in WAR-Format oder als Webprojekt in WebSphere Studio). Die WSDL-Datei muss außerdem von der Serviceseite nach WEB-INF/wsdl kopiert werden. Darüber hinaus muss die Datei 'webservicesclient.xml' manuell bearbeitet werden (mit einem Texteditor oder - bei WebSphere Studio - mit dem XML-Editor), wobei alle Vorkommen von 'META-INF' in 'WEB-INF' geändert werden müssen.
KLassenname mit Unterstreichungszeichen: Wenn ein Webservice von einer JavaBean oder EJB erstellt wird und der Klassenname der Service-Bean ein Unterstreichungszeichen enthält sowie der nachfolgende Buchstabe Kleinschreibung aufweist (wie zum Beispiel in test.Simple_bean), dann kann der Service nicht auf WebSphere Application Server gestartet werden. Das Problem wird umgangen, indem entweder für die Service-Bean ein Name ohne Unterstreichungszeichen verwendet wird oder aber für den ersten Buchstaben nach dem Unterstreichungszeichen die Großschreibung verwendet wird (wie zum Beispiel in test.Simple_Bean).
- Wenn Sie ein Szenario für die Erstellung eines Webservices durchblättern, ohne dass sich ein Web-Server im Arbeitsbereich befindet, bewirkt das Klicken auf die Schaltfläche 'Zurück' auf der dritten Seite, dass die Schaltfläche 'Weiter' inaktiviert wird. Das Problem kann umgangen werden, indem die Arbeit mit dem Assistenten abgebrochen wird und der Assistent neu gestartet wird. Um das Problem zu vermeiden, erstellen Sie den Server und die Konfiguration, bevor Sie das Webservice-Szenario starten, oder verzichten Sie darauf, auf der dritten Seite auf die Schaltfläche 'Zurück' zu klicken, wenn kein Web-Server vorhanden ist.
- Wenn in der Workbench auf eine Java-Datei geklickt wird, generiert die Aktion in dem Dialogfenster Beispielanwendung generieren im Menü 'Webservices' JSPs für Webservice-Beispiele für einen IBM SOAP-Proxy. Um JSPs für Webservice-Beispiele für die anderen Webservice-Laufzeiten zu generieren (IBM WebSphere 5.0.2 und Apache Axis 1.0), klicken Sie mit der rechten Maustaste auf eine WSDL-Datei und wählen Sie im Webservices-Menü im Dialogfenster die Aktion Client generieren aus. Wählen Sie beim Arbeiten in diesem Assistenten die Option Generierten Proxy testen aus.
Wenn Skeletons oder Clients aus einer WSDL-Datei generiert werden, über relative Importe verfügt und durch HTTP-Basisauthentifizierung geschützt ist, wird eine Fehlernachricht angezeigt, deren Inhalt besagt, dass die WSDL-Datei nicht aufgelöst werden kann, selbst wenn die korrekte Benutzer-ID und das entsprechende Kennwort eingegeben werden. Das Problem besteht darin, dass Benutzer-ID und Kennwort nur zum Abrufen der WSDL-Originaldatei verwendet werden, nicht aber der Dateien, die diese Datei importiert.
Dieses Problem kann umgangen werden, indem zuerst die WSDL-Datei sowie alle Dateien, die von der WSDL-Datei importiert werden, in die Workbench heruntergeladen werden, und erst anschließend ein Skeleton oder ein Client aus der heruntergeladenen WSDL-Datei generiert wird.
- Keine Unterstützung für WSDL: Das Hinzufügen von WSDL zur Endpunkt-URL eines Webservices, der auf WebSphere v5.0.2 implementiert wurde und in der Testumgebung oder einer fernen Serverumgebung ausgeführt wird, wird zum Abrufen der WSDL-Datei für den implementierten Webservice nicht unterstützt. Die generierte WSDL-Datei befindet sich im Verzeichnis 'WebContent/WEB-INF/wsdl' des Webprojekts für den JavaBean-Webservice und im Verzeichnis 'ejbModule/META-INF/wsdl' des EJB-Projekts für den EJB-Webservice. Ist die WSDL-Bereitstellung von einem Webprojekt erforderlich, kann der Benutzer entweder auf die Kopie der WSDL-Datei im Verzeichnis 'WebContent/wsdl' des Webprojekts verweisen oder eine eigene Position unter dem Verzeichnis 'WebContent' erstellen und die WSDL von dem Webprojekt bereitstellen.
- Vorhandensein einer Dienstprogramm-JAR oder mehrerer Quelleordner: Wenn ein Webservice von einer JavaBean oder EJB erstellt wird, werden möglicherweise nicht erforderliche Dateien in dem Modul generiert, falls das Webprojekt mehrere Quellenordner enthält oder falls sich die Beans in einer Dienstprogramm-JAR in der EAR-Datei befinden. Da diese generierten Dateien bereits in dem Modul vorhanden sind (und zwar entweder in der Dienstprogramm-JAR oder in einem anderen Quellenordner), müssen sie gelöscht werden, damit das Projekt richtig kompiliert und der Webservice korrekt ausgeführt werden kann. Eine andere Lösung besteht darin, die Quellenordner in einen Ordner zusammenzufassen oder die Beans aus der Dienstprogramm-JAR in den Quellenordner zu kopieren.
- Array in 'RPC/literal' nicht unterstützt: Beim Erstellen eines 'RPC/literal'-Service darf die Methodensignatur keinen Array enthalten. Tut sie dies dennoch, kann der Service nicht mit dem generierten Client-Code aufgerufen werden. Zu diesem Problem gibt es derzeit keine Fehlerumgehung. Bitte versuchen Sie, 'document/literal' oder 'RPC/encoded' zu verwenden, falls möglich.
- Methodenüberladung in 'document/literal' nicht unterstützt: Methodenüberladung (identischer Methodenname, andere Eingabeparameter) wird für die Erstellung eines 'document/literal'-Services nicht unterstützt. Zu diesem Problem gibt es derzeit keine Fehlerumgehung. Bitte versuchen Sie, 'RPC/literal' oder 'RPC/encoded' zu verwenden, falls möglich.
- WSDL-Import: Die WSDL-Importanweisung kann nur absolute URLs oder relative URLs in demselben Verzeichnis haben. Der relative Import in folgendem Format wird zum Beispiel nicht unterstützt:
<import namespace="http://beliebigerNamensbereich/" location="../beliebigeDatei.wsdl"/>- Bindungselement vor Element 'portType': Wenn Sie einen Client-Proxy oder ein Skeleton aus einer WSDL-Datei generieren, die ein Bindungselement vor dem Element 'portType' enthält, wird der folgende Fehler gemeldet: 'Fehler beim Gernerieren der Java-Dateien und Implementierungsdeskriptoren aus einer WSDL-Datei. (Detail: Doppelt vorhandener Operationsname'
- Abstrakte Elemente: Wenn Skeletons aus einer WSDL-Datei mit einer Operation generiert werden, die abstrakte Elemente oder Typen verwendet, werden die generierten JavaBeans nicht kompiliert.
- Typen ohne Standard-JAX-RPC-Zuordnungen: Wenn Skeletons aus einer WSDL-Datei mit Operationen generiert werden, die 'inout'-Parameter von Typen enthält, die über keinerlei Standard-JAX-RPC-Zuordnungen verfügen, wird die generierte Implementierungs-Bean nicht kompiliert. Das Problem wird dadurch verursacht, dass 'javax.xml.soap.SOAPElement' bei seiner Erstellung aus 'javax.xml.soap.SOAPFactory' eine Ausnahmebedingung 'javax.xml.soap.SOAPException' auslöst. Da die Implementierungs-Bean diese Ausnahmebedingung nicht abfängt oder erneut auslöst, wird die Bean nicht kompiliert.
- Derselbe Schematyp für Eingabe und Ausgabe: Wenn Skeletons aus einer WSDL-Datei generiert werden, die denselben Schematyp für ihre Eingabe-/Ausgabenachrichten und Fehlernachrichten verwendet, funktionieren die generierten Artefakte nicht während der Laufzeit. Um dieses Problem zu vermeiden, sollten Sie XML-Schematypdefinitionen nicht gemeinsam für Eingabe-/Ausgabenachrichten und Fehlernachrichten verwenden.
- XSD-Elementverweise mit 'minOccurs' und 'maxOccurs': Wenn Sie Skeletons aus einer WSDL-Datei generieren, verwenden Sie keine XSD-Elementverweise mit benutzerdefinierten Werten für 'minOccurs' und 'maxOccurs' (<element ref="..." minOccurs="0" maxOccurs="unbounded"/>). Die Verwendung solcher Elemente hat eine 'java.util.MissingResourceException'-Ausnahmebedingung beim Starten des Servers zur Folge.
- Ausgegebene Beans mit anderen APIs als die Service-Bean: Wenn die vom Emitter generierten Beans andere APIs haben als die Service-Bean, wenn ein Webservice aus einer JavaBean oder EJB erstellt wird, tritt möglicherweise ein Laufzeitfehler der folgenden Art auf:
The method is undefined. (Die Methode ist nicht definiert.)
Couldn't find a matching Java operation. (Es konnte keine übereinstimmtende Java-Operation gefunden werden.)
Service-Beans, die andere APIs als die generierten Beans haben, sind zum Beispiel:
- Beans mit 'public'-Feldern,
- 'boolean'-Felder mit Abruffunktion namens 'getBooleanValue an Stelle von isBooleanValue,
- Methodenname, bei dem der Name der Methode groß geschrieben ist
Verknüpfung 'document/literal' mit aktiviertem Umbruch: Wenn Sie einen Bottom-up-Webservice mit einer 'document/literal'-Verknüpfung erstellen, ist die Umbruchoption standardmäßig aktiviert. Sie stoßen möglicherweise auf Interoperabilitätsprobleme, falls mehrere Eingaben mit unterschiedlichen Typen oder überhaupt keine Eingabe vorhanden sind. Sie umgehen das Problem, indem Sie 'RPC/literal' verwenden. JavaBean in Kleinschreibung oder mit Unterstreichungszeichen: Wenn ein Webservice aus einer JavaBean mit einem klein geschriebenen Dateinamen oder einem Unterstreichungszeichen gefolgt von einem klein geschriebenen Buchstaben erstellt wird, wird folgender Fehler gemeldet:
Fehler beim Generieren der Java-Dateien und Implementierungsdeskriptoren aus einer WSDL-Datei.
In diesem Zusammenhang wird auf die E-/A-Ausnahmebedingung getOutputStream() IOException hingewiesen.Unterschiedliche Sicherheitskonfigurationen: Generieren Sie keine Webservices mit unterschiedlichen Sicherheitskonfigurationen in demselben Modul/Projekt. Verwenden Sie für jeden Webservice ein anderes Projekt.
Wenn WebSphere Application Server V5.0 als Host für einen DADX-Webservice verwendet wird, sollte die Datei 'group.properties' für die DADX-Gruppe die folgende Eigenschaft für 'initialContextFactory' aufweisen:
initialContextFactory=com.ibm.websphere.naming.WsnInitialContextFactoryDarüber hinaus muss zu der Datei 'web.xml' für das Projekt, in dem sich die DADX-Gruppe befindet, Folgendes hinzugefügt werden. (Hierbei wird vorausgesetzt, dass der JNDI-Datenquellenname 'jdbc/hospital' ist.)
<resource-ref id="ResourceRef_1058550453092">
<res-ref-name>jdbc/hospital</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>CONTAINER</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
Wenn der Universelle Testclient nicht in der Lage ist, die von der WebSphere v5.0.2- o der Axis-Laufzeit generierte Client-Locator-Klasse voher zu laden, liegt dies darin begründet, dass der Name der JavaBean-Klasse im Service-Webprojekt identisch mit dem Namen der SEI-Klasse im Client-Webprojekt ist. Führen Sie die folgenden Schritte aus, um dieses Problem zu umgehen:
- Löschen Sie das Client-Webprojekt aus dem Arbeitsbereich.
- Klicken Sie mit der rechten Maustaste aus das Client-Webprojekt, und klicken Sie auf 'Löschen'.
- Suchen Sie die Datei 'application.xml' im EAR-Projekt, und doppelklicken Sie auf die Datei, um Sie im Editor für Implementierungsdeskriptoren von Anwendungen zu öffnen. Wählen Sie das Client-Webprojektmodul aus, und klicken Sie auf 'Entfernen'. Schließen Sie den Editor und speichern Sie die Änderungen.
- Erstellen Sie das Client-Webprojekt unter einer anderen EAR, wobei der EAR-Projektname in alphabetischer Sortierung vor dem Namen des Service-EAR-Projekts stehen muss. Wenn der Name des Service-EAR-Projekts 'DefaultEAR' lautet, erstellen Sie das neue EAR-Projekt mit dem Namen 'ClientEAR'.
- Führen Sie den Assistenten für Webservices erneut aus.
Die Vorgaben zum Überschreiben von Dateien, zur Erstellung von Dateien und zum automatischen Check-out von Dateien werden nicht berücksichtigt, wenn die Webservices unter Verwendung der WebSphere v5.0.2- und der Axis-Laufzeit erstellt werden. Die Erstellung von Ordnern ist zu jedem Zeitpunkt zulässig und der automatische Check-out von Dateien ist nie aktiviert.
Wenn Sie die WebSphere v5.0.2-Laufzeit verwenden, werden die WSDL-Datei, die SEI- und Implementierungsartefakte (Parallel-Seriell-Umsetzer und Seriell-Parallel-Umsetzer) immer überschrieben. Die Entwicklungsartefakte (Service-Bean, Beans komplexen Typs sowie Holder- und Unterstützungsklassen) werden nie überschrieben. Es wird jedoch trotzdem eine Warnung mit dem Inhalt angezeigt, dass die Implementierungsdekriptoren überschrieben werden, sofern sie vorhanden sind. In diesem Fall kann die Meldung mit 'OK' bestätigt werden, sodass die Implementierungsdeskriptoren überschrieben werden, und anschließend kann mit dem Szenario fortgefahren werden. Soll vermieden werden, dass die Deskriptoren überschrieben werden, muss 'Abbrechen' gewählt werden.
Wenn die Apache Axis 1.0-Laufzeit verwendet wird, generieren die Axis-Emitter jedes Mal alle Server-/Client-Java-Dateien ('deploy.wsdd' und 'undeploy.wsdd'). WSDL2Java für das Szenario für die Servicegenerierung generiert nur die Skeleton-Implementierungsdatei, sofern diese nicht schon vorhanden ist. Ist diese Implementierung bereits vorhanden, wird sie nicht überschrieben.
Die Erstellung von Webservices unter Verwendung der Apache Axis 1.0-Laufzeit beruht auf den Emittern Java2WSDL und WSDL2Java, die Axis 1.0 zur Verfügung stellt. Die Unterstützung für 'document/literal' und 'document/literal (wrapped)' ist in Axis 1.0 problematisch. Daher sollte bei der Erstellung von Webservices unter Verwendung der Apache Axis 1.0-Laufzeit 'RPC/encoded' verwenden.
Wenn Sie angepasste Zuordnungen zwischen Paket und Namensbereich definieren und dann auf die Schaltfläche Hinzufügen klicken, werden in der Tabelle das falsche (Standard-)Paket und der falsche (Standard-)Namensbereich angezeigt. In diesem Fall sollten sie diese Standardwerte überschreiben und Ihre eigene Paket- und Namensbereichszuordnung eingeben.
Beim Generieren von Webserviceentwürfen oder Proxys aus WSDL, die denselben Namen für eines ihrer <service>- und <port>-Elemente verwendet, sollten sie keine Beispiel-JSPs als Testclient verwenden. Die generierte Beispiel-JSP enthält Fehler und lässt keine Kompilierung zu. Jeder Versuch, die Beispiel-JSPs auf dem Server auszuführen, werden den FEHLER 500 im Browser zur Folge haben, der darauf hinweist, dass die Beispiel-JSPs nicht geladen werden können. Außerdem werden Ausnahmebedingungen in der Serverkonsole ausgelöst, die angeben, dass der Servlet-Container die Beispiel-JSPs nicht kompilieren konnte.
Wenn das Befehlszeilentool unter Windows in deutscher Sprache ausgeführt wird, werden bestimmte Zeichen in der Ausgabe als '?' angezeigt. Dieses Zeichen stellt vermutlich einen deutschen Umlaut dar.
Der Assistent für die Erstellung von Webservices kann bei der WSDL-Generierung fehlgeschlagen, wenn der Hostname 'localhost' nicht auf dem Computer definiert ist. Möglicherweise kann auch UTC nicht erfolgreich gestartet werden, wenn 'localhost' nicht definiert ist.
Unter Windows muss der folgende Eintrag in der Datei [INSTALLATIIONSLAUFWERK]\WINNT\system32\drivers\etc\hosts vorhanden sein:
127.0.0.1 localhost
Unter Linux muss der folgende Eintrag in der Datei /etc/hosts vorhanden sein:
127.0.0.1 localhost
Die IBM SOAP-Laufzeit sollte vorwiegend aus Gründen der Abwärtskompatibilität verwendet werden. Es wird stark angeraten, dass Sie für alle Produktionsziele und -zwecke den Webservice-Assistenten mit der IBM WebSphere 5.0.2-Laufzeit verwenden. Bei Verwendung des Webservice-Assistenten mit der IBM SOAP-Laufzeit können Sie auf folgende dauerhafte Einschränkungen treffen:
- Ein WSDL-Dokument aus einer Java-Bean generieren
- Für char und java.lang.Character ist erforderlich, dass Sie angepasste Zuordnungen angeben, da keine Standardzuordnungen von char oder java.lang.Character zu WSDL XSD vorhanden sind.
- Die primitiven Wrapper-Typen java.lang.Boolean, java.lang.Byte, java.lang.Short, java.lang.Integer, java.lang.Long, java.lang.Float und java.lang.Double können nicht parallel zu ihren entsprechenden einzelnen primitiven Typen boolean, byte, short, int, long, float und double über alle Eingabeparameter einer Service-Bean hinweg existieren. So kann zum Beispiel eine Service-Bean, in der sowohl java.lang.Integer als auch int an beliebiger Stelle als Eingabeparametertypen erscheinen, nicht in einen vollständigen Webservice umgesetzt werden. Wenn Sie versuchen, mit dem Assistenten für Webservices einen Webservice aus dieser Art von Service-Bean zu erstellen, wird eine Warnung ausgegeben, es sei denn, die Methoden, die die primitiven Typen oder Wrapper-Typen enthalten, sind im Assistenten auf der Webservice-Seite für Java-Bean-Methoden nicht ausgewählt. Sie müssen jedoch sicherstellen, dass diese Methode(n) nicht ausgewählt ist bzw. sind, wenn die Webservice-Seite für Java-Bean-Methoden erstmals angezeigt wird. Wenn Sie nach Anzeige der Warnung auf diese Seite zurückkehren und diejenigen Methoden entfernen, die die Probleme verursachen, resultiert dies unter Umständen in der Erstellung eines unvollständigen Webservice. Sollte dies der Fall sein, muss der Assistent neu gestartet werden, so dass die richtigen Methoden ausgewählt werden können, wenn die Webservice-Seite für Java-Bean-Methoden erstmals angezeigt wird.
- Mehrdimensionale Arrays werden nicht unterstützt. Als Alternative können in Java Java-Beans zwischen den Dimensionen eingefügt werden. Anstelle von MyType[][] kann beispielsweise das Muster MyArray[] verwendet werden, wobei MyArray eine Eigenschaft des Typs MyType[] besitzt.
- Für eine Methode mit einer Eingabeargumentenliste mit einer Mischung aus DOM-Element- und einfachen Bean-Typen ist der Eintrag von einer oder mehreren angepassten Zuordnungen erforderlich. Die WSDL-Spezifikation (Web Services Definition Language) für Version 1.1 unterstützt eine Verschlüsselungsdarstellung für alle Eingabeteile (Parameter). Die Laufzeit von SOAP (Simple Object Access Protocol) Version 2.2 hat keine Standardzuordnungsunterstützung für DOM-Elemente mit SOAP-Verschlüsselung für primitive Typen und Beans mit Literal-XML-Verschlüsselung.
- Wenn Sie beim Konfigurieren einer angepassten Zuordnung versuchen, eine Serialisierungs- oder Entserialisierungsklasse über die SOAP-Laufzeit zu verwenden (d. h., Klassen aus dem Paket org.apache.soap.encoding.soapenc), kann der folgende Fehler angezeigt werden: 'Die ausgewählte Serialisierungs-/Entserialisierungsklasse kann von diesem Projekt aus nicht geladen werden'. In diesem Fall befindet sich die Datei soap.jar höchstwahrscheinlich nicht im Erstellungspfad Ihres Webprojekts. Um das Problem zu korrigieren, brechen Sie den Assistenten ab, und verwenden Sie den Eigenschaftsdialog des Webprojekts, um Folgendes zum Erstellungspfad des Webprojekts hinzuzufügen: WS_installationsverzeichnis\wstools\eclipse\plugins\com.ibm.etools.webservice\runtime\soap.jar. Versuchen Sie anschließend, den Webserviceassistent neu zu starten.
- Angepasste Zuordnung wird für verschachtelte komplexe Typen nicht unterstützt. Obwohl verschachtelte Typen auf der Zuordnungsseite des Assistenten angezeigt werden, werden angepasste Zuordnungen für diese Typen ignoriert.
- Beim Erstellen eines Webservices aus einer Java-Klasse, deren Schnittstelle einen abstrakten Java-Typ enthält, kann es vorkommen, dass auf der Seite für Webservicezuordnung von Java nach XML das Entserialisierungsfeld für den abstrakten Typ fälschlicherweise auf org.apache.soap.encoding.soapenc.BeanSerializer eingestellt wird. Dies führt zum Fehlschlagen während der Laufzeit, da der Entserialisierungscode in der Klasse 'BeanSerializer' nicht in der Lage ist, ein Exemplar des abstrakten Typs zu erstellen. Um dies zu vermeiden, wählen Sie gegebenenfalls die Option 'Angepasste Zuordnung' für den Typ aus, und ändern Sie das Entserialisierungsfeld auf den Namen einer Klasse, die zur Entserialisierung des abstrakten Typs geschrieben wurde.
- Die Webservice-Tools unterstützen aktuell nicht die Erstellung von Webservices aus Java-Beans, die verschachtelte innere Klassen enthalten (d. h. innerhalb einer Klasse auf höchster Ebene definierte innere Klassen). Als Umgehung sollten Sie die inneren Klassen in die Klassen auf höchster Ebene in separaten Java-Dateien verschieben.
- Wenn ein Webservice aus einer JavaBean erstellt wird, die andere JavaBeans mit den Eigenschaften 'Vector', 'Hashtable' oder 'Map' verwendet, wird XSD mit komplexen Typen (complexTypes) generiert, die die Typen 'Vector' und 'Map' des Namensbereichs 'http://xml.apache.org/xml-soap' enthalten. Da gegenwärtig kein Schema für diesen Namensbereich existiert, verursacht das XSD-Prüfprogramm Fehler und Warnungen wie folgt:
Diese Fehler und Warnungen stören nicht die korrekte Verarbeitung der WSDL und XSD durch die Assistenten für Webservices. Die Typen 'Map' und 'Vector' werden ihren Java-Gegenstücken korrekt zugeordnet. Beachten Sie, dass andere Softwareanbieter eventuell Schwierigkeiten bei der Verarbeitung von WSDL oder XSD haben, die diese Typen enthalten, da http://xml.apache.org/xml-soap kein Namensbereich ist, der von den WSDL 1.1- oder SOAP 1.1-Spezifikationen anerkannt wird. Um die Interoperabilität zu steigern, sollten Sie erwägen, die Java-Objektgruppenklassen an Arrays und Beans anzupassen und anschließend die Webservices von den Adaptern zu erstellen.
- Error src-resolve: Cannot resolve the name 'xsd2:Vector' to a(n) type definition component. (Fehler bei Quellauflösung: Der Name 'xsd2:Vector' kann nicht in einen (n)-Typ-Definitionskomponente aufgelöst werden.)
- Warning src-import.0: Failed to read imported schema document 'null'. (Warnung bei Quellimport.0: Das importierte Schemadokument 'null' konnte nicht gelesen werden.)
- Java-Artefakte aus einem WSDL-Dokument generieren
- Die Unterstützung ist auf ein part-Element pro input- oder output-Element begrenzt. Mehrere logische part-Elemente in einer Ein- oder Ausgabenachricht werden nicht unterstützt. Das erste part-Element wird verarbeitet und die übrigen werden ignoriert.
- Beim Generieren von Webserviceentwürfen oder Proxies aus WSDL, die den Typ 'base64Binary' aus dem XSD-Namensbereich (http://www.w3.org/2001/XMLSchema) verwenden, verwendet die Webservicelaufzeit tatsächlich die xsi:type base64 aus dem Namensbereich soapenc (http://schemas.xmlsoap.org/soap/encoding/). Im Allgemeinen sind die beiden Typen frei austauschbar. Es ist jedoch möglich, dass die Differenz zwischen dem Typ in der Nachricht und dem Typ im Schema dazu führt, dass die Nachricht von einigen SOAP-Protokoll-Laufzeiten zurückgewiesen wird. Sollte dies der Fall sein, können Sie einen Parallel-Seriell-Umsetzer ähnlich dem Base64Serializer von Apache SOAP manuell erstellen. Dieser Umsetzer schreibt jedoch xsd:base64binary anstelle von soapenc:base64.
- Java-Bean-Gerüste können nicht kompiliert werden, wenn sie aus WSDL-Dokumenten generiert wurden, die Namen für Operationen und Komponenten beinhalten, die keine gültigen Java-Kennungen darstellen. Für eine erfolgreiche Erstellung eines Java-Bean-Gerüstes müssen die WSDL-Operations- und Komponentennamen aus gültigen Java-Kennungen bestehen.
- Die Webservice-Assistenten verwenden beim Generieren von WSDL standardmäßig 'http'-URIs. Manche WSDL-Dokumente aus anderen Tools verwenden jedoch Webservice-URIs, SOAP-Action-URIs oder URIs für den Zielnamensbereich, die andere Schemata als 'http' enthalten, z. B. 'urn'. Beim Generieren von Proxies oder Gerüsten aus WSDL, die Nicht-http-URIs enthalten, ordnen die Webservice-Assistenten die URIS unter Umständen dem Java-Paket 'com.example' anstatt einem bedeutenderen Paket zu. In einigen Fällen können die Webservice-Assistenten solche URIs überhaupt nicht bearbeiten und generieren den Fehler 'IWAB0234E Ein interner Fehler ist aufgetreten.' ('IWAB0234E An internal error occured.')
- Beim Generieren von Java-Proxies und Java-Gerüsten aus WSDL haben Sie nun die Möglichkeit, die XSD-internen Typen 'boolean', 'byte', 'short', 'int', 'long', 'float' und 'double' zu den 'java.lang'-Wrappertypen zuzuordnen (z. B. java.lang.Integer) anstatt zu den Java-Basislementen (z. B. 'int'). Die Webservice-Assistenten ordnen sich standardmäßig den Java-Basiselementen zu. Damit sich die Assistenten stattdessen den 'java.lang'-Wrapperklassen zuordnen, öffnen Sie Fenster -> Benutzervorgaben -> Webservices -> Codegenerierung, und aktivieren Sie die Option Einfache XML-Datentypen zu java.lang-Wrapperklassen zuordnen.
- Wenn Sie eine angepasste Zuordnung von einem Java-Typ zu einem XSD-Typ bei Erstellung eines Webservices von einer JavaBean oder EJB angeben, wird im Feld für die Bean-Klasse automatisch der vollständige Name des Java-Typs angezeigt. Diese Angabe kann nicht bearbeitet werden. Bei der angepassten Zuordnung eines Java-Arrays liegt der Name der Bean-Klasse in Arrayformat vor, zum Beispiel 'java.lang.String[]', und wird als solcher in die '.isd'- und 'dds.xml'-Implementierungsdeskriptordateien ausgegeben. Dieses Format von Klassennamen wird von der SOAP-Laufzeit nicht korrekt verarbeitet und verursacht ähnliche Fehler wie den folgenden:
Deployment error in SOAP service http://tempuri.org/webservice.AddressBook: class name java.lang.String[] could not be resolved: java.lang.String[]
(Entwicklungsfehler in SOAP-Service http://tempuri.org/webservice.AddressBook: Klassenname java.lang.String[] konnte nicht aufgelöst werden: java.lang.String[])Demzufolge ist es nicht möglich, eine angepasste Zuordnung des Parallel-Seriell-Umsetzers für einen Java-Array auf der Seite des Services auszuführen. Eine Teillösung besteht darin, das Feld für die Klasse des Parallel-Seriell-Umsetzers für die angepasste Zuordnung leer zu lassen. Dadurch wird die Generierung des Klassennamens für den Array im Implementierungsdeskriptor unterdrückt, was die Ausführung des Services erlaubt. Beachten Sie, dass die Klasse des Seriell-Parallel-Umsetzers und die Möglichkeit der angepassten Zuordnung des Seriell-Parallel-Umsetzers von diesem Problem und der entsprechenden Fehlerumgehung nicht betroffen sind.
- Überlegungen zur Laufzeit
- Wenn Sie die Benutzervorgabe für Webservices-Codegenerierung 'Elementbasierte Zuordnung aktivieren' auswählen und die Implementierung auf einem WebSphere Application Server der Version 4 ausgewählt hatten, erhalten Sie unter Umständen folgenden Eintrag in der ISD-Datei und dds.xml:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x=""
qname="x:some-name"
xml2JavaClassName="some-serializer"/>Der XML-Editor markiert unter Umständen den folgenden Fehler:
Der Wert des Attributs 'xmlns:x' ist ungültig. Vorangestellte Namensbereichsbindungen sind unter Umständen nicht leer. (The value of the attribute 'xmlns:x' is invalid. Prefixed namespace bindings may not be empty.)
Dies bedeutet keinen Schaden für den WebSphere Application Server V4. Versuchen Sie jedoch nicht, diese dds.xml auf einem anderen Server zu implementieren, der Xerces 2.x (XML4J 4.x) oder höher verwendet (z. B. WebSphere Application Server V5). Ansonsten erhalten Sie einen ähnlichen Xerces-Parsefehler, wenn der Server die dds.xml-Datei lädt. Sie sollten die dds.xml-Datei erneut generieren, indem Sie die Schritte des Webservice-Szenario befolgen und den richtigen Servertyp auswählen. Damit wird die korrekte dds.xml-Datei für diesen Servertyp generiert.
Ebenso erhalten Sie einen ähnlichen Xerces-Parsefehler, wenn Sie versuchen, Webservice von dieser ISD-Datei zu implementieren. Als Umgehung können Sie die Datei manuell bearbeiten, sodass sie folgendes Format hat:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
qname="some-name"
xml2JavaClassName="some-serializer"/>
- Beim Aufrufen eines von einer Java-Bean oder EJB erstellten Webservice erhalten Sie eine SOAPException mit einer targetException wie z. B.:
'java.lang.IllegalArgumentException: Instanzieren nicht möglich...' ('java.lang.IllegalArgumentException: Unable to instantiate...')
Das Problem ist möglicherweise, dass die als Webservice freigegebene Methode eine Java-Bean ohne öffentlichen Standardkonstruktor als Parameter und/oder Rückgabetyp enthält. Ein öffentlicher Standardkonstruktor wird benötigt, damit die SOAP-Laufzeit das Objekt als Teil des Entserialisierungsprozesses konstruiert.- Die aktuell in das Webprojekt implementierten Sicherheitsdateien cl-ver-config.xml und sv-ver-config.xml stammen aus WebSphere Version 4.0 und passen nicht genau zu den DTDs. Die Dateien können jedoch sowohl für WebSphere Version 4.0 als auch für WebSphere Version 5.0 verwendet werden, trotz der Gültigkeitsüberprüfungsfehler, die besagen, dass 'xmlns:ds' oder 'xmlns:SOAP-SEC' deklariert werden müssen.
- Wird die Serverkonfiguration in einem Editor geöffnet, kann der Webservice-Assistent unter Umständen den Server nicht starten, da das Webservice-Webprojekt nicht zu der Serverkonfiguration hinzugefügt wurde. Das Problem kann durch Schließen des Serverkonfigurationseditors gelöst werden.
- ISD-Webservices
- Nach dem Angeben einer angepassten Zuordnung beim Erstellen von Java- oder EJB-Webservices werden die Informationen zur angepassten Zuordnung, mit Ausnahme der URL der XSD-Position in der ISD-Datei gespeichert. Die Informationen werden abgerufen, wenn Webservices aus dieser ISD-Datei erstellt werden. Geben Sie daher beim Erstellen von Webservices aus einer ISD-Datei auf der Seite 'Zuordnungen von Java zu XML für Webservice' des Assistenten die URL der XSD-Position manuell an.
Wenn Sie einen Webservice aus einer JavaBean oder EJB erstellen und dabei IBM SOAP als Laufzeit für den Service und Apache Axis 1.0 als Laufzeit für den Client angeben, wird möglicherweise der folgende Fehler angezeigt:
WSDL Not found (WSDL nicht gefunden)
Das Problem kann vermieden werden, wenn Sie zuerst den Webservice generieren, ohne dafür die Generierung eines Proxys auszuwählen. Erstellen Sie anschließend einen Webservice-Client von der generierten WSDL-Datei.
Wenn Sie im Assistenten 'Webservice-Client' arbeiten und auf der Seite 'Konfiguration der Clientumgebung' auf 'Fertig stellen' klicken, wird folgender Fehler angezeigt:
'null' kann nicht aufgelöst werden
Dieses Problem kann umgangen werden, indem Sie auf dieser und der nachfolgenden Seite auf 'Weiter' klicken und erst dann auf 'Fertig stellen'.
In den Spickzetteln 'Einen WS-I-kompatiblen Webservice erstellen, testen und auswerten' und 'Erstellen eines Webservices aus einer WSDL-Datei' sollten Sie, falls Sie die Datei 'HelloService.wsdl' aus dem Verzeichnis wsad_install/wstools/eclipse/plugins/com.ibm.etools.cs.wsdl.content_5.1/examples verwenden, die Position des Service-Ports in Übereinstimmung mit den folgenden Angaben für die verschiedenen Laufzeiten ändern:
IBM Soap:
Position = 'http://localhost:9080/HelloWorldSample/servlet/rpcrouter'
Apache Axis- oder WebSphere 5.0.2-Laufzeit
Position = 'http://localhost:9080/HelloWorldSample/services/Hello_Port'
Wenn Sie eine eigene WSDL-Datei importieren, stellen Sie bitte sicher, dass die Position für die ausgewählte entsprechend der obigen Angaben korrekt angegeben ist.
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved. (C) Copyright IBM Deutschland GmbH 2000, 2003. Alle Rechte vorbehalten.