Différences

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

--- cours:projetsi32018:seance1 [2019/06/03 16:46] – tigli
+++ cours:projetsi32018:seance1 [2019/06/03 16:46] (Version actuelle) – tigli
@@ Ligne 10: / Ligne 10: @@
   *  Domaine 2019 : Smart Building ... Gestion intelligente des files d'attente ...
-==== Architecture orienté service ====
-Une architecture orientée service, est basée sur une approche distribuée. En premier lieu elle repose sur un ensemble de service disponibles. Chaque service fournit une API (Application Protocol Interface) comme celle d'une bibliothèque, à ceci près que les invocations de cette API se font à travers le réseau depuis un client vers un serveur.
-Ces services peuvent fournir :
-  * des interfaces graphiques (ex. le Service Web [[https://thingspeak.com/|ThingSpeak]]),
-  * 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.)
-Tous ces services sont indépendants de l'application qui l'utilise. Ils sont ainsi utilisables et  réutilisables par de multiples applications.
-{{ :cours:projetsi32018:ocs_architecture.png?700 |}}
-Une application est dès lors un //orchestrateur// qui gère la logique métier à mettre en place dans les interactions entre les services utilisés.
-L'ajout d'un nouveau service dans les services disponibles est complétement indépendant de l'ajout d'une nouvelle application utilisant les services disponibles.
-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.
-=== Et sur mon téléphone ?===
-Après avoir [[https://java2blog.com/android-development-tutorial-install-android-studio-sdk/|installé Android Studio]], voici deux tutoriaux pour de tous premiers développements sous android ([[https://java2blog.com/android-hello-world-example-using-android-studio/|Hello World!]] et une première [[https://java2blog.com/create-first-android-app-using-android-studio/|application graphique]]).
-La mise en oeuvre de service web de type REST est présentée dans [[https://www.javatpoint.com/android-web-service|ce tutorial]].
-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//)