Schnittstelle SAAJ (SOAP with Attachments API for Java)

Die Schnittstelle SOAP with Attachments API for Java™ (SAAJ) wird für SOAP-Messaging verwendet und unterstützt eine standardisierte Methode, um von einem Java-Programmiermodell XML-Dokumente über das Internet zu senden. SAAJ wird verwendet, um die SOAP-Nachricht während der Übertragung in der Laufzeitumgebung für den entsprechenden Kontext zu ändern.

Bewährte Verfahren: IBM® WebSphere Application Server unterstützt das Programmiermodell Java API for XML-Based Web Services (JAX-WS) und das Programmiermodell Java API for XML-based RPC (JAX-RPC). JAX-WS ist das Web-Service-Programmiermodell der nächsten Generation, das die vom Programmiermodell JAX-RPC bereitgestellte Grundlage erweitert. Durch die Verwendung des strategischen Programmiermodells JAX-WS, das ein auf Standards basierendes Annotationsmodell unterstützt, vereinfacht sich die Entwicklung von Web-Services und -Clients. Obwohl das Programmiermodell JAX-RPC und JAX-RPC-Anwendungen weiterhin unterstützt werden, sollten Sie das einfach zu implementierende Programmiermodell JAX-WS für die Entwicklung neuer Web-Service-Anwendungen und -Clients nutzen.

Das Programmiermodell Java API for XML-Based RPC (JAX-RPC) unterstützt SAAJ 1.2 für die Bearbeitung der XML.

Das Programmiermodell JAX-WS unterstützt SAAJ 1.2 und 1.3. SAAJ 1.3 beinhaltet die Unterstützung für SOAP-1.2-Nachrichten.

Die Unterschiede zwischen den Spezifikationen SAAJ 1.2 und SAAJ 1.3 sind im Artikel "Unterschiede zwischen den SAAJ-Versionen" beschrieben.

Verwendung von Nachrichten in Web-Services

Web-Services verwenden für den Nachrichtenaustausch die XML-Technologie. Diese Nachrichten entsprechen dem XML-Schema. Bei der Entwicklung von Web-Service-Anwendungen ist nur eine begrenzte Anzahl von XML-APIs für die Arbeit vorhanden, z. B. Document Object Model (DOM). Es ist effizienter, die Java-Objekte zu bearbeiten und die Serialisierung und Entserialisierung während der Laufzeit ausführen zu lassen.

Web-Services verwenden SOAP-Nachrichten, um die Fernprozeduraufrufe zwischen Client und Server darzustellen. Gewöhnlich wird die SOAP-Nachricht in eine Reihe von Java-ValueType-Geschäftsobjekten entserialisiert, die die Parameter und Rückgabewerte darstellen. Daneben stellt das Java -Programmiermodell APIs bereit, die die direkte Bearbeitung der SOAP-Nachricht durch Anwendungen und Handler unterstützen. Weil nur eine begrenzte Anzahl von XML-Schematypen von den Programmiermodellen unterstützt werden, stellt die Spezifikation das SAAJ-Datenmodell als Erweiterung für die Bearbeitung der Nachricht bereit.

Damit Sie die XML-Schematypen bearbeiten können, müssen Sie die XML-Schematypen mit einem angepassten Datenbinder Java-Typen zuordnen.

SAAJ-Schnittstelle

Die SAAJ-bezogenen Klassen sind im Paket "javax.xml.soap" enthalten. SAAJ stützt sich auf die Schnittstellen und abstrakten Klassen. Viele Klassen beginnen mit dem Aufruf von Factory-Methoden, um eine Factory, wie z. B. SOAPConnectionFactory und SOAPFactory, zu erstellen.

Fehler vermeiden Fehler vermeiden: Ist die Java-Sicherheit aktiviert und liegt keine Leseberechtigung für die Datei "jaxm.properties" vor, wenn eine SOAPFactory-Instanz über einen Aufruf von javax.xml.soap.SOAPFactory.newInstance() oder eine MessageFactoray-Instanz durch einen Aufruf von MessageFactory.newInstance() erstellt wird, tritt eine Ausnahme vom Typ SecurityException ein, und die folgende Ausnahme wird in das Systemprotokoll geschrieben:
Permission:

      /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties : access denied 
(java.io.FilePermission /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties
read)

Code: 

     com.ibm.ws.wsfvt.test.binding.addr1.binder.AddressBinder  
in  {file:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/
ahp6405Node01Cell/DataBinding.ear/address1.war/WEB-INF/lib
/addressbinder1.jar}

Stack Trace: 

java.security.AccessControlException: access denied (java.io.FilePermission 
/opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties read)
.

Die SOAPFactory ignoriert die Ausnahme und fährt mit der nächsten Methode zur Feststellung der zu ladenden Implementierung fort. Daher können Sie den Protokolleintrag für diese Sicherheitsausnahme ignorieren.

Da dieses Produkt die SOAPFactory verwendet, um andere Web-Service-Technologien, wie z. B. WS-Addressing (WS-A), WS-Atomic Transaction (WS-AT) und WS-Notification, zu unterstützen, können Sie diese SecurityException in allen Web-Service-Anwendungen, in denen die Java-Sicherheit aktiviert ist, ignorieren.

gotcha
Die am häufigsten verwendeten Klassen sind im Folgenden aufgelistet:
  • SOAPMessage: Enthält die Nachricht, sowohl die XML- als auch die Nicht-XML-Abschnitte
  • SOAPHeader: Stellt das XML-Element für den SOAP-Header dar
  • SOAPBody: Stellt das XML-Element für den SOAP-Hauptteil dar
  • SOAPElement: Stellt die anderen Elemente in der SOAP-Nachricht dar
