Architecture du Web des objets

Les services web

Web des objets

Au cours des dernières années, l’Internet des objets (IoT) a évolué à une vitesse exceptionnelle, connectant un nombre important d’objets hétérogènes (capteurs, actionneurs, smartphones, applications, etc.). Malgré les différents protocoles de communication, il a été difficile d’interconnecter ces objets entre eux. Ainsi, au-dessus de l’Internet, il y’a eu l’apparition du web des objets faisant référence à l’applicatif, qui fonctionne sur cette infrastructure, en lien avec les technologies et standards du Web, il permet à l’utilisateur d’interagir avec les services (simples ou composites). Un objet physique est alors vu comme un ensemble de services accessibles au travers du web et dont l’environnement physique permet de préciser le contexte.

La notion du Web des objets est définie par une architecture commune et très utilisée telle que le World Wide Web afin d’y intégrer des objets physiques, permettant ainsi de combler le fossé entre les mondes physiques et numériques [https://www.rapport-gratuit.com/]. Ainsi tout objet connecté devient alors une ressource disponible sur le Web. Il peut donc à son tour être utilisé dans n’importe quelle application basée sur le Web, conçue pour interagir avec le monde physique.

But du Web des objets

Le Web des objets consiste essentiellement dans le développement de concepts, d’outils et de systèmes pour la création et l’exploitation de réseaux d’objets associés à des ressources embarquées (puces RFID, capteurs et actionneurs, installations informatiques complexes) accessibles par des services web . Le principal avantage du Web des objets est l’utilisation de normes et de protocoles Web comme le protocole de transfert hypertexte (HTTP) ou les identificateurs uniformes de ressources (URI), le protocole REST pour bien représenter les services Web.

Intégration des objets au Web

Le Web des objets propose d’embarquer des serveurs web dans les environnements systèmes qui sont très contraints et ne disposent pas d’écran. Une des particularités communes à ces serveurs web embarqués est qu’ils utilisent le concept d’AJAX9. Ce modèle d’application Web permet de construire des applications Web et des sites Web dynamiques interactifs depuis un poste client à travers le protocole http (figureI.2). Dans le cas des objets intelligents limités en ressources, notamment ceux qui n’ont pas de connexion filaire, les besoins des protocoles TCP/IP et HTTP ne sont pas adaptés car trop consommateurs en termes d’énergie, de calcul, de mémoire et de bande passante. De plus, certains objets intelligents ne les supportent pas nativement. C’est généralement le cas des réseaux de capteurs sans-fil. Dans ce cas, l’intégration du monde physique (objets intelligents) au Web passe par l’utilisation d’un reverse-proxy. Il sert de passerelle entre le réseau interne (les objets qui ne communiquent pas via IP) et le Web.

 XML-RPC XML-RPC est un protocole RPC (Remote procedure call), une spécification simple et un ensemble de codes qui permettent à des processus s’exécutant dans des environnements différents de faire des appels de méthodes à travers un réseau. Le XML-RPC permet la transmission du point A au point B. Il n’y a qu’un seul appel de méthode par message de requête et une seule valeur renvoyée, sous forme de tableau ou de structure pour transmettre plusieurs valeurs, par message de réponse. Les processus d’invocation de service à distance utilisent le protocole http pour le transport des données et le langage XML pour leur codage (voir figure II.4). Il est toutefois possible de faire du XML-RPC sur un autre protocole que http. XML-RPC permet d’appeler une fonction sur un serveur distant à partir de n’importe quel système (Windows, MacOSX, Linux) et avec n’importe quel langage de programmation. Le serveur est lui même sur n’importe quel système et est programmé dans n’importe quel langage.

SOAP 

SOAP (Simple Object Access Protocol) est un protocole de communication, supportant un RPC (Remote procedural Call) ou encore des messages de type document. Le SOAP est un protocole d’architecture SOA. Il est produit de Microsoft et IBM, sa première version a été acceptée par le W3C en 2000. Il permet l’échange des documents. Sa caractéristique principale c’est qu’il est entièrement basé sur le langage XML pour définir la structure du message (l’enveloppe) et les données véhiculées. Le fait que SOAP utilise des protocoles de transport standards de l’Internet est une autre caractéristique essentielle [9] de type XML. Il permet aussi l’envoie des messages via le protocole de transport http. Le but de SOAP c’est l’échange des différents types d’informations via le net sur des différents environnements en suivant trois (03) majeur éléments :

L’architecture REST REST est un style d’architecture réseau pour Web Services qui met l’accent sur la définition de ressources identifiées par des URI, et utilise les messages du protocole HTTP pour définir la sémantique de la communication client/serveur: GET pour le rapatriement d’une ressource, POST pour une création, PUT pour une modification/création, DELETE pour un effacement.

REST est l’acronyme de “Representational State Transfer” inventé par Roy T. Fielding dans sa dissertation “an architecture style of networked systems”. Il existe une traduction en français ici. Roy T. Fielding participe de puis 1994 aux travaux du W3C sur les sujets URI, HTTP, HTML et WebDAV et a été le co-fondateur du projet Apache, le serveur Web qui équipe 70% des sites Web de tout l’Internet (IIS de Microsoft n’a que 20%). REST décrit les caractéristiques du Web qui en ont fait son succès. L’explication de la signification de REST telle que donnée par Roy T. Fielding est la suivante : “Representational State Transfer évoque l’image du fonctionnement d’une application Web bien construite : un réseau de pages Web (une machine à états finis virtuelle) où l’utilisateur progresse dans l’application en cliquant sur des liens (transition entre états) ce qui provoque l’affichage de la page suivante (représentant le nouvel état de l’application) à l’utilisateur qui peut alors l’exploiter”.

On a plusieurs définitions sur l’architecture REST, on cite quelque unes : Selon Roy Thomas Fielding: «REST is a hybrid style derived from several of the network-based architectural styles and combined with additional constraints that define a uniform connector interface» [11]. Roy Thomas Fielding a créé cette architecture « REST » selon sa définition le REST est un modèle hybride dérivé de plusieurs modèles basés sur les concepts réseau.

Selon Martin Kalin: « REST is a style of software architecture for distributed hypermedia systems; that is, systems in which text, graphics, audio, and other media are stored across a network and interconnected through hyperlinks. »[13] On conclut du point de vue de “ Martin Kalin“ que REST est un style d’architecture pour les systèmes hypermédia distribués, c’est un système auquel le texte, les graphiques,  Conclusion Générale Notre projet s’inscrit dans le domaine de génie logiciel, plus particulièrement dans la technologie des services Web. Dans le premier chapitre, nous avons présenté la notion web des objets. Dans le deuxième, on a présenté les services web et ces architectures. En troisième chapitre, nous avons présentés en détail l’architecture REST vu son importance. Finalement, nous avons présenté la conception et la réalisation de notre application. Le travail qui nous a été associé consiste à permettre la gestion d’une banque avec deux architecture SOAP et REST afin de soulever les points forts de REST. On a rencontré beaucoup de difficulté lors de la réalisation du générateur, ceci est dû aux spécificités des langages de descriptions et du nombre des outils et du serveur à maitriser. Comme perspective, on peut penser à la description et à la représentation sémantique d’une ressource physique dans le monde du web des objets et de gérer ses fonctionnalités par l’architecture REST.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Introduction Générale
Chapitre I Web des objets
I.1 Introduction
I.2 Définition
I.3 But du Web des objets
I.4 Architecture du Web des objets
I.5 Intégration des objets au Web
I.6 Conclusion
Chapitre II Les services web
II.1 Introduction
II.2 Définition
II.3 Principales caractéristiques
II.4 Objectifs
II.5 L’architectures des services WEB
II.6 Architecture orientée service
II.6.1 Terminologie dans une architecture SOA
II.7 Communiquer avec les Web Service
II.7.1 Méthode REST (Representational State Transfer)
II.7.2 XML-RPC
II.7.2 SOAP
III.8 Tableau comparatif entre REST et SOAP
II.8 Conclusion
Chapitre III L’architecture REST
III.1 Introduction
III.2 Historique
III.3.1 Définition
III.4 L’architecture REST
III.4.1 Le modèle vide
III.4.2 Le modèle client-serveur
III.4.3 Le modèle sans état
III.4.4 Le modèle cache
III.4.5 La contrainte interface uniforme
III.4.6 Le modèle Système en couche
III.4.7 La contrainte code à la demande
III.5 Principes de REST
III.6 Fonctionnalités des services RESTFUL
III.7 SOAP VS REST
III.8 avantage et Inconvénients
III.9 Conclusion
Chapitre IV Conception et réalisation de l’application
IV.1 Introduction
IV.2 La démarche UML
IV.2.1 Diagramme de classe
IV.3 Langages de programmation utilises
IV.4 Les outils utilisés
IV.5 Configuration de server WildFly et bdd
IV.6 Conclusion
Conclusion Générale
Références Bibliographiques
Liste des Figures
Annexes

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *