Différences

Ci-dessous, les différences entre deux révisions de la page.

--- cours:projetsi32019:seance2 [2019/06/03 17:01] – [Architecture orienté service] tigli
+++ cours:projetsi32019:seance2 [2019/06/04 12:08] (Version actuelle) – [Premiers pas avec les outils de développement du projet] tigli
@@ Ligne 9: / Ligne 9: @@
 === Outils pour le développement du projet avec un Raspberry PI  ===
+{{:cours:projetsi32019:projet_si3.pdf|}}
 === Outils pour le développement du projet avec un Smart Phone ===
@@ Ligne 18: / Ligne 19: @@
 Pour les plus avancés voici quelques conseils qui vous permettront de mettre en œuvre un broker MQTT sur votre téléphone:
   * installer tout d'abord le broker MQTT sur votre téléphone. Par exemple : MQTT broker App (Cf. Play Store)
-  * suivre un tutorial comme [[https://internetofhomethings.com/homethings/?p=1943|celui-ci]], pour la création de clients MQTT (avec des //publishers// et des //subscribers//)
+  * installer le pack pour MQTT et reprendre les exercices de [[https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mm.tc.doc/tc10130_.htm|ce lien]], pour la création de clients MQTT (avec des //publishers// et des //subscribers//)
+Pour ceux qui voudraient retrouver un environnement Node-Red tel que celui utilisé sur le raspberry PI, sachez que Node-Red est aussi déployable sur Android (et pourquoi pas en effet !).
+([[https://iotbyhvm.ooo/nodered-on-android-how-to-use-node-red-on-android-smartphone/|Installation de Node-Red sur un smarphone android]] et [[https://nodered.org/docs/platforms/android|ici]])
 ==== Architecture orienté service ====
@@ Ligne 32: / Ligne 35: @@
 |||
-  * ** Une approche Frontend - Backend telle que vous l'avez appréhendée lors de la première partie de votre projet.** En génie logiciel, les termes front-end et back-end font référence à la séparation des préoccupations entre la couche de présentation (front-end) et la couche d'accès aux données (back-end). Dans le modèle client – serveur, le client est généralement considéré comme le serveur frontal et le serveur, comme le serveur principal, même lorsqu'un travail de présentation est en réalité effectué sur le serveur lui-même. Cette vision est plutôt adaptée à l'utilisation du smartphone comme terminal utilisateur exécutant des applications qui communiquent avec le backend. Ces applications peuvent être natives. Mais dans la mesure du possible, on leur préférera des applications web dotées de mécanismes de responsive design qui pourront s'exécuter sur n'importe cible dotée d'un browser.
+  * ** Une approche Frontend - Backend telle que vous l'avez appréhendée lors de la première partie de votre projet.** En génie logiciel, les termes front-end et back-end font référence à la séparation des préoccupations entre la couche de présentation (front-end) et la couche d'accès aux données (back-end). Dans le modèle client – serveur, le client est généralement considéré comme le serveur frontal et le serveur, comme le serveur principal, même lorsqu'un travail de présentation est en réalité effectué sur le serveur lui-même. Cette vision est plutôt adaptée à l'utilisation du smartphone comme terminal utilisateur exécutant des applications qui communiquent avec le backend. Ces applications peuvent être natives. Mais dans la mesure du possible, on leur préférera des applications web dotées de mécanismes de responsive design qui pourront s'exécuter sur n'importe cible dotée d'un browser.
 |||
-  * **L'autre approche consiste à considérer le smartphone comme un dispositif physique ou objet connecté particulier**. Dans ce cas votre Smartphone doit être vu comme un des N équipements connectés autour de vous offrant des services à l'instar de ceux fournis par votre backend, google, votre SMART TV etc.  La vision architectural est alors celle d'un ensemble d'API accessibles via le Web (services web) proposant différentes fonctionnalités, fussent-elles liées à des SAAS providers, des équipements connectés etc. On parle parfois dans ce cas de // bus de services //.
+  * **L'autre approche consiste à considérer le smartphone comme un dispositif physique ou objet connecté particulier**. Dans ce cas votre Smartphone doit être vu comme un des N équipements connectés autour de vous offrant des services à l'instar de ceux fournis par votre backend, google, votre SMART TV etc.  La vision architecturale est alors celle d'un ensemble d'API accessibles via le Web (services web) proposant différentes fonctionnalités, fussent-elles liées à des SAAS providers, des équipements connectés etc. On parle parfois dans ce cas de // bus de services //.
 Ce second type d'intégration d'un smartphone est souvent difficile à envisager. En effet le smartphone est trop souvent perçu comme un terminal mobile plus proche du PC que de la télécommande, et pourtant ... {{ :cours:projetsi32018:telecommande_medpi.jpg?140|}}
@@ Ligne 60: / Ligne 63: @@
   * des accès à des équipements physiques (ex. smart TV, smart sensors)
   * des accès à des bases de données (ex. MongoDB)
-  * des accès à d'autres systèmes d'information (ex. Google API, Microsoft Azure) à haute valeur ajoutée (carte, traffic temps réel, reconnaissance d'image, reconnaissance vocale, etc.)
+  * des accès à d'autres systèmes d'information (ex. Google API, Microsoft Azure) à haute valeur ajoutée (carte, trafic temps réel, reconnaissance d'image, reconnaissance vocale, etc.)
 Tous ces services sont indépendants de l'application qui l'utilise. Ils sont ainsi utilisables et  réutilisables par de multiples applications.
@@ Ligne 71: / Ligne 74: @@
 Cette architecture est donc particulièrement adaptée aux méthodes agiles où les incréments peuvent être de 2 catégories : ajouter un nouveau service (offert par un équipement, un système d'information, etc.) ou modifier l'application en modifiant la logique de l'orchestrateur.
-=== Eléments Techniques pour le Projet SI3 ===
-Les protocoles d'échange entre vos fournisseurs d'API et votre orchestrateur(utilisateur des APIs) peuvent être de différentes natures.
-  * une des approches les plus connues et utilisées sont les Web services de type REST. Cette approche basée sur des communications Web (protocole HTTP),sont de type client/serveur. Les APIs sont donc accessibles à travers des Serveur Web. L'orchestrateur y accède avec des clients.
-  * d'autres approches peut se baser sur d'autres protocoles d'échange et même de modèle de communication. C'est le cas des communications événementiels qui se distingue des approches client/serveurs. Un des exemples les plus connus est MQTT.