Fournisseurs de liaisons personnalisées pour les applications JAX-RPC

Un fournisseur de liaisons personnalisées est constitué par le regroupement des classes de lieurs de données personnalisés associées à un fichier de métadonnées déclaratif. Il a principalement pour objet de cumuler les lieurs de données personnalisés associés afin de prendre en charge des scénarios utilisateur particuliers. Le fournisseur de liaisons personnalisé permet d'associer des lieurs de données personnalisés au système d'exécution et aux outils d'émission afin que ces derniers puissent générer les artefacts appropriés et que le système d'exécution puisse augmenter son système de mappage de type existant pour prendre en compte les lieurs de données personnalisés appliqués et les appeler.

Un fournisseur de liaisons personnalisé utilise un type de schéma XML spécifique, tandis que les applications mettent en oeuvre quelques types de schéma XML connexes. Vous devez mettre en oeuvre un mécanisme permettant de regrouper et de déclarer plusieurs lieurs de données personnalisés afin d'offrir une solution de liaison complète. Le concept de fournisseur de liaisons personnalisé définit un modèle déclaratif permettant d'associer un ensemble de lieurs de données personnalisés à des outils d'émission ou au système d'exécution.

Reportez-vous aux informations relatives aux lieurs de données personnalisées et à l'interface de CustomBinder pour en savoir plus sur les lieurs de données personnalisées et sur l'API de CustomBinder inclus dans WebSphere Application Server. Après avoir défini les lieurs de données personnalisés, vous êtes prêt à déployer le package de CustomBinder. Pour en savoir plus sur le déploiement de ce package, reportez-vous aux informations relatives aux modèles d'utilisation pour le déploiement de lieurs de données personnalisés pour les applications JAX-RPC.

Le fichier de métadonnées déclaratif, CustomBindingProvider.xml, est un fichier XML intégré aux classes du fournisseur personnalisé sous la forme d'un fichier JAR (Java™ archive) unique situé dans /META-INF/services/directory. Une fois que le fichier JAR du fournisseur a été intégré, les informations binaires et le fichier de métadonnées situé dans le fichier JAR peuvent être utilisées par l'outil de ligne de commande WSDL2Java et le système d'exécution.

L'exemple suivant décrit le schéma XML du fichier CustomBindingProvider.xml. Le type de niveau supérieur correspond au providerType qui contient une liste des éléments de mappage. Chaque élément de mappage définit le lieur de données personnalisé associé et ses propriétés, y compris xmlQName, javaName et qnameScope. Pour en savoir plus sur ces propriétés, reportez-vous aux informations relatives à l'interface CustomBinder des applications JAX-RPC. Le providerType possède également l'attribut scope pouvant avoir la valeur serveur, application ou module. Cet attribut est utilisé par le déploiement du serveur dans le but de résoudre les conflits et d'établir une hiérarchie de liaison personnalisée.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema 
    targetNamespace=
       "http://www.ibm.com/webservices/customdatabinding/2004/06" 
    xmlns:customdatabinding=
        "http://www.ibm.com/webservices/customdatabinding/2004/06"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified" attributeFormDefault="qualified">
	
   <xsd:element name="provider" type="customdatabinding:providerType"/>
   
   <xsd:complexType name="providerType">
   <xsd:sequence>
     <xsd:element name="description" type="xsd:string" minOccurs="0"/>
     <xsd:element name="mapping" minOccurs="0" maxOccurs="unbounded">
      <xsd:complexType>
        <xsd:sequence>
          <xsd:element name="description" type="xsd:string" minOccurs="0"/>
          <xsd:element name="xmlQName" type="xsd:QName"/>
          <xsd:element name="javaName" type="xsd:string"/>
          <xsd:element name="qnameScope" 
                       type="customdatabinding:qnameScopeType"/>
          <xsd:element name="binder" type="xsd:string"/>
        </xsd:sequence>
       /xsd:complexType>
      </xsd:element>
       <xsd:attribute name="scope" 
             type="customdatabinding:ProviderScopeType" default="module"/>
       </xsd:sequence>
   </xsd:complexType

  <xsd:simpleType name="qnameScopeType">
      <xsd:restriction base="xsd:string">
         <xsd:enumeration value="simpleType"/>
         <xsd:enumeration value="complexType"/>
         <xsd:enumeration value="element"/>
      </xsd:restriction>
  </xsd:simpleType>

  <xsd:simpleType name="ProviderScopeType">
     <xsd:restriction base="xsd:string">
         <xsd:enumeration value="server"/>
         <xsd:enumeration value="application"/>
         <xsd:enumeration value="module"/>
     </xsd:restriction>
  </xsd:simpleType>  
