Serveur SMTP universel - Pourquoi des services web ?

Vue d'ensemble
La programmation à base de composants est devenue plus populaire que jamais. Il n'y a guère d'application aujourd'hui qui n'implique pas l'utilisation de composants sous une forme ou une autre, provenant généralement de différents fournisseurs. Au fur et à mesure que les applications sont devenues plus sophistiquées, la nécessité d'exploiter des composants distribués sur des machines distantes s'est également accrue.

Une solution de commerce électronique de bout en bout constitue un exemple d'application basée sur des composants. Une application de commerce électronique hébergée sur une ferme de serveurs Web doit transmettre les commandes à une application de gestion intégrée (ERP) en arrière-plan. Dans de nombreux cas, l'application ERP est hébergée sur un matériel différent et peut fonctionner sous un autre système d'exploitation.

Le Modèle d'objets distribués de Microsoft (DCOM), une infrastructure d'objets distribués qui permet à une application d'appeler des composants du Modèle d'objets composant (COM) installés sur un autre serveur, a été porté sur plusieurs plateformes non Windows. Mais le DCOM n'a jamais été largement adopté sur ces plateformes, de sorte qu'il est rarement utilisé pour faciliter la communication entre des ordinateurs Windows et non Windows. Les éditeurs de logiciels ERP créent souvent des composants pour la plateforme Windows qui communiquent avec le système back-end via un protocole propriétaire.

Certains services utilisés par une application de commerce électronique peuvent ne pas se trouver du tout au sein du centre de données. Par exemple, si l'application de commerce électronique accepte les paiements par carte de crédit pour les articles achetés par le client, elle doit faire appel aux services de la banque commerciale pour traiter les informations de carte de crédit du client. Mais dans la pratique, DCOM et les technologies associées telles que CORBA et Java RMI sont limitées aux applications et composants installés au sein du centre de données de l'entreprise. Cela s'explique principalement par deux raisons : par défaut, ces technologies utilisent des protocoles propriétaires, et ces protocoles sont intrinsèquement orientés connexion.

Les clients qui communiquent avec le serveur via Internet se heurtent à de nombreux obstacles potentiels. Partout dans le monde, les administrateurs réseau soucieux de la sécurité ont mis en place des routeurs et des pare-feu d'entreprise afin de bloquer pratiquement tout type de communication sur Internet. Il faut souvent un événement exceptionnel pour qu'un administrateur réseau accepte d'ouvrir des ports au-delà du strict minimum.

Si vous avez la chance de convaincre un administrateur réseau d'ouvrir les ports nécessaires au fonctionnement de votre service, il y a fort à parier que vos clients n'auront pas cette chance. Par conséquent, les protocoles propriétaires tels que ceux utilisés par DCOM, CORBA et Java RMI ne sont pas adaptés aux scénarios Internet.

L'autre problème, comme je l'ai dit, avec ces technologies, c'est qu'elles sont intrinsèquement orientées connexion et ne peuvent donc pas gérer correctement les interruptions de réseau. Comme vous n'avez pas de contrôle direct sur Internet, vous ne pouvez pas faire de suppositions quant à la qualité ou à la fiabilité de la connexion. En cas d'interruption de réseau, la prochaine requête que le client enverra au serveur risque d'échouer.

Le fait que ces technologies soient orientées connexion complique également la mise en place des infrastructures à équilibrage de charge nécessaires pour atteindre une grande évolutivité. Une fois la connexion entre le client et le serveur interrompue, il n'est pas possible de simplement rediriger la requête suivante vers un autre serveur.

Les développeurs ont tenté de surmonter ces limites en s'appuyant sur un modèle appelé sans nationalité programmation, mais leur succès a été limité car ces technologies sont assez lourdes et rendent coûteux le rétablissement d'une connexion avec un objet distant.

Étant donné que le traitement de la carte de crédit d'un client est effectué par un serveur distant sur Internet, DCOM n'est pas la solution idéale pour faciliter la communication entre le client du site de commerce électronique et le serveur de traitement des cartes de crédit. Comme dans une solution ERP, un composant tiers est souvent installé au sein du centre de données du client (dans ce cas, par le fournisseur de la solution de traitement des cartes de crédit). Ce composant ne sert guère plus qu’un proxy facilitant la communication entre le logiciel de commerce électronique et la banque du commerçant via un protocole propriétaire.

