Interface SAAJ (SOAP with Attachments API for Java)

L'interface SAAJ (SOAP with Attachments API for Java™) (SAAJ) est utilisée pour la messagerie SOAP qui permet d'envoyer de façon standard des documents XML sur Internet à partir d'un modèle de programmation Java. SAAJ sert à manipuler dans le contexte approprié le message SOAP lorsque ce dernier traverse l'environnement d'exécution.

pratiques recommandées : IBM® WebSphere Application Server prend en charge les modèles de programmation JAX-WS (Java API for XML-Based Web Services) et JAX-RPC (Java API for XML-based RPC). JAX-WS représente la future génération du modèle de programmation des services Web qui étend la base du modèle JAX-RPC. L'utilisation du modèle de programmation JAX-WS stratégique simplifie le développement des services et des clients Web par la prise en charge d'un modèle d'annotations normalisé. Bien que le modèle de programmation et les applications JAX-RPC soient toujours pris en charge, vous avez tout avantage à recourir au modèle de programmation JAX-WS, facile à mettre en oeuvre, pour développer de nouvelles applications et de nouveaux clients de services Web.

Le modèle de programmation JAX-RPC (Java API for XML-Based RPC) prend en charge SAAJ 1.2 pour manipuler le XML.

Le modèle de programmation JAX-WS prend en charge SAAJ 1.2 et 1.3. SAAJ 1.3 comprend la prise en charge des messages SOAP 1.2.

Les différences des spécifications SAAJ 1.2 et SAAJ 1.3 peuvent être consultées dans la rubrique "Différences des versions de SAAJ".

Comment les messages sont-ils utilisés dans les services web ?

Les services Web utilisent la technologie XML pour l'échange de messages. Ces messages sont conformes au schéma XML. Lors du développement des applications web services, il existe un nombre limité d'API XML utilisables, tels que Document Object Model (DOM). Il est plus efficace de manipuler les objets Java et d'effectuer la sérialisation et la désérialisation pendant la phase d'exécution.

Web Services utilise des messages SOAP pour représenter des appels RPC entre le client et le serveur. En général, le message SOAP est désérialisé en une série d'objets métier de type valeur Java, qui représentent les paramètres et les valeurs de retour. En outre, le modèle de programmation Java fournit des API qui prennent en charge des applications et des gestionnaires pour traiter directement le message SOAP. En raison du nombre limité de types de schéma XML pris en charge par les modèles de programmation, la spécification fournit le modèle de données SAAJ en tant qu'extension permettant de manipuler le message.

Pour manipuler les types de schéma XML, vous devez les mapper aux types Java à l'aide d'un lieur de données personnalisé.

Interface SAAJ

Les classes liées à SAAJ se trouvent dans le package javax.xml.soap. SAAJ s'appuie sur les interfaces et les classes abstraites et la plupart des classes commencent par appeler des méthodes de fabrique pour créer une fabrique telle que SOAPConnectionFactory et SOAPFactory.

Eviter les incidents Eviter les incidents: Si la sécurité Java est activée, et les autorisations permettant de lire de fichier jaxm.properties n'ont pas été accordées, une exception SecurityException survient lorsqu'une instance SOAPFactory est créée par un appel à javax.xml.soap.SOAPFactory.newInstance(), ou une instance MessageFactory et créée par un appel à MessageFactory.newInstance(), et l'exception suivante est enregistrée dans le journal système :
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)
.

SOAPFactory ignore l'exception et passe au moyen suivant de déterminer l'implémentation à charger. Vous pouvez donc ignorer l'entrée du journal pour cette exception de sécurité.

Etant donné que ce produit utilise SOAPFactory pour prendre en charge les technologies de services Web, telles que WS-Addressing (WS-A), WS-Atomic Transaction (WS-AT) et WS-Notification, vous pouvez ignorer cette exception de sécurité dans l'application des services Web dans laquelle la sécurité Java est activée.

gotcha
Les classes les plus couramment utilisées sont les suivantes :
  • SOAPMessage : contient les parties XML et non XML du message
  • SOAPHeader : représente l'élément XML SOAP header
  • SOAPBody : représente l'élément XML SOAP body
  • SOAPElement : représente les autres éléments du message SOAP
