La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Architecture SOA,service WCF et robotique Architecture d’application Hugo St-Louis.

Présentations similaires


Présentation au sujet: "Architecture SOA,service WCF et robotique Architecture d’application Hugo St-Louis."— Transcription de la présentation:

1 Architecture SOA,service WCF et robotique Architecture d’application Hugo St-Louis

2 Plan  Historique  Architecture SOA  Service WCF  Introduction à la robotique avec MindStorm  Conclusion

3 Introduction  Dans cette présentation nous comprendrons ce qui nous a menés à utiliser l’architecture SOA.  Nous verrons les éléments de bases pour la création d’un service WCF.  Ce sujet sera traité plus en profondeur dans le cours d’informatique distribué lors de la prochaine session.

4 PolymorphismeEncapsulation Classes & héritage Basée sur les messages Schéma & Contrat Liaisons via des règles 1980 2000 Basée sur les interfaces Chargement dynamique Notion de métadonnées 1990 Orienté objet Orientation Service Orientation composant Historique de la programmation Internet App. Distribué

5 Les applications distribuées  Une application distribuée est une application dont tous les éléments qui la composent (classes, persistance, logique métier) sont distants et communiquent entre eux via des réseaux locaux d’entreprise ou par Internet.  L’utilisateur final n’a pas conscience de la nature distribuée de l’applicatif, car il utilise une interface – Web ou autre –, dont le but est de gérer les éléments distants pour atteindre l’objectif de l’application tout en masquant les mécanismes d’accès.

6 Technologies pour applications distribuées  Le principe même des applications distribuées n’est pas nouveau. Beaucoup de technologies et de protocoles, souvent incompatibles entre eux ont été mis en œuvre pour permettre aux composants d’une application distribuée, de communiquer entre eux.

7 La naissance du SOA  Malgré le fait que des technologies comme DCOM, RMI ou.Net Remoting permettent de transporter les objets et donc de dépasser les frontières de la machine grâce au réseau, on s’est souvent heurté à des problèmes de compatibilité entre plateformes, d’où le besoin d’une standardisation et la mise en commun des protocoles (SOAP, XML, …). De là est née la notion d’architecture orientée services (SOA).

8 Les 4 grands principes du SOA  La définition du service est explicite :  Un service est une classe exposée à travers les réseaux. Le but de ce service est de fournir une prestation bien définie. Les détails d’un service sont contenus dans un document standardisé, qui fait office de contrat entre le client et le serveur(WSDL).  Les services sont autonomes :  Un service se doit d’être totalement autonome. On doit pouvoir le remplacer ou le déplacer sans que cela affecte d’autres services. Un service implémente ses propres composants et ses propres méthodes d’accès aux données, il ne doit dépendre d’aucun élément externe.

9 Les 4 grands principes du SOA  Les clients et les services ne partagent que des contrats :  On a vu dans le premier principe du SOA, que les services exposent des contrats pour exposer aux clients leurs fonctionnalités et comment les utiliser. Cette interface est la seule chose que le serveur partage avec le client. En aucun cas, le service et le client ne doivent partager du code.  La compatibilité est basée sur les règles. (Théoriquement … )

10 Fonctionnement

11 Éléments conventionnés  La description du service, consistant à décrire les paramètres d'entrée du service et le format et le type des données retournées. Le principal format de description de services est WSDL (Web Services Description Language), normalisé par le W3C.  La publication (en anglais advertising) et la découverte (discovery) des services. Le principal standard utilisé est UDDI (Universal Description Discovery and Integration), normalisé par l'OASIS.  L' invocation, représentant la connexion et l'interaction du client avec le service. Le principal protocole utilisé pour l'invocation de services est SOAP (Simple Object Access Protocol).

12 Standards de l’architecture Les standards sont un élément clé d’une SOA, ils assurent l’interopérabilité Transporte SOAP W3C Simple Object Access Protocol Spec pour Repository/Registry UDDI Microsoft, IBM, HP Universal Description Discovery and Integration WSDL W3C Web Services Description Language Décris le contrat Les trois piliers des Services Web

