La création d'un web service : « Note Reminder »

Dodi Alphonse Mbuta Ikoko

Description

Les web services sont définis dans la littérature TI comme étant des cadres d’architecture (Architecture Framework) pour la conversation entre deux ordinateurs, l’un client et l’autre serveur, communiquant ou partageant des informations sur le web et parlant dans un vocabulaire commun avec un fort ensemble de protocoles. Pour Printz Jacques (2012), ils sont plutôt à présenter comme étant des technologies C/S améliorées qui permet aux différentes applications informatiques actuelles de pouvoir communiquer entre elles, et cela, même si elles sont implémentées sur des différentes plates-formes ou avec des langages de programmation différents.
Actuellement, trois types de web services sont implémentes au sein des organisations ou entreprises, à savoir le SOAP, le REST/RESTful et l’OData. Ils sont bâtis sur des cadres d’architecture orientés services (SOA : Service-Oriented Architecture) et/ou à partir des processus ou services métier bien définis. Décrits généralement sous le format cryptographique XML, les trois types de web services cités peuvent posséder plusieurs fonctions, ressources ou services, consommables par des applications informatiques clientes natives, web et/ou hybrides, et peuvent également gérer la sécurité́, la fiabilité́ et la gestion de tous les échanges ou partages d’informations entre les ordinateurs dans un réseau de communication.
Dans le cadre du module de cours - Ingénierie des systèmes à base de services -, suivi à l’UPJV, nous allons donc tenter de créer un web service RESTful, de nom de « W-S Note Reminder », sous l’IDE Netbeans, et cela, avec l’aide du langage JAVA EE et du web API JAX-RS. Ce dernier sera une architecture logicielle client-serveur qui devrait être capable d’offrir des fonctions, ressources ou services CRUD (Create, Read, Update and Delete) et celles d’authentification des utilisateurs.
En complément, une application cliente devrait être développée pour consommer les différentes fonctions, ressources ou services CRUD à implémenter sur ledit web service à créer. Notre choix est porté sur ce type des web services car il est considéré́ comme le plus populaire et utilise le protocole mythique de transfert hypertexte, le HTTP, dans toute son intégralité, notamment avec l’usage des URL significatives ou opaques et des méthodes tels que le GET, le HEAD, le POST et le DELETE. La modélisation pour l’ensemble de notre produit-logiciel à créer et/ou à développer sera réalisée en UML.

Sujets

• Extensible Markup Language
• SOAP
• JavaScript Object Notation
• Representational State Transfer
• Open Data Protocol
• Web service
• JAX-RS
• JAVA

Informations

• Publié par: daniellambutamankoni16
• Publié le: 06 février 2019
• Nombre de lectures: 26
• Licence : En savoir +
  Paternité, pas d'utilisation commerciale, partage des conditions initiales à l'identique
• Langue: Français
• Poids de l'ouvrage: 3 Mo

Extrait

Université de Picardie Jules Verne UFR des sciences Module de cours : D314, Ingénierie des systèmes à base de services cours et superviseur des activités :Tuteur du Durand David Activités pratiques et collaboratives entre apprenants La création d’un web service : « Note Reminder » (activité n°2) MBUTA IKOKO Dodi Alphonse & MEKUATE DEFO Gisèle Université de Picardie Jules Verne, Amiens, France _________________ Résumé Les web services sont définis dans la littérature TI comme étant des cadres d’architecture (Architecture Framework) pour la conversation entre deux ordinateurs, l’un client et l’autre serveur, communiquant ou partageant des informations sur le web et parlant dans un vocabulaire commun avec un fort ensemble de protocoles. Pour Printz Jacques (2012), ils sont plutôtà présenter comme étantdes technologies C/S améliorées qui permet aux différentes applications informatiques actuelles de pouvoir communiquer entre elles, et cela, même si elles sont implémentées sur des différentes plates-formes ou avec des langages de programmation différents. Actuellement, trois types de web services sont implémentes au sein des organisations ou entreprises, à savoir le SOAP, le REST/RESTful et l’OData. Ils sont bâtis sur des cadres d’architecture orientés services (SOA : Service-Oriented Architecture) et/ou àpartir des processus ou services métier bien définis. Décrits généralement sous le format cryptographique XML, les trois types de web services cités peuvent posséder plusieurs fonctions, ressources ou services, consommables par des applications informatiques clientes natives, web et/ou hybrides, et peuvent également gérer la sécurité́, la fiabilité́et la gestion de tous les échanges ou partages d’informations entre les ordinateurs dans un réseau de communication. Dans le cadre du module decours-Ingénierie des systèmes à base de services-, suivi à l’UPJV, nous allons donc tenter de créer un web service RESTful, de nom de « W-S Note Reminder », sous l’IDE Netbeans, et cela, avec l’aide du langage JAVA EE et du web API JAX-RS. Ce dernier sera une architecture logicielle client-serveur qui devrait être capable d’offrir des fonctions, ressources ou services CRUD (Create, Read, Update and Delete) et celles d’authentification des utilisateurs. En complément, une application cliente devrait être développée pour consommer les différentes fonctions, ressources ou services CRUD à implémenter sur ledit web service à créer. Notre choix est porté sur ce type des web services car il est considéré́ comme le plus populaire et utilise le protocole mythique de transfert hypertexte, le HTTP, dans toute son

Page 1 sur 54

