Für die Übertragung von SOAP-Nachrichten zwischen Clients und Servern können Sie
als Alternative zu SOAP over HTTP das Transportprotokoll SOAP over Java™ Message Service (JMS) verwenden.
Informationen zu diesem Vorgang
Dieses Produkt unterstützt die Spezifikation des neu entstehenden Branchenstandards SOAP-over-JMS-Protokoll. Die Spezifikation
"SOAP over JMS" stellt einen Standardsatz von Interoperabilitätsrichtlinien für die Verwendung
eines JMS-kompatiblen Transports mit
SOAP-Nachrichten bereit, um die Interoperabilität zwischen den Implementierungen verschiedener
Lieferanten zu ermöglichen. Wenn dieser Standard verwendet wird, können Client- und Serverkomponenten
unterschiedlicher Lieferanten interagieren, wenn SOAP-Anforderungs- und -Antwortnachrichten über den JMS-Transport
für JAX-WS- (Java API
for XML Web Services) und JAX-RPC-Web-Services
(Java API for XML-based RPC) ausgetauscht werden.
Mithilfe des JMS-Transports können Ihre auf Enterprise-Beans basierenden Web-Service-Clients und -Server
JMS-Warteschlangen und -Topics anstelle von HTTP-Verbindungen für die Kommunikation verwenden.
Veraltetes Feature: In früheren Versionen des Anwendungsservers wurde
ein
IBM® proprietäres
SOAP over JMS-Protokoll
für
JAX-RPC-Anwendungen (Java API for XML-based RPC) unterstützt. In WebSphere Application
Server 7.0 und höher wurde dieses proprietäre SOAP-over-JMS-Protokoll nun zu Gunsten eines aufkommenden SOAP-over-JMS-Protokolls nach
Industriestandard als veraltet gekennzeichnet.
Sie können das IBM proprietäre
SOAP-over-JMS-Protokoll zwar für Ihre JAX-WS-
(Java API for XML Web Services)
oder JAX-RPC-Web-Services
verwenden, es wird jedoch empfohlen, das neue Standardprotokoll "SOAP over JMS" zu verwenden.
Wenn Ihre Clientanwendung auf Enterprise-Beans basierende Web-Services aufruft, die von einer früheren Version
von WebSphere Application
Server unterstützt werden, müssen Sie das IBM proprietäre SOAP-over-JMS-Protokoll
verwenden, um auf diese Web-Services
zuzugreifen.depfeat
Einige Vorteile von JMS sind
im Folgenden aufgeführt:
- Reliable Messaging-Transport für die Übertragung von Anforderungs- und Antwortnachrichten.
- Flexible unidirektionale Anforderungen für Clients und Server. So muss der Server beispielsweise nicht aktiv sein, wenn der Client die unidirektionale Anforderung sendet.Unidirektionale Anforderungen können mittels eines Topic gleichzeitig an mehrere
Server gesendet werden.
- Synchrone bidirektionale Anforderungen werden für JAX-WS- (Java API for XML-Based Web Services) und JAX-RPC-Clients (Java API for XML-based RPC) unterstützt.
- Unterstützung asynchroner Anforderungen für JAX-WS-Clients.
Die Spezifikation "SOAP over JMS" definiert eine URI-Syntax für JMS-Endpunkte bei der Angabe von JMS-Zielen.
Ein JMS-Endpunkt-URL wird verwendet, um über den JMS-Transport auf JAX-WS- und JAX-RPC-Web-Services
zuzugreifen. Dieser URL gibt das JMS-Ziel und die Verbindungsfactory sowie den Namen der Portkomponente für
die Web-Service-Anforderung an.
Dieser Endpunkt-URL gleicht dem HTTP-Endpunkt-URL, der Host und Port sowie Stammkontext und Name der Portkomponente
angibt.
- Entwickeln Sie die Enterprise-Bean, die Sie als Serviceimplementierungs-Bean verwenden möchten.
- Fügen Sie für JAX-WS-Anwendungen die Annotation @BindingType zu Ihrer Endpunktimplementierungsklasse hinzu, und geben Sie
die ID der SOAP-over-JMS-Bindung für Ihren Endpunkt an. Beispiel:
@WebService
@BindingType("http://www.w3.org/2010/soapjms/")
public class MyServiceBeanImpl {
...
}
Die Annotation @BindingType wird verwendet, um anzuzeigen, welches Protokoll (SOAP) und welcher Transport (JMS)
beim Senden von Anforderungs- und Antwortnchrichten für den Endpunkt verwendet werden sollen.
- Assemblieren Sie die Enterprise-Beans.
- Assemblieren Sie eine
JAR-Datei mit Unterstützung für Web-Services aus einer Enterprise-Bean. Sie
können die Artefakte, die erforderlich sind, um das Enterprise-Bean-Modul für Web-Services zu aktivieren,
in einer JAR-Datei assemblieren.
- Assemblieren Sie eine JAR-Datei für eine Enterprise-Bean mit Unterstützung
für Web-Services zu einer EAR-Datei. Sie können die Artefakte, die zum Aktivieren
der JAR-Datei, die Web-Services unterstützt, zu einer EAR-Datei assemblieren.
- Aktivieren Sie die Enterprise-Bean-basierten Endpunkte mit dem Befehl endptEnabler. Verwenden Sie die Option -transport jms, um den Befehl endptEnabler anzuweisen,
einen MDB-Listener für jede EJB-JAR-Datei zu erstellen, die Web-Service-Implementierungs-Beans enthält.
Diese MDB (Message-Driven Bean) dient als Listener für Anforderungen, die den in der EJB-JAR-Datei enthaltenen Web-Service-Endpunkten
zugeordnet sind.
- Legen Sie die Namen und Arten der von Ihrer Anwendung verwendeten JMS-Objekte fest.
Vor der Installation Ihrer Anwendung müssen Sie Folgendes tun:
- Entscheiden Sie, ob Ihr Web-Service die Anforderungen von einer
Warteschlange oder von einem Topic empfangen soll.
- Legen Sie fest, ob ein sicheres Ziel oder ein nicht sicheres Ziel verwendet werden soll.
- Legen Sie die Namen für Ihre Warteschlangen und Topics, Verbindungsfactory und Aktivierungsspezifikation fest.
Verwenden Sie die folgenden Richtlinien bei der Festlegung der JMS-Objektnamen und -typen.
Normalerweise können Sie eine Warteschlange für den Empfang von Web-Service-Anforderungen verwenden.
- Warteschlange
- In einer Warteschlange können alle Typen von Anforderungen empfangen werden. Gültige Anforderungen sind
unidirektionale, bidirektionale und synchrone Anforderungen.
Asynchrone Anforderungen sind nur für JAX-WS-Web-Services gültig.
- Eine Warteschlange wird jeweils nur von einer einzigen EJB-JAR-Datei für den Empfang der Anforderungen
für Web-Service-Endpunkte verwendet, die in dieser EJB-JAR-Datei enthalten sind.
- Topic
- Ein Topic wird verwendet, um ausschließlich unidirektionale Anforderungen zu empfangen.
- Sie können ein Topic für mehrere EJB-JAR-Dateien gemeinsam nutzen. Jede an ein Topic gesendete Anforderungsnachricht
wird von jedem der MDB-Listener verarbeitet, die für dieses Topic konfiguriert wurden.
Das bedeutet, dass jede Anforderungsnachricht von jeder EJB-JAR-Datei verarbeitet wird, die diesem speziellen Topic zugeordnet ist.
Im folgenden Beispiel wird eine typische Konfiguration für eine einzelne EJB-JAR-Datei beschrieben, die Web-Service-Endpunkte enthält:
- Angenommen, die EJB-Datei "StockQuoteEJB.jar" enthält einen oder mehrere Web-Service-Endpunkte für den Service
"StockQuote".
- Sie haben eine einzige Warteschlange "StockQuote_Q" mit dem JNDI-Namen jms/StockQuote_Q, die
für den Empfang von Anforderungen verwendet wird.
- Sie haben eine Verbindungsfactory "StockQuote_CF" mit dem JNDI-Namen jms/StockQuote_CF, die von Clients verwendet werden kann,
um eine Verbindung zum JMS-Provider herzustellen.
- Außerdem haben Sie eine Verbindungsfactory "StockQuote_ReplyCF" mit dem JNDI-Namen jms/StockQuote_ReplyCF, die vom
MDB-Listener für die EJB-JAR-Datei verwendet wird, um eine Verbindung zum JMS-Provider herzustellen, wenn Antwortnachrichten gesendet werden.
- Sie haben eine Aktivierungsspezifikation "StockQuote_AS" mit dem JNDI-Namen jms/StockQuote_AS, die verwendet wird,
um den MDB-Listener der Datei "StockQuoteEJB.jar" der Warteschlange "StockQuote_Q" zuzuordnen.
- Definieren Sie die verwalteten JMS-Objekte..
Nachdem
Sie die Namen und Typen der JMS-Objekte festgelegt haben, können Sie mit der Administrationskonsole oder
dem Scripting-Tool wsadmin die JMS-Objekte definieren.
Es stehen verschiedene Möglichkeiten für die Verwaltung von JMS-Ressourcen zur Verfügung. Welche Methode verwendet
wird, richtet sich nach dem verwendeten JMS-Provider. Lesen Sie den Artikel zur Auswahl eines Messaging-Providers, um mehr über die
Verwaltung von JMS-Ressourcen zu erfahren.
- Implementieren Sie die Web-Service-Anwendung.
Während
der Installation müssen Sie für jede EJB-JAR-Datei, die für Web-Services aktiviert und in der EAR-Datei enthalten ist,
zwei Angaben vornehmen:
- Sie müssen den JNDI-Namen der Verbindungsfactory angeben, die der MDB-Listener verwendet, um Antwortnachrichten zu senden.
Wenn Ihr Web-Service bidirektionale Operationen enthält, muss der MDB-Listener, der mit dem Befehl endptEnabler definiert wird,
auf eine Warteschlangenverbindungsfactory zugreifen, um der Antwortwarteschlange eine Antwortnachricht hinzuzufügen.
Der MDB-Listener verwendet die Ressourcenumgebungsreferenz java:comp/env/jms/WebServicesReplyQCF.
Deshalb müssen Sie während der Installation der Anwendung den tatsächlichen JNDI-Namen der
Verbindungsfactory angeben, die vom MDB-Listener für diesen Web-Service verwendet werden soll. Im vorherigen Beispiel
ist der JNDI-Name jms/StockQuote_ReplyCF.
- Sie müssen den Namen der Aktivierungsspezifikation angeben, die der MDB-Listener verwenden soll.
Eine Aktivierungsspezifikation
ist ein Objekt, das verwendet wird, um eine JMS-Verbindungsfactory einem JMS-Ziel (Warteschlange oder Topic) zuzuordnen.
Bei der Implementierung wird eine MDB
mit der korrekten Aktivierungsspezifikation konfiguriert, sodass Nachrichten von der
Warteschlange bzw. vom Topic ordnungsgemäß an die MDB gesendet werden. Während der Implementierung können Sie den Namen der
Aktivierungsspezifikation ändern, die den einzelnen MDB-Listenern zugeordnet ist. Als Standardwert wird der in der EAR-Eingabedatei
enthaltene Aktivierungsspezifikationsname angezeigt. Wenn Sie mit dem Befehl
endptEnabler den richtigen Aktivierungsspezifikationsnamen angeben, können Sie
den Standardwert übernehmen. Andernfalls müssen Sie den richtigen Aktivierungsspezifikationsnamen angeben.
- Legen Sie fest, ob das neue Industriestandardprotokoll "SOAP over JMS" oder das
IBM proprietäre Protokoll "SOAP/JMS" verwendet werden soll.
Bewährtes Verfahren: Es empfiehlt sich, das
Industriestandardprotokoll "SOAP over JMS" zu verwenden. Das Protokoll IBM proprietäre "SOAP/JMS" ist ab diesem Release veraltet.
Wenn Ihre Anwendung jedoch mit früheren Versionen des Produkts interagieren muss, verwenden Sie das
proprietäre Protokoll.
bprac
- (Optional) Konfigurieren Sie Endpunkt-URL-Informationen für JMS-Bindungen.
Verwenden Sie die
Administrationskonsole, um ein URL-Präfix für JMS-Endpunkte zu konfigurieren, das Sie
jedem EJB-JAR-Modul in Ihrer Anwendung zuordnen können.
Der WSDL-Veröffentlicher (Publisher) verwendet diesen Abschnitt der URL-Zeichenfolge, um für jede in der
EJB-JAR-Datei definierte Portkomponente den tatsächlichen JMS-URL zu
erzeugen. Die Clients, die den Web-Service aufrufen müssen, können die veröffentlichte WSDL-Datei verwenden.
Führen Sie diesen Schritt nur aus, wenn Sie die WSDL-Datei für Ihre Anwendung veröffentlichen.
- (Optional) Veröffentlichen Sie die
WSDL-Datei für Ihre Anwendung.
Wenn Sie die WSDL-Datei veröffentlichen, werden WSDL-Dokumente
erzeugt, die Sie für die Entwicklung Ihrer Clientanwendungen verwenden können.
Der Veröffentlichungsprozess erzeugt vollständig aufgelöste
Endpunktpositions-URLs in den WSDL-Dateien.
Führen Sie diesen Schritt nur aus, wenn Sie die veröffentlichten WSDL-Dateien für die Entwicklung Ihrer Clientanwendungen benötigen.
Nächste Schritte
Entwickeln Sie einen Web-Service-Client.