Voyez-vous une tendance se dessiner ici ? En raison des limites des technologies existantes pour faciliter la communication entre les systèmes informatiques, les éditeurs de logiciels ont souvent dû se résoudre à mettre en place leur propre infrastructure. Cela signifie que des ressources qui auraient pu servir à améliorer les fonctionnalités du système ERP ou du système de traitement des cartes de crédit ont été consacrées à l'élaboration de protocoles réseau propriétaires.

Afin de mieux prendre en charge ce type de scénarios Internet, Microsoft a d'abord opté pour une stratégie visant à enrichir ses technologies existantes, notamment les COM Internet Services (CIS), qui permettent d'établir une connexion DCOM entre le client et le composant distant via le port 80. Pour diverses raisons, les CIS n'ont pas été largement adoptés.

Il est apparu clairement qu'une nouvelle approche s'imposait. Microsoft a donc décidé d'aborder le problème en partant de la base. Voyons quelques-unes des exigences auxquelles la solution devait répondre pour être couronnée de succès.

• Interopérabilité Le service à distance doit pouvoir être utilisé par des clients sur d'autres plateformes.
• Accessibilité sur Internet Cette solution devrait permettre de prendre en charge efficacement les clients qui accèdent au service à distance depuis Internet.
• Interfaces fortement typées Il ne doit y avoir aucune ambiguïté quant au type des données envoyées à un service distant et reçues de celui-ci. De plus, les types de données définis par le service distant devraient correspondre assez bien aux types de données définis par la plupart des langages de programmation procéduraux.
• Capacité à tirer parti des normes Internet existantes La mise en œuvre du service à distance doit s'appuyer autant que possible sur les normes Internet existantes et éviter de réinventer des solutions à des problèmes qui ont déjà été résolus. Une solution fondée sur des normes Internet largement adoptées peut tirer parti des outils et des produits existants conçus pour cette technologie.
• Prise en charge de toutes les langues La solution ne doit pas être étroitement liée à un langage de programmation particulier. Java RMI, par exemple, est étroitement lié au langage Java. Il serait difficile d'invoquer des fonctionnalités sur un objet Java distant à partir de Visual Basic ou de Perl. Un client doit pouvoir implémenter un nouveau service Web ou utiliser un service Web existant, quel que soit le langage de programmation dans lequel il a été écrit.
• Prise en charge de toute infrastructure de composants distribués La solution ne doit pas être étroitement liée à une infrastructure de composants particulière. En effet, vous ne devriez pas être obligé d'acheter, d'installer ou de maintenir une infrastructure d'objets distribués simplement pour créer un nouveau service distant ou utiliser un service existant. Les protocoles sous-jacents doivent permettre un niveau de communication de base entre les infrastructures d'objets distribués existantes, telles que DCOM et CORBA.

Au vu du titre de cet ouvrage, il n'est guère surprenant que la solution mise au point par Microsoft soit connue sous le nom de Services Web. Un service Web met à disposition une interface permettant d'invoquer une activité spécifique pour le compte du client. Un client peut accéder au service Web en utilisant les normes Internet.

Éléments constitutifs des services Web
Le schéma suivant présente les éléments fondamentaux nécessaires pour permettre la communication à distance entre deux applications.

Voyons ensemble à quoi sert chacun de ces éléments constitutifs. Comme de nombreux lecteurs connaissent bien DCOM, je mentionnerai également l'équivalent DCOM de chaque élément constitutif.

