Vue d'ensemble des services Web XML natifs

Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité.

Cette rubrique compare les services Web XML natifs de Microsoft SQL Server avec Microsoft SQLXML, décrit le fonctionnement des services Web XML et énumère les avantages que présente leur utilisation.

Les services Web XML natifs ne sont pas utiles ni recommandés dans les scénarios suivants :

  • Applications caractérisées par des accès en temps réel à fort taux de simultanéité, avec des transactions très courtes.

  • Déploiement évolutif de type batterie de serveurs Web.

  • Comme solution de remplacement pour la couche intermédiaire, en particulier où votre architecture d'applications subit des demandes de logique d'entreprise à grande échelle qui sont gérées le mieux au sein de composants de couche intermédiaire.

Comparaison des services Web XML natifs avec SQLXML

Avant SQL Server 2005, l'accès à une base de données SQL Server nécessite l'utilisation du TDS (Tabular Data Stream). Le TDS est un protocole propriétaire qui doit être pris en charge pour les clients de bureau Windows. Parfois, les clients SQL Server doivent utiliser Microsoft MDAC (Data Access Components). La pile MDAC est installée sur l'ordinateur client qui se connecte à SQL Server. Pour SQL Server, SQLXML 3.0 est un composant de couche intermédiaire qui prend en charge l'accès Web à SQL Server, mais il faut utiliser aussi IIS (Internet Information Services).

Dans SQL Server 2005, grâce à l'association de HTTP et de SOAP, les services Web XML natifs fournissent une alternative pour les environnements autres que Windows, comme l'indique l'illustration suivante.

Comparaison entre les services Web XML natifs et SQLXML

Comme il n'est plus nécessaire d'installer MDAC sur le client ou de disposer de SQLXML avec sa dépendance au niveau intermédiaire sur IIS, l'accès SOAP et HTTP permet à davantage de clients d'accéder à SQL Server. C'est le cas notamment pour les clients Web qui utilisent des applications clientes existantes, par exemple un navigateur Web. Les services Web XML natifs facilitent l'utilisation de Microsoft .NET Framework, Microsoft SOAP Toolkit, Perl et d'autres systèmes d'exploitation et outils de développement Web.

Le tableau suivant récapitule quelques fonctionnalités pour chaque technologie.

Services Web XML natifs

Microsoft SQLXML

  • Une mise en œuvre de serveur totalement compatible SOAP pouvant prendre en charge des clients SOAP 1.1 et SOAP 1.2.

  • Prise en charge totale pour exécuter des traitements paramétrés.

  • Génération WSDL dynamique au niveau du serveur.

  • Modèle XML et fichiers de schéma. Ceux-ci prennent en charge les vues XML pouvant être mises à jour.

  • Codes de mise à jour (updategrams).

  • Chargement XML en masse.

Fonctionnement des services Web XML natifs

Pour utiliser les services Web XML natifs dans SQL Server, il faut qu'un point de terminaison HTTP soit établi au niveau du serveur. Ce point de terminaison est par nature la passerelle par laquelle les clients HTTP peuvent interroger le serveur. Une fois qu'un point de terminaison HTTP est établi, il est possible d'ajouter des procédures stockées ou des fonctions créées par l'utilisateur ou de les mettre à la disposition des utilisateurs finaux. Cela peut se produire lorsque le point de terminaison est créé ou mis à jour. Lors de l'activation des procédures et des fonctions, celles-ci sont spécifiées comme méthodes Web. Une collection de méthodes Web conçues pour être utilisées ensemble peut s'appeler un service Web.

Ces services Web peuvent être décrits avec la syntaxe WSDL. La syntaxe WSDL est produite par une instance de SQL Server et retournée aux clients SOAP pour n'importe quel point de terminaison HTTP sur lequel WSDL est activé, comme l'indique l'illustration suivante. Au besoin, la syntaxe WSDL peut être une solution personnalisée à la place de celle que crée SQL Server. Le point de terminaison peut éventuellement être configuré pour ne pas répondre aux demandes WSDL.

Fonctionnement des services Web XML natifs

Selon ce processus, des collections de services Web compatibles SQL Server peuvent être mises en œuvre et utilisés pour aider à créer et remplir une SOA (Service-Oriented Architecture). Pour plus d'informations, cherchez le mot clé « SOA » dans la bibliothèque en ligne MSDN sur ce site Web de Microsoft.

Avantages de l'utilisation des services Web XML natifs

Une instance de SQL Server qui peut être son propre service Web XML procure les avantages suivants :

  • Toute application de services Web peut accéder à une instance de SQL Server

    C'est le principal avantage. Étant donné que les services Web XML natifs reposent sur des technologies bien connues telles que XML et HTTP, n'importe quel périphérique capable d'analyser le langage XML et d'envoyer des demandes HTTP peut maintenant accéder à SQL Server. Cela facilite l'accès à SQL Server dans des environnements hétérogènes dans lesquels des applications qui s'exécutent sur des systèmes d'exploitation autres que Windows peuvent nécessiter une connectivité à SQL Server. Dans ce type de situation, en principe l'utilisation de pilotes JDBC (Java Database Connectivity) ou ODBC (Open Database Connectivity) était la seule solution possible. Les services Web XML natifs de SQL Server procurent une autre alternative moins coûteuse. Par exemple, cette fonctionnalité pourrait être très utile pour des scénarios dans lesquels un administrateur de base de données a un script écrit en Perl qui s'exécute sur des systèmes d'exploitation autres que Windows pour gérer une ressource SQL Server.

  • Meilleure intégration avec des outils de développement Web Microsoft et d'autres sociétés

    Avec les services Web XML natifs, les résultats des requêtes SQL sont retournés au format XML. Grâce à des schémas prédéfinis, des environnements IDE (Integrated Development Environments) intelligents qui offrent une prise en charge SOAP/HTTP intégrée, par exemple Microsoft Visual Studio 2005 ou JBuilder, peuvent tirer parti des services Web XML natifs pour aider à créer du code proxy qui résume la communication avec une instance de SQL Server. La plupart du temps, l'IDE crée et fournit les objets que les applications clientes peuvent ensuite utiliser pour un accès à des données Web.

  • Meilleure prise en charge des clients mobiles qui sont connectés par intermittence ou aléatoirement

    L'utilisation des services Web XML natifs permet également d'accéder à une instance de SQL Server n'importe où et à n'importe quel moment. Cela facilite le développement d'applications pour des périphériques mobiles ou qui ne sont pas connectés en permanence. Une fois qu'une connexion a été établie et que le serveur a commencé à traiter les requêtes, le serveur peut être surveillé grâce aux mécanismes qui sont proposés aux clients réseau traditionnels qui utilisaient TDS et les Net-Library SQL Server.

  • Les mesures de sécurité inhérentes au serveur réduisent la nécessité de mettre en œuvre des pare-feu supplémentaires

    Les services Web XML natifs fournissent un niveau de sécurité intégré pour l'accès Web. Contrairement à un serveur Web standard, les points de terminaison HTTP qui sont créés pour une utilisation avec SQL Server n'autorisent pas les accès utilisateur anonymes. Pour créer des points de terminaison, il faut d'abord des privilèges administratifs au niveau du système sur le serveur et les points de terminaison n'exposent que les méthodes stockées qui sont rendues publiques lors de la configuration des points de terminaison.