Les autres parties de l'interface SAAJ sont les suivantes :
  • MessageContext : contient un message SOAP et les propriétés associées
  • AttachmentPart : représente une pièce jointe binaire
  • SOAPPart : représente la partie XML du message
  • SOAPEnvelope : représente l'élément XML SOAP envelope
  • SOAPFault : représente l'élément XML SOAP fault

L'interface principale dans le modèle SAAJ est javax.xml.soap.SOAPElement, également appelée SOAPElement. Ce modèle permet aux applications de gérer un modèle SAAJ qui utilise un code DOM préexistant. La conversion d'objets DOM préexistants en objets SAAJ est également plus facile.

Les messages créés à l'aide de l'interface SAAJ suivent les normes SOAP. Une message SOAP est représenté dans le modèle SAAJ sous la forme d'un objet javax.xml.soap.SOAPMessage. Le contenu XML du message est représenté par un objet javax.xml.soap.SOAPPart. Chaque partie SOAP a une enveloppe SOAP. Cette enveloppe est représentée par l'objet SAAJ javax.xml.SOAPEnvelope. La spécification SOAP définit différents éléments qui résident dans l'enveloppe SOAP. SAAJ définit des objets pour les différents éléments dans l'enveloppe SOAP.

Le message SOAP peut également contenir des données non XML appelées pièces jointes (attachments). Ces pièces jointes sont représentées par des objets SAAJ AttachmentPart qui sont accessibles à partir de l'objet SOAPMessage.

Plusieurs raisons expliquent pourquoi les gestionnaires et les applications utilisent l'API SOAPElement plutôt qu'un mappage fortement lié :
  • Le service Web peut servir de conduit vers un autre service Web. Dans ce cas, le message SOAP est seulement transféré.
  • Le service Web peut manipuler le message à l'aide d'un autre modèle de données, par exemple, un objet SDO (Service Data Object). Il est plus facile de convertir le message d'un DOM SAAJ en un autre modèle de données.
  • Un gestionnaire tel qu'un gestionnaire de validation de signatures numériques, peut manipuler le message de façon générique.

Vous devrez peut-être effectuer d'autres actions pour mapper vos types de schéma XML car l'interface SOAPElement ne représente pas toujours la meilleure solution avec les systèmes hérités. Dans ce cas, vous pouvez utiliser un modèle de programmation générique, tel que SDO, qui plus adapté aux applications centrées sur les données.

Le schéma XML peut être configuré de façon à inclure une liaison de données personnalisée qui associe le SDO ou l'objet de données à l'objet Java. Par exemple, l'exécution génère un message SOAP entrant vers une interface SOAPElement et le transmet au lieur de données du destinataire pour un traitement supplémentaire. Si le message entrant contient un SDO, l'exécution reconnaît le code d'objet de données, interroge son mappage de type pour localiser un lieur personnalisé et génère l'interface SOAPElement qui représente le code SDO. Le SOAPElement est transmis au SDOCustomBinder.

Pour plus d'informations sur le processus de développement d'applications avec SOAPElement, SDO et les lieurs personnalisés, reportez-vous à la rubrique relative aux lieurs de données personnalisés.

Pour les utilisateurs en transition Pour les utilisateurs en transition: Depuis WebSphere Application Server version 8, les méthodes SOAPMessage.getSOAPHeader et getSOAPBody génèrent une exception SOAPException s'il n'existe pas d'élément correspondant dans le message. Une propriété système, com.ibm.websphere.webservices.soap.IBMSOAPMessage.ENABLE_LEGACY_GETSOAP_BEHAVIOR, est fournie pour inverser le comportement, afin de renvoyer la valeur null au lieu d'émettre une exception. Cette propriété système est définie à l'aide d'une propriété personnalisée de machine virtuelle Java, com.ibm.websphere.webservices.soap.enable.legacy.get.behavior. La valeur par défaut de cette propriété personnalisée de machine virtuelle Java est false. L'association de cette propriété de machine virtuelle Java à la valeur true restaure le comportement précédent, qui consiste à renvoyer la valeur null pour les méthodes SOAPMessage.getSOAPHeader et getSOAPBody lorsqu'il n'existe pas de message correspondant.

Le comportement précédent de retour de null n'est pas conforme à la spécification.

trns

Pour obtenir la liste complète des normes et spécifications prises en charge, voir les spécifications des services Web et la documentation des API.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_saaj
Nom du fichier : cwbs_saaj.html