Vue d'ensemble<\/b>
\nLa programmation \u00e0 base de composants est devenue plus populaire que jamais. Il n'y a gu\u00e8re d'application aujourd'hui qui n'implique pas l'utilisation de composants sous une forme ou une autre, provenant g\u00e9n\u00e9ralement de diff\u00e9rents fournisseurs. Au fur et \u00e0 mesure que les applications sont devenues plus sophistiqu\u00e9es, la n\u00e9cessit\u00e9 d'exploiter des composants distribu\u00e9s sur des machines distantes s'est \u00e9galement accrue.<\/p>\n
<\/p>\n
Une solution de commerce \u00e9lectronique de bout en bout constitue un exemple d'application bas\u00e9e sur des composants. Une application de commerce \u00e9lectronique h\u00e9berg\u00e9e sur une ferme de serveurs Web doit transmettre les commandes \u00e0 une application de gestion int\u00e9gr\u00e9e (ERP) en arri\u00e8re-plan. Dans de nombreux cas, l'application ERP est h\u00e9berg\u00e9e sur un mat\u00e9riel diff\u00e9rent et peut fonctionner sous un autre syst\u00e8me d'exploitation.<\/p>\n
Le Mod\u00e8le d'objets distribu\u00e9s de Microsoft (DCOM), une infrastructure d'objets distribu\u00e9s qui permet \u00e0 une application d'appeler des composants du Mod\u00e8le d'objets composant (COM) install\u00e9s sur un autre serveur, a \u00e9t\u00e9 port\u00e9 sur plusieurs plateformes non Windows. Mais le DCOM n'a jamais \u00e9t\u00e9 largement adopt\u00e9 sur ces plateformes, de sorte qu'il est rarement utilis\u00e9 pour faciliter la communication entre des ordinateurs Windows et non Windows. Les \u00e9diteurs de logiciels ERP cr\u00e9ent souvent des composants pour la plateforme Windows qui communiquent avec le syst\u00e8me back-end via un protocole propri\u00e9taire.<\/p>\n
Certains services utilis\u00e9s par une application de commerce \u00e9lectronique peuvent ne pas se trouver du tout au sein du centre de donn\u00e9es. Par exemple, si l'application de commerce \u00e9lectronique accepte les paiements par carte de cr\u00e9dit pour les articles achet\u00e9s par le client, elle doit faire appel aux services de la banque commerciale pour traiter les informations de carte de cr\u00e9dit du client. Mais dans la pratique, DCOM et les technologies associ\u00e9es telles que CORBA et Java RMI sont limit\u00e9es aux applications et composants install\u00e9s au sein du centre de donn\u00e9es de l'entreprise. Cela s'explique principalement par deux raisons : par d\u00e9faut, ces technologies utilisent des protocoles propri\u00e9taires, et ces protocoles sont intrins\u00e8quement orient\u00e9s connexion.<\/p>\n
Les clients qui communiquent avec le serveur via Internet se heurtent \u00e0 de nombreux obstacles potentiels. Partout dans le monde, les administrateurs r\u00e9seau soucieux de la s\u00e9curit\u00e9 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 \u00e9v\u00e9nement exceptionnel pour qu'un administrateur r\u00e9seau accepte d'ouvrir des ports au-del\u00e0 du strict minimum.<\/p>\n
Si vous avez la chance de convaincre un administrateur r\u00e9seau d'ouvrir les ports n\u00e9cessaires au fonctionnement de votre service, il y a fort \u00e0 parier que vos clients n'auront pas cette chance. Par cons\u00e9quent, les protocoles propri\u00e9taires tels que ceux utilis\u00e9s par DCOM, CORBA et Java RMI ne sont pas adapt\u00e9s aux sc\u00e9narios Internet.<\/p>\n
L'autre probl\u00e8me, comme je l'ai dit, avec ces technologies, c'est qu'elles sont intrins\u00e8quement orient\u00e9es connexion et ne peuvent donc pas g\u00e9rer correctement les interruptions de r\u00e9seau. Comme vous n'avez pas de contr\u00f4le direct sur Internet, vous ne pouvez pas faire de suppositions quant \u00e0 la qualit\u00e9 ou \u00e0 la fiabilit\u00e9 de la connexion. En cas d'interruption de r\u00e9seau, la prochaine requ\u00eate que le client enverra au serveur risque d'\u00e9chouer.<\/p>\n
Le fait que ces technologies soient orient\u00e9es connexion complique \u00e9galement la mise en place des infrastructures \u00e0 \u00e9quilibrage de charge n\u00e9cessaires pour atteindre une grande \u00e9volutivit\u00e9. Une fois la connexion entre le client et le serveur interrompue, il n'est pas possible de simplement rediriger la requ\u00eate suivante vers un autre serveur.<\/p>\n
Les d\u00e9veloppeurs ont tent\u00e9 de surmonter ces limites en s'appuyant sur un mod\u00e8le appel\u00e9 sans nationalit\u00e9 <\/i>programmation<\/i>, mais leur succ\u00e8s a \u00e9t\u00e9 limit\u00e9 car ces technologies sont assez lourdes et rendent co\u00fbteux le r\u00e9tablissement d'une connexion avec un objet distant.<\/p>\n
\u00c9tant donn\u00e9 que le traitement de la carte de cr\u00e9dit d'un client est effectu\u00e9 par un serveur distant sur Internet, DCOM n'est pas la solution id\u00e9ale pour faciliter la communication entre le client du site de commerce \u00e9lectronique et le serveur de traitement des cartes de cr\u00e9dit. Comme dans une solution ERP, un composant tiers est souvent install\u00e9 au sein du centre de donn\u00e9es du client (dans ce cas, par le fournisseur de la solution de traitement des cartes de cr\u00e9dit). Ce composant ne sert gu\u00e8re plus qu\u2019un proxy facilitant la communication entre le logiciel de commerce \u00e9lectronique et la banque du commer\u00e7ant via un protocole propri\u00e9taire.<\/p>\n
Voyez-vous une tendance se dessiner ici ? En raison des limites des technologies existantes pour faciliter la communication entre les syst\u00e8mes informatiques, les \u00e9diteurs de logiciels ont souvent d\u00fb se r\u00e9soudre \u00e0 mettre en place leur propre infrastructure. Cela signifie que des ressources qui auraient pu servir \u00e0 am\u00e9liorer les fonctionnalit\u00e9s du syst\u00e8me ERP ou du syst\u00e8me de traitement des cartes de cr\u00e9dit ont \u00e9t\u00e9 consacr\u00e9es \u00e0 l'\u00e9laboration de protocoles r\u00e9seau propri\u00e9taires.<\/p>\n
Afin de mieux prendre en charge ce type de sc\u00e9narios Internet, Microsoft a d'abord opt\u00e9 pour une strat\u00e9gie visant \u00e0 enrichir ses technologies existantes, notamment les COM Internet Services (CIS), qui permettent d'\u00e9tablir une connexion DCOM entre le client et le composant distant via le port 80. Pour diverses raisons, les CIS n'ont pas \u00e9t\u00e9 largement adopt\u00e9s.<\/p>\n
Il est apparu clairement qu'une nouvelle approche s'imposait. Microsoft a donc d\u00e9cid\u00e9 d'aborder le probl\u00e8me en partant de la base. Voyons quelques-unes des exigences auxquelles la solution devait r\u00e9pondre pour \u00eatre couronn\u00e9e de succ\u00e8s.<\/p>\n
Au vu du titre de cet ouvrage, il n'est gu\u00e8re surprenant que la solution mise au point par Microsoft soit connue sous le nom de Services Web<\/i>. Un service Web met \u00e0 disposition une interface permettant d'invoquer une activit\u00e9 sp\u00e9cifique pour le compte du client. Un client peut acc\u00e9der au service Web en utilisant les normes Internet.<\/p>\n
\u00c9l\u00e9ments constitutifs des services Web<\/b>
\nLe sch\u00e9ma suivant pr\u00e9sente les \u00e9l\u00e9ments fondamentaux n\u00e9cessaires pour permettre la communication \u00e0 distance entre deux applications.<\/p>\n
Voyons ensemble \u00e0 quoi sert chacun de ces \u00e9l\u00e9ments constitutifs. Comme de nombreux lecteurs connaissent bien DCOM, je mentionnerai \u00e9galement l'\u00e9quivalent DCOM de chaque \u00e9l\u00e9ment constitutif.<\/p>\n
En l'absence d'une m\u00e9thode standard pour formater les messages, il est pratiquement impossible de d\u00e9velopper un ensemble d'outils permettant de dissocier le d\u00e9veloppeur des protocoles sous-jacents. La mise en place d'une couche d'abstraction entre le d\u00e9veloppeur et les protocoles sous-jacents permet \u00e0 ce dernier de se concentrer davantage sur le probl\u00e8me m\u00e9tier \u00e0 r\u00e9soudre et moins sur l'infrastructure n\u00e9cessaire \u00e0 la mise en \u0153uvre de la solution.<\/p>\n
Choix de conception des services Web<\/b><\/p>\n
Abordons quelques-uns des choix de conception qui sous-tendent ces \u00e9l\u00e9ments constitutifs des services Web.<\/p>\n
Choix des protocoles de transport<\/b><\/p>\n
La premi\u00e8re \u00e9tape consistait \u00e0 d\u00e9terminer comment le client et le serveur allaient communiquer entre eux. Le client et le serveur peuvent se trouver sur le m\u00eame r\u00e9seau local, mais le client pourrait \u00e9galement communiquer avec le serveur via Internet. Le protocole de transport doit donc \u00eatre adapt\u00e9 aussi bien aux environnements de r\u00e9seau local qu'\u00e0 Internet.<\/p>\n
Comme je l\u2019ai mentionn\u00e9 pr\u00e9c\u00e9demment, des technologies telles que DCOM, CORBA et Java RMI ne sont pas adapt\u00e9es 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\u00e9finit un mod\u00e8le de messagerie de type requ\u00eate\/r\u00e9ponse permettant d\u2019envoyer une requ\u00eate et d\u2019obtenir la r\u00e9ponse correspondante. SMTP d\u00e9finit un protocole de messagerie routable destin\u00e9 \u00e0 la communication asynchrone. Voyons pourquoi HTTP et SMTP sont particuli\u00e8rement adapt\u00e9s \u00e0 Internet.<\/p>\n
Les applications Web bas\u00e9es sur le protocole HTTP sont, par nature, sans \u00e9tat. Elles ne reposent pas sur une connexion permanente entre le client et le serveur. Cela fait du protocole HTTP un protocole id\u00e9al pour les configurations \u00e0 haute disponibilit\u00e9, telles que les pare-feu. Si le serveur qui a trait\u00e9 la requ\u00eate initiale du client devient indisponible, les requ\u00eates suivantes peuvent \u00eatre automatiquement redirig\u00e9es vers un autre serveur sans que le client ne s'en aper\u00e7oive ni ne s'en soucie.<\/p>\n
Presque toutes les entreprises disposent d'une infrastructure prenant en charge le protocole SMTP. Le protocole SMTP est particuli\u00e8rement adapt\u00e9 \u00e0 la communication asynchrone. En cas d'interruption du service, l'infrastructure de messagerie g\u00e8re automatiquement les nouvelles tentatives d'envoi. Contrairement au protocole HTTP, vous pouvez transmettre des messages SMTP \u00e0 un serveur de messagerie local qui se chargera de tenter de les acheminer \u00e0 votre place.<\/p>\n
L\u2019autre avantage majeur du protocole HTTP et du protocole SMTP r\u00e9side dans leur omnipr\u00e9sence. Les employ\u00e9s comptent d\u00e9sormais sur le courrier \u00e9lectronique et leurs navigateurs Web, et les administrateurs r\u00e9seau ma\u00eetrisent parfaitement la gestion de ces services. Des technologies telles que la traduction d'adresses r\u00e9seau (NAT) et les serveurs proxy permettent d'acc\u00e9der \u00e0 Internet via HTTP depuis des r\u00e9seaux locaux d'entreprise qui seraient autrement isol\u00e9s. Les administrateurs exposent souvent un serveur SMTP situ\u00e9 \u00e0 l'int\u00e9rieur du pare-feu. Les messages envoy\u00e9s \u00e0 ce serveur sont ensuite achemin\u00e9s vers leur destination finale via Internet.<\/p>\n
Dans le cas d'un logiciel de traitement des paiements par carte bancaire, une r\u00e9ponse imm\u00e9diate de la banque du commer\u00e7ant est n\u00e9cessaire pour d\u00e9terminer si la commande doit \u00eatre transmise au syst\u00e8me ERP. Le protocole HTTP, avec son mod\u00e8le de messages requ\u00eate\/r\u00e9ponse, est parfaitement adapt\u00e9 \u00e0 cette t\u00e2che.<\/p>\n
La plupart des progiciels ERP ne sont pas capables de traiter les volumes importants de commandes susceptibles d'\u00eatre g\u00e9n\u00e9r\u00e9s par l'application de commerce \u00e9lectronique. De plus, il n'est pas indispensable que les commandes soient transmises au syst\u00e8me ERP en temps r\u00e9el. Le protocole SMTP peut donc \u00eatre utilis\u00e9 pour mettre les commandes en file d'attente, afin qu'elles puissent \u00eatre trait\u00e9es de mani\u00e8re s\u00e9quentielle par le syst\u00e8me ERP.<\/p>\n
Si le syst\u00e8me ERP prend en charge les transactions distribu\u00e9es, une autre option consiste \u00e0 utiliser Microsoft Message Queue Server (MSMQ). Tant que l'application de commerce \u00e9lectronique et le syst\u00e8me ERP se trouvent sur le m\u00eame r\u00e9seau local (LAN), la connectivit\u00e9 via des protocoles autres qu'Internet ne pose pas de probl\u00e8me majeur. L'avantage de MSMQ par rapport au protocole SMTP r\u00e9side dans le fait que les messages peuvent \u00eatre plac\u00e9s dans la file d'attente et en \u00eatre retir\u00e9s dans le cadre d'une transaction. Si une tentative de traitement d'un message retir\u00e9 de la file d'attente \u00e9choue, ce message est automatiquement replac\u00e9 dans la file d'attente lorsque la transaction est interrompue.<\/p>\n
Choix d'un sch\u00e9ma de codage<\/b><\/p>\n
Les protocoles HTTP et SMTP permettent d'\u00e9changer des donn\u00e9es entre le client et le serveur. Cependant, aucun des deux ne pr\u00e9cise comment les donn\u00e9es contenues dans le corps du message doivent \u00eatre encod\u00e9es. Microsoft avait besoin d'une m\u00e9thode standard et ind\u00e9pendante de la plateforme pour encoder les donn\u00e9es \u00e9chang\u00e9es entre le client et le serveur.<\/p>\n
L'objectif \u00e9tant de tirer parti des protocoles Internet, le langage XML (Extensible Markup Language) s'est impos\u00e9 comme un choix naturel. Le XML offre de nombreux avantages, notamment une compatibilit\u00e9 multiplateforme, un syst\u00e8me de types commun et la prise en charge des jeux de caract\u00e8res standard de l'industrie.<\/p>\n
Les sch\u00e9mas de codage binaire, tels que ceux utilis\u00e9s par DCOM, CORBA et Java RMI, doivent tenir compte des probl\u00e8mes de compatibilit\u00e9 entre les diff\u00e9rentes plates-formes mat\u00e9rielles. Par exemple, les diff\u00e9rentes plates-formes mat\u00e9rielles ont des repr\u00e9sentations binaires internes diff\u00e9rentes pour les nombres multi-octets. Les plates-formes Intel ordonnent les octets d'un nombre multi-octets selon la convention \u00ab little endian \u00bb ; de nombreux processeurs RISC ordonnent les octets d'un nombre multi-octets selon la convention \u00ab big endian \u00bb.<\/p>\n
Le format XML \u00e9vite les probl\u00e8mes li\u00e9s au codage binaire, car il utilise un sch\u00e9ma de codage textuel qui s'appuie sur des jeux de caract\u00e8res standard. De plus, certains protocoles de transport, tels que le SMTP, ne peuvent prendre en charge que des messages textuels.<\/p>\n
Les m\u00e9thodes d'encodage binaires, telles que celles utilis\u00e9es par DCOM et CORBA, sont lourdes et n\u00e9cessitent une infrastructure de soutien permettant de soustraire le d\u00e9veloppeur aux d\u00e9tails techniques. Le XML est beaucoup plus l\u00e9ger et plus facile \u00e0 manipuler, car il peut \u00eatre cr\u00e9\u00e9 et exploit\u00e9 \u00e0 l'aide de techniques standard d'analyse de texte.<\/p>\n
De plus, il existe toute une gamme d'analyseurs XML permettant de simplifier encore davantage la cr\u00e9ation et l'utilisation de documents XML sur pratiquement toutes les plateformes modernes. Le format XML est l\u00e9ger et b\u00e9n\u00e9ficie d'une excellente prise en charge par les outils ; son encodage offre donc une port\u00e9e incroyable, car pratiquement n'importe quel client, quelle que soit sa plateforme, peut communiquer avec votre service Web.<\/p>\n
Choix d'une convention de mise en forme<\/b><\/p>\n
Il est souvent n\u00e9cessaire d'inclure des m\u00e9tadonn\u00e9es suppl\u00e9mentaires 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\u00e9pondre \u00e0 votre requ\u00eate, telles que la participation \u00e0 une transaction ou des informations de routage. Le langage XML ne propose aucun m\u00e9canisme permettant de distinguer le corps du message des donn\u00e9es qui lui sont associ\u00e9es.<\/p>\n
Les protocoles de transport tels que HTTP offrent un m\u00e9canisme extensible pour les donn\u00e9es d'en-t\u00eate, mais certaines donn\u00e9es associ\u00e9es au message peuvent ne pas \u00eatre sp\u00e9cifiques au protocole de transport. Par exemple, le client peut envoyer un message qui doit \u00eatre achemin\u00e9 vers plusieurs destinations, \u00e9ventuellement via diff\u00e9rents protocoles de transport. Si les informations de routage \u00e9taient plac\u00e9es dans un en-t\u00eate HTTP, elles devraient \u00eatre converties avant d\u2019\u00eatre envoy\u00e9es \u00e0 l\u2019interm\u00e9diaire suivant via un autre protocole de transport, tel que SMTP. \u00c9tant donn\u00e9 que les informations de routage sont sp\u00e9cifiques au message et non au protocole de transport, elles devraient faire partie int\u00e9grante du message.<\/p>\n
Le protocole SOAP (Simple Object Access Protocol) offre un moyen, ind\u00e9pendant du protocole utilis\u00e9, d'associer des informations d'en-t\u00eate au corps du message. Tout message SOAP doit d\u00e9finir une enveloppe. L'enveloppe comporte un corps qui contient la charge utile du message et un en-t\u00eate pouvant contenir des m\u00e9tadonn\u00e9es associ\u00e9es au message.<\/p>\n
SOAP n'impose aucune restriction quant au formatage du corps du message. Cela peut poser probl\u00e8me, car en l'absence d'une m\u00e9thode coh\u00e9rente d'encodage des donn\u00e9es, il est difficile de d\u00e9velopper un ensemble d'outils permettant de faire abstraction des protocoles sous-jacents. Vous risquez de devoir consacrer beaucoup de temps \u00e0 vous familiariser avec l\u2019interface du service Web au lieu de r\u00e9soudre le probl\u00e8me m\u00e9tier en question.<\/p>\n
Il fallait trouver un moyen standard de formater un message d'appel de proc\u00e9dure \u00e0 distance (RPC) et d'encoder sa liste de param\u00e8tres. C'est exactement ce que pr\u00e9voit la section 7 de la sp\u00e9cification SOAP. Elle d\u00e9crit une convention de nommage et un style d'encodage standard pour les messages orient\u00e9s proc\u00e9dure.<\/p>\n
Comme SOAP fournit un format standard pour la s\u00e9rialisation des donn\u00e9es dans un message XML, des plateformes telles qu'ASP.NET et Remoting peuvent se charger de masquer ces d\u00e9tails pour vous.<\/p>\n
Choix des m\u00e9canismes de description<\/b><\/p>\n
Le protocole SOAP fournit un moyen standard de formater les messages \u00e9chang\u00e9s entre le service Web et le client. Cependant, le client a besoin d'informations suppl\u00e9mentaires pour pouvoir s\u00e9rialiser correctement la requ\u00eate et interpr\u00e9ter la r\u00e9ponse. XML Schema permet de cr\u00e9er des sch\u00e9mas pouvant servir \u00e0 d\u00e9crire le contenu d'un message.<\/p>\n
XML Schema fournit un ensemble de base de types de donn\u00e9es int\u00e9gr\u00e9s pouvant \u00eatre utilis\u00e9s pour d\u00e9crire le contenu d'un message. Vous pouvez \u00e9galement cr\u00e9er vos propres types de donn\u00e9es. Par exemple, la banque d'affaires peut cr\u00e9er un type de donn\u00e9es complexe pour d\u00e9crire le contenu et la structure du corps d'un message utilis\u00e9 pour envoyer une demande de paiement par carte bancaire.<\/p>\n
Un sch\u00e9ma contient un ensemble de d\u00e9finitions de types de donn\u00e9es et d'\u00e9l\u00e9ments. Un service Web utilise ce sch\u00e9ma non seulement pour indiquer le type de donn\u00e9es attendu dans un message, mais aussi pour valider les messages entrants et sortants.<\/p>\n
Un sch\u00e9ma ne fournit toutefois pas \u00e0 lui seul suffisamment d'informations pour d\u00e9crire efficacement un service Web. En effet, le sch\u00e9ma ne d\u00e9crit pas les mod\u00e8les de messages entre le client et le serveur. Par exemple, un client doit savoir s'il doit s'attendre \u00e0 recevoir une r\u00e9ponse lorsqu'une commande est enregistr\u00e9e dans le syst\u00e8me ERP. Il doit \u00e9galement conna\u00eetre le protocole de transport par lequel le service Web attend de recevoir les requ\u00eates. Enfin, le client doit conna\u00eetre l'adresse \u00e0 laquelle le service Web est accessible.<\/p>\n
Ces informations sont fournies par un document WSDL (Web Services Description Language). Le WSDL est un document XML qui d\u00e9crit en d\u00e9tail un service Web donn\u00e9. Des outils tels que WSDL.exe (ASP.NET) et SOAPSUDS.exe (Remoting) peuvent exploiter le WSDL et g\u00e9n\u00e9rer automatiquement des proxys pour le d\u00e9veloppeur.<\/p>\n
Comme pour tout composant utilis\u00e9 dans le d\u00e9veloppement d'un logiciel, un service Web doit \u00e9galement \u00eatre accompagn\u00e9 d'une documentation \u00e9crite destin\u00e9e aux d\u00e9veloppeurs qui programment en s'appuyant sur ce service. Cette documentation doit d\u00e9crire le fonctionnement du service Web, les interfaces qu'il expose, ainsi que quelques exemples d'utilisation. Une documentation de qualit\u00e9 est particuli\u00e8rement importante lorsque le service Web est accessible aux clients via Internet.<\/p>\n
Choix des m\u00e9canismes de d\u00e9couverte<\/b><\/p>\n
Une fois que vous avez d\u00e9velopp\u00e9 et document\u00e9 un service Web, comment les clients potentiels peuvent-ils le trouver ? Si le service Web est destin\u00e9 \u00e0 \u00eatre utilis\u00e9 par un membre de votre \u00e9quipe de d\u00e9veloppement, votre approche peut \u00eatre assez informelle : il suffit par exemple de partager l'URL du document WSDL avec votre coll\u00e8gue assis deux bureaux plus loin. Mais lorsque les clients potentiels se trouvent sur Internet, promouvoir efficacement votre service Web est une tout autre histoire.<\/p>\n
Il faut un moyen commun de faire conna\u00eetre les services Web. UDDI (Universal Description, Discovery, and Integration) offre justement un tel m\u00e9canisme. UDDI est un service d'annuaire centralis\u00e9, norme industrielle, qui peut \u00eatre utilis\u00e9 pour publier et localiser des services Web. UDDI permet aux utilisateurs de rechercher des services Web \u00e0 l'aide d'une multitude de crit\u00e8res de recherche, notamment le nom de l'entreprise, la cat\u00e9gorie et le type de service Web.<\/p>\n
Les services Web peuvent \u00e9galement \u00eatre mis en avant via DISCO, un format de document XML propri\u00e9taire d\u00e9fini par Microsoft qui permet aux sites Web de mettre en avant les services qu'ils exposent. DISCO d\u00e9finit un protocole simple facilitant la localisation des ressources \u00e0 l'aide de liens hypertextes. Le principal utilisateur de DISCO est Microsoft Visual Studio.NET. Un d\u00e9veloppeur peut cibler un serveur Web particulier et parcourir les diff\u00e9rents services Web expos\u00e9s par ce serveur.<\/p>\n
Qu'est-ce qui manque aux services Web ?<\/b><\/p>\n
Vous avez peut-\u00eatre remarqu\u00e9 que certains \u00e9l\u00e9ments cl\u00e9s d'une infrastructure de composants distribu\u00e9s ne sont pas d\u00e9finis par les services Web. Deux des lacunes les plus notables sont l'absence d'une API bien d\u00e9finie pour la cr\u00e9ation 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\u00e9es. Examinons chacune de ces lacunes.<\/p>\n
Afin de garantir que les services Web soient ind\u00e9pendants du langage de programmation, Microsoft a laiss\u00e9 aux \u00e9diteurs de logiciels le soin de lier la prise en charge des services Web \u00e0 une plate-forme particuli\u00e8re. J'aborderai plus loin dans cet ouvrage deux impl\u00e9mentations de services Web pour la plate-forme .NET : ASP.NET et Remoting.<\/p>\n
Certains services, tels que la prise en charge des transactions distribu\u00e9es, peuvent \u00eatre int\u00e9gr\u00e9s ult\u00e9rieurement, \u00e0 mesure que la technologie \u00e9volue. D'autres, tels que la mise en pool d'objets et, \u00e9ventuellement, la gestion du cycle de vie des objets, peuvent \u00eatre consid\u00e9r\u00e9s comme des d\u00e9tails d'impl\u00e9mentation de la plateforme. Par exemple, Remoting d\u00e9finit 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.<\/p>\n
R\u00e9sum\u00e9<\/b><\/p>\n
La programmation orient\u00e9e composants s'est r\u00e9v\u00e9l\u00e9e \u00eatre un v\u00e9ritable atout pour la productivit\u00e9 des d\u00e9veloppeurs, mais certains services ne peuvent pas \u00eatre encapsul\u00e9s dans un composant h\u00e9berg\u00e9 au sein du centre de donn\u00e9es du client. Les technologies h\u00e9rit\u00e9es telles que DCOM, CORBA et Java RMI ne sont pas adapt\u00e9es pour permettre aux clients d\u2019acc\u00e9der \u00e0 des services via Internet ; Microsoft a donc jug\u00e9 n\u00e9cessaire de repartir de z\u00e9ro et de mettre au point une m\u00e9thode conforme aux normes de l\u2019industrie pour acc\u00e9der \u00e0 des services distants.<\/p>\n
Services Web<\/i> est un terme g\u00e9n\u00e9rique qui d\u00e9signe un ensemble de protocoles et de services conformes aux normes du secteur, utilis\u00e9s pour garantir un niveau minimal d'interop\u00e9rabilit\u00e9 entre les applications. Le soutien apport\u00e9 par le secteur aux services Web est sans pr\u00e9c\u00e9dent. Jamais auparavant autant d'entreprises technologiques de premier plan ne s'\u00e9taient mobilis\u00e9es pour soutenir une norme facilitant l'interop\u00e9rabilit\u00e9 entre les applications, quelle que soit la plateforme sur laquelle elles s'ex\u00e9cutent.<\/p>\n
L'un des facteurs qui contribuent au succ\u00e8s des services Web r\u00e9side dans le fait qu'ils s'appuient sur des normes Internet existantes, telles que XML et HTTP. De ce fait, tout syst\u00e8me capable d'analyser du texte et de communiquer via un protocole de transport Internet standard peut communiquer avec un service Web. Les entreprises peuvent \u00e9galement tirer parti des investissements qu'elles ont d\u00e9j\u00e0 r\u00e9alis\u00e9s dans ces technologies.<\/p>","protected":false},"excerpt":{"rendered":"
Overview Component-based programming has become more popular than ever. Hardly an application is built today that does not involve leveraging components in some form, usually from different vendors. As applications have grown more sophisticated, the need to leverage components distributed on remote machines has also grown.<\/p>","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-231","post","type-post","status-publish","format-standard","hentry","category-smtp-servers"],"_links":{"self":[{"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/posts\/231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/comments?post=231"}],"version-history":[{"count":1,"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/posts\/231\/revisions"}],"predecessor-version":[{"id":232,"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/posts\/231\/revisions\/232"}],"wp:attachment":[{"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/media?parent=231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/categories?post=231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/tags?post=231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}