intégralité, notamment avec l’usage des URL significatives ou opaques et des méthodes tels que le GET, le HEAD, le POST et le DELETE. La modélisation pour l’ensemble de notre produit-logiciel à créer et/ou à développer sera réalisée en UML. Mots clés : Web service, SOAP, REST, OData, JAVA, JAX-RS, XML, JSON, etc. 1Introduction 1.1Contexte du projet Le monde actuel, dominé désormais par l’Internet et par tous les grands acteurs de l’industrie des TI, les web services ont fini par s’imposer comme étant l’élément central de toute architecture logicielle utilisée dans n’importe quelle organisation ou entreprise qui se veut 2.0. La littérature TI parle de trois types de web services qui sont utilisés actuellement, à savoir le SOAP, le REST/RESTful et l’OData. Dans leur forme la plus simple, tous ces web services sont définis comme étant des cadres d’architecture (Architecture Framework) pour la conversation entre deux ordinateurs, l’un client et l’autre serveur, communiquant ou partageant des informations sur le web et parlant dans un vocabulaire commun avec un fort ensemble de protocoles. L’une des choses la plus importante et qui fait voire leur force actuelle est leur format de messagerie qui est généralement sous le format XML. Toutefois, en dehors de XML, d’autres formats sont également utilisés par des développeurs web, le cas de format JSON, ATOM ou RSS. 1 Dans le cadre du module de cours D314 - Ingénierie des systèmes à base de services -, suivi à l’UPJV, nous allons tenter de créer un web service de nom de « W-S Note Reminder ». Ce web service à créer sera une architecture logicielle client-serveur qui devrait être capable d’offrir des fonctions, ressources ou services CRUD (Create, Read, Update and Delete) et celles d’authentification des utilisateurs. C’est donc un système ou un produit-logiciel client- serveur à fabriquer et qui, selon les exigences du tuteur du module de cours, devrait aussi donner aux utilisateurs finaux la possibilité de créer leur profil et/ou de s’authentifier, mais aussi de créer, d’ajouter, d’afficher, d’éditer, de réarranger et de supprimer une note. Les utilisateurs pour lesquels nous allons fabriquer ce produit-logiciel passent pour des accros aux applications informatiques natives, web ou hybrides existant actuellement sur le marché des TI. Virtuels dans le cadre de activité ou projet de développement informatique, ils sont donc considérés comme des parties prenantes. Selon les règles de l’art, ils représentent ainsi la maîtrise d’œuvre (MOA). 2 Pour pouvoir répondre alors aux exigences et/ou spécifications , fournies par le tuteur de ce module de cours, une étroite collaboration est recommandée entre les différentes parties prenantes du projet même si le projet devrait logiquement être réalisé par deux ressources représentant la maîtrise d’ouvrage (MOE).

1  En informatique, un service désigne l’ensemble des programmes œuvrant pour effectuer des traitements particuliers, manipulant des types de données ou d’informations particulières et partageant un mode de communication. Donc, il forme un ensemble des protocoles et/ou des formats de données et de dialogue mais aussi de règles d’échanges qui constituent tous les éléments de la structuration de l’information. Toutefois, il faut noter ici qu’un protocole n’est pas directement vu comme un programme informatique mais aussi comme une sorte de cahier des charges pour un ensemble de programmes exécutables ou à faire exécuter. 2 Les exigences sont des propriétés qui sont exposées afin de pouvoir résoudre un problème dans le monde réel. Elles peuvent être fonctionnelles ou non fonctionnelles (cf. SWEBOK : 2004, cité par Mbuta Ikoko, 2011). Dans un projet informatique, pour qu’un produit-logiciel fabriqué soit considéré comme conforme aux exigences définies ou élaborées par les différentes parties prenantes, il devrait alors répondre aux besoins exprimés explicitement par le client et/ou l’utilisateur final (exigences métier) mais aussi aux besoins non exprimés (implicites) qui sont techniques et essentiels puis pris en compte par le fournisseur pour pouvoir transformer réellement les besoins exprimés en une solution (exigences produit).

Page 2 sur 54

1.2Objectifs du projet L’objectif principal de notre projet, comme nous venons de le mentionner dans le précédent point, est de pouvoir créer un web service. Ce dernier, par notre propre décision, sera de type RESTful et devra donc être extensible, neutre et indépendant afin de pouvoir offrir à n’importe quelle application cliente la possibilité de consommer sans difficultés les différentes fonctions, ressources ou services qui devraient être implémentés ou offerts. Parmi les fonctions, ressources ou services attendus, nous devrions donc nous focaliser davantage sur ceux qui vont permettre à un utilisateur de pouvoir ajouter (créer), afficher, éditer (modifier), réarranger et supprimer une note, c.à.d. de pouvoir effectuer les différents services CRUD. Le langage de programmation JAVA et l’ensemble de son écosystème, imposés par le tuteur du module de cours, devraient donc soutenir cette implémentation ou mise en œuvre. Profitons également pour préciser que la modélisation, pour l’ensemble de notre produit- logiciel à créer et/ou à développer, sera réalisée en UML afin de nous faciliter la tâche de concevoir en parallèle une base de données flexible pour le côté Back-end (serveur) lors de la mis en production. Le côté Front-end (client) du produit-logiciel ne devrait pas non plus échapper à l’usage des langages à balises ou à scripts, tels que le HTML/XHTML, le CSS, le Java Script et le Bootstrap ou Guid enfin de dégager enfin la beauté d’un design que nous souhaitons interactif ou react mais aussi professionnel. 1.3Contenu La suite de ce document constitue le rapport technique de réalisation de notre projet. Il comporte 5 principaux points. Hormis l’introduction (point 1), le point 2 est un rappel théorique. Il va tenter de nous permettre d’avoir une compréhension ou une vue d’ensemble du sujet abordé, et cela, avec l’aide des points essentiels se rapportant aux trois web services possibles d’implémentation et aux projets informatiques de développement logiciel mixte. Ce deuxième point va être suivi par un troisième point. Ce dernier va tenter à son tour de nous présenter les différentes technologies ou outils qui vont être utilisés par l’équipe de projet constituée pour pouvoir concevoir le produit-logiciel. C’est aussi dans de ce troisième point que le choix de notre méthodologie de travail et celui de notre approche technique de réalisation du projet vont être détaillées. Le planning de travail et les ressources affectées pendant la réalisation ou le déroulement de ce projet vont également être indiqués. Il s’agit d’un planning déjà défini dans un autre document du projet intitulé « PDL : Plan de développement logiciel ». Quant au point 4 de ce rapport technique, il va concerner les résultats et les discussions sur les résultats obtenus. Les éléments d’entrée vont concerner la conception réalisée pour obtenir un produit-logiciel opérationnel, optimisé et sécurisé. Ici, sous une logique présentant les différentes lignes conceptuelles, nous allons insister sur les spécifications ou les exigences fournies par le client. Ces dernières vont donc nous permettre de créer et/ou de décrire de manière détaillée des diagrammes UML que nous allons jugés importants. Il s’agit donc tout simplement d’un point qui va présenter principalement les différents processus de conception 3 ou de développement de notre produit-logiciel . Quelques images et lignes de codes vont également être présentées au cours de ce point pour montrer de manière concrète les différentes technologies et approche programmatique utilisées pour la dite conception. Le point 5 va être la conclusion de ce rapport technique. Il va présenter, dans un premier temps, une synthèse sur la discussion de résultats obtenus lors de la réalisation dudit produit- 3 Rappelons ici qu’un processus représente un « ensemble d’activités ou actions à effectuer par une ou plusieurs personnes dans une organisation ou une entreprise dans le but de créer un produit (bien ou service) ou de la valeur » (Mbuta Ikoko, 2003). Selon la norme ISO 10006 : 2003, un processus est coordonné et maîtrisé. Il peut également être un processus de management, de réalisation, ou de support.