• Découverte L'application cliente qui doit accéder aux fonctionnalités fournies par un service Web doit pouvoir déterminer l'emplacement du service distant. Cela s'effectue par le biais d'un processus généralement appelé découverte. La découverte peut être facilitée par un annuaire centralisé ou par des méthodes plus ponctuelles. Dans DCOM, le Service Control Manager (SCM) fournit des services de découverte.
• Description Une fois que le point de terminaison d'un service Web donné a été identifié, le client a besoin d'informations suffisantes pour interagir correctement avec celui-ci. La description d'un service Web comprend des métadonnées structurées concernant l'interface destinée à être utilisée par une application cliente, ainsi qu'une documentation écrite sur le service Web, incluant des exemples d'utilisation. Un composant DCOM expose des métadonnées structurées concernant ses interfaces via une bibliothèque de types (typelib). Les métadonnées contenues dans la bibliothèque de types d'un composant sont stockées dans un format binaire propriétaire et sont accessibles via une interface de programmation d'application (API) propriétaire.
• Format du message Pour échanger des données, un client et un serveur doivent s'accorder sur une méthode commune d'encodage et de formatage des messages. Une méthode standard d'encodage des données garantit que les données encodées par le client seront correctement interprétées par le serveur. Dans DCOM, les messages échangés entre un client et un serveur sont formatés conformément au protocole DCOM Object RPC (ORPC).

En l'absence d'une méthode standard pour formater les messages, il est pratiquement impossible de développer un ensemble d'outils permettant de dissocier le développeur des protocoles sous-jacents. La mise en place d'une couche d'abstraction entre le développeur et les protocoles sous-jacents permet à ce dernier de se concentrer davantage sur le problème métier à résoudre et moins sur l'infrastructure nécessaire à la mise en œuvre de la solution.

• Codage Les données transmises entre le client et le serveur doivent être encodées dans le corps du message. DCOM utilise un schéma d'encodage binaire pour sérialiser les données contenues dans les paramètres échangés entre le client et le serveur.
• Transports Une fois le message formaté et les données sérialisées dans le corps du message, celui-ci doit être transféré entre le client et le serveur via un protocole de transport. DCOM prend en charge plusieurs protocoles propriétaires liés à divers protocoles réseau, tels que TCP, SPX, NetBEUI et NetBIOS sur IPX.

Choix de conception des services Web

Abordons quelques-uns des choix de conception qui sous-tendent ces éléments constitutifs des services Web.

Choix des protocoles de transport

La première étape consistait à déterminer comment le client et le serveur allaient communiquer entre eux. Le client et le serveur peuvent se trouver sur le même réseau local, mais le client pourrait également communiquer avec le serveur via Internet. Le protocole de transport doit donc être adapté aussi bien aux environnements de réseau local qu'à Internet.

Comme je l’ai mentionné précédemment, des technologies telles que DCOM, CORBA et Java RMI ne sont pas adaptées pour prendre en charge la communication entre le client et le serveur sur Internet. Des protocoles tels que le protocole de transfert hypertexte (HTTP) et le protocole simple de transfert de courrier (SMTP) sont des protocoles Internet qui ont fait leurs preuves. HTTP définit un modèle de messagerie de type requête/réponse permettant d’envoyer une requête et d’obtenir la réponse correspondante. SMTP définit un protocole de messagerie routable destiné à la communication asynchrone. Voyons pourquoi HTTP et SMTP sont particulièrement adaptés à Internet.

Les applications Web basées sur le protocole HTTP sont, par nature, sans état. Elles ne reposent pas sur une connexion permanente entre le client et le serveur. Cela fait du protocole HTTP un protocole idéal pour les configurations à haute disponibilité, telles que les pare-feu. Si le serveur qui a traité la requête initiale du client devient indisponible, les requêtes suivantes peuvent être automatiquement redirigées vers un autre serveur sans que le client ne s'en aperçoive ni ne s'en soucie.

Presque toutes les entreprises disposent d'une infrastructure prenant en charge le protocole SMTP. Le protocole SMTP est particulièrement adapté à la communication asynchrone. En cas d'interruption du service, l'infrastructure de messagerie gère automatiquement les nouvelles tentatives d'envoi. Contrairement au protocole HTTP, vous pouvez transmettre des messages SMTP à un serveur de messagerie local qui se chargera de tenter de les acheminer à votre place.

L’autre avantage majeur du protocole HTTP et du protocole SMTP réside dans leur omniprésence. Les employés comptent désormais sur le courrier électronique et leurs navigateurs Web, et les administrateurs réseau maîtrisent parfaitement la gestion de ces services. Des technologies telles que la traduction d'adresses réseau (NAT) et les serveurs proxy permettent d'accéder à Internet via HTTP depuis des réseaux locaux d'entreprise qui seraient autrement isolés. Les administrateurs exposent souvent un serveur SMTP situé à l'intérieur du pare-feu. Les messages envoyés à ce serveur sont ensuite acheminés vers leur destination finale via Internet.

