Services Web activés par un bus : restrictions connues

Il existe quelques restrictions connues qui s'appliquent lors de l'utilisation des services Web activés par un bus d'intégration de services.

Les en-têtes SOAP sont transmis via le bus d'intégration de services

Si le WSDL du service contient des éléments <soap:header> dans l'élément <wsdl:definition>, le bus transmet les en-têtes SOAP. Ce comportement est correct. Cependant, les effets suivants sont également observés :
  • Les en-têtes SOAP ne sont pas inclus dans le fichier WSDL généré par les technologies d'intégration de services.
  • Si vous définissez l'indicateur "must understand" dans le message SOAP, vous obtenez un message d'erreur.

Limitations de la prise en charge de SOAP avec des pièces jointes

Le bus d'intégration de services prend en charge les messages SOAP qui contiennent des anciennes pièces jointes (comme il est décrit dans le site SOAP with attachments W3C Note) ou les pièces jointes qui utilisent Web Services-Interoperability (WS-I) Attachments Profile Version 1.0. Si vous devez convertir les pièces jointes d'un style vers un autre, vous pouvez utiliser une médiation pour effectuer des mappages entre les différents styles de codage de pièce jointe.

Les services Web activés par le bus ne peuvent pas appeler un service Web hébergé par WebSphere Application Server si ce service contient une opération sans pièces jointes dans son message de demande, mais avec une pièce jointe dans son message de réponse.

Les scénarios suivants ne sont pas pris en charge :
  • Utilisation de DIME.
  • Utilisation de la balise WSDL mime:mimeXml.
  • Imbrication d'une balise mime:multipartRelated dans une balise mime:part.
  • Utilisation de tableaux ou de vecteurs de gestionnaires de données, d'images, etc.
Les en-têtes MIME du message entrant ne sont pas conservés pour les pièces jointes référencées. Le message sortant contient de nouveaux en-têtes MIME pour Content-Type, Content-Id etContent-Transfer-Encoding.

Si vous transmettez une pièce jointe de grande taille via le bus d'intégration de services, une erreur de mémoire insuffisante peut être générée dans la machine virtuelle Java™ . Pour résoudre cet incident, augmentez la taille du segment JVM comme décrit dans Optimisation des services Web activés par un bus.

Pour plus d'informations, voir rubrique Transmission de messages SOAP avec des pièces jointes via le bus d'intégration de services.

Disponibilité des jetons de justificatif du sujet JAAS non garantie sur les services de communications sortantes

Lors de l'utilisation de WS-Security, les contenus suivants d'un jeu de justificatifs du sujet JAAS peuvent être indisponibles pour le code exécuté sur un service de communications sortantes s'ils sont définis lors du traitement d'une demande de services de communications entrantes :
  • Contenus non sérialisables.
  • Les jetons qui implémentent com.ibm.wsspi.security.token.Token ou l'une de ses sous-interfaces, et n'attribuent pas la valeur true à l'attribut forwardability.

Exemple : un destinataire de jeton personnalisé est configuré dans la configuration et les liaisons WS-Security appliquées à un port de communications entrantes. Ce destinataire définit un jeton dans les justificatifs privés du sujet JAAS, et ce jeton implémente com.ibm.wsspi.security.token.Token et attribue la valeur false à l'attribut forwardability. Dans ce cas, l'expéditeur de jetons personnalisé configuré dans la configuration et les liaisons WS-Security du port de communications sortantes correspondant ne doit pas compter sur la disponibilité de ce jeton au sein du sujet JAAS.

Tolérance des messages SOAP dont la syntaxe est incorrecte

Les services Web activés par un bus vérifient plus en détail la validité des messages des services Web que dans WebSphere Application Server Version 5.1. Suite à ces opérations, certaines applications client qui utilisent des demandes ou des réponses dont la syntaxe est incorrecte (où les noms des parties de message sont incorrects) et qui fonctionnent lors de l'utilisation de la Version 5.1 sont identifiées comme ayant une syntaxe incorrecte dans les versions ultérieures.