13 Éléments du SOA  Avantages  Les services Web fournissent l'interopérabilité entre divers logiciels fonctionnant sur diverses plates-formes.interopérabilitélogicielsplates-formes  Les services Web utilisent des standards et protocoles ouverts.standards et protocoles ouverts  Les protocoles et les formats de données sont au format texte dans la mesure du possible, facilitant ainsi la compréhension du fonctionnement global des échanges.formats de données  Basés sur le protocole HTTP, les services Web peuvent fonctionner au travers de nombreux pare-feu sans nécessiter des changements sur les règles de filtrage.HTTPpare-feufiltrage  Les outils de développement, s'appuyant sur ces standards, permettent la création automatique de programmes utilisant les services Web existants.outils de développement

14 Éléments du SOA  Inconvénients  Les services Web souffrent de performances faibles comparées à d'autres approches de l'informatique répartie telles que le RMI, CORBA, ou DCOM.RMICORBADCOM  Par l'utilisation du protocole HTTP, les services Web peuvent contourner les mesures de sécurité mises en place au travers des pare-feu.HTTPpare-feu

15 WCF  SOA est une architecture  Ce n’est pas un ou des produits  Par conséquent, Microsoft se devait de donner son interprétation de la solution.  Ils ont donc créé WCF.

16 Les bases fondamentales de WCF  Première étape : définition du contrat. On définit les signatures des méthodes composant notre service WCF, et du format des données à échanger.  Seconde étape : implémentation du contrat. On implémente les services.  Troisième étape : configuration du service. On définit les endPoints, autrement dit les points d’accès au service(Adresse + binding(protocole)).  Quatrième étape : hébergement des services dans une application.NET.

17 Contrats : Qu’est-ce qu’on définit? Contrats de Service Définit les opérations, communications, comportements. Contrats de Donnée Définis les types de données et de paramètres. Contrats d’erreur (Fault) Définis les types d’erreur Contrats de Message Définis les formats de message Contrats de Service Définit les opérations, communications, comportements. Contrats de Donnée Définis les types de données et de paramètres. Contrats d’erreur (Fault) Définis les types d’erreur Contrats de Message Définis les formats de message

18 Contrat de service [ServiceContract] – Ensemble d’opérations [OperationContract] – Méthode unique [ServiceContract] – Ensemble d’opérations [OperationContract] – Méthode unique [ServiceContract] public interface IService { [OperationContract] string GetData(int value); } public class ConcreteService : IService { public string GetData(int value) {... } public string OtherMethod() {... } }

19 Durée de vie  Par défaut, la durée de vie des variables du service sont à chaque appel.  Si on veut prolonger cette durée, on peut soit sauvegarder les données dans une base de données ou transformer l’instance en singleton.

20 Contrat de données [DataContract] – Un type = un data contrat [DataMember] – Membres du contrat [DataContract] – Un type = un data contrat [DataMember] – Membres du contrat [DataContract] public class CustomType { [DataMember] public bool MyFlag { get; set; } [DataMember] public string MyString { get; set; } }

21 Transfert de données Sur un réseau les données sont sérialisées. Le Framework.Net contient déjà un attribut de sérialisation Si vous voulez utiliser des types de données pour les transférer, assurez-vous qu’elle soit sérialisable. Sur un réseau les données sont sérialisées. Le Framework.Net contient déjà un attribut de sérialisation Si vous voulez utiliser des types de données pour les transférer, assurez-vous qu’elle soit sérialisable.

22 Contrat de données DataContract: créer spécifiquement pour WCF DataMember: spécifie quelle propriété fera partie du contrat EmitDefaultValue, IsRequired, Name, Order properties DataContract: créer spécifiquement pour WCF DataMember: spécifie quelle propriété fera partie du contrat EmitDefaultValue, IsRequired, Name, Order properties

23 Contrat de données [DataContract(Name="Contact")] public class Person { [DataMember(IsRequired=true, Name="SurName")] public string LastName; public string FirstName; //Not included in contract }

24 Erreurs SOAP Trois types d’exceptions possibles: Erreur de Communication Erreur inattendue du service Erreur contextuelle du service Les exceptions.NET sont spécifiques à cette technologie Toutes les exceptions sur le réseau seront du type SOAP Faults Trois types d’exceptions possibles: Erreur de Communication Erreur inattendue du service Erreur contextuelle du service Les exceptions.NET sont spécifiques à cette technologie Toutes les exceptions sur le réseau seront du type SOAP Faults

25 Erreurs Pour WCF, les SOAP faults sont des objets de type FaultException Les services doivent émettre des FaultExceptions et non des Exceptions Pour WCF, les SOAP faults sont des objets de type FaultException Les services doivent émettre des FaultExceptions et non des Exceptions

26 Points de terminaison (end points) A ddress Où se trouve le service ? adresse à laquelle le client doit se connecter pour utiliser le service. B inding Comment parler au service ? protocole à utiliser par le client pour communiquer avec le service. A ddress Où se trouve le service ? adresse à laquelle le client doit se connecter pour utiliser le service. B inding Comment parler au service ? protocole à utiliser par le client pour communiquer avec le service.

27 Adresse Combinaison du transport, nom du server, port & path Le transport est défini par le type de binding Exemples http://localhost:8001 net.tcp://localhost:8002/MyService net.pipe://localhost/MyPipe net.msmq://localhost/private/MyService net.msmq://localhost/MyService Combinaison du transport, nom du server, port & path Le transport est défini par le type de binding Exemples http://localhost:8001 net.tcp://localhost:8002/MyService net.pipe://localhost/MyPipe net.msmq://localhost/private/MyService net.msmq://localhost/MyService

28 Adresse et binding La configuration du fichier de configuration sera couverte plus en détail dans le cours de Services.

29 Hébergements possibles IIS HTTP seulement WAS (Windows Activation Service) Utilisable avec n’importe quel transport Etc. IIS HTTP seulement WAS (Windows Activation Service) Utilisable avec n’importe quel transport Etc.

30 Un peu d’algo? SI vous avez des questions ALORS Posez-les SINON Exécuter l’exercice

31 Exercice  Allons comprendre dans Visual Studio maintenant  #1 - Nous allons faire un service qui permet de retourner le résultat d’une addition et d’une division.  #2 – Nous allons ajouter les fonctionnalités à ce service pour qu’il puisse ajouter un étudiant à un cours et de retourner la liste des étudiants inscrits à ce cours. Pour simplifier, nous allons considéré qu’il n’y a qu’un seul cours dans l’école.

32 Robot MindStorm Automne 2015 Algorithme et programmation (420-CAC-HY)

33 Plan de présentation  Présentation de MindStorm  Présentation de la librairie de communication  Réalisation de la première application  Exercice

34 MindStorm  Initiative de Lego pour intégrer la robotique pour les enfants.  Le Lego Mindstorms EV3 est la troisième génération de brique programmable Mindstorms:  1998: LEGO MINDSTORMS (RCX)  2006: LEGO MINDSTORMS NXT  2013: LEGO MINDSTORMS EV3  Normalement, il existe un environnement de développement propre à Légo…mais comme nous ne sommes pas des enfants, nous utiliserons Visual Studio

35 MindStorm  On distingue 3 composants principaux:  la brique EV3,  les moteurs,  les capteurs.

36 La brique  La brique est l’ordinateur qui commande le robot.  Les moteurs et les capteurs s’y connectent.

37

38 Grand moteur  Il sera utilisé en priorité pour le déplacement des robots.  Le grand moteur tourne à un régime de 160-170 tours par minute (tpm)  Nous pourrons déterminer par programmation:  La force envoyer sur le port (négatif ou positif),  Le nombre de degrés de rotation,  Si le moteur est en action,

39 Moteur moyen  Le moteur moyen est un moteur moins puissant, mais plus rapide. Il est aussi plus léger.  Il sera utilisé lorsqu’on aura besoin d’une réaction plus rapide qu’avec le gros moteur. Le moteur moyen tourne à un régime de 240- 250 tpm.  Note: il n’existe pas de petit moteur.

40 Le capteur de couleurs  Le capteur de couleur peut détecter les couleurs ou l'intensité de la lumière.  Trois modes d'utilisation sont disponibles:  Couleur  Intensité de la lumière réfléchie  Intensité lumineuse ambiante.  Nous pourrons lire par programmation:  Les données recueillis par le capteur.  Attention, il est possible que les données ne soient pas toujours exact!

41 Le capteur de couleurs  En mode Couleur, le capteur reconnaît sept couleurs  noir,  bleu,  vert,  Rouge,  Jaune,  Blanc,  Marron.  Conseil d’utilisation : place le capteur perpendiculairement à la surface à mesurer.

42 Le capteur de couleurs  En mode Intensité de la lumière réfléchie, le capteur mesure l'intensité de la lumière réfléchie en émettant une lumière rouge.  Le capteur utilise une échelle allant de 0 (très sombre) à 100 (très clair).

43 Le capteur de couleurs  En mode Intensité lumineuse ambiante, le capteur mesure l'intensité de la lumière ambiante qui pénètre par la fenêtre.  Le capteur utilise une échelle allant de 0 (très sombre) à 100 (très lumineux).

44 Capteur tactile  Le capteur tactile est un capteur analogique qui détecte quand son bouton rouge est enfoncé et relâché. Il peut être programmé pour définir une action en utilisant trois possibilités:  Enfoncé  Relâché  Heurté (enfoncé puis relâché)  Nous pourrons lire par programmation:  Si le capteur est enfoncé.  Le nombre de fois où le capteur a été enfoncé

45 Capteur infrarouge  Permet de définir la distance entre le capteur et un objet en face du capteur.  La porté de ce capteur est de 70 cm.  Nous pourrons lire par programmation:  La distance en cm.

46 Communication  Pour communiquer entre MindStorm et votre application, il existe trois moyens de communication(Bluetooth, Wifi, USB).

47 Librairie de communication  Pour faire le lien entre Visual Studio, nous utiliserons une librairie de communication:  MonoBrick Communication Library MonoBrick Communication Library

48 ATTENTION!  Il faut toujours prendre en considération qu’un ordinateur envoie seulement des commandes sans attendre de confirmation. Il faudra donc vérifier qu’une commande est terminée avant d’en demander une autre.

49 Application MindStorm Ev3  Nous allons construire une télécommande (application c#) qui permet de diriger le robot.  S.V.P. Une seule personne à la fois par robot.

50 La première étape est de se connecter par Bluetooth 1. Ajouter un périphérique Bluetooth, 2. Connecter vous à EV3.

51 La première étape est de se connecter par Bluetooth 1. Sur la brique, accepter la connexion et entrer un code(1234) 2. Sur l’ordinateur entrer le même code(1234).

52 La première étape est de se connecter par Bluetooth  Ensuite, vous aurez un message qui confirme l’installation.  Veuillez prendre en note le COM de connexion. Nous en aurons besoin dans l’application.

53 Application Visual Studio  Pour le reste, vous pouvez utiliser la solution fournis avec le cours.  Si vous voulez partir d’une application vierge, télécharger la librairie, ajouter les *.dll en référence à votre solution et ajouter les bon using dans votre code.

54 La connexion *Déclarer votre _brick globale, ce sera plus pratique  N’oubliez pas de fermer votre connexion à la fin: Votre COM de connexion ou USB si vous êtes USB.

55 Configuration de votre robot  Configuration du senseur du touché:  Propriétés possibles:

56 Configuration de votre robot  Configuration du senseur de couleurs:  Propriétés possibles:

57 Configuration de votre robot  Configuration du senseur infrarouge:  Les autres possibilités sont utile pour la télécommande fournis avec le Robot…que nous n’utiliserons pas.

58 Lire les données du senseur  Pour lire les données des senseurs, nous utiliserons la commande suivante(utiliser le bon numéro de senseur):

59 À vous de jouer  Suivre les étapes avec votre professeur favoris.

60 Les moteurs  On peut envoyer un courant directement sur un port de la façon suivante: OU Vitesse d’exécution [- 100, 100] Nombre de degré de rotation Est-ce que le freine à la fin?

61 Les moteurs  Pour attendre la fin d’exécution d’un moteur, nous pouvons utiliser le code suivant: Vérifie si un moteur reçoit du courant Attends un nombre de millisecondes(5 0).

62 Les moteurs  Pour bouger deux moteurs en même temps, la méthode la plus facile est de configurer un Véhicule:

63 Compléter l’exercice  Terminer la manette avec votre enseignant.

64 Des questions?


Télécharger ppt "Architecture SOA,service WCF et robotique Architecture d’application Hugo St-Louis."

Présentations similaires


Annonces Google