Dans le cas d'un logiciel de traitement des paiements par carte bancaire, une réponse immédiate de la banque du commerçant est nécessaire pour déterminer si la commande doit être transmise au système ERP. Le protocole HTTP, avec son modèle de messages requête/réponse, est parfaitement adapté à cette tâche.

La plupart des progiciels ERP ne sont pas capables de traiter les volumes importants de commandes susceptibles d'être générés par l'application de commerce électronique. De plus, il n'est pas indispensable que les commandes soient transmises au système ERP en temps réel. Le protocole SMTP peut donc être utilisé pour mettre les commandes en file d'attente, afin qu'elles puissent être traitées de manière séquentielle par le système ERP.

Si le système ERP prend en charge les transactions distribuées, une autre option consiste à utiliser Microsoft Message Queue Server (MSMQ). Tant que l'application de commerce électronique et le système ERP se trouvent sur le même réseau local (LAN), la connectivité via des protocoles autres qu'Internet ne pose pas de problème majeur. L'avantage de MSMQ par rapport au protocole SMTP réside dans le fait que les messages peuvent être placés dans la file d'attente et en être retirés dans le cadre d'une transaction. Si une tentative de traitement d'un message retiré de la file d'attente échoue, ce message est automatiquement replacé dans la file d'attente lorsque la transaction est interrompue.

Choix d'un schéma de codage

Les protocoles HTTP et SMTP permettent d'échanger des données entre le client et le serveur. Cependant, aucun des deux ne précise comment les données contenues dans le corps du message doivent être encodées. Microsoft avait besoin d'une méthode standard et indépendante de la plateforme pour encoder les données échangées entre le client et le serveur.

L'objectif étant de tirer parti des protocoles Internet, le langage XML (Extensible Markup Language) s'est imposé comme un choix naturel. Le XML offre de nombreux avantages, notamment une compatibilité multiplateforme, un système de types commun et la prise en charge des jeux de caractères standard de l'industrie.

Les schémas de codage binaire, tels que ceux utilisés par DCOM, CORBA et Java RMI, doivent tenir compte des problèmes de compatibilité entre les différentes plates-formes matérielles. Par exemple, les différentes plates-formes matérielles ont des représentations binaires internes différentes pour les nombres multi-octets. Les plates-formes Intel ordonnent les octets d'un nombre multi-octets selon la convention « little endian » ; de nombreux processeurs RISC ordonnent les octets d'un nombre multi-octets selon la convention « big endian ».

Le format XML évite les problèmes liés au codage binaire, car il utilise un schéma de codage textuel qui s'appuie sur des jeux de caractères standard. De plus, certains protocoles de transport, tels que le SMTP, ne peuvent prendre en charge que des messages textuels.

Les méthodes d'encodage binaires, telles que celles utilisées par DCOM et CORBA, sont lourdes et nécessitent une infrastructure de soutien permettant de soustraire le développeur aux détails techniques. Le XML est beaucoup plus léger et plus facile à manipuler, car il peut être créé et exploité à l'aide de techniques standard d'analyse de texte.

De plus, il existe toute une gamme d'analyseurs XML permettant de simplifier encore davantage la création et l'utilisation de documents XML sur pratiquement toutes les plateformes modernes. Le format XML est léger et bénéficie d'une excellente prise en charge par les outils ; son encodage offre donc une portée incroyable, car pratiquement n'importe quel client, quelle que soit sa plateforme, peut communiquer avec votre service Web.

Choix d'une convention de mise en forme

Il est souvent nécessaire d'inclure des métadonnées supplémentaires dans le corps du message. Par exemple, vous pouvez souhaiter inclure des informations sur le type de services qu'un service Web doit fournir pour répondre à votre requête, telles que la participation à une transaction ou des informations de routage. Le langage XML ne propose aucun mécanisme permettant de distinguer le corps du message des données qui lui sont associées.

