Les Web services s'intègrent í ServiceNow. Mais qu'est ce qu'un Web service?
Un service Web est un service d'interaction accessible depuis le réseau qui vise l'interopérabilité et la cohérence par l'utilisation d'un format d'échange pivot, souvent XML.
Les Web services s'intègrent au modèle SOA[sup]1[/sup].
Les bases
Les principes sous-jacents des Web services sont étonnamment simples et n'ont rien de nouveau dans le monde du calcul distribué et de l'internet.
- Le fournisseur de service internet défini un format pour les requêtes vers son service et la réponse que le service génèrera
- Un ordinateur fait une requête pour le Web service í travers le réseau
- Le Web service exécute une action, et renvoie une réponse
Cette action pourrait être la récupération d'un cours de bourse, trouver le meilleur prix pour un produit particulier sur le net, l'enregistrement d'un nouveau rendez-vous í un calendrier, la traduction d'un passage de texte dans une autre langue, ou la validation d'un numéro de carte de crédit.
L'intérêt d'un Web service
La raison pour laquelle nous devrions soudainement trouver un intérêt pour les modèles de services est l'incorporation de normes, de protocoles ouverts[sup]2[/sup] (ils utilisent le plus souvent XML, et fonctionnent par-dessus HTTP), compréhensibles par la majorité des programmes, pour appeler les services et transmettre les données. Ils sont donc indépendants des plates-formes. Ainsi, cela permet aux vendeurs d'outils de développement d'offrir différentes méthodes et interfaces de programmation, í différents niveaux de sophistication.
Vous l'aurez donc compris: la façon la plus efficace de partager des fonctionnalités, ce sont les Web services. De plus ils permettent une économie de temps pour le développeur et d'argent pour le client en tirant directement parti de services existants.
Fonctionnement d'un Web service
Scénario
Alors, quand devrais-je utiliser un Web service?
Imaginons que je suis un développeur et que j'ai été invitée í fournir une nouvelle fonctionnalité sur le site de mon entreprise: je dois inclure une installation de validation de code postal pour vérifier que les codes postaux sont corrects lorsque les clients soumettent un formulaire d'inscription.
La validation devra vérifier les codes postaux pour les pays où nous exerçons nos activités, et il faudra également vérifier si l'entrée de la ville correspond au code postal. Je n'ai pas ces données, et je soupçonne que cela va me coûter beaucoup d'argent pour les obtenir.
Plutôt que d'acheter les données, d'écrire le code moi-même, d'entretenir les données et d'optimiser les performances de mon code, je vais rechercher dans l'UDDI (par exemple) et voir si quelqu'un propose un Web service qui fait ce genre de travail. Navigation vers www.uddi.org, je fais une recherche et trouve le service parfait de l'entreprise X.
J'analyse soigneusement la définition du Web service (écrit dans le "Web Services Description Language" (WSDL), une syntaxe XML pour la définition des Web services), pour que je sois certaine que le Web service fait ce dont j'ai besoin. Je vérifie ensuite avec mes collègues de l'industrie que l'entreprise X est fiable, et entre en contact avec l'entreprise X pour parler finance. Après avoir trouvé un prix cohérent par rapport í mon budget, j'écris du code qui appelle le service X depuis ma page JSP, et voilí , validation instantanée de code postal.
Architecture
Les services Web ont été conçus, pour être réalisés sur de nombreux systèmes et déployés de façon indépendante, en reprenant la plupart des idées et des principes du Web (HTTP, XML), et en les appliquant í des interactions entre machines. Ils communiquent via un ensemble de technologies fondamentales: HTTP, WSDL[sup]3[/sup], SOAP et UDDI...
D'autres technologies telles que le DCOM[sup]4[/sup], named pipes[sup]5[/sup], la RMI[sup]6[/sup] ont précédemment adopté ce style architectural mais ont souvent échoué en raison de la diversité des plates-formes utilisées dans les entreprises et faute d'un usage inadapté í Internet (problème de passage í travers des pares-feu, etc.) d'où la lenteur, voire l'absence de réponses sur ce réseau.
L'intégration est sans doute le facteur essentiel qui favorise l'utilisation des services Web.
Alors, quand devrais-je utiliser un Web service?
Imaginons que je suis un développeur et que j'ai été invitée í fournir une nouvelle fonctionnalité sur le site de mon entreprise: je dois inclure une installation de validation de code postal pour vérifier que les codes postaux sont corrects lorsque les clients soumettent un formulaire d'inscription.
La validation devra vérifier les codes postaux pour les pays où nous exerçons nos activités, et il faudra également vérifier si l'entrée de la ville correspond au code postal. Je n'ai pas ces données, et je soupçonne que cela va me coûter beaucoup d'argent pour les obtenir.
Plutôt que d'acheter les données, d'écrire le code moi-même, d'entretenir les données et d'optimiser les performances de mon code, je vais rechercher dans l'UDDI (par exemple) et voir si quelqu'un propose un Web service qui fait ce genre de travail. Navigation vers www.uddi.org, je fais une recherche et trouve le service parfait de l'entreprise X.
J'analyse soigneusement la définition du Web service (écrit dans le "Web Services Description Language" (WSDL), une syntaxe XML pour la définition des Web services), pour que je sois certaine que le Web service fait ce dont j'ai besoin. Je vérifie ensuite avec mes collègues de l'industrie que l'entreprise X est fiable, et entre en contact avec l'entreprise X pour parler finance. Après avoir trouvé un prix cohérent par rapport í mon budget, j'écris du code qui appelle le service X depuis ma page JSP, et voilí , validation instantanée de code postal.
Architecture
Les services Web ont été conçus, pour être réalisés sur de nombreux systèmes et déployés de façon indépendante, en reprenant la plupart des idées et des principes du Web (HTTP, XML), et en les appliquant í des interactions entre machines. Ils communiquent via un ensemble de technologies fondamentales: HTTP, WSDL[sup]3[/sup], SOAP et UDDI...
SOAP
Le Simple Object Access Protocol (SOAP) est un protocole standard du W3C qui représente le format des demandes de service Web.
Les messages SOAP sont envoyés dans les deux sens entre le fournisseur de service et l'utilisateur du service dans des enveloppes SOAP, contenant í l'allée une demande pour une certaine action et au retour le résultat de cette action. Les enveloppes SOAP sont au format XML, et sont assez faciles í décoder. Ci-dessous une requête SOAP simple, qui pourrait être envoyé via une requête HTTP í un service Web:
Les éléments clés de notre enveloppe SOAP sont faciles í reconnaître: deux paramètres (
Une réponse í cette demande pourrait ressembler í ceci:
Ce message est encore plus simple í interpréter. L'élément
UDDI
L'UDDI (Universal Description, Discovery and Integration) permet aux entreprises d'offrir leurs Web services í d'autres entreprises en agissant comme un annuaire téléphonique pour les Web services. Il n'y a pas de coûts associés í l'enregistrement de votre Web service dans l'UDDI, et les fondateurs espèrent que cela fournira une liste de référence centrale de tous les services résidant í travers le net, afin que les développeurs í la recherche d'un service puissent simplement utiliser l'UDDI pour localiser le fournisseur le plus approprié.
Le Simple Object Access Protocol (SOAP) est un protocole standard du W3C qui représente le format des demandes de service Web.
Les messages SOAP sont envoyés dans les deux sens entre le fournisseur de service et l'utilisateur du service dans des enveloppes SOAP, contenant í l'allée une demande pour une certaine action et au retour le résultat de cette action. Les enveloppes SOAP sont au format XML, et sont assez faciles í décoder. Ci-dessous une requête SOAP simple, qui pourrait être envoyé via une requête HTTP í un service Web:
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
<m:ValidatePostcode
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://www.somesite.com/Postcode">
<Postcode>44000</Postcode>
<Country>FR</Country>
</m:ValidatePostcode>
</env:Body>
</env:Envelope>
Les éléments clés de notre enveloppe SOAP sont faciles í reconnaître: deux paramètres (
et
Postcode
) sont contenus dans un élément nommé
Country
, qui se trouve être le nom du service web que nous appelons. D'autres données au sein de l'enveloppe, comme le texte de codage et la version SOAP, aide le Web services í traiter la demande.
ValidatePostcode
Une réponse í cette demande pourrait ressembler í ceci:
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
<env:Body>
<m:ValidatePostcodeResponse
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://www.somesite.com/Postcode">
<Valid>Yes</Valid>
</m:ValidatePostcodeResponse>
</env:Body>
</env:Envelope>
Ce message est encore plus simple í interpréter. L'élément
de notre demande a été répondu par un élément
ValidatePostcode
dans ce message SOAP, qui contient un seul élément,
ValidatePostcodeResponse
, indiquant si oui ou non notre code postal était correct. Ainsi, í travers la magie de SOAP, nous pouvons construire une requête pour achever une partie du travail, et recevoir une réponse cohérente au format XML retourné í travers le réseau.
Valid
UDDI
L'UDDI (Universal Description, Discovery and Integration) permet aux entreprises d'offrir leurs Web services í d'autres entreprises en agissant comme un annuaire téléphonique pour les Web services. Il n'y a pas de coûts associés í l'enregistrement de votre Web service dans l'UDDI, et les fondateurs espèrent que cela fournira une liste de référence centrale de tous les services résidant í travers le net, afin que les développeurs í la recherche d'un service puissent simplement utiliser l'UDDI pour localiser le fournisseur le plus approprié.
D'autres technologies telles que le DCOM[sup]4[/sup], named pipes[sup]5[/sup], la RMI[sup]6[/sup] ont précédemment adopté ce style architectural mais ont souvent échoué en raison de la diversité des plates-formes utilisées dans les entreprises et faute d'un usage inadapté í Internet (problème de passage í travers des pares-feu, etc.) d'où la lenteur, voire l'absence de réponses sur ce réseau.
L'intégration est sans doute le facteur essentiel qui favorise l'utilisation des services Web.
Développement du service
Les développeurs ne sont pas obligés de se contenter des Web services créés par des tiers. En utilisant des plateformes modernes qui intègrent pour la grande majorité SOAP et XML, nous pouvons, assez simplement, créer de nouveaux Web services ou multiplier et intégrer les fonctionnalités aux Web services existants puis í notre tour les rendre disponibles.
En résumé
- Caractéristiques d'un Web service :- Accessible via le réseau- Dispose d'une interface publique décrite en XML- Ses descriptions (fonctionnalités (dans le document WSDL), comment l'invoquer et où le trouver ?) sont stockées dans l'annuaire UDDI- Communique en utilisant des messages XML transportés par des protocoles Internet (généralement HTTP, mais on peut également utiliser d'autres protocoles de transfert tels SMTP, FTP, BEEP, etc. )
- Les services Web utilisent des standards et protocoles ouverts. Les outils de développement, s'appuyant sur ces standards permettent la création automatique de programmes utilisant les services Web existants
- Les services Web fournissent l'interopérabilité entre divers programmes fonctionnant sur diverses plates-formes
- L'intégration d'applications en implémentant des Web services produit des systèmes faiblement couplés (constitués d'unités indépendantes). Le Web service peut disparaître sans perturber l'application cliente qui trouvera un autre fournisseur en cherchant dans l'annuaire
- L'interface des Web services est décrite d'une manière interprétable par les machines, ce qui permet aux applications clientes d'accéder aux services de manière automatique
- Basés sur le protocole HTTP, les services Web peuvent fonctionner au travers de nombreux pares-feu sans nécessiter des changements sur les règles de filtrage
Malheureusement, tout le grand potentiel du concept des Web services a certains coûts:
- L'utilisation de XML comme format de transfert signifie que nos messages sont lourds: les balises XML prennent beaucoup d'espace, ce qui est un fardeau pour la création, l'interprétation, ainsi que le transport de nos messages
- L'utilisation des ordinateurs distants pour faire notre traitement nous met í la merci du réseau, et crée de nombreux points de défaillance potentiels entre le serveur web et notre Web Service
- Par l'utilisation du protocole HTTP, les Web services peuvent contourner les mesures de sécurité mises en place au travers des pares-feu
- L'octroi de licences et de tarification des modèles de Web services doivent être acceptables pour les développeurs. Les normes des Web services sont actuellement récentes dans certains domaines, et cela pourrait prendre du temps avant que le coût des services devienne clair
Une fois qu'ils sont en place et qu'ils sont abordables, les Web services peuvent se révéler un atout précieux pour les développeurs, et nous donner í tous l'accès í un monde de puissance de calcul et de flexibilité. Il est temps de découvrir ce que les Web services peuvent offrir.
[sup]1[/sup] Architecture orientée services (SOA) : l'idée est de construire une architecture logicielle globale décomposées en services correspondant aux processus métiers de l'entreprise
[sup]2[/sup] Protocoles ouverts : désignent des formats de données interopérables et dont les spécifications techniques sont publiques et sans restriction d'accès ni de mise en œuvre
[sup]3[/sup] Web Service Description Language : tentative de normalisation pour la description des éléments pour mettre en place l'accès í un service réseau (Web service). Interface publique d'accès í un Web service
[sup]4[/sup] Distributed Component Object Model (DCOM) : une technique propriétaire de Microsoft qui permet la communication entre des composants logiciels distribués au sein d'un réseau informatique
[sup]5[/sup] Les named pipes : est une mise en œuvre des tubes Unix (ce mécanisme permet de chaîner des processus de sorte que la sortie d'un processus alimente directement l'entrée du suivant)
[sup]6[/sup] Remote method invocation (RMI) : ensemble de fonctons s'apparentant í une tuyauterie permettant les échanges de messages entre objets
