Programmation Approche composants Ing5 SI

Présentation au sujet: "Programmation Approche composants Ing5 SI"— Transcription de la présentation:

1 Programmation Approche composants Ing5 SI

2 Plan du module Approche composants et interopérabilité des SI sur .net. Approche composants et interopérabilité des SI sur Java. TP approche composants Création d application ASP.NET Création de web services. Consommation de web services (sur différents type de clients) “interopérabilité dans .net”

3 Organisation du module
Approche composants .Net 4*3H Examen DS Approche composant Java 4*3H TP *4H ??

4 Plan du cours Rappels des notions techniques abordées.
Approche composants. Évolution de la programmation composant. Modèle en couches. Programmation distribuée. Présentations des technologies. Les solutions Microsoft. .NetRemoting. ASP.NET. Les Web services. Interopérabilité API/COM dans .Net.

5 Rappels

6 Rappel de notions techniques
Classes abstraites. Interfaces. Les fabriques. ADO Net.

7 Classe Abstraite Sert de base à une hiérarchie d'objets partageant des méthodes communes mais dont l'implémentation réelle peut varier. Une classe est dite abstraite si elle ne fournit pas d'implémentation pour au moins l’une de ses méthodes. Une classe abstraite ne peut être instanciée

8 Code source

9 Interface Une interface peut être vue comme une classe abstraite "pure", c'est à dire une classe dont tous les attributs sont abstraits. Une interface n'est pas instanciable. Une interface est en fait un contrat qu'une classe s'engage à respecter. Une interface ne peut contenir aucun code. Une classe n'hérite pas d'une interface, elle l'implémente. Une classe peut implémenter plusieurs interfaces.

10 Code source

11 Les fabriques de classes
Les classes fabriques sont utiliser pour simuler un constructeur d’un objet Interface. Sa mission est de créer un objet spécifique en fonction d'un paramètre et de retourner une interface au client.

12 Code source

13 ADO.net DataSet DataTable DataAdaptater DbConnexion DbCommande
DbParameters DataTableMapping DbProviderFactory DbProviderFactories DbProviderInvariantName

14 Code Source

15 Approche composant

16 Approche Mainframe AVANTAGES Modèle de conception simple.
Pas de dépendance avec d’autre code. ‘Facilité’ de distribution. INCONVENIANT Code difficile à maintenir. Difficulté de travail coopératif. Pas de réutilisation du code. Ces approches sont adaptées à de petit projet ne demandant pas une grande évolution dans le temps.

17 La complexité des applications informatiques modernes atteint des proportions telles qu’il devient impossible de maîtriser les nouveaux développements si l’on ne leur applique pas une structuration et une méthodologie rigoureuses. Dans ce domaine, les approches « anciennes » de type mainframe, ou même l’approche « pur objet » ont montré un certain nombre de limites.

18 Évolution des modèles N/Tiers
Séparation du code en plusieurs couches spécialisées. Indépendance entre les différentes couches Répartition des charges sur différentes machines (client et serveur)

19 Modèle à 1 couche Aucune séparation entre les données le code de l’application et l’interface utilisateur.

20 Inconvénient du modèle 1 couches
Nécessite une connexion différente au serveur de BDD pour chaque utilisateur. Le client doit posséder les drivers des BDD auxquelles il désire accéder. Le code de l’interface est mélange à la logique métier et à la gestion des connexions aux Bdd.

21 Difficulté de gestion à plusieurs utilisateurs ayant accès à plusieurs type de bases.

22 Modèle à 2 couches Ajout d’une couche d’accès aux données.

23 Avantages Indépendance entre le client et le type de données.
Possibilté de mutualiser les accès aux BDD. Le client n’a pas à connaître le type de BDD à laquelle il se connecte.

24 Inconvénients Le code métier et le code de l’interface sont mélangés.

25 Avantage du modèle à 3 couches
Centralisation de la logique métier. Mise a jour de la logique métier sans recompilation des applications clientes. L’application cliente est indépendante du format des données de la BDD. Possibilité de partager les couches métier entre plusieurs utilisateurs. Les clients n’ont plus besoins des drivers de BDD.

26 Modèle adapté à la programmation Web
Notion de clients légers.

27 Définition du rôle de chaque couches

28 La couche représentation.
Interface graphique, console de saisie ou autre (navigateur web). C’est l’intermédiaire entre l’utilisateur et l’application. Formatage des informations de saisie et des valeurs de retours. Spécifique à chaque matériel d’affichage, Applications Web, Windows form, Pocket PC ... Gestion des différents appareils de saisie, Clavier, souris, Tablet Pc, ...

29 La couche logique. Formate les informations pour les communiquer aux BDD ou aux interfaces utilisateurs. Peut dédier de façon transparente pour l’utilisateur une partie de son traitement, via des composants distribués. Masque au client l’infrastructure sous jacente de l’application. Développement de composants hyper spécialises plus facile à maintenir. Effectue le traitement du processus métier de l’application

30 La couche d’accès aux données.
Cette couche permet un accès uniforme aux données de la Bdd. Communiques aux couches supérieures les résultats de ses recherches. La couche d’accès peut se trouver sur le même serveur que la base, mais peut aussi gérer l’accès à plusieurs types de BDD.

31 Évolution de la programmation par composants
Introduction des bibliothèques (compilation séparée). Programmation par objets (intégration des données et des services). Bus logiciel réparti (accès à distance). Modèle de composants faiblement couplés.

32 Les composants distribués
Partage d’une ressource entre plusieurs utilisateurs. Facilité de mise à jours. Homogénéisation des versions clientes. Répartition des charges sur plusieurs serveurs. Support des architectures hétérogènes.

33 Présentations des technologies de programmation distribuée
Com / Dcom (Distributed Component Object Model). Java RMI (Remode Method Invocation). CORBA (Common Object Resquest Broker Architecture). Service Web.

34 Com / Dcom Architecture étroitement liée aux systèmes Microsoft.
Difficulté de configuration de Dcom. Architecture étroitement liée aux systèmes Microsoft. Intégré à Windows depuis la version NT4. Développement Com prit en charge par de nombreux outil (Visaul Studio 6). Supporté par plusieurs langages.

35 RMI Obligation d’utiliser le langage JAVA.
Intégré au Java Developpement kit depuis la version 1.1. L’ORB (Object Request Broker) RMI est natif dans la machine virtuelle Java. Pas interface de description des données. Solution légère et peu gourmande. Multi plateforme. Obligation d’utiliser le langage JAVA.

36 CORBA Norme de distribution d’objet définie par l’OMG (Object Management Group), donc non propriétaire. Indépandance de la plateforme d’application. Support multi langage. Nécessité de disposer d’un langage intermédiaire définissant l’interface des objets distribués, IDL (Interface Definition Langage). Le compilateur IDL, utilisé pour la création des proxy est spécifique à chaque langage.

37 Service Web Technologie lourde et gourmande en ressource machine.
Pas de format binaire utilisation de caractères ASCII. Forte surcharge de la bande passante. Technologie récente et pas encore totalement standardisée, notamment pour la gestion de workFlow. Basé sur des protocoles standards. Peut transiter par le protocole Http Supporté par de nombreux langages. Indépendant de la plate forme. Exploite des standards libres.