Les protocoles de transport tels que HTTP offrent un mécanisme extensible pour les données d'en-tête, mais certaines données associées au message peuvent ne pas être spécifiques au protocole de transport. Par exemple, le client peut envoyer un message qui doit être acheminé vers plusieurs destinations, éventuellement via différents protocoles de transport. Si les informations de routage étaient placées dans un en-tête HTTP, elles devraient être converties avant d’être envoyées à l’intermédiaire suivant via un autre protocole de transport, tel que SMTP. Étant donné que les informations de routage sont spécifiques au message et non au protocole de transport, elles devraient faire partie intégrante du message.

Le protocole SOAP (Simple Object Access Protocol) offre un moyen, indépendant du protocole utilisé, d'associer des informations d'en-tête au corps du message. Tout message SOAP doit définir une enveloppe. L'enveloppe comporte un corps qui contient la charge utile du message et un en-tête pouvant contenir des métadonnées associées au message.

SOAP n'impose aucune restriction quant au formatage du corps du message. Cela peut poser problème, car en l'absence d'une méthode cohérente d'encodage des données, il est difficile de développer un ensemble d'outils permettant de faire abstraction des protocoles sous-jacents. Vous risquez de devoir consacrer beaucoup de temps à vous familiariser avec l’interface du service Web au lieu de résoudre le problème métier en question.

Il fallait trouver un moyen standard de formater un message d'appel de procédure à distance (RPC) et d'encoder sa liste de paramètres. C'est exactement ce que prévoit la section 7 de la spécification SOAP. Elle décrit une convention de nommage et un style d'encodage standard pour les messages orientés procédure.

Comme SOAP fournit un format standard pour la sérialisation des données dans un message XML, des plateformes telles qu'ASP.NET et Remoting peuvent se charger de masquer ces détails pour vous.

Choix des mécanismes de description

Le protocole SOAP fournit un moyen standard de formater les messages échangés entre le service Web et le client. Cependant, le client a besoin d'informations supplémentaires pour pouvoir sérialiser correctement la requête et interpréter la réponse. XML Schema permet de créer des schémas pouvant servir à décrire le contenu d'un message.

XML Schema fournit un ensemble de base de types de données intégrés pouvant être utilisés pour décrire le contenu d'un message. Vous pouvez également créer vos propres types de données. Par exemple, la banque d'affaires peut créer un type de données complexe pour décrire le contenu et la structure du corps d'un message utilisé pour envoyer une demande de paiement par carte bancaire.

Un schéma contient un ensemble de définitions de types de données et d'éléments. Un service Web utilise ce schéma non seulement pour indiquer le type de données attendu dans un message, mais aussi pour valider les messages entrants et sortants.

Un schéma ne fournit toutefois pas à lui seul suffisamment d'informations pour décrire efficacement un service Web. En effet, le schéma ne décrit pas les modèles de messages entre le client et le serveur. Par exemple, un client doit savoir s'il doit s'attendre à recevoir une réponse lorsqu'une commande est enregistrée dans le système ERP. Il doit également connaître le protocole de transport par lequel le service Web attend de recevoir les requêtes. Enfin, le client doit connaître l'adresse à laquelle le service Web est accessible.

Ces informations sont fournies par un document WSDL (Web Services Description Language). Le WSDL est un document XML qui décrit en détail un service Web donné. Des outils tels que WSDL.exe (ASP.NET) et SOAPSUDS.exe (Remoting) peuvent exploiter le WSDL et générer automatiquement des proxys pour le développeur.

Comme pour tout composant utilisé dans le développement d'un logiciel, un service Web doit également être accompagné d'une documentation écrite destinée aux développeurs qui programment en s'appuyant sur ce service. Cette documentation doit décrire le fonctionnement du service Web, les interfaces qu'il expose, ainsi que quelques exemples d'utilisation. Une documentation de qualité est particulièrement importante lorsque le service Web est accessible aux clients via Internet.

Choix des mécanismes de découverte

Une fois que vous avez développé et documenté un service Web, comment les clients potentiels peuvent-ils le trouver ? Si le service Web est destiné à être utilisé par un membre de votre équipe de développement, votre approche peut être assez informelle : il suffit par exemple de partager l'URL du document WSDL avec votre collègue assis deux bureaux plus loin. Mais lorsque les clients potentiels se trouvent sur Internet, promouvoir efficacement votre service Web est une tout autre histoire.