Les services Web activés par un bus prennent en charge les applications qui génèrent des messages lorsque les parties du message ne portent pas les noms appropriés, à condition qu'elles correspondent quand même au format général du schéma. Grâce à cette prise en charge :
  • les messages dont la syntaxe est incorrecte peuvent être acceptées par le bus.
  • les messages dont la syntaxe est incorrecte peuvent être générés par le bus.
Pour les messages de sortie, un message mal formaté est produit uniquement si le message d'entrée est mal formaté et que le message ne doit pas être réécrit par les services Web activés par le bus. Lorsque les services Web activés par un bus doivent écrire à nouveau le message (parce qu'il a été modifié par une médiation, par exemple), un message SOAP avec syntaxe correcte est généré à l'aide de noms corrects pour les parties, comme défini dans le document WSDL. Dans ce cas, si le service ou le client doit utiliser les noms de partie de message de réponse incorrects, modifiez le client ou restructurez l'élément WSDL associé aux services Web activés par un bus afin que les noms des parties correspondent à ceux attendus par les applications.
Remarque : Seuls des noms de partie de message incorrects sont tolérés. Les noms d'opération et les structures de partie incorrects ne sont pas tolérés.

Limitations de la prise en charge pour les spécifications du projet WS-Security précédent

Les versions de la spécification du projet WS-Security qui étaient prises en charge par les services Web dans les versions précédentes de WebSphere Application Server ne sont pas prises en charge par les technologies d'intégration de services. Les technologies d'intégration de services prennent en charge uniquement la "spécification OASIS Web Services Security Version 1.0", le "profil de jeton d'utilisateur version 1.0" et le "profil de jeton X.509 version 1.0." Pour plus d'informations sur ces spécifications et profils pris en charge, consultez la section Fonctionnalités prises en charge de la spécification OASIS.

Toutes les applications client et les services cible qui utilisent WS-Security pour interagir avec les technologies d'intégration de services doivent également se conformer aux niveaux pris en charge de ces spécifications. Les applications client et les services cible qui se conforment aux versions précédemment prises en charge de la spécification WS-Security ne peuvent pas interagir avec les technologies d'intégration de services car le format WF du message SOAP avec WS-Security a été modifié dans la spécification OASIS Web Services Security Version 1.0 et n'est pas compatible avec les projets précédents de la spécification.

Limitations relatives aux types Java utilisés par les services qui sont reciblés via une application client JAX-RPC

Lorsque vous transmettez des messages via le bus d'intégration de services à une destination en envoyant des messages de service Web directement sur le bus à partir d'un client JAX-RPC, il existe des limitations concernant les types Java que vous pouvez utiliser.

vous ne pouvez réacheminer que les services qui limitent les types utilisés dans leur interface à ceux pour lesquels des mappages sont définis dans la spécification JAX-RPC. La prise en charge se trouve donc limitée à un sous-ensemble de schémas XML possibles pouvant être utilisés dans un document WSDL. Par exemple, si l'interface comporte un grand nombre d'éléments qui mappent vers SOAPElement, elle ne peut pas être redirigée via le bus.

Configuration d'un service sortant pour utiliser un port WSDL

Lorsque vous configurez un service de communications sortantes pour utiliser un port WSDL utilisant la liaison d'EJB, les technologies d'intégration de services appellent ce service à l'aide du protocole RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol). Toutefois, toutes les classes transmises au bean enterprise doivent se trouver dans le chemin d'accès aux classes de WebSphere Application Server. Par exemple :
  • Si vous transmettez un objet de type Address, cette classe et les classes de tous les objets sérialisés dans un objet Address doivent se trouver dans le chemin d'accès aux classes de WebSphere Application Server.
  • Si la signature d'une méthode du bean enterprise contient un objet java.util.List et que la liste doit correspondre à une liste d'objets Address, la classe Address doit se trouver dans le chemin d'accès aux classes de WebSphere Application Server.

Icône indiquant le type de rubrique Rubrique de référence



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=rjw_restrict
Nom du fichier : rjw_restrict.html