</xsd:schema>
L'exemple suivant décrit un fichier CustomBindingProvider.xml correspondant au schéma DataGraph SDO présenté dans la rubrique relative à l'interface CustomBinder. Cet exemple illustre le mappage entre un type de schéma, DataGraphType, et un type Java, commonj.sdo.DataGraph. Le lieur qui représente ce mappage est appelé test.sdo.SDODataGraphBinder.
<cdb:provider
	xmlns:cdb="http://www.ibm.com/webservices/customdatabinding/2004/06"
   xmlns:sdo="commonj.sdo">
   <cdb:mapping>
   		<cdb:xmlQName>sdo:DataGraphType</cdb:xmlQName>
   		<cdb:javaName>commonj.sdo.DataGraph</cdb:javaName>
   		<cdb:qnameScope>complexType</cdb:qnameScope>
   		<cdb:binder>test.sdo.SDODataGraphBinder</cdb:binder>
   </cdb:mapping>   
</cdb:provider>

Vous devez importer les lieurs personnalisés dans l'outil de ligne de commande WSDL2Java à des fins de développement. Les lieurs de données personnalisés contrôlent la manière dont les artefacts de développement, y compris l'interface SEI (Service Endpoint Interface) et les données de mappage JSR 109, sont générés à partir du fichier WSDL (Web Services Description Language). L'outil de ligne de commande WSDL2Java est livré avec WebSphere Application Server et utilise le fichier d'archive Java du lieur personnalisé ou le package de lieur personnalisé pour générer ces artefacts de développement.

L'exemple suivant présente un fichier WSDL qui référence le schéma DataGraph SDO présenté dans la rubrique relative à l'interface CustomBinder.
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://sdo.test" 
   xmlns:impl="http://sdo.test" 
   xmlns:intf="http://sdo.test" 
   xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
   xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" 
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:sdo="commonj.sdo">

 <wsdl:types>
  <schema elementFormDefault="qualified" targetNamespace="http://sdo.test" 
       xmlns="http://www.w3.org/2001/XMLSchema" xmlns:sdo="commonj.sdo">
   <import namespace="commonj.sdo" schemaLocation="sdo.xsd"/>
  </schema>
 </wsdl:types>

 <wsdl:message name="echoResponse">
  <wsdl:part element="sdo:datagraph" name="return"/>
 </wsdl:message>

 <wsdl:message name="echoRequest">
   <wsdl:part element="sdo:datagraph" name="parameter"/>
 </wsdl:message>

 <wsdl:portType name="EchoService">
   <wsdl:operation name="echo">
     <wsdl:input message="impl:echoRequest" name="echoRequest"/>
     <wsdl:output message="impl:echoResponse" name="echoResponse"/>
    </wsdl:operation>
 </wsdl:portType>

 <wsdl:binding name="EchoServiceSoapBinding" type="impl:EchoService">
   <wsdlsoap:binding style="document" 
                     transport="http://schemas.xmlsoap.org/soap/http"/>
     <wsdl:operation name="echo">
        <wsdlsoap:operation soapAction=""/>
        <wsdl:input name="echoRequest">
         <wsdlsoap:body use="literal"/>
        </wsdl:input>

       <wsdl:output name="echoResponse">
          <wsdlsoap:body use="literal"/>
       </wsdl:output>
    </wsdl:operation>
  </wsdl:binding>

  <wsdl:service name="EchoServiceService">
     <wsdl:port binding="impl:EchoServiceSoapBinding" name="EchoService">
       <wsdlsoap:address location="http://<uri>"/>
    </wsdl:port>
  </wsdl:service>

</wsdl:definitions>
Si vous lancez la commande WSDL2Java sans le package de liaison de données personnalisé, la sortie suivante est générée par l'interface SEI (Service Endpoint Interface) avec un type de paramètre, conformément à la spécification JAX-RPC :
public interface EchoService extends java.rmi.Remote {
		public javax.xml.soap.SOAPElement
			echo(javax.xml.soap.SOAPElement parameter)
				throws java.rmi.RemoteException;
}
Lorsque vous lancez la commande WSDL2Java avec le package de liaison de données personnalisé, les lieurs de données personnalisés sont utilisés pour générer les types de paramètre. Pour appliquer les lieurs de données personnalisées, utilisez l'option -classpath dans l'outil WSDL2Java. Ce dernier recherche son chemin d'accès aux classes afin de localiser tous les fichiers dont le chemin d'accès correspond à /META-INF/services/CustomBindingProvider.xml. L'exemple suivant décrit comment vous pouvez utiliser la commande pour générer une sortie de l'interface SEI (Service Endpoint Interface) avec le type de paramètre commonj.sdo.Datagraph :
WSDL2Java -role develop-server -container web classpath sdobinder.jar echo.wsdl
La sortie SEI générée est similaire à la suivante :
public interface EchoService extends java.rmi.Remote {
		public commonj.sdo.DataGraph
			echo(commonj.sdo.DataGraph parameter)
				throws java.rmi.RemoteException;
}
Le fichier JAR qui intègre le lieur personnalisé doit être disponible lors de l'exécution afin que le client de service Web puisse être appelé, qu'il s'agisse d'un client fondé sur un module de remplacement ou d'un client DII (Dynamic Invocation Interface). Cela s'applique également au service.

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_custombinderprovider
Nom du fichier : cwbs_custombinderprovider.html