Im Folgenden sind weitere Abschnitte der Schnittstelle SAAJ aufgelistet:
  • MessageContext: Enthält eine SOAP-Nachricht und zugehörige Eigenschaften.
  • AttachmentPart: Stellt einen binären Anhang dar.
  • SOAPPart: Stellt einen XML-Abschnitt der Nachricht dar.
  • SOAPEnvelope: Stellt das XML-Element für die SOAP-Rahmenanweisung (Envelope) dar.
  • SOAPFault: Stellt das XML-Element für SOAP-Fehler dar.

Die primäre Schnittstelle des SAAJ-Modells ist "javax.xml.soap.SOAPElement", auch "SOAPElement" genannt. Mit diesem Modell können Anwendungen ein SAAJ-Modell mit bereits vorhandenem DOM-Code verarbeiten. Außerdem können vorhandene DOM-Objekte so leichter in SAAJ-Objekte konvertiert werden.

Nachrichten, die über die Schnittstelle SAAJ erstellt werden, folgen den SOAP-Standards. Eine SOAP-Nachricht wird im SAAJ-Modell als ein javax.xml.soap.SOAPMessage-Objekt dargestellt. Der XML-Inhalt der Nachricht wird von einem javax.xml.soap.SOAPPart-Objekt dargestellt. Jeder SOAP-Abschnitt hat ein SOAP-Envelope. Dieses Envelope wird von dem SAAJ-Objekt javax.xml.SOAPEnvelope dargestellt. Die SOAP-Spezifikation definiert verschiedene Elemente im SOAP-Envelope und SAAJ definiert Objekte für diese Elemente.

Die SOAP-Nachricht kann auch Daten enthalten, die keine XML-Daten sind. Solche Daten werden als Anlage bezeichnet. Anlagen werden von SAAJ-AttachmentPart-Objekten dargestellt, auf die das SOAPMessage-Objekt zugreifen kann.

Es gibt verschiedene Gründe, aus denen Handler und Anwendungen anstelle der strikten Zuordnung die generische API SOAPElement verwenden:
  • Der Web-Service könnte eine Verbindung zu einem anderen Web-Service herstellen. In diesem Fall wird die SOAP-Nachricht nur weitergeleitet.
  • Der Web-Service könnte die Nachricht nach einem anderen Datenmodell bearbeiten, z. B. SDO (Service Data Objects). Es ist einfacher, die Nachricht von SAAJ DOM in ein anderes Datenmodell zu konvertieren.
  • Ein Handler für die Validierung digitaler Signaturen könnte die Nachricht generisch bearbeiten wollen.

Möglicherweise müssen Sie noch einen Schritt weiter gehen, um Ihre XML-Schematypen zuzuordnen, weil die Schnittstelle "SOAPElement" für traditionelle Systeme nicht immer die beste Alternative darstellt. In diesem Fall könnten Sie ein generisches Programmiermodell wie Service Data Object (SDO) verwenden, das sich für datenzentrierte Anwendungen besser eignet.

Das XML-Schema kann so konfiguriert werden, dass es eine angepasste Datenbindung enthält, die das SDO oder Datenobjekt dem Java -Objekt zuordnet. Beispielsweise übergibt die Laufzeit eine ankommende SOAP-Nachricht an eine Schnittstelle "SOAPElement" und leitet sie zwecks Weiterverarbeitung an den angepassten Datenbinder weiter. Falls die ankommende Nachricht ein SDO enthält, erkennt die Laufzeit den Datenobjektcode, fragt seine Typenzuordnung ab, um einen angepassten Binder zu lokalisieren, und erstellt die Schnittstelle "SOAPElement", das den SDO-Code darstellt. Das SOAPElement wird an den SDOCustomBinder weitergegeben.

Der Prozess für die Entwicklung von Anwendungen mit SOAPElement, SDO und angepassten Bindern ist in den Informationen zu angepassten Datenbindern beschrieben.

Hinweis zur Umstellung Hinweis zur Umstellung: Ab WebSphere Application Server Version 8 lösen die Methoden SOAPMessage.getSOAPHeader und getSOAPBody eine Ausnahmebedingung des Typs SOAPException aus, wenn in der Nachricht kein entsprechendes Element enthalten ist. Die Systemeigenschaft com.ibm.websphere.webservices.soap.IBMSOAPMessage.ENABLE_LEGACY_GETSOAP_BEHAVIOR wird bereitgestellt, um das Verhalten so zurückzusetzen, dass null zurückgegeben und keine Ausnahmebedingung ausgelöst wird. Diese Systemeigenschaft wird mit der angepassten JVM-Eigenschaft com.ibm.websphere.webservices.soap.enable.legacy.get.behavior festgelegt. Der Standardwert für diese angepasste JVM-Eigenschaft ist false. Wenn Sie diese JVM-Eigenschaft auf den Wert true setzen, wird das vorherige Verhalten verwendet und für die Methoden "SOAPMessage.getSOAPHeader" und "getSOAPBody" wird null zurückgegeben, wenn keine entsprechende Nachricht existiert.

Das vorherige Verhalten, bei dem standardmäßig ein Nullwert zurückgegeben wurde, ist mit der Spezifikation nicht kompatibel.

trns

Eine vollständige Liste der unterstützten Standards und Spezifikationen finden Sie in der Dokumentation zu den Web-Service-Spezifikationen und den Anwendungsprogrammierschnittstellen.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_saaj
Dateiname:cwbs_saaj.html