Page 3 sur 54

logiciel mais aussi sur ceux du déroulement global de notre projet. En deuxième, nous allons évoquer les quelques difficultés rencontrées et les perspectives futures relatives au produit- logiciel réalisé ou créé. 2Notions théoriques liées aux web services 2.1L’Internet et ses différents protocoles ou services de base offerts L’Internet regroupe aujourd’hui une multitude des réseaux de communication à l'échelle mondiale mais aussi des outils, des applications et/ou des services TI aux caractéristiques très 4 variables. Devenu voire l’Internet des objets (Internet of things ), par abus de vocabulaire et à 5 cause de l’extension de son nommage et des différents objets connectés se multipliant, l’Internet est défini comme étant le « réseau des réseaux » ou l’ensemble de ressources organisationnelles, technologiques, informationnelles ou multimédias rendues disponibles par tous et auxquelles il est possible d’accéder via des infrastructures télématiques existantes. Il est donc ce « service télématique grand public même si sa gouvernance et celle de tous les autres outils, applications et/ou services TI qu’il fédère actuellement semblent être devenues très complexes mais pas impossible » (Mbuta Ikoko, 2011). D’ailleurs, la difficulté d’appréhender correctement ces deux types de gouvernance fait que ce service télématique grand public, défini donc avec l’aide des applicationsinformatiques natives, web ou hybrides existant actuellement sur le marché des TI, soit également considéré comme étant un grand réseau de communication ou une grande infrastructure technologique réellement ouverte, neutre et indépendante. Pour renforcer notre compréhension sur cette grande infrastructure technologique ou télématique étendue et/ou ouverte, nous profitons de passer ci-dessous, de manière rapide et synthèse, les différents services ou protocoles de base qui sont offerts ou fournis par sa base technologique principale, à savoir le TCP/IP (lire davantage Pujolle Guy, 2002 ; Tanenbaum Andrew, 2003 ; et Comer Douglas, 2006, cité par Mbuta Ikoko, 2007). En effet, de manière fondamentale, nous avons deux niveaux de services ou protocoles de base dans le réseau Internet :les services ou protocoles de niveau réseau et les services ou protocoles de niveau application.Les services ou protocoles de base de niveau réseau sont « responsables de la réception des datagrammes IP et de leur transmission sur un réseau physique spécifique » (Comer Douglas, 2006, cité par Mbuta Ikoko, 2007). Ici, comme étant lui-même un outil, application ou service télématique ou TI fédérant d’autres outils, applications ou services TI pour utilisateurs professionnels, l’Internet fournit alors deux grands types de services, à savoir(1) les services de transmission de paquets ou datagrammes en mode sans connexionUser Datagramme Protocol) ou en modeless-UDP :  (connection connexion (connexion oriented-TCP : Transmission Control Protocol), et(2) les services de transport de flux fiableà une possibilité d’interconnexion de machines ou objets (suite