Il faut un moyen commun de faire connaître les services Web. UDDI (Universal Description, Discovery, and Integration) offre justement un tel mécanisme. UDDI est un service d'annuaire centralisé, norme industrielle, qui peut être utilisé pour publier et localiser des services Web. UDDI permet aux utilisateurs de rechercher des services Web à l'aide d'une multitude de critères de recherche, notamment le nom de l'entreprise, la catégorie et le type de service Web.

Les services Web peuvent également être mis en avant via DISCO, un format de document XML propriétaire défini par Microsoft qui permet aux sites Web de mettre en avant les services qu'ils exposent. DISCO définit un protocole simple facilitant la localisation des ressources à l'aide de liens hypertextes. Le principal utilisateur de DISCO est Microsoft Visual Studio.NET. Un développeur peut cibler un serveur Web particulier et parcourir les différents services Web exposés par ce serveur.

Qu'est-ce qui manque aux services Web ?

Vous avez peut-être remarqué que certains éléments clés d'une infrastructure de composants distribués ne sont pas définis par les services Web. Deux des lacunes les plus notables sont l'absence d'une API bien définie pour la création et l'utilisation des services Web, ainsi que l'absence d'un ensemble de services de composants, tels que la prise en charge des transactions distribuées. Examinons chacune de ces lacunes.

• API spécifique aux services Web La plupart des infrastructures de composants distribués définissent une API permettant d'effectuer des tâches telles que l'initialisation de l'environnement d'exécution, la création d'une instance d'un composant et la réflexion des métadonnées utilisées pour décrire ce composant. Comme la plupart des langages de programmation de haut niveau offrent un certain degré d'interopérabilité avec le C, l'API est généralement exposée sous la forme d'un ensemble plat de signatures de méthodes en C. RMI va jusqu’à coupler étroitement son API à un seul langage de haut niveau, Java.

Afin de garantir que les services Web soient indépendants du langage de programmation, Microsoft a laissé aux éditeurs de logiciels le soin de lier la prise en charge des services Web à une plate-forme particulière. J'aborderai plus loin dans cet ouvrage deux implémentations de services Web pour la plate-forme .NET : ASP.NET et Remoting.

• Services des composants La plateforme de services Web ne fournit pas bon nombre des services que l'on trouve habituellement dans les infrastructures de composants distribués, tels que la gestion du cycle de vie des objets à distance, la mise en pool d'objets et la prise en charge des transactions distribuées. La mise en œuvre de ces services est laissée à la charge de l'infrastructure de composants distribués.

Certains services, tels que la prise en charge des transactions distribuées, peuvent être intégrés ultérieurement, à mesure que la technologie évolue. D'autres, tels que la mise en pool d'objets et, éventuellement, la gestion du cycle de vie des objets, peuvent être considérés comme des détails d'implémentation de la plateforme. Par exemple, Remoting définit des extensions permettant la prise en charge de la gestion du cycle de vie des objets, tandis que Microsoft Component Services prend en charge la mise en pool d'objets.

Résumé

La programmation orientée composants s'est révélée être un véritable atout pour la productivité des développeurs, mais certains services ne peuvent pas être encapsulés dans un composant hébergé au sein du centre de données du client. Les technologies héritées telles que DCOM, CORBA et Java RMI ne sont pas adaptées pour permettre aux clients d’accéder à des services via Internet ; Microsoft a donc jugé nécessaire de repartir de zéro et de mettre au point une méthode conforme aux normes de l’industrie pour accéder à des services distants.

Services Web est un terme générique qui désigne un ensemble de protocoles et de services conformes aux normes du secteur, utilisés pour garantir un niveau minimal d'interopérabilité entre les applications. Le soutien apporté par le secteur aux services Web est sans précédent. Jamais auparavant autant d'entreprises technologiques de premier plan ne s'étaient mobilisées pour soutenir une norme facilitant l'interopérabilité entre les applications, quelle que soit la plateforme sur laquelle elles s'exécutent.

L'un des facteurs qui contribuent au succès des services Web réside dans le fait qu'ils s'appuient sur des normes Internet existantes, telles que XML et HTTP. De ce fait, tout système capable d'analyser du texte et de communiquer via un protocole de transport Internet standard peut communiquer avec un service Web. Les entreprises peuvent également tirer parti des investissements qu'elles ont déjà réalisés dans ces technologies.