Les End Points ou points de terminaison

  • Article

Par Romelard Fabrice, MVP .NET et Consultant Technique Ilem SA
Membre du Groupe Utilisateurs SQL Server

Avec SQL Server 2005, nous avons la possibilité de publier des objets SQL sous la forme de Web Services. Ceux-ci sont appelé des « End Points » (EP) ou points de terminaison. Nous allons donc voir comment mettre en place et gérer un EP. Dans un prochain article, nous verrons comment utiliser cet EP dans nos développements.

Sur cette page

Introduction Introduction
Principe Principe
Création du Point de Terminaison Création du Point de Terminaison
Listage des EP présents sur notre serveur SQL Listage des EP présents sur notre serveur SQL
Suppression ou modification d’un EP Suppression ou modification d’un EP
Conclusion Conclusion

Introduction

SQL Server 2000 supportait plus ou moins le XML (grâce à l’option FOR XML en sortie), avec la nouvelle version « SQL Server 2005 », Microsoft a voulu franchir le pas du support complet du format XML. Cela a été facilité par l’utilisation du FrameWork .NET 2.0.
Dans cette stratégie, il fallait donc aussi regarder ce qui était possible avec les Web Services.

En effet, depuis le développement des interactions entre les applications, les Web Services sont devenus très importants avec des architectures de plus en plus complexes. Jusqu’à maintenant (avec SQL Server 2000), on était obligé de développer ce Web Service alors que celui-ci ne fait par exemple que lister le contenu d’une table SQL. Ainsi, on se retrouvait dans une situation nous obligeant à trouver un serveur IIS afin d’héberger ce Web Service qui lui-même transfère la demande vers SQL Server afin d’exécuter la procédure stockée. Ce résultat était alors retourné au serveur IIS qui l’embarquait dans le flux XML pour le transférer au demandeur.

On avait donc du travail inutile du point de vue du développement, mais surtout beaucoup de travail et de flux inutiles du point de vue des serveurs et du réseau.

De plus, on savait déjà que le FrameWork .NET était capable de gérer des requêtes HTTP (Cassini en est le parfait exemple). Ainsi, la solution a été de faire usage de cette possibilité directement dans SQL Server 2005.

De ce fait, avec SQL Server 2005, nous pouvons directement référencer un Web Service qui sera exposé et géré par le moteur SQL Server lui-même. L’objectif de cet article est donc de présenter ce travail et par la suite de présenter comment intégrer ce Web Service dans votre développement .NET.

Principe

SQL Server 2005 est basé sur le FrameWork .NET 2.0 pour une partie de son fonctionnement interne, ainsi les EP sont une mise à la disposition des utilisateurs extérieurs de Web Services. Ces Web Services ne seront pas installés (comme il est habituellement le cas dans le monde Windows) sur IIS.
En effet, avec le FrameWork .NET est venue la possibilité de répondre à des requêtes HTTP via HTTP.SYS. Ainsi lors de la mise à disposition de ces objets, il faudra d’abord réserver un nom dans HTTP.SYS qui transférera toutes les requêtes correspondantes à cette réservation vers SQL Server 2005.

Cette réservation est associée avec le paramétrage de cet EP qui lui permet de spécifier l’URL d’accès ainsi que toutes les options de cet EP. On pourra alors ajouter des méthodes à cet EP, ce sont les méthodes qui correspondent aux objets (uniquement les fonctions ou Procédures Stockées) de SQL Server 2005.

De ce fait, lorsque l’application cliente de ce Web Service demande l’url de celui-ci, le noyau HTTP du serveur (HTTP.SYS) détecte qu’une réservation a bien été faite sur cette URL. Une fois cette vérification faite, le transfert est effectué et SQL Server prend en charge cette requête afin de retourner ce qui est demandé (résultat WSDL, exécution de la méthode, …). Maintenant que nous avons vu le principe de fonctionnement, voyons comment faire pour créer un EP.

Création du Point de Terminaison

On ne peut publier que certains objets SQL Server en EP, il s’agit en effet uniquement des fonctions et des procédures stockées utilisateurs.
Nous baserons notre exemple sur la base fournie avec SQL Server 2005:
• AdventureWorks

Cette base contient un ensemble de tables permettant de construire une maquette.

Nous prendrons un exemple simple de sélection des 10 premiers clients classés par ordre alphabétique (Nom, Prénom et Email). Cette procédure stockée ne prend donc aucun paramètre en entrée.

USE AdventureWorks
GO
CREATE PROCEDURE Selection10PremiersClients
AS
SELECT 
	TOP 10
	Cont.LastName		AS Nom,
	Cont.FirstName		AS Prénom,
	Cont.EmailAddress		AS Email
FROM 
	Person.Contact Cont
ORDER BY
	Cont.LastName ASC,
	Cont.FirstName ASC
GO

Nous avons donc maintenant une procédure stockée très simple qui doit ensuite être utilisée dans une application Web qui n’a pas accès au serveur SQL, nous souhaitons donc utiliser un Web Service pour cela.
Il faut donc alors utiliser la procédure de création des End Points avec un script comme celui qui suit :

CREATE ENDPOINT SQLEP_ArticleTechnet
	STATE = STARTED
AS HTTP
(
	PATH = '/EndPointArticleTechnet',
	AUTHENTICATION = (INTEGRATED),
	PORTS = (CLEAR),
	CLEAR_PORT = 8080,
	SITE = 'localhost'
)
FOR SOAP
(
	WEBMETHOD 'Liste10PremiersClients'
	(NAME='AdventureWorks.dbo.Selection10PremiersClients'),
	BATCHES = DISABLED,
	WSDL = DEFAULT,
	DATABASE = 'AdventureWorks',
	NAMESPACE = 'http://Adventure-Works/Persons'
)

Vous pouvez trouver toutes les options et paramètres possibles pour cette commande de création sur le site de la MSDN :
• CREATE ENDPOINT (Transact-SQL)

Pour simplifier, la première partie correspond aux options de ce Web Service, la seconde est liée à la méthode qui va être associée à ce Web Service.
L’URL de ce Web Service est dans notre cas :
• https://localhost:8080/EndPointArticleTechnet

Nous avons activé la publication du WSDL (c’est une vision XML qui permet de connaître les méthodes exposées et leurs paramètres), cette vision est disponible en ajoutant « ?WSDL » à notre URL, ce qui donne dans notre exemple :
• https://localhost:8080/EndPointArticleTechnet?WSDL

Si on ouvre cette URL dans un navigateur internet, nous aurons une demande d’authentification puis le WSDL de ce Web Service.

Listage des EP présents sur notre serveur SQL

En tant que DBA, il est utile de savoir si des EP ont été mis en place sur un serveur, pour cela il faut interroger des tables système en utilisant les requêtes suivantes.

  SELECT *
FROM sys.endpoints
WHERE sys.endpoints.protocol_desc= 'HTTP';
SELECT *
FROM sys.http_endpoints;
SELECT * 
FROM sys.soap_endpoints;
SELECT *
FROM sys.endpoint_webmethods;

• La première table « sys.endpoints » permet de lister les End Points créés. En effet, le protocole HTTP est une des possibilités de points de terminaison, mais il existe d’autres.
• La seconde table « sys.http_endpoints » nous donne la liste des EP HTTP ainsi que les paramètres d’accès de chacun (sécurité, URL, port, …).
• La troisième table « sys.soap_endpoints » retourne les paramètres SOAP et WSDL ce ces points de terminaison (vision WSDL ou non, base de données par défaut, espace de nom, …).
• La dernière table « sys.endpoints_webmethods » retourne la liste des méthodes associées à ces EP. On peut bien sur associer plusieurs méthodes pour un seul point de terminaison.

Suppression ou modification d’un EP

Dans le cas où un point de terminaison n’est plus utile, on peut bien sur le supprimer avec la commande DROP, comme suit :

DROP ENDPOINT SQLEP_ArticleTechnet
GO

On peut aussi désactiver un EP, afin éventuellement de le réutiliser plus tard sans pour autant le supprimer.

ALTER ENDPOINT SQLEP_ArticleTechnet 
	STATE = DISABLED
GO

On peut choisir pour cette option « DISABLED » qui demande au serveur de ne plus du tout écouter le point de terminaison et donc ne plus répondre aux demandes. La seconde option possible est « STOPPED » pour laquelle le serveur continue d’écouter le point de terminaison, mais de retourner une erreur.

Dans le cadre d’un développement, on peut souhaiter laisser la vision du WSDL, mais le désactiver pour les serveurs de production (pour des raisons de sécurité), il faut alors exécuter le script suivant.

ALTER ENDPOINT SQLEP_ArticleTechnet 
FOR SOAP
(
	WSDL = NONE
)
GO

La vision de la précédente URL dans un navigateur retournera alors une page blanche.

Maintenant, comme nous l’avons expliqué juste au dessus, nous souhaitons ajouter une seconde méthode à cet EP, il faut alors passer par un script de mise à jour. Nous créerons dans un premier temps une procédure stockée afin d’obtenir les dix premiers contacts dont le nom commence par une lettre transmise.

USE AdventureWorks
GO
CREATE PROCEDURE Selection10PremiersClientsSuivantLettre
	@Lettre AS char
AS
SELECT 
	TOP 10
	Cont.LastName		AS Nom,
	Cont.FirstName		AS Prénom,
	Cont.EmailAddress		AS Email
FROM 
	Person.Contact Cont
WHERE
	Cont.LastName LIKE @Lettre +'%'
ORDER BY
	Cont.LastName ASC,
	Cont.FirstName ASC
GO

Il nous faut donc mettre à jour notre EP afin d’ajouter la procédure nouvellement créée. Cela se fait toujours avec la commande « ALTER ENDPOINT » comme suit.

ALTER ENDPOINT SQLEP_ArticleTechnet
FOR SOAP
(
	ADD WEBMETHOD 'Liste10PremiersClientsSuivantLettre' 
	(name='[AdventureWorks].[dbo].[Selection10PremiersClientsSuivantLettre]')
);
GO

Nous pouvons comme dans tout Web Service publier autant de méthodes que nous le souhaitons.

Conclusion

Nous avons vu cette nouvelle possibilité offerte avec la version SQL Server 2005. Cette mise à disposition de Web Service n’est pas possible avec SQL Server 2005 Express Edition. Pour les autres versions, cette possibilité permet de penser autrement ses mises en place de Web Service.

On peut même réfléchir sur de nouvelles architectures pour des développements ou l’ouverture du port SQL Server standard est un problème. En effet, le gain de temps dans les développements utilisant les Web Services comme alimentation de données trouveront un intérêt tout particulier à cette possibilité.

Pour ce qui est de la sécurité, il faut faire très attention et s’accorder avec les administrateurs des serveurs lors du choix de la mise en place de cette solution. Elle peut en effet impacter de nombreuses configurations pour les FireWall et les routeurs par exemple.

Nous allons pouvoir nous attarder dans la prochaine partie sur l’utilisation de cet End Point dans un développement .NET