4 L’Internet des objets est la matérialisation du croisement entre l’informatique ubiquitaire et les objets connectés ou produits intelligents. C’est tout simplement le réseau Internet qui est étendu au réseau des capteurs, c.à.d. notre cyberespace qui est ainsi ouvert aux autres types d’outils, applications et services TI qui ne sont entre autres que des produits intelligents ou objets connectés. 5  Les objets connectés sont définis comme « des objets électroniques connectés sans fil, partageant des informations avec un ordinateur, une tablette ou un Smartphone, etc. et capables de percevoir, d'analyser et d'agir selon les contextes et notre environnement » (http://www.usine-digitale.fr/objets-connectes/). Porter Michael et Heppelmann James les appellent « des produits intelligents » et les définissent à leur tour comme « un ensemble des systèmes complexes qui associent des équipements matériels, des capteurs, des stockages de données, des microprocesseurs, des logiciels, avec d’innombrables possibilités de connectivité » (Porter Michael et Heppelmann James, 2015, cité par Mbuta Ikoko, 2017). Pour eux, ces produits intelligents comprennent trois séries d’éléments fondamentaux qui sont les composants physiques, les composants intelligents et les composants de connectivité.

Page 4 sur 54

intelligents). Les services de transport de flux fiable sont construits sur le niveau réseau avec pour objectif de pouvoir l’enrichir. Ce niveau contient aussi quatre autres services ou protocoles qui sont l’ARP (Adress Resolution Protocol), le RARP (Reverse Adress Resolution Protocol), l’ICMP (Internet Control Message Protocol) et le RIP (Routing Information Protocol). Ces quatre autres services ou protocoles sont associés à leur tour avec d’autres protocoles de la pile TCP/IP pour pouvoir matérialiser les deux premiers services ou protocoles que nous venons de citer (lire Pujolle Guy, 2002 ; Tanenbaum Andrew, 2003 ; Lohier Stéphane et al, 2004 ; et Servin Claude, 2006, cité par Mbuta Ikoko, 2007). C’est donc sur le niveau réseau que le protocole,nommé IP (Internet Protocol), offre les fonctions de routage de paquets. Quant au niveau application, il regroupe tous les services ou protocoles de base situés au- dessus de la couche TCP et UDP du modèle TCP/IP. Ces services ou protocoles de base proviennent presque tous du monde UNIX (lire Pujolle Guy, 2002 ; et Tanenbaum Andrew, 2003, cité par Mbuta Ikoko, 2007) et fonctionnent sous un modèle ou une logique 6 architecturale appelée C/S (client/serveur) . Le modèle C/S ont vu le jour vers la moitié des années 1980. Leur avènement « se situait plus dans la phase de besoins de centralisation (information cohérente, non redondante et accessible) et de décentralisation (conserver la puissance et l’interface des micros - ordinateurs) des entreprises » (Ivinza Lepapa, 1997). C’est un modèle d’architecture qui compose librement des services ou opérations génériques, tels que le CRUD (Create-Read-Update-Delete), l’ETL (Extract-Transform-Load), ou l’EAI (Enterprise Application Integration), en y ajoutant un nouvel organe qui est la bibliothèque de ces différents services puis un éditeur correspondant qui permet la gestion de ladite bibliothèque (lire Printz Jacques, 2012). Il permet une bonne communication ou une bonne transmission de données avec l’aide des requêtes ou routines de base, c.à.d. avec l’aide des appels de procédures distants (RPC : Remote Procedure Call) et/ou de procédures XDR (eXternal Data Representation) qui répartissent à leur tour des données transmises entre les postes clients et les postes serveurs et, accompagnent les différents services à exécuter. Il y a même aujourd’hui une variante optimisée de ce modèle ou logique d’architecture C/S qui existe sous une logique orientée service, appelée SOA (Service-oriented architecture). La SOA renseigne tout simplement qu’un système informatique réparti est organisé comme une structure de services de communication. Son but est de pouvoir répondre aux exigences métier de ce système et, plus que d’autres technologies, l’une de ses forces ce qu’elle encourage également la réutilisation des services implémentés. Elle représente donc aucune exigence ou restriction des autres technologies et permet voire de créer en plus un service de communication entre un poste client et un poste serveur dans n’importe quel langage de programmation, avec des routines ou des normes telles que celles de RPC, CORBA (Common Object Request Broker Architecture), XML (eXtensible Markup Language), OLE/DCOM (Object Linking & Embedding/ Distributed Component Object Model), etc. Souvent associée à des services web ou web services basés sur le SOAP (Simple Object Access Protocol), mais pas uniquement limitée à eux, il faut noter que la SOA reste différente d’un web ou des services du web même si ce dernier est la manière privilégiée pour réaliser une SOA. Gall Nick (2014, cité dans l’encyclopédie Wikipédia, 2017) mentionne que la déclinaison des SOA, telle qu’observée aujourd’hui au profit des services entièrement dédiés au web, est connu sous le nom de WOA (Web Oriented Architecture) et définie sous la formule mathématique : « WOA = SOA + WWW + REST ». Nous allons comprendre davantage cette différence dans les sections qui vont suivre.

6 Dans la pratique, la maîtrise des systèmes architecturaux C/S passe plus par la compréhension des SGBD, des middlewares, des objets et des interfaces graphiques.

Page 5 sur 54

7 En parlant du web , disons tout simplement qu’il est un service ou un protocole Internet de base au niveau de la couche application. Il s’occupe donc de la navigation entre les pages, comme c’est fut le cas avec le GOPHER, et s’exécute en mode hypertexte non crypté - HTTP : HyperText Transfert Protocol - ou en mode hypertexte crypté – HTTPS : HyperText Transfert Protocol Secure -). Parmi les autres services ou protocoles Internet de base de niveau application, nous avons aussi les services ou protocoles de transfert de fichiers (FTP/TFTP : File TransfertTrivial File Transfert Protocol), de connexion et/ou Protocol/ gestion à distance des utilisateurs et des bureaux (TELNET : Terminal Network, SSH : Secure Shell, NIS : Network Information Service, rlogin, rsh, etc.), de configuration des annuaires distribués (DNS/DNSSEC : Domain Name System/Domain Name System Security Extensions et DHCP), de sécurisation des échanges (SSL : Secure Sockets Layer ou TLS : Transport Layer Security), d’accès aux fichiers distants ou hébergement de sites web (le web hosting avec NFS : Network File System ou SMB : Server Message Block), de conception des sites web ou le web design (HTML : HyperText Markup Language qui est basé sur le SGML : Standard Generalized Markup Language et qui, selon Koch Daniel et al. (2000), constitue la clé d’une page web), de messagerie électronique (Web mail avec SMTP : Simple Mail Transfert Protocol, POP : Post Office Protocol, IMAP : Internet Message Access Protocol et MIME : Multipurpose Internet Mail eXtensions) et de forums, newsgroups ou dialogue en temps réel (NNTP : Network News Transfer Protocol ou IRC : Internet Relay Chat). La maîtrise de tous ces différents services ou protocoles de base que nous venons de citer constitue donc une des premières étapes pour la compréhension de l’univers Internet mais aussi l’une des étapes importantes avant de pouvoir se lancer dans la création ou dans l’implémentation d’un web service. Mais c’est quoi donc un service web, ou « web service » en anglais, la section suivante va donc tenter de nous répondre. 2.2Les web services a)Définitions et autres éléments de base associés Les web services pilotent aujourd’hui toute la communication sur l’Internet. Ils sont au cœur des toutes les applications informatiques modernes et sont également comptés « parmi les services ou protocoles les plus importants de la couche application de l’Internet » (Tanenbaum Andrew, 2003). Agrebi Meriem et Chandon Jean-Louis (2009, cité par Mbuta Ikoko, 2017), qui citent Eighmey John (1997) et Kumar Nanda et Benbasat Izak (2002), parlent d’un « média le plus riche, pouvant intégrer du texte, des images, de l’audio et de la vidéo ». En s’appuyant sur Printz Jacques (2012), qui parle à son tour de la conception et du développement des applications informatiques modernes simples, sûres et adaptables par des architectes, des décideurs DSI, des maîtres d’ouvrage et des chefs de projets, nous pouvons également faire noter que les web service sont tout simplement « l’élément central de toute architecture logicielle moderne » (Printz Jacques, 2012). En ce terme, ils disposent ainsi des normes ou protocoles d’utilisation très stricts qui sont voire, dans la plupart de cas, documentées pour le compte des développeurs web. 7 Le WWW : World Wide Web, appelé aussi « protocole ou service web », est un tout simplement programme de balayage ou de recherche d’information (référence au navigateur web ou web browser) qui contient « un ensemble de pages ou documents web reliés entre eux par des liens et accessibles par l’Internet » (Berners Lee - RFC 1630-, 1994, cité par Comer Douglas, 2006 et relayé par Mbuta Ikoko, 2007). « Ces pages web reliés disposent des noms uniques qui sont identifiables entre elles et leurs différents liens permettent alors de localiser universellement toutes les ressources disponibles du web. Ils sont composés de trois parties qui sont le nom du protocole HTTP (http://), le nom DNS de la machine où la page web devrait être hébergée (www.zaire.zr) et le nom du fichier contenant la page (/presentation.html) et qui se trouve souvent dans un répertoire donné (accueil par exemple). Les trois parties citées donnent donc lieu à un lien dit de typehypertexte :http://www.zaire.zr/accueil/presentation.html. D’où le nom connu de lien hypertexte » (Mbuta Ikoko, 2001).

Page 6 sur 54

Historiquement, nous pouvons préciser que les web services ne sont pas un concept nouveau. 8 D’ailleurs, dautres tentatives de réalisation d’un cadre d’architecture ont même existé bien avant l’avènement d’Internet et de Web services. Déjà vers la moitié des années 1960, certaines applications informatiques étaient implémentées avec des architectures similaires aux web services et tournaient sur des serveurs physiques dits « mutualisés » (en miroirs ou en clustering) ou « dédiés virtuels » (info gérés) qui « contiennent des données et fournissent des services d’acquisition, de stockage, de traitement, d’échange et de diffusion des données » (Moreau René, 1987, cité par Mbuta Ikoko, 2003). Ces premiers cadres d’architectures similaires aux web services étaient plutôt implémentées dans l’esprit de minimiser des risques qui étaient dus aux pannes logicielles ou matérielles de l’époque. Quelques années plus tard, c.à.d. vers les années 1970 et 1980, les applications informatiques adoptèrent la technologie C/S et vont finir par faire de son ensemble un cadre d’architecture alors disponible sur n’importe quelle application informatique ou réseau de communication. L’essor des réseaux de communication ou des applications informatiques dans les années 1990, le cas du réseau Internet, a donné une importance sans précédent à cette technologie. Avec l’Internet rendu public, les web services ont suivi et passent aujourd’hui pour l’amélioration continue de la technologie C/S. Profitons de cette ligne synthèse historique pour dire aussi que l’une des premières véritables implémentations notables du cadre d’architecture C/S amélioré, au style proche d’un web service, fut celle qui était connue sous le nom de l’EDI ou du Web-EDI (Web - Electronic Data Interchange). L’idée générale d’implémentation était ici la dématérialisation des échanges de données entre entreprises. Avec le web-EDI, « les échanges ou communications de données informatisées entre entreprises ou postes de travail sont traitées via des messages ou des requêtes HTTP mais aussi parfois via des messages ou des requêtes SMTP » (Mbuta Ikoko, 2001). Il s’agit donc de la même chose pour le web service aujourd’hui. Toutefois, le format de ces messages ou de ces requêtes se différencie considérablement. Ceci veut simplement dire que si vous êtes un architecte ou développeur logiciel et que vous souhaitez utiliser du web-EDI ou du web service, vous devriez obligatoirement connaître le format de messages à échanger et les normes ou spécifications qui les accompagnent, mais aussi l’interface de programmation d’application utilisé (en anglais, API : Application 9 Programming Interface) et les principales actions, requêtes, verbes ou méthodes HTTP associées, le cas par exemple des méthodes GET (demande de téléchargement de contenu d’une page web), HEAD (récupération de l’en-tête d’une page web), POST (envoie des informations d’une page web au serveur DNS pour traitement), PUT/PATCH (mise à jour de la ressource) et DELETE (suppression de la ressource située sur l’URL spécifié). Cette compréhension ou connaissance obligatoire de formats de messages à échanger, en rapport

8 Le cadre d’architecture dont il est question ici est à considérer en quelque sorte comme un sous cadre de celui qui est souvent mis en place dans une entreprise. Celui de l’entreprise étant alors défini comme une composante de sa stratégie informatique (pattern centralisé) au travers du cadre de présentation des technologies et des processus d’entreprises mais aussi au travers de la productivité de cette présentation tout en impliquant la sécurité face aux risques opérationnels et de conformité qu’ils conviendraient d’analyser les enjeux en termes de communication, de coordination et de coopération en rapport avec les compétences des acteurs concernés. Il s’agit aussi d’une spécification sur la façon d’organiser et de présenter par la suite l’architecture de l’ensemble du système d’information ou informatique d’un organisme. Pour Morley Chantal (2012), cette spécification est aujourd’hui employée dans la gouvernance tout projet système d’information. 9  Appelé web API dans notre contexte, l’interface de programmation d’application est donc vue ici comme un langage utilisé pour communiquer avec un web service qui, comme un bibliothécaire, peut fournir à un poste client via un navigateur web une collection des ressources dont dispose un serveur web, c.à.d. une bibliothèque. Il s’agit au fait « d’un concept qui constitue aujourd’hui un des piliers de développement web, mais qui est habituellement limité du côté d’une application cliente (y compris tous les Framework web utilisés). Il n’inclut généralement pas les paramètres d’implémentation du serveur ou du navigateur web, tels que les SAPI ou les API des moteurs de navigateur web, à moins qu'ils ne soient accessibles au public par un application web à distance » (Wikipédia, 2017).

Page 7 sur 54

avec le développement et le fonctionnement d’un web service, passe aujourd’hui pour une compétence essentielle recommandée à tous les architectes ou développeurs web. D’un point de vue pratique, c’est lors d’un échange ou d’une communication de données entre postes de travail sur Internet qu’un web service et ses différentes ressources ou services interviennent ou sont utilisés. Ici, le poste client concerné par cet échange devrait alors envoyer une requête HTTP (au format HTML) et le serveur, qui reçoit cette requête, devra la traiter et renvoie une réponse auposte client(voire figure 1).

Figure 1 – Requête entre un client et un server avec l’aide d’un (web) service Les réponses renvoyées par le poste serveur ou par un web service au poste client s’accompagnent toujours d’un code ditde retour ou d’état qui représente alors l’état dans lequel se trouve le serveur et les ressources qu’il renferme. Le client peut utiliser ces codes retour ou d’état pour identifier les réussites et les échecs d’échanges ou de communications, puis répondre automatiquement aux étapes suivantes. Le RFC 7231 parlent donc de codes retour à trois chiffres et les divisent même en 5 groupes ou séries : (1)la série 1XX: indique qu’une RFC réponse comprend des informations ; (2)la série 2XX: indique que la demande du client a été effectuée avec succès ;la série 3XX: indique également un succès mais le client devrait effectuer en complément une action telle qu’une redirection vers une autre URI ; la série 4XX: indique une erreur au niveau du client (la demande d’une page web qui n’existe pas par exemple, etc.) ; et enfinla série 5XX: qui signifie que le serveur a rencontré une erreur. En plus, les deux postes concernés par l’échange évoqué ci-dessus peuvent aussi utiliser en complément du JavaScript ou un autre langage de scripts pour traiter les différentes requêtes et réponses HTTP. Dans ce cas, le client va ne plus recevoir seulement le contenu de la réponse du serveur mais va aussi recevoir d’autres contenus connexes sous d’autres formats en dehors du HTML, à savoir le format XML ou JSON, etc. L’illustration claire est souvent celle d’un poste client qui demande des données logées sur un serveur SGBD (cf. principes 10 d’architecture C/S universel, dit « 3-tiers » ou à 3 strates ou couches par Gardarin Georges et Gardarin Olivier, 1999). Donc, le web service à utiliser « ferait appel à une procédure distante connue sous le nom de RPC. Il s’agit d’une norme ou procédure différente des normes EDI traditionnelles, tels que EDIFACT, etc., et qui permet aux ordinateurs clients d’appeler des fonctions ou des sous-routines, hébergées par des ordinateurs distants (serveurs), en utilisant une syntaxe aussi similaire que possible au code qu’ils pourraient utiliser localement. C’est une norme basée sur un environnement distribué (DCE : Distributed Computer Environment) » (Mbuta Ikoko, 2001). 10  L’architecture trois tiers (« 3 tiers ») est un modèle logique d’architecture applicative qui vise à séparer très nettement trois couches logicielles au sein d’une même application ou système à modéliser ou présenter cette application comme un empilement de la présentation des données (couche présentation), de traitement métier des données (couche métier ou application) et d’accès aux données persistantes (couche accès aux données ou persistance).

Page 8 sur 54

Concernant le format de messages ou de requêtes évoqué ci-dessus, c’est le format XML qui est le plus utilisé à ce jour. Ce dernier passe pour une grammaire universelle et c’est donc tout simplement une évolution de HTML via le SGML (Standard Generalized Markup Language). A la différence de HTML, les messages au format XML n’ont pas de tags prédéfinis. En plus, nous devons faire noter ici que dans les premiers jours de web services, les données structurées étaient renvoyées sous la forme d’un fichier XML simple utilisant un marquage générique appelé POX (Plain Old XML). Ce format POX utilise des balises et des attributs de la même manière que le HTML (Hypertext Markup Language) mais, selon les besoins, peut aussi définir ses propres balises afin de pouvoir échanger des données vers et/ou à partir d’un web service. Il est sensible à la casse et représente souvent des données dans différentes zones (de stockage et filtrage de données, du web et du format de transport). Quant au format XML actuel, les messages qu’il représente sont des données typées ou non typées qui peuvent aussi être exportées, sérialisées, ou encryptées sous d’autres formats XML, dits « particuliers », du genre POX (le cas d’ATOM), CSV (Comma-separated values), JSON (JavaScript Object Notation) et RSS (Really Simple Syndication). Le RSS semble aujourd’hui fédérer tous ces différents formats, à l’exception de ATOM qui souffre d’ambition à compléter et/ou à remplacer totalement format RSS. Concernant le JSON, sa force se trouve dans sa facilité d’être lu par un humain et d’être interprété par une machine. Il est complètement indépendant des langages de programmation (C, C++, Perl, Python, Java, C#, VB, JavaScript, etc.) mais utilise des conventions qui leur sont communes. Toutefois, dans un web service, le stockage et le filtrage de données ou messages se font logiquement à travers une base de données XML qui est juste un système logiciel permettant de stocker des données au format XML. Cette base de données est souvent associée à une autre base de données orientée document (document-oriented database, or document store), le NoSQL par exemple, et, pour afin obtenir un document XML bien structuré pour et/ou dans un web service à partir de cette association, on doit alors utiliser en complément un schéma XML ou un DTD (Document Type Definition) et plusieurs autres modules optionnels, le cas de Xlink, de Xpointer & Xfragments, de CSS (Cascading Style Sheets), de XSL (eXtensible Stylesheet Language), de DOM (Document Object Modele), etc. Pour conclure, disons que les web services sont issus de la technologie C/S qui est fondée à son tour sur un des protocoles mythique de navigation entre les pages web, appeléle HTTP. Ils sont actuellement implémentés en masse au sein des organisations en raison de l’amélioration souhaitée sur la communication ou le digital. Pour Berners Lee et al. (RFC 1738, 1994), les pages web d’une application ou d’un site web, qui servent de navigation sur le réseau Internet, sont accessibles et reliées les unes par rapport aux autres grâce aux liens hypertextes. Elles sont donc nommées au moyen d’une URI (Universal Ressource Identifier) ou URL (Universal Ressource Locator) et représentent au final des fichiers hypermédias (voices, datas and images). Considérés aussi aujourd’hui comme l’un des services clés et importants de cette technologie C/S, les web services passent également pour une sorte des systèmes logiciels conçus pour supporter l’interopérabilité entre différentes machines se trouvant sur un réseau de communication, à l’instar du réseau Internet. Mahmoud Qusay et al. (2005, cité par Mbuta Ikoko, 2007) dit même que ces systèmes logiciels représentent plutôt l’« implémentation d’une fonctionnalité commerciale bien définie, et les différents web services à construire derrière cette implémentation sont consommés aujourd’hui par des postes clients dans différentes applications ou processus métier ». Ils permettent donc aux différentes applications informatiques de communiquer entre elles même si elles sont implémentées sur des plates-formes ou avec des langages de programmation différents. Leur but est désormais celui d’induire l’extensibilité et la neutralité mais aussi l’indépendance entre les postes se trouvant dans une infrastructure technologique.

Page 9 sur 54

b)Les web services phares et leurs différentes normes ou spécifications Parmi les web services phares possibles d’implémentation actuellement au sein des organisations, nous avons principalement le SOAP, le REST et l’OData. Ces trois web services sont bâtis presque tous sur des cadres d’architectures orientés services (SOA). Ils sont décrits en grande partie au format XML afin de pouvoir gérer correctement des processus et des transactions, mais aussi la sécurité, la fiabilité et la gestion des échanges ou partages d’informations dans un réseau de communication. Ils sont donc devenus des standards dans le domaine du web. Ci-dessous, nous allons tenter de décrire de manière sommaire ces trois standards phares du web actuellement. -Le SOAP Le SOAP est le tout premier web service connu du monde de l’Internet. Il a été développé et opérationnalisé à la fin des années 1990. Il est tout simplement une série de spécification des protocoles pour l’échange d’informations structurées entre différents systèmes distribués ou décentralisés et éventuellement aussi hétérogènes. Il utilise le XML comme étant le format des messages de demande et de réponse entre les clients et les serveurs. Comme spécification de protocoles, il utilise et s’appuie aussi « sur d’autres protocoles de la couche application de l’Internet, tels que le HTTP et le SMTP,pour une bonne extensibilité» (Tidwell Doug and all., 2001 : traduction libre). Le SOAP définit donc quel format des messages XML utiliser pour échanger des informations. Toutefois, à l’intérieur de ce format à utiliser, les développeurs restent libres d’ajouter ce qu’ils veulent, le cas par exemple de l’inclusion des pièces jointes binaires dans l’envoi d’un message de demande ou de réponse avec du MTOM (Message Transmission Optimization Mechanism). Pour rappel, à l’époque où le SOAP a été mis sur pied, la plupart des gens le connaissaient alors comme le standard par défaut pour tout web service (lire Tidwell Doug and all., 2001). Ivinza Lepapa (1997) a même évoqué que le SOAP était l’arrivée d’une norme de facto robuste pour pouvoir enfin décrire correctement la manière d’intégrer des applications informatiques en réseau, et dont l’architecture orientée services devrait en dépendre fortement car son implémentation devrait viser la simplification de l’intégration tout en fournissant une connectivité universelle aux systèmes et données existants. Actuellement, le SOAP et ses 11 différents protocoles ou spécifications implémentées , connues collectivement sous le nom de normes WS (Web Services), sont toujours opérationnels et s’appliquent même désormais aux autres types de web services. Ils passent donc pour ce standard rêvé et restent toujours largement utilisés par certains professionnels du domaine. Toutefois, d’autres professionnels le décrient en disant qu’il tente, ensemble avec ses protocoles ou spécifications, de générer une course à la performance technologique. Les protocoles ou les spécifications SOAP implémentées définissent normalement une enveloppe (<SOAP envelope>) qui doit contenir le message à échanger. A l’intérieur de ladite enveloppe, nous trouvons un en-tête (<header>) et un corps (<body>). Le corps inclut parfois une section appelée « fault » (<fault>) et des sous-sections. Seul le corps <body> est obligatoire. La section fault est uniquement utilisée pour les réponses lorsqu’une erreur survient, non pour les demandes. Lors d’une demande ou appel d’un web service SOAP, le corps (<body>) inclut généralement l’action à appeler sur le web service ainsi que tous les

11 Parmi les protocoles ou spécifications SOAP implémentées, nous pouvons citer le WS-star qui inclue le WS- Policy, le WS-Addressing, le WS-Trust, le WS-Security, le WS-Transaction et d’autres. Fournis et gérés par OASIS (acronyme Organization for the Advancement of Structured Information Standards), tous ces protocoles SOAP, dérivés du WS-star, sont essentiels pour fournir des fonctionnalités d’entreprises aux web services. Ils sont aujourd’hui indépendants de la plate-forme à utiliser ; ce qui signifie qu’un web service qui implémente du WS-Transaction peut faire partie d’une transaction distribuée entre des systèmes hétérogènes. C’est le W3C qui assure la mise à jour de la spécification de tous ces protocoles ou normes.

Page 10 sur 54

arguments possibles. Via ses protocoles ou ses spécifications, le SOAP peut utiliser une requête, souvent le POST ou le GEST, et soumettre l’enveloppe qui est définie en tant qu’une charge utile pour une seule URL connue. Ici, l’infrastructure technologique liée dirigerait alors cette demande vers une classe et vers une méthode basées sur un système C/S qui prend en charge deux styles de communication réseau, à savoir le style RPC et le style d’échange des messages ou des documents sous le format XML. Il y a également un style combinant le XML et le RPC (XML-RPC). Enraison de la nature neutre du format des messages ou fichiers XML à échanger entre les différentes infrastructures ou plates-formes technologiques ou encore entre les différents OS utilisés, les protocolesou les spécifications SOAPpeut aussi s’associer avec un fichier d’échanges de messages qui a un format XML dérivé. C’est le fichier WSDL (Web Services Definition Language) ou l’UDDI (Universal Description, Discovery and Integration). Le fichier WSDL est utilisé dans SOAP pour exprimer les services disponibles. Dans un environnement de développement donné (IntegratedIDE : Development Environement),le cas de Visual Studio de Microsoft ou de Netbeans de Sun Microsystems, le fichier WSDL peut arriver donc automatiquement àgénérer des proxys de code à personnaliser et qui devraient également aider par la suite un web service SOAP en implémentation de pouvoir interagir par la suite avec une application cliente Par contre, le fichier UDDI, c’est pour répertorier les services disponibles. Ilexiste également un autre format XML dérivé en dehors du WSDL et de l’UDDI. C’est le fichier WADL (Web Application Description Language). Ce dernier est souvent moins exploité par les développeurs web mais sa description et/ou son implémentation aide à faciliter une consommation automatique des différents services ou ressources à offrir par un web service type. Pour terminer, disons globalement que le web service SOAP met aujourd’hui à la disposition des développeurs ou architectes web un fichier WSDL à l’intérieur du quel sont décrits, sous un format XML, les détails de l’ensemble des différents services à utiliser indépendamment de la plateforme, c.à.d. qui décrit le nom de chaque méthode d’action, les paramètres et les valeurs de retour de chacun de services mais aussi les erreurs prévisibles. Le fichier est relativement facile à comprendre mais parfois difficile à écrire. -Le REST (Representational State Transfer) Le REST est un autre standard web devenu aujourd’hui plus populaire que le SOAP. Il s’est imposé dans le monde du web par le fait qu’il est une alternative facile d’implémentation surtout pour le développement des applications clientes devant consommer au final un service ou une ressource du web service créé ou implémenté. A proprement parler, le REST ou RESTful n’est pas forcement un standard ou protocole mais plutôt un style d’architecture logicielle (référence à la combinaison XML-RPC du SOAP) ou tout simplement un ensemble des bonnes pratiques à respecter qui peut alors être utilisé avec des nombreux formats de messages ou de requêtes. C’est donc un format de message particulier pour tout web service c.à.d. une autre forme d’architecture multicouche orientée service mais moins restrictif que le standard SOAP. Il aide donc au transfert d’état de représentation des web services grâce aux messages, requêtes ou protocoles HTTP. Comme le SOAP, il n’est pas du tout nouveau. Il a été initialement défini en 2000 par Roy Fielding dans sa thèse de doctorat, avec 7 contraintes respectives (Client-Server architecture, de Statelessness, de Cacheability, de Layered system, de Code on demand et d’Uniform interface). D’ailleurs, Roy Fielding est présenté aujourd’hui dans toutes les réunions IETF comme parmi les personnes qui ont contribuées énormément au développement du protocole HTTP. L’on doit aussi également faire noter ici que les messages, requêtes ou protocoles utilisés par le REST/RESTful sont plus petites, plus concises et peuvent être très rapides que celles utilisées par le SOAP. Ils ne contiennent pas autant d’informations ou métadonnées que

Page 11 sur 54