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

Jacques Augustin Nov- Jan 2012 Cours dArchitecture des Systèmes d'Information EFREI.

Présentations similaires


Présentation au sujet: "Jacques Augustin Nov- Jan 2012 Cours dArchitecture des Systèmes d'Information EFREI."— Transcription de la présentation:

1 Jacques Augustin Nov- Jan 2012 Cours dArchitecture des Systèmes d'Information EFREI

2 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 2 Sommaire Introduction Rôle de larchitecte de systèmes dinformation Architecture et intégration de systèmes Cartographie du SI Considérations stratégiques Conception et modélisation Middlewares Les premières technologies : DCOM et CORBA Middleware transactionnel : COM+ et EJB Middleware orienté messages (MOM) Architecture orientée services Conception et mise en œuvre Orchestration et mise en œuvre Persistance et stockage de données Couche de persistance et loutil Hibernate Interaction avec les systèmes de gestion de bases de données Problématique particulière des migrations de données

3 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 3 Introduction

4 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 4 Introduction But de cette formation Vous donner les éléments de base darchitecture de systèmes dinformation. Deux parties avec de fortes adhérences : architecture systèmes et réseaux. Agrégation et orchestration de connaissances diverses (technologies, conception et programmation, bases de données et réseaux) Organisation du cours 5 cours 3 cours 100% théoriques en nov-déc 2 cours 50/50 théorie / pratique

5 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 5 Introduction Architecture de systèmes dinformation Architecture (Larousse) : "Art de concevoir et de construire un bâtiment selon des partis pris esthétiques et des règles techniques et déterminés". Ne pas confondre avec architecture des ordinateurs Rôle dun architecte Concevoir les différentes briques du système dinformation et sassurer de leur interopérabilité. Il veille aussi à lévolution de ces briques. Il doit sassurer dune bonne orchestration de ces briques en termes de qualité, performance, de flexibilité et de sécurité. Positionnement stratégique par rapport au fonctionnement de lentreprise.

6 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 6 Introduction Architecture et intégration de systèmes Lintégration de systèmes est avant tout une démarche logicielle. Larchitecte va plus loin que lintégrateur en intégrant des paramètres durbanisation, des règles dentreprise, des contraintes dharmonisation et de sécurité. Les compétences de larchitecte englobent la programmation, les réseaux, les bases de données, les mainframes, les traitements batchs, les technologies Web et les règles métier de lentreprise. Ses connaissances doivent être constamment à jour dans tous ces domaines. Il assiste efficacement le DSI et participe à toutes les décisions stratégiques concernant le système dinformation. Il a une connaissance rigoureuse et exacte de la cartographie du système dinformation.

7 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 7 Introduction Cartographie du SI Diagramme illustrant toutes les briques dun système dinformation.

8 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 8 Introduction Considérations stratégiques Larchitecte de SI doit constamment jauger ses décisions à la lumière des questions suivantes : Quels sont les avantages et inconvénients techniques de cette approche? Cette solution est-elle flexible? Quel est le coût de mise en œuvre et de maintenance? Cette technologie a-t-elle un avenir? Approche "custom" ou "package" ? Le niveau de performances est-il acceptable? Le niveau de qualité est-il suffisant? La solution est-elle fiable et sécurisée? Quel est le retour sur investissement (ROI) de cette solution ? Cela vaut-il la peine de remplacer/faire évoluer lexistant?

9 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 9 Conception et modélisation

10 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 10 Design patterns : définition Design patterns Les problèmes auxquels font face concepteurs et développeurs sont rarement exceptionnels. Ils sont en fait souvent récurrents. Et la réapparition systématique de ces problèmes a poussé la communauté des concepteurs à échafauder des solutions réutilisables. Ainsi est née une approche visant à élever la réutilisabilité au niveau de la conception et de l'architecture des systèmes orientés objets, par lemploi de modèles capturant la sémantique et la structure de solutions utilisées de façon récurrente pour résoudre des problèmes survenant dans des contextes similaires. Un patron est donc une solution répondant à un problème récurrent, dans un contexte spécifique. Connaître les principaux patrons est très utile à tout développeur du monde objet, surtout dans le cadre de grands projets (basés sur le modèle objet). En effet, l'appréhension d'un système développé en utilisant des patterns est grandement facilitée, puisque leur identification permet de comprendre plus vite les différentes parties du système en question et d'avoir ainsi une vue de plus haut niveau plus rapidement.

11 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 11 Différents types de patterns Patterns architecturaux Ce sont des modèles pour des architectures logicielles concrètes et peuvent donc être vus comme des patrons à grande échelle. Ils spécifient les différents sous-systèmes et composants d'un système, leurs responsabilités, ainsi que les règles d'organisation de leurs interrelations. L'un des modèles architecturaux les plus connus est le modèle MVC (Model – View – Controller). Patterns de conception Un patron de conception fournit un schéma pour raffiner les sous-systèmes ou les composants d'un système logiciel. Il décrit une structure de composants communiquant entre eux et solutionnant un problème de conception récurrent. On peut compléter cette définition en ajoutant la notion de contexte attaché au problème et indissociable de celui-ci. Un patron de conception peut donc être vu comme la description d'un problème et de sa solution.

12 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 12 Classification des patterns Patterns : classification Le GoF (Gang of Four, nom donné aux auteurs de « Design Patterns – Catalogue de modèles de conceptions réutilisables) propose une classification des design patterns suivant deux critères : Le rôle du modèle, qui traduit ce qu'il fait : créateur : création des objets. Ces patrons fournissent des interfaces de création des objets, évitant ainsi l'instanciation directe des objets. Le programme gagne en flexibilité en décidant quels objets doivent être créés pour un cas donné. Exemples : fabrique (abstract factory, factory method), singleton structurel : composition des classes ou des objets. Ces patrons servent à regrouper des objets dans des structures plus grandes, comme par exemple des interfaces utilisateur complexes. Exemples : adaptateur, composite, décorateur, façade, proxy comportemental : définition des interactions entre classes et objets, et de la répartition des responsabilités. Ces patrons définissent une communication entre les objets. Exemples : commande, itérateur, observateur, stratégie Le domaine (ou la portée) du modèle, qui précise si le modèle sapplique à des classes ou à des objets : les modèles de classes traitent des relations entre les classes et leurs sous-classes les modèles d'objets traitent des relations entre les objets

13 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 13 Exemple de pattern Patterns : exemple Le pattern Singleton Ce modèle créateur permet de s'assurer que la classe n'aura qu'une seule instance, accessible par un point d'entrée unique (une méthode) bien déterminé. Implémentation Linstance unique est conservée comme membre de classe (protégé pour permettre lhéritage), créée par un constructeur accessible uniquement par la classe et ses dérivées (donc également en accès protégé). Le point dentrée est une méthode publique statique (ne nécessitant heureusement la création préalable daucune instance de singleton).

14 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 14 Exercice Singleton Un singleton sert à contrôler le nombre d'instances d'une classe présent à un moment donné. C'est souvent très pratique pour les classes sans état et effectuant toujours les mêmes traitements. Un singleton est construit grâce à des méthodes de classes. Ces méthodes appartiennent à une classe et peuvent être accédées indépendamment de l'objet. Compléter le code suivant pour implémenter correctement le pattern Singleton public CanvasFactory { /** Donnée de classe contenant l'instance courante */ private ??? CanvasFactory instance = new CanvasFactory(); /** Constructeur privé interdisant l'instanciation en dehors de cette classe */ ??? CanvasFactory () {} /** Singleton de la classe courante */ public ??? CanvasFactory getInstance() { ??? ; }... } Typiquement l'usage de la classe CanvasFactory se fera ainsi : CanvasFactory cf = CanvasFactory.getInstance();

15 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 15 Le pattern architectural MVC Introduction (1/2) Le concepteur d'applications interactives (avec interface homme-machine (IHM)) doit faire face à un problème fondamental qui est celui de la flexibilité de ses interfaces. Dune part, divers utilisateurs de son application doivent accéder aux mêmes données, avec des interfaces hétérogènes, pouvant dépendre de leurs préférences, de leurs besoins et de leurs environnements matériel et logiciel. Cette diversité des IHM constitue un problème de flexibilité d'apparence pour le concepteur. En outre, les fonctionnalités mêmes peuvent varier d'un type d'utilisateur à un autre ou d'une période à une autre (ajout / suppression dune fonctionnalité). Le développeur doit pouvoir gérer ces modifications sans toucher aux fonctionnalités essentielles de l'application. Dans ce cas, le couplage interface - système est faible.

16 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 16 Le pattern architectural MVC Introduction (2/2) Dans le cas contraire (couplage fort), il devra implémenter des modules entiers – mélangeant fonctionnalités et interface – par type d'utilisateur. On peut alors facilement imaginer la difficulté que constitue la synchronisation de tout changement effectué sur une interface. Afin de répondre à cette problématique, un pattern architectural appelé MVC (Model View Controller) a été proposé (pour Smalltalk 80) et rapidement adopté par la communauté des développeurs d'applications ou de modules de type IHM. Il permet de faire collaborer une équipe d'infographistes et une équipe d'informaticiens.

17 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 17 Le pattern architectural MVC Composants Une application conforme au modèle MVC comporte trois parties distinctes : le MODELE, comprenant les fonctionnalités de base (logique métier) et les données – ou l'accès à ces dernières – (état de l'application). Il ne contient pas dinformation relative à la façon dafficher les informations quil contient. Le modèle est donc indépendant de la représentation des données et est facilement portable dun environnement à un autre. la VUE, affichant des informations à l'utilisateur (représentation graphique ou textuelle des informations contenues par le modèle) le CONTROLEUR, gérant la réaction du système aux événements provoqués par l'utilisateur (dont la synchronisation entre la vue et le modèle)

18 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 18 Le pattern architectural MVC Interactions (I) La vue est la partie graphique de l'interface, cest-à-dire ce que l'utilisateur voit. Elle constitue en fait le dispositif dintroduction des données dans le système. Les événements (clics de souris, sélection dans un menu, …) déclenchés par lutilisateur sont interceptés par le contrôleur qui les transmet par la suite au modèle pour les traitements appropriés. Le contrôleur peut donc être vu comme un gestionnaire d'événements. Ainsi, à chaque intervention de l'utilisateur nécessitant l'"attention" du contrôleur, ce dernier effectue deux tâches : l'interception de l'événement l'envoi d'un message au modèle demandant l'activation d'un service correspondant En outre, le contrôleur intervient également pour la sélection d'une vue (une par fonctionnalité) conformément à la cinématique (cheminement) définie pour le traitement des actions.

19 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 19 Le pattern architectural MVC Interactions (II) Le modèle entre en scène dans l'un des deux cas de figure suivants : envoi d'un message du contrôleur suite à une action de l'utilisateur demande, par la vue (ou les vues), de données actualisées, lorsque l'état du système change Un message du contrôleur au modèle peut entraîner un changement au niveau des données, sans que la vue en soit avertie (perte de cohérence entre données du système et données de l'interface). Or le modèle MVC impose qu'il n'y ait pas de lien direct du modèle vers la vue : le modèle doit rester indépendant de la vue ou des vues qui en dépendent. Comment faire alors pour que cette dernière dispose toujours des informations les plus récentes afin de les afficher à l'utilisateur ? La réponse à cette question réside dans un mécanisme de diffusion de messages (ou d'événements) : une fois sa tâche exécutée, le modèle "avertit" les vues qui lui sont associées du changement. Pour cela, il maintient un registre de "dépendants" (liste de vues ou de paires vue- contrôleur), qui sont informés de tout changement par simple envoi de messages au registre (pattern comportemental Observer-Observable).

20 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 20 Le pattern architectural MVC Avantages De par la séparation qu'il propose, le modèle MVC offre des avantages évidents concernant l'extensibilité et la maintenance des applications développées selon ce pattern : la dissociation de la structure logique de sa représentation visuelle permet dassocier plusieurs représentations visuelles pour un même modèle (vues de plusieurs faces dun objet en 3D, modification du look and feel, …). On peut ainsi changer la ou les vues sans rien modifier de la structure logique (plusieurs affichages graphiques – camembert, histogramme, … – dun même tableau de données). l'association modèle / représentation visuelle est effectuée dynamiquement, c'est-à-dire à l'exécution, par le contrôleur (pas de liaison statique à réaliser avant le lancement de l'application).

21 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 21 La mise en œuvre des patterns Les frameworks Le champ d'application des patterns est volontairement le plus large possible, puisqu'ils font figures de schémas abstraits standardisés. Un développeur désireux d'utiliser des patterns doit donc bien en connaître les principes ou suivre à la lettre les directives de son concepteur. Or le développeur évolue dans un domaine particulier et sil sait qu'il existe une solution à son problème, il s'intéressera plutôt au moyen de mettre en œuvre rapidement et de manière fiable cette solution, sans s'embarrasser de considérations abstraites. Beaucoup d'outils ont été proposés pour atteindre cet objectif. L'approche qui est la plus adoptée actuellement (et qui fait l'objet de cette partie) est celle qui consiste à utiliser une structure "préfabriquée", un moule, qui garantit au développeur que l'application qu'il va concevoir sur cette base, sera conforme à tel ou tel modèle. Cette démarche est celle concernant les frameworks. Un framework est un modèle (une base) de programme réutilisable représenté par un ensemble de classes, qui coopèrent et forment ainsi un moule pour produire des applications sur mesure, de même structure, dans une catégorie spécifique de logiciels. En contraste avec les techniques traditionnelles de réutilisation en développement orienté objet, basées principalement sur la réutilisation de classes, les frameworks sont conçus pour une activité précise. Un framework est donc utilisé pour la génération de multiples applications d'un domaine particulier.

22 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 22 C.O.R.B.A.

23 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 23 CORBA - Principe simplifié Middleware Objet ClientServeur Objet

24 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 24 Qu'est ce que C.O.R.B.A. ? CORBA ( Common Object Request Broker Architecture ) est un environnement réparti (middleware). Défini par l'OMG Créé en 1989 But non lucratif Plus de 850 membres (Sun, IBM, Microsoft,...) Crée et maintient les spécifications CORBA UML

25 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 25 Objectifs de CORBA Fournir un environnement ouvert les membres participent aux spécifications Fournir un environnement portable les API sont définis pour rendre les applications portables ( quelque soit le produit CORBA utilisé ) Fournir un environnement interopérable Permettre aux applications CORBA de collaborer entre elles.

26 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 26 PCSparc NT PC UNIX Le bus CORBA Le bus CORBA = ORB

27 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 27 La vue réelle du bus CORBA PCSparc NT PC UNIX ORB PC/NT ORB PC/UNIX ORB Sparc/UNIX Réseau TCP/IP

28 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 28 Architecture de CORBA IDL

29 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 29 Serveur et objets Un serveur CORBA peut héberger plusieurs objets CORBA. Chaque objet est accessible indépendamment des autres objets du serveur. Chaque objet exprime son offre de services. Pour cela, on utilise un langage de description de services appelé IDL CORBA.

30 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page Composants Stub : partie cliente Skeleton : partie serveur Object Adapter : enregistrement des objets ORB : passage de message IIOP : Internet Inter-ORB Protocol générés automatiquement

31 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page Objet CORBA

32 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 32 Le langage IDL CORBA Il s'agit de décrire au sein d'une interface ( vue cliente de l'objet ) la liste des services offerts ( ensemble de fonctions ). interface Horloge { string donne_heure_a_paris(); string donne_heure_a_pekin(); };

33 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 33 La compilation IDL Une description IDL est compilée pour générer les amorces nécessaires au mécanisme RPC. description IDL Génération de l'amorce cliente souche Génération de l'amorce serveur squelette

34 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 34 Intervention des amorces C.O.R.B.A. PCSparc NT PC UNIX ORB Java PC/NT ORB PC/UNIX ORB C++ Sparc/UNIX Protocole IIOP Souche Java Client Java Squelette C++ Objet C++

35 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 35 Souche : Coté client Fonctions de la souche : Prépare les paramètres dentrée de linvocation Décode les paramètres de sortie et le résultat Souche statique Une par type dobjet serveur à invoquer Identique aux talons clients RPC Générée à la compilation à partir de linterface IDL Souche dynamique Souche générique construisant dynamiquement tout type de requêtes Permet dinvoquer des objets serveurs que lon découvre à lexécution (i.e. dont on ne connaît pas linterface à la compilation : Référentiel dinterfaces)

36 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 36 Squelette : Côté serveur Fonctions du squelette : décode les paramètres dentrée des invocations prépare les paramètres de sortie et le résultat Squelette statique un par type dobjet serveur invocable identique aux talons serveurs RPC généré à la compilation à partir de linterface IDL Squelette dynamique squelette générique prenant en compte dynamiquement tout type de requêtes permet de créer à lexécution des classes dobjets serveurs (i.e. que lon ne connaissait pas à la compilation)

37 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 37 L'identité d'un objet C.O.R.B.A. Chaque objet C.O.R.B.A. est associé à une référence d'objet qui forme son identité. Deux objets C.O.R.B.A. du même type ( exemple deux objets Horloge ) ont deux identités différentes. serveur Les références d'objets sont le moyen d'accès à un objet.

38 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 38 Le bus C.O.R.B.A. ( O.R.B. ) Adaptateur d'objets L'adaptateur d'objets Souche A Client Squelette A Objet A Squelette B Objet B Serveur

39 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 39 L'adaptateur d'objets Fonctions Interface entre les objets CORBA et lORB Enregistrement et recherche des implantations dobjets Génération de références pour les objets Gestion de linstanciation des objets serveurs Activation des processus dans le serveur Aiguillage des invocations de méthodes vers les objets serveurs Différents type dadaptateur BOA (Basic Object Adapter) POA (Portable Object Adapter)

40 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 40 Les communications avec CORBA Les participants à un échange CORBA communiquent à l'aide d'un protocole spécifique à CORBA : IIOP ( Internet Inter-ORB Protocol ). Le protocole IIOP est indépendant du langage de programmation, du système d'exploitation et de la machine utilisée. Un client Java pourra utiliser un serveur C++

41 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 41 Normalisation des communications Protocoles dinteropérabilité entre ORBs conformes à CORBA 2 GIOP : General Inter-ORB Protocol Messages : request, reply, cancelrequest, … nécessite un protocole de transport fiable, orienté connexion IIOP (Internet IOP) : instanciation de GIOP sur TCP Autres implantations de GIOP au-dessus de HTTP, RPC DCE, RPC Sun Composants du protocole CDR : Common Data Representation Format de données dencodage des données IOR : Interoperable Object References (références dobjets)

42 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 42 L'annuaire C.O.R.B.A. L'annuaire C.O.R.B.A. est un service. Il s'agit d'un serveur qui enregistre des associations nom / référence d'objet. Un serveur peut enregistrer ses objets dans l'annuaire. Un client peut récupérer l'accès à un objet en consultant l'annuaire.

43 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 43 Compilation d'une description IDL La description doit être compilée afin de générer les amorces ( souche et squelette ) requises pour l'établissement de la communication inter-processus. A l'issu de la compilation, plusieurs fichier sont créés : Le squelette La souche, L'interface Les opérations de l'interface

44 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 44 Concept de « mapping » Une description IDL est traduite vers un langage de programmation. Les règles de traduction sont appelées « mapping » et font partie de la spécification CORBA. Grâce au mapping, deux fournisseurs d'ORBs offriront le même modèle de programmation. portabilité des applications

45 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 45 Développer les objets CORBA Pour développer un objet CORBA plusieurs critères sont à prendre à compte : le type de l'adaptateur d'objet utilisé, l'approche de développement. Deux adaptateurs d'objets sont disponibles : le B.O.A. ( Basic Object Adapter ) le P.O.A. ( Portable Object Adapter ) Deux approches existent : l'approche par héritage : ici l'implantation de l'objet doit hériter du squelette ( c'est à dire de la classe Java correspondant au squelette qui à été générée par le compilateur ). l'approche par délégation (prochaine partie).

46 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 46 Développement de notre premier objet CORBA public class PremierImpl extends PremierPOA { public void affiche( String message ) { System.out.println( message ); } L'implantation hérite du squelette. La seule obligation est de ne pas oublier l'héritage du squelette. Ensuite, il faut tout simplement fournir le code des opérations décrites dans l'interface IDL. !

47 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 47 Développer le serveur Les étapes à respecter sont les suivantes : initialiser l'ORB initialiser l'adaptateur d'objets créer l'objet CORBA enregistrer l'objet CORBA exporter la référence de l'objet CORBA attendre les invocations clientes

48 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 48 Initialiser l'ORB Pour cela, on fait appel à la fonction statique « init » de la classe « org.omg.CORBA.ORB ». Deux formes de cette fonction sont disponibles : org.omg.CORBA.ORB.init( ) org.omg.CORBA.ORB.init( String [] args, java.util.Properties prop ) public static void main( String [ ] args ) { org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init( args, null ); // … }

49 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 49 Initialiser l'adaptateur d'objets Une application serveur contient au minimum un POA (elle peut en avoir plusieurs) appelé le RootPOA Le(s) POA(s) sont gérés par le POA Manager Une application serveur doit Récupérer une référence dobjet RootPOA POA rootpoa = POAHelper.narrow(orb.resolve_initial_references («RootPOA»)); et Activer le POA Manager rootpoa.the_POAManager().activate();

50 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 50 POAManager & POA

51 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 51 Créer et enregistrer l'objet CORBA Pour créer l'objet CORBA, il suffit de créer une instance de la classe d'implantation de l'objet ( PremierImpl ). Dans la terminologie POA, cet objet sappelle un servant PremierImpl premier = new PremierImpl(); Enregistrer un servant revient à lui associer une référence : org.omg.CORBA.Object ref = rootpoa.servant_to_reference(premier );

52 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 52 Echanger une référence d'objet Chaque objet CORBA dispose d'une identité ( la référence d'objet ). Pour qu'un client puisse appeler un objet CORBA, celui-ci doit en connaître la référence de l'objet. C'est pourquoi l'objet CORBA doit échanger avec le client sa référence d'objet. Pour cela, on utilise deux opérations particulières de la classe « org.omg.CORBA.ORB » : object_to_string : cette opération transforme une référence d'objet en une chaîne de caractères. string_to_object : cette opération transforme une chaîne de caractères en une référence d'objet.

53 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 53 Le code du serveur import org.omg.CORBA.ORB; import org.omg.PortableServer.*; public class Serveur { public static void main( String [] args ) { try { ORB orb = ORB.init( args, null ); POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA")); rootpoa.the_POAManager().activate(); PremierImpl premier = new PremierImpl(); org.omg.CORBA.Object objref = rootpoa.servant_to_reference(premier); String ref = orb.object_to_string( objref ); java.io.FileOutputStream file = new java.io.FileOutputStream("ObjectID"); java.io.PrintStream output = new java.io.PrintStream( file ); output.println( ref ); output.close(); orb.run(); } catch ( Exception ex ) { ex.printStackTrace(); } }

54 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 54 Développer le client Les étapes à suivre sont les suivantes : Initialiser l'ORB, Récupérer la référence de l'objet à utiliser, Convertir la référence vers le type de l'objet à utiliser, Utiliser l'objet.

55 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 55 Conversion de références d'objets org.omg.CORBA.Object Premier object_to_string org.omg.CORBA.Object string_to_object Conversion La conversion consiste à utiliser une fonction spécifique appelée « narrow ».

56 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 56 Les classes helpers Pour chaque élément décrit en IDL, le compilateur génère une classe supplémentaire appelée classe helper. Cette classe porte le nom de l'élément IDL avec pour suffixe "Helper". Les classes helpers associées aux interfaces IDL comportent une opération de conversion ( narrow ). public class PremierHelper { public static Premier narrow( org.omg.CORBA.Object obj ) { //… } //... }

57 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 57 Le code du client public class Client { public static void main( String [ ] args ) { org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init( args, null ); try { java.io.FileInputStream file = new java.io.FileInputStream("ObjectID"); java.io.InputStreamReader input = new java.io.InputStreamReader( file ); java.io.BufferedReader reader = new java.io.BufferedReader(input); String ref = reader.readLine(); file.close(); org.omg.CORBA.Object obj = orb.string_to_object(ref) ; Premier premier = PremierHelper.narrow( obj ); premier.affiche("Bonjour du client…"); } catch ( java.lang.Exception ex ) { ex.printStackTrace(); } }

58 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 58 Exécuter l'application Suivre les étapes suivantes : lancer le serveur, copier le fichier contenant la référence d'objet sur le poste client, lancer le client.

59 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 59 Synthèse Le développement d'une application CORBA respecte toujours les même étapes. Description des objets à l'aide de l'IDL, Implantation des divers objets, Implantation du serveur avec échanges des références, Implantation du client.

60 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 60 CORBA - TP Nous allons réaliser un petit programme qui affiche Hello EFREI!, en faisant communiquer entre eux deux objets, sur un bus CORBA. 1. Définissons linterface IDL Dans un éditeur de texte, créez le fichier Hello.idl contenant les instructions suivantes : module HelloApp { interface Hello { string sayHello(); oneway void shutdown(); }; 2. Construisons lobjet serveur Que devrait contenir cet objet? Quel est son rôle?

61 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 61 CORBA - TP Classe HelloServer.java import HelloApp.*; import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; import org.omg.PortableServer.*; import org.omg.PortableServer.POA; import java.util.Properties; class HelloImpl extends HelloPOA { private ORB orb; public void setORB(ORB orb_val) { orb = orb_val; } // implement sayHello() method public String sayHello() { return "\nHello EFREI !\n"; } // implement shutdown() method public void shutdown() { orb.shutdown(false); }

62 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 62 CORBA - TP Classe HelloServer.java (suite) public class HelloServer { public static void main(String args[]) { try{ // create and initialize the ORB ORB orb = ORB.init(args, null); // get reference to rootpoa & activate the POAManager POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA")); rootpoa.the_POAManager().activate(); // create servant and register it with the ORB HelloImpl helloImpl = new HelloImpl(); helloImpl.setORB(orb); // get object reference from the servant org.omg.CORBA.Object ref = rootpoa.servant_to_reference(helloImpl); Hello href = HelloHelper.narrow(ref); // get the root naming context // NameService invokes the name service org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); // Use NamingContextExt which is part of the Interoperable // Naming Service (INS) specification. NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

63 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 63 CORBA - TP Classe HelloServer.java (suite) // bind the Object Reference in Naming String name = "Hello"; NameComponent path[] = ncRef.to_name( name ); ncRef.rebind(path, href); System.out.println("HelloServer prêt et en attente..."); // wait for invocations from clients orb.run(); } catch (Exception e) { System.err.println("ERROR: " + e); e.printStackTrace(System.out); } System.out.println(« Arrêt de HelloServer..."); }

64 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 64 CORBA - TP 3. Construisons lobjet client Que devrait contenir cet objet? Quel est son rôle?

65 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 65 CORBA - TP Classe HelloClient.java import HelloApp.*; import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; public class HelloClient { static Hello helloImpl; public static void main(String args[]) { try{ // create and initialize the ORB ORB orb = ORB.init(args, null); // get the root naming context org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); // Use NamingContextExt instead of NamingContext. This is // part of the Interoperable naming Service. NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

66 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 66 CORBA - TP Classe HelloClient.java (suite) // resolve the Object Reference in Naming String name = "Hello"; helloImpl = HelloHelper.narrow(ncRef.resolve_str(name)); System.out.println("Obtained a handle on server object: " + helloImpl); System.out.println(helloImpl.sayHello()); helloImpl.shutdown(); } catch (Exception e) { System.out.println("ERROR : " + e) ; e.printStackTrace(System.out); }

67 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 67 CORBA - TP 4. Compilons les différents éléments Compilation de linterface IDL idlj -fall Hello.idl Compilation des classes générées suite à la compilation de linterface javac -Xlint *.java HelloApp/*.java 5. Démarrer lORB start orbd -ORBInitialPort Démarrer lobjet serveur start java HelloServer -ORBInitialPort ORBInitialHost localhost 7. Lancer lobjet client java HelloClient -ORBInitialPort ORBInitialHost localhost

68 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 68 Conclusions Solution non propriétaire Standard Libre choix de limplémentation et du langage Solution fonctionnelle dinteropérabilité Plusieurs implémentations libres et open-source Mais.. Mise en œuvre assez complexe..

69 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 69 DCOM

70 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 70 Introduction DCOM est une extension de COM the (Component Object Model) pour supporter la communication entre objets se trouvant sur des sites différents. Les applications peuvent être localisées dans les sites les plus appropriées aux besoins des utilisateurs (distance, interfaces, …).

71 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 71 Le modèle de DCOM COM définit comment les composantes et leurs clients communiquent: le client appelle les méthodes de la composante. COM fournit cette communication de manière transparente. Il intercepte les appels dun client et les achemine vers le composant dans un autre processus. Client Composant Com Run time Com Run time ClientComposant Service Sécurité Service Sécurité DCE RPC DCE RPC LPC

72 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 72 Larchitecture de DCOM Com Run time Com Run time ClientComposant Service Sécurité Service Sécurité DCE RPC DCE RPC Pile de protocoles COM fournit cette communication de manière transparente a travers un réseau si le client et la composante se trouvent sur des machines différentes. Pile de protocoles Réseau

73 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 73 Propriétés de DCOM Réutilisation de composantes: les développeurs DCOM construisent des composantes réutilisables Indépendance vis-à-vis de l emplacement: cache lemplacement dune composante les appels aux composantes se font de la même façon sur une même machine ou a travers un réseau. Interface usager Client Accès BD Validation Traitement COM DCOM

74 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 74 Les interfaces DCOM Les interface de DCOM sont une collection d'appels de fonctions (contrats). Les interfaces sont accessibles grâce a une table virtuelle (vtable) qui permettent de pointer vers les implantations des interfaces. Données internes Fonction d'interface Pointeur vers l'objet Implantations des fonctions

75 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 75 Références d'objets Un objet est identifié par son Interface Identifier (IID) qui est un identificateur global sur 128 bits (GIID). Le IID est utilisé pour référencer l'interface à travers plusieurs fonctions (ex. QueryInterface).

76 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 76 Les objets DCOM Un objet DCOM (ou objet ActiveX) est une composante qui offre plusieurs interfaces. Chaque classe est identifiée par son Class ID (CLSID). Chaque classe DCOM implante une interface commune appelée IUnknown pour contrôler un objet (ex. obtenir la liste des interfaces, …) Objet DCOM Interface A Interface B Interface C IUnknown

77 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 77 Les serveurs DCOM Un serveur est un ensemble d'objets référencés par leur CLSID. Les serveur dispose d'une Class Factory qui crée des objets et retourne leurs pointeurs. Le serveur effectue les tâches suivantes: Implante Class Factory (IClassFactory) pour la création d'instances de classes Enregistre les classes qu'il offre Active une libraire de classes... Objet DCOM Class Factory IClassFactory Interfaces de l'objet

78 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 78 La répartition avec DCOM DCOM supporte la transparence dans les répartitions. Trois types de répartitions de serveurs sont définis dans DCOM: Serveurs dans le même processus que le client: utilisent un DLL. Serveurs locaux: utilisent DCOM lightweight RPC (LRPC) Serveurs distante: utilisent les RCP version DCE

79 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 79 Architecture des applications DCOM Remote Object Proxy In-Process Object In-Process Server DCOM COM Client Stub Objet local COMServeur local Local Object Proxy Stub Objet local COMServeur local Processus serveur local Processus serveur distant Machine distante LRPC RPC Processus client

80 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 80 L'interface IUnknown L'interface IUnknown est utilisée pour la gestion des interfaces lors de l'exécution. Elle possède les fonctions: QueryInterface: négociation d'interfaces. AddRef. Release. Objet IUnknown QueryInteface AddRef Release

81 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 81 Création d'objets Le scénario suivant illustre le mécanisme de création des objets CoGetClassObject CoRegisterClassObject CreateInstanceLic IMyInterface Obtention des services Release CoRevokeClassObject Create ClientAPI de DCOMIClassFactory

82 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 82 Enterprise Java Beans : lessentiel

83 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 83 Objet distribué (rmi)

84 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 84 Middleware Explicite transfer(Account account1, Account account2, long amount) { // 1: Call middleware API to perform a security check // 2: Call middleware API to start a transaction // 3: Call middleware API to load rows from the database // 4: Subtract the balance from one account, add to the other // 5: Call middleware API to store rows In the database // 6: Call middleware API to end the transaction }

85 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 85 Middleware implicite

86 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 86 Architecture 3-tiers

87 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 87 Les Enterprise JavaBeans Spécification dune architecture permettant la création dapplications distribuées Implantations de la spec : WebLogic, Jonas,IBM Websphere, Jboss Composant développé pour être exécuté sur un serveur dEJB Ne pas confondre avec un Java bean

88 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 88 Les Enterprise JavaBeans

89 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 89 Objectifs des EJB Fournir une plate-forme standard pour la construction dapplications distribuées en Java Simplifier lécriture de composants serveurs Portabilité Considérer le développement, le déploiement et lexécution des applications

90 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 90 Division des responsabilités Le fournisseur de bean Produit les composants métier Le fournisseur de conteneur EJB Fournit lenvironnement permettant lexécution des beans Le fournisseur de serveur EJB Fournit lenvironnement dexécution pour un ou plusieurs conteneurs Lassembleur dapplication Le déployeur (installateur) Ladministrateur

91 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 91 Les Enterprise Beans Composants qui peuvent être déployés dans un environnement multi-tiers et distribué. Exposent une interface qui peut être appelé par ses clients Configurés de façon externe Linterface et limplantation du bean doivent être conforme à la spécification EJB Les clients peuvent être Une servlet Une applet Un autre bean

92 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 92 Les Enterprise Beans

93 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 93 Les types de Beans Session Beans : contiennent la logique métier de lapplication Stateful session bean Stateless session bean Message bean : contiennent la logique orientée message Entity Beans : contiennent la logique de gestion des données persistantes Attention! Depuis la spec. Java EE 5 les Entity Beans sont deprecated. Sun préconise lutilisation de lAPI JPA pour le mapping Objet-Relationnel.

94 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 94 Session Bean Fournit un service à un client Durée de vie limitée à celle du client Effectue des calculs ou des accès à une base de donnée Peut être transactionnel Non recouvrable Peuvent être sans état ou conversationnel (stateless ou stateful)

95 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 95 Exemple de Session bean import public class SimpleSessionBean implements SimpleSession { private String message = Je suis un session bean !"; public String getMessage() { return message; }

96 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 96 Linterface Linterface décrit le contrat avec les clients import public interface SimpleSession { public String getMessage(); }

97 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 97 Le descripteur de déploiement Fournit les informations nécessaires au déploiement dans le conteneur et pour la configuration des intercepteurs savecustomer_ear daosessionbeanwebclient.war /daosessionbeanwebclient daosessionbean.jar

98 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 98 Le client import javax.ejb.EJB; public class SessionBeanClient private static SimpleSession simpleSession; private void invokeSessionBeanMethods() { System.out.println(simpleSession.getMessage()); System.out.println("\nSimpleSession is of type: " + simpleSession.getClass().getName()); } public static void main(String[] args) { new SessionBeanClient().invokeSessionBeanMethods(); }

99 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 99 Les entity beans (deprecated) Implantation dobjets métiers persistants (client, compte,…) Persistance gérée par Les conteneurs (CMP) Le bean lui-même (BMP) Le conteneur gère également les transactions et la sécurité pour le composant. Utile pour gérer les accès concurrents à des données persistantes.

100 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 100 Exemple dentity bean (CMP) (deprecated) public class BookEJB implements javax.ejb.EntityBean { public String author; public String titlel; public int price; private EntityContext context; public String getTitle() {return title;} public String getAuthor() {return author;}; public int getPrice() {return price;} public void setPrice(int _price) {price=_price;} public String ejbCreate (String _author, String _title) throws CreateException { author=_author; title=_title; price=0; return null; } … // Méthodes requises par le conteneur public void ejbPostCreate(String _author,String _title) { } public void ejbRemove() { } public void ejbLoad() { } public void ejbStore() {} public void setEntityContext(EntityContext context) { this.context = context;} public void unsetEntityContext() { context=null; } public void ejbActivate() { } public void ejbPassivate() { } }

101 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 101 Home interface (deprecated) public interface BookHome extends EJBHome { public Book create(String id, String url) throws RemoteException, CreateException; public Book findByPrimaryKey (String id) throws RemoteException, FinderException; public Collection findAll() throws RemoteException, FinderException; Public Collection findByAuthor(String author) throws RemoteException, FinderException; }

102 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 102 Interface de lEntity Bean (deprecated) public interface Book extends EJBObject { public String getAuthor() throws RemoteException; public String getTitle() throws RemoteException; public int getPrice() throws RemoteException; public void setPrice(int mode) throws RemoteException; }

103 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 103 Le descripteur de lentity bean Book BookHome Book BookEJB Container java.lang.String False title author price title findByAuthor java.lang.String select distinct object(b) from Book b where b.author=?1

104 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 104 Message Driven Bean Intégration des EJB et de JMS Interactions asynchrones Utilisé pour réagir à des messages JMS Stateless bean Une seule méthode dans linterface onMessage()

105 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 105 Exemple de message bean import javax.ejb.MessageDriven; import javax.jms.JMSException; import javax.jms.Message; import javax.jms.MessageListener; import = "jms/GlassFishBookQueue") public class ExampleMessageDrivenBean implements MessageListener { public void onMessage(Message message) { TextMessage textMessage = (TextMessage) message; try { System.out.print("Received the following message: "); System.out.println(textMessage.getText()); System.out.println(); } catch (JMSException e) { e.printStackTrace(); }

106 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 106 Paquetage dapplication

107 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 107 Déploiement Création dun paquetage contenant Les classes des beans Le fichier de description Les fichiers de configuration spécifique au serveur Dautres librairies Mise en place dans le serveur (outils spécifique ou déploiement à chaud)

108 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 108 Intérêt des EJB Simplicité de lécriture des composants Mais le design est plus complexe Portabilité des composants A lexception des adaptations des serveurs Réutilisation/Composition Il faut quand même programmer Indépendance par rapport aux vendeurs Migration pas toujours évidente dune plate-forme à une autre

109 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 109 Bénéfices dun serveur dEJB Gestion automatisée des stocks de ressources Gestion automatisée du cycles de vie des composants Gestion de la concurrence Scalabilité Fonctionnalités déclaratives Disponibilité et tolérance aux pannes Modèle dobjet distribué

110 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 110 Middlewares Orientés Messages (MOM)

111 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 111 Pourquoi la messagerie? Couplage fort Le client dépend de linterface du serveur Le client doit «connaître» le serveur (Référence) Dépendance temporelle Le client et le serveur doivent être simultanément disponibles Communication synchrone/bloquante (habituellement) Le client est bloqué entre lenvoi de la requête et larrivée de la réponse

112 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 112 Middleware orienté message Les middlewares orientés messages (MOM) proposent une infrastructure permettant léchange de messages dans une architecture répartie.

113 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 113 MOM – Entités de base Le client (utilisateur du MOM) Émission et réception de messages Le fournisseur (ou «provider») support du MOM : routage, stockage des messages Le message (support des données transmises) Type MIME -formats texte, son, image,.. Le récepteur Emetteur Récepteur MOM Message Récepteur

114 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 114 Avantages des MOM Intégration de multiples protocoles et des multiples plateformes Messages définis par les utilisateurs GMD : Guaranteed Message Delivery Equilibrage de charge Tolérance de pannes Support pour plateformes hétérogènes Gestion et configuration sur interfaces graphiques

115 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 115 Les types de MOM Les logiciels de MOM peuvent fonctionner de trois façons différentes Le Point-To-Point (PTP) Le Publish-Subsribe(Pub/Sub) Le Request-Reply(RR)

116 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 116 Le modèle Point-to-Point Chaque message est stocké dans une file («Queue») jusquà ce que le destinataire le lise Chaque message est consommé une seule fois (par un seul destinataire) Pas de dépendance temporelle entre émetteur et destinataire du message

117 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 117 Queues PTP Plusieurs producteurs peuvent placer les messages pour divers destinataires dans une queue Gestionnaire de files(Serveur MOM) Producteur Récepteur Producteur Récepteur Queue de distribution

118 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 118 Le modèle Publish-Subscribe Le sujet («Topic») gère l envoi de messages pour un ensemble de lecteurs abonnés Découplage entre les «publishers» et les «subscribers» Les fournisseurs n ont pas besoins de connaître les consommateurs Dépendance temporelle Un client ne peut lire un message qu après s être abonné à un topic, Un client abonné à un topic doit continuer à être actif pour recevoir les message du topic.

119 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 119 Sujets de Pub/Sub La publication et l'abonnement à un sujet découple le producteur et le consommateur Gestionnaire de sujets (Serveur MOM) Producteur Récepteur Producteur Récepteur

120 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 120 Le modèle Request/Reply Le domaine R/R définit un programme qui envoie un message et attend une réponse immédiatement Ce domaine modélise : l'approche client/serveur l'approche des systèmes distribués EJB CORBA DCOM

121 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 121 MOM – Synthèse Exemples de services de messagerie Websphere MQ par IBM SoniqMQ par Progress WebLogic JMS par Oracle Active MQ par Apache Jusqu à ~2001, peu ou pas defforts de normalisation Une API par vendeur Conceptions différentes (ex. utilisation des ressources) Fonctionnalités différentes Difficultés Limitation de linteropérabilité (critique) Problèmes de maintenance et dévolutivité Évolutions Java Messaging Service (JMS) -une API standard pour le client CORBA COS Notification -une API pour le client, description de linfrastructure (objets et API) Advanced Message Queueing Protocol (AMQP) –un standard ouvert pour linteropérabilité de middlewares à message écrits en différents langages et pour différentes plates-formes

122 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 122 Architecture Orientée Services

123 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 123 Présentation SOA = Services Oriented Architecture Lancée par Gartner Group, elle définit un modèle dinteraction applicative mettant en œuvre des connexions en couplage faible entre divers composants logiciels. Il sagit dune vision dun système destinée à traiter toute application comme un fournisseur de services. Objectif: Décomposition dune fonctionnalité en un ensemble de fonctions basiques, appelées services.

124 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 124 Service Oriented Architecture A chacun sa définition Chaque rôle s'approprie SOA différemment : Un ensemble de services que l'entreprise souhaite exposer à leurs clients et partenaires, ou d'autres parties de l'organisation Un modèle de programmation avec ses standards, paradigmes, outils et technologies associées Un style architectural basé sur un fournisseur, un demandeur et une description de service, et supporte les propriétés de modularité, encapsulation, découplage, réutilisation et composabilité Un intergiciel offrant des fonctionnalités en terme d'assemblage, d'orchestration, de surveillance et de gestion des services DirigeantsAnalystes métier Architectes DéveloppeursIntégrateurs

125 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page Sont les composants de base de l'Architecture Orientée Services. Consistent en une fonction ou fonctionnalité bien définie. Exposent une interface qui définit le traitement offert sous la forme dun message dentrée et dun autre de réponse. Les services

126 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 126 Un service ne peut pas appeler un autre service. Il délègue cette fonction à un traitement spécialisé dans lenchaînement (fonction dorchestration). Un service doit être activable à distance indépendamment de sa technologie. Lactivation se fait par lenvoi (et la réception) dun message XML Lappel au service fonctionne quelque soit le langage et les système dexploitation du consommateur (utilisateur du service) Les services

127 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 127 Un service expose un contrat dutilisation (déclaration des messages dentrée et de réponse du traitement offert, déscription des standards et protocoles techniques utilisés pour lactivation du service). Le service doit exposer une interface dutilisation qui est la même indépendamment de sa localisation sur le réseau. Les services sont connectés aux clients et autres services via des standards. Les services

128 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 128 Un Service expose un Contrat Les services communiquent par messages in out Un Service est autonome et sans état Les Frontières entre services sont explicites Les services Les 4 propriétés principales

129 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 129 SOA et Web services Attention à ne pas confondre les 2 ! SOA est un ensemble de concepts : Une SOA peut se mettre en œuvre sans Web Services Les WS sont de lordre de la technologie : On peut utiliser les Web Services sans faire de SOA Les WS constituent la meilleure solution standardisée disponible Un service métier = un webservice

130 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 130 Implémentation possible des services métiers Cest un traitement délivré par un fournisseur et utilisé par un consommateur Il doit respecter principalement les propriétés suivantes : Couplage faible: un service ne peut pas appeler un autre service. Il délègue cette fonction à un traitement spécialisé dans lenchaînement (fonction dorchestration). Expose un contrat dutilisation Les Web services

131 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 131 Standards de larchitecture (I) La description de service est la manière de décrire les paramètres d'entrée du service, 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. Ensuite la publication consiste à publier dans un registre (en anglais registry ou repository) les services disponibles aux utilisateurs, tandis que la notion de découverte recouvre la possibilité de rechercher un service parmi ceux qui ont été publiés. Le principal standard utilisé est UDDI (Universal Description Discovery and Integration), normalisé par l'OASIS. Enfin l'invocation représente 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).

132 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 132 Standards de larchitecture (II) Les standards sont un élément clé dune SOA, ils assurent linteropé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écrit le contrat BPEL Oasis Business Process Execution Language Les trois piliers des Services Web Décrit les processus métier

133 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 133 SOAP Protocole déchange de messages (client / serveur) Basé entièrement sur XML Standard W3C (Initiative IBM et Microsoft) Concepts Message = Enveloppe ( Header + Body ) Extensibilité Porté sur HTTP, SMTP, …

134 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 134 Structure dun message SOAP Un message SOAP est contenu dans une balise Envelope Une Envelope peut contenir une balise Header Une Header peut contenir nimporte quel ensemble de balises. Ces balises doivent appartenir à des namespaces. Une Envelope doit contenir une balise Body Un Body peut contenir nimporte quelle ensemble de balises. Ces balises peuvent appartenir à des namespaces. Un Body peut contenir des balises Fault qui permettent didentifier des erreurs.

135 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 135 SOAP Header Mécanisme dextension du protocol SOAP La balise Header est optionnelle Si la balise Header est présente, elle doit être le premier fils de la balise Envelope La balise Header contient des entrées Une entrée est nimporte quelle balise incluse dans un namespace

136 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 136 SOAP Header Example 5

137 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 137 SOAP Body Le Body contient le message à échanger La balise Body est obligatoire La balise Body doit être le premier fils de la balise Envelope (ou le deuxième si il existe une balise Header) La balise Body contient des entrées Une entrée est nimporte quelle balise incluse optionnellement dans un namespace Une entrée peut être une Fault.

138 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 138 SOAP Fault La balise Fault, permettant de signaler des cas derreur, contient les balises suivantes : faultcode : un code permettant didentifier le type derreur Client, Server, VersionMismatch, MustUnderstand faultstring : une explication en langage naturel faultactor : une information identifier linitiateur de lerreur detail : Définition précise de lerreur.

139 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 139 Encodage Un message SOAP contient des données typées. Il faut donc définir un moyen dencoder ces données. Vocabulaire SOAP : Value (valeur dune donnée) Simple value (string, integers,etc) Compound value (array, struct, …) Type (dune value) Simple Type Compound Type

140 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 140 Encodage Lencodage cest la représentation de valeurs sous forme XML. Le décodage cest la construction de valeurs à partir dXML LXML qui représente les valeurs a une structure qui dépend du type des valeurs Il faut donc définir le type Soit mécanisme définit par lutilisateur Soit utilisation dXML Schéma (préconisé)

141 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 141 Simple Types Type (XML Schema) Valeurs 45 Blue Type XML Schema Construction de Type XML Schema

142 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 142 Simple Types La définition dun XML Schéma pour tout type peut être fastidieux SOAP a défini deux façons de préciser le type dune valeur sans définir le Schéma XML:

143 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 143 Compound Types Une structure est un type composé dans lequel les membres sont accessibles uniquement grâce à des noms différents. Un tableau est un type composé dans lequel les membres sont accessibles uniquement grâce à leur position.

144 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 144 Struct Type (XML Schéma) Valeur Xavier 30

145 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 145 SOAP avec HTTP SOAP peut être facilement porté sur Http. Convient au mode Request/Response de Http Le message SOAP est mis dans une requête POST avec un content-type text/xml Définition dun header http : SOAPAction Utilisation des codes http (2xx, 4xx, 5xx)

146 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 146 Questions Comparer SOAP par rapport à CORBA ? IDL ? IIOP ? Quel est lintérêt de porter SOAP sur dautres protocoles ?

147 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 147 WSDL Langage de définition de Web Services Basé entièrement sur XML Standard W3C (Initiative IBM et Microsoft) Actuellement WSDL 2.0 Définition de linterface, de lURL et du port du Web Service. Utilise le système de typage de XML Schéma

148 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 148 WSDL Description Une description WSDL : Décrit le type dun service web (méthodes, types des paramètres) Cette description peut être comparée à la description IDL CORBA, elle peut servir à générer automatiquement des amorces. Décrit les aspects techniques dimplantation dun service web (quel est le protocole utilisé, quel est le ladresse du service) Cette description sert à se connecter concrètement à un service web.

149 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 149 WSDL Balises Une description WSDL est un document XML qui commence par la balise definition et contient les balises suivantes : types: cette balise décrit les types utilisés message: cette balise décrit la structure dun message échangé portType: cette balise décrit un ensemble dopérations (interface dun service web) operation: cette balise décrit une opération réalisée par le service web. Une opération reçoit des messages et envois des messages. binding: cette balise décrit le lien entre un protocole (http) et un portType. service: cette balise décrit un service comme un ensemble de ports. port: cette balise décrit un port au travers duquel il est possible daccéder à un ensemble dopérations. Un port référence un Binding

150 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 150 WSDL Balises

151 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 151 types Description en utilisant XML Schema.

152 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 152 message Les messages sont envoyés entre deux interlocuteurs (ex: une opération reçoit des message et envoie des messages. Un message est composé de plusieurs parts Deux façons de définir des parts Soit une part est un élément de type simple Soit une part est un élément XML dont le type est défini dans un XML Schema

153 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 153 message Part de type simple Part qui utilise un XML Schema Défini dans un Schema XML

154 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 154 portType Un portType permet didentifier (nommer) de manière abstraite un ensemble dopérations. … …

155 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 155 operation WSDL définit 4 types dopération : One-Way : lorsque les opérations reçoivent des messages mais nen nenvoient pas Request-response : lorsque les opérations reçoivent des messages puis renvoient des messages Solicit-response : lorsque les opérations envoient des messages puis en reçoivent Notification : lorsque les opérations envoient des messages mais nen reçoivent pas

156 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 156 operation Quelque soit le type dopération la définition est sensiblement la même. Une opération : Reçoit des messages : Envoie des messages : ou La présence et lordre des input/outputs/fault dépendent du type de lopération.

157 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 157 operation * *

158 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 158 binding WSDL permet de lier une description abstraite (portType) à un protocole. Chacune des opérations dun portType pourra être liée de manière différente. Le protocole SOAP est un des protocole qui peut être utilisé. Dautres binding sont standardisés par WSDL : HTTP et MIME.

159 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 159 binding Un Binding : peut être identifié par un nom : name identifie le portType : type

160 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 160 binding SOAP Pour préciser que le binding est de type SOAP, il faut inclure la balise suivante : Transport définit le type de transport pour utiliser SOAP/HTTP Style définit la façon dont sont créer les messages SOAP de toutes les opérations rpc : Encodage RPC défini par SOAP RPC document : Encodage sous forme délément XML

161 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 161 binding SOAP Pour chaque opération du portType : il faut préciser lURI de lopération : soapAction Il est aussi possible de repréciser la façon dont sont créés les messages SOAP : style Pour chaque message de chaque opération, il faut définir comment sera créé le message SOAP

162 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 162 Exemple

163 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 163 service Un service est un ensemble de ports Un port a un portType Dans le cadre de SOAP, un port à une adresse (qui correspond à ladresse http)

164 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 164 Questions A quoi sert le WSDL ? Comparer WSDL à IDL ? Et comparer cette approche avec CORBA ? Expliquer les dépendances entre SOAP et WSDL ? Comment se fait le mapping avec un langage de programmation ?

165 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 165 UDDI Référentiel de définitions Web Service Permet de construire dynamiquement des clients Recommandation OASIS Référentiel défini lui-même en WSDL Référentiel Public / Privé

166 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 166 Rôles Un référentiel UDDI joue 3 rôles : Pages blanches : le référentiel comporte des informations sur les fournisseurs de services. Pages Jaunes : le référentiel comporte des critères de catégorisation de services. Pages vertes : le référentiel comporte des informations techniques (WSDL).

167 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 167 Exemple Le référentiel UDDI de microsoft est accessible à Il est possible de parcourir ce référentiel à laide dun navigateur pour : Rechercher un service. Ajouter un service au référentiel.

168 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 168 Façons de rechercher un service. Nous allons rechercher les Web Services de la société Amazon. Exemple de recherche de Web services

169 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 169 Exemple de recherche de Web services AmazonBusiness propose un Web Service Ce Web Service sappelle GetBookPrice

170 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 170 Référentiels Type Public : Microsoft : uddi.microsoft.com IBM : HP : uddi.hp.com SAP : udditest.sap.com Privé ou dentreprise Accès Défini en WSDL JAXR définit une API pour naviguer dans un référentiel UDDI

171 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 171 Questions Quel est la place dUDDI dans les Web Services ? Comparer les référentiels UDDI avec les moteurs de recherche style Yahoo et Google ? Quel est lintérêt des référentiels UDDI dentreprise ?

172 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 172 BPEL le chef dorchestre

173 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 173 Le langage BPEL BPEL = Business Process Execution Language Standard de lOASIS Norme permettant de décrire des processus en XML Propose les fonctions basiques dun langage de programmation: sequence, flow, loop, switch… Identification des instances de Process Gestion des transactions longue durée (scope, compensation) Gestion des exceptions

174 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 174 ESB : couche de médiation ESB = Enterprise Service Bus Cest le point dentrée vers un service => invocation indirecte du service au travers du bus Ce point dentrée doit être normalisé mais on ne sait pas qui fournit le service et comment il le fournit (implémentation). Infrastructure qui optimise les échanges entre consommateurs et fournisseurs de services. Il peut prendre en charge : Routage transformation des données transactions, sécurité, qualité de service, … Le but dun ESB est de permettre de communiquer de manière simple et standardisée entre des applications hétérogènes

175 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 175 Quelques manières dimplémenter un ESB Intergiciels de type MOM (Message Oriented Middleware) Intergiciels de type Bus (CORBA par exemple) Intergiciels de type EAI (Message Broker avec connecteurs propriétaires liés au moteur dintégration) Routeurs Web services tel que WebSphere Web Services Gateway Selon le type dimplémentation retenu, lESB assurera plus ou moins de services : le choix dépend des besoins LESB nest pas obligatoire : mais il est fortement recommandé pour éviter le couplage entre fournisseur et consommateur

176 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 176 Exemples darchitecture techniques Avec vs Sans ESB Avec ESB Sans ESB Plusieurs connecteurs Orchestration importante Transactions conséquentes Communications initiées par les applications seront donc homogènes Pas dorchestration, parce que pas dintermédiaire: invocations de services directement pilotées par le code Peu de transactions, ou alors les gérer à la main

177 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 177 Moteurs dexécution de processus Plate-forme dintégration IBM Websphere Process Server BEA Weblogic Integrator/Aqualogic Microsoft Biztalk Oracle BPEL PM SAP Netweaver Apache ODE ESB IBM Websphere ESB Celtix hosted on ObjectWeb/IONA Technologies OpenESB (java.net) Mule (codehaus.org) Sonic ESB

178 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 178 Exemple: Gamme d'outils IBM couvrant le cycle de vie complet WebSphere Process Server WebSphere ESB WebSphere Business Modeler WebSphere Integration Developer Rational Software Architect WebSphere Business Monitor WSDLBPEL KPIs WebSphere Service Repository & Registry WebSphere Business Services Fabric Service Specification Service Development Service execution & Management Business Analyst Integration Developer Rational Application Developer DeveloperService Architect Service RegistrarGovernance Manager Performance Manager Server Administrator

179 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 179 Avantages et inconvénients Architecture adaptative Réutilisation du code Utilisation de standards Productivité accrue Manque de maturité des standards Lenteur dexécution Difficile à effectivement implémenter Encore peu de chose sur la contractualisation

180 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 180 Paradoxe des principes fondamentaux Utilisation de standards Mais un standard reste un standard tant que tout le monde lutilise (cf CORBA) La course à la spécification fait rage Désaccords multiples entre le W3C et lOASIS sur : Les specs des processus Les specs sur la sécurité … Pas de remise en cause de lexistant lors dévolutions technologiques Mais dépendance relative vis-à-vis de léditeur retenu. Découplage entre fournisseurs et consommateurs de services Mais certains composants de services sappellent directement au niveau du code Couplage fort entre fournisseurs et consommateurs, réintroduit par la couche IT.

181 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 181 Bases de données & Persistance

182 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 182 Modélisation du réel Réel Modèle conceptuel Indépendant du modèle de données Indépendant du SGBD Modèle logique Dépendant du modèle de données Indépendant du SGBD RelationnelObjetXML Modèle Physique Dépendant du modèle de données Dépendant du SGBD Organisation physique des données Structures de stockage des données Structures accélératrices (index) Médecin effectue Visite

183 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 183 Le modèle relationnel Inventé par E.F. CODD en 1970 (IBM) Fondement mathématique Basé sur les relation n-aire. Algèbre relationnel Langage dinterrogation simple déclaratif SQL Organisation des données en Tables (relations): des lignes (enregistrements ou n-uplets) des colonnes (champs ou attributs)

184 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 184 Modélisation Relationnelle (1) Champs, attributs, colonnes Id-DNomPrénom 1DupontPierre 2DurandPaul 3MasseJean ….……..…… Relation ou table Tuples, lignes ou n-uplets

185 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 185 Modélisation Relationnelle (2) Docteurs Id-DNomPrénom 1DupontPierre 2DurandPaul 3MasseJean ….……..…… Visites Id-DId-PId-VDatePrix juin août juillet mars250 Patients Id-PNomPrénomVille 1LebeauJacquesParis 2TrogerZoeEvry 3DoeJohnParis 4PerryPauleValenton ….……. Prescriptions Id-VLigneId-MPosologie par jour gouttes 2182 par jour par jour 2332 gouttes …. ………… Médicaments Id-MNomDescription 1Aspegic 1000…………………………….. 2Fluisédal…………………………….. 3Mucomyst…………………………….. ….……..……………………………..

186 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 186 Intégrité et clés Propriétés dintégrité générale clés uniques clés candidates et clés primaires clés étrangères Clé unique Un ensemble de colonnes de la table est dite clé unique si deux lignes de la table ne peuvent pas avoir les mêmes valeurs. Identifie de manière unique une ligne de la table Une clé composée est un ensemble contenant plusieurs colonnes

187 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 187 Clé primaire Parmi les clés candidates, il y en a une qui est choisie comme la clé primaire. La clé primaire est utilisée pour faire référence aux lignes dune table. Clé étrangère Une clé étrangère est un ensemble dune ou de plusieurs colonnes dune table qui fait référence à une clé primaire dune autre table. Clés primaire et étrangère

188 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 188 Le langage SQL SQL: Structured Query Language Contient trois parties: DDL: Data Definition language Créer des tables, index, view,… Modifier leurs structures DML:Data Manipulation Language: Interroger la base de données Modifier les tables de la BD DCL :Data Control language Définir les règles d'accès a la BD

189 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 189 Les types de données Les types de données de base sont: integer32 bits smallint16 bits decimal(m,n)décimal en virgule fixe float32 bits char(n), varchar(n)chaîne de longueur (max) n dateaa/mm/jj timehh:mm:ss.ss Les commandes SQL les plus utilisées: create table, create view, create index,... select, update, insert, delete, commit, abort,..

190 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 190 La commande create table create table (, …) [as ]; create table Etudiant (NumE char(12), Nom Varcahr(30), Telephone char (10), Age smallint, moyenne decimal(2,2) ); create table EtudiantForts (NumE, Moyenne) as (select NumE, Moyenne from Etudiants where moyenne > 3.5 );

191 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 191 La commande select select from where select * from etudiant ; select * from etudiants where Nom="Alain"; select Nom, NumC, Titre from etudiant, suit where Etudiant.NumE=Suit.NumE; select Nom, NumC, Titre from etudiant e, suit s where e.NumE= s.NumE; select * from Etudiant where Age 3;

192 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 192 Les sous-requêtes select from where ; select NumC from Suit where NumE in (select NnumE from etudiant where age<21); select NumE from Suit where Age >= all ( select NnumE from etudiant); select NumC from Cours un where exists (select * from suit where NumC=un.NumC)

193 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 193 La commande insert insert into (A1, A2, …) values (v1, v2,…) insert into etudiants values ('12345', 'Robert', ' '); insert into cours (NumC) (select from Suit where NumE='12345');

194 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 194 La commande delete Delete from where delete from cours where Numc='INF-2344'; delete from Suit where NumC not in (select NumC from Cours);

195 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 195 La commande update update set where update Etudiant set Telephone=' ' where NumE='1234'; update Etudiant set NbrCours=NbrCours where NumE in (select NumE form Suit);

196 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 196 Les vues Une façon de limiter l'accès aux tables d'une BD. Create view as (select ….) create BonsEtudiants as (select * from Etudiant where Moyenne > 3.5); create NomCours (NumE, NOM, Cours) as (select e.NumE, e.Nom, c.NomC from Etudiant e, Suit s, Cours c where e.NumE=s.NumE and s.NumC=c.NumC)

197 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 197 Les transactions en SQL Une transaction est une séquence d'instruction a exécuter selon le mode du tout ou rien. commit: rend définitives l'effet d'un transaction rollback: défait une transaction

198 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 198 ESQL Le langage SQL ne permet pas de créer des applications autonomes écrites exclusivement en SQL. Il faut passer par un langage de programmation (C, C++, Java,…). Cest possible grâce à des instruction ESQL (Embedded SQL) qui sont imbriquées dans le langage hôte (C, C++, Java,…). Avantages: Prétraitement de la partie statique des requêtes Plus facile à utiliser. Inconvénients: Besoin du pré-processeur Doit être connecté à une BD

199 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 199 Structure dun programme Inclure le support SQL (SQLCA, SQLDA) Déclarations Connexion à la BD Traitement Traitement des erreurs Commit/Abort et Déconnexion main(int argc, char **argv) { };

200 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 200 Les SGBD et lunivers Java ODBC driver JDBC-ODBC bridge driver JDBC driver pour Oracle JDBC-Net driver JDBC driver pour Sybase JDBC DriverManager Java Oracle API JDBC API Driver JDBC Protocole Y Protocole X Protocole Z Sybase OracleSybase

201 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 201 La couche JDBC JDBC Java DataBase Connectivity. L API Fournit un ensemble de classes et d interfaces permettant lutilisation sur le réseau dun ou plusieurs SGBD à partir dun programme Java. Les tâches assurées par JDBC sont: Gestion des connexions et transactions Préparation de requêtes SQL Accès aisé aux résultats

202 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 202 Un modèle à 2 couches La couche externe : API JDBC C est la couche visible et utile pour développer des applications Java accédant à des SGBD représentée par le package java.sql Les couches inférieures : Destinées à faciliter l implémentation de drivers pour des bases de données Représentent une interface entre les accès de bas niveau au moteur du SGBD et la partie applicative

203 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 203 Modèles de connexion en Java Modèle 2-tiers : 2 entités interviennent 1. une application Java ou une applet 2. le SGBD Modèle 3-tiers : 3 entités interviennent 1. une application Java ou une applet 2. un serveur middleware installé sur le réseau 3. le SGBD

204 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 204 Modele 2-tiers Principe : l application (ou l applet) cliente utilise JDBC pour parler directement avec le SGBD qui gère la base de données Avantages : simple à mettre en œuvre bon choix pour des applications clientes peu évoluées, à livrer rapidement et n exigeant que peu de maintenance Inconvénients : dépendance forte entre le client et la structure du SGBD modification du client si l environnement serveur change tendance à avoir des clients « graisseux » tout le traitement est du côté client

205 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 205 Architecture 2-tiers Application ou Applet JDBCJDBC Client BD Serveur SGBD

206 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 206 Modele 3-tiers Principes : le serveur middleware est l interlocuteur direct du code Java client; c est lui qui échange des données avec le SGBD pas forcément écrit en Java si c est le cas : utilise souvent JDBC pour accéder au SGBD Avantages: le middleware peut ajouter un niveau de sécurité plusieurs supports pour les échanges avec le client : sockets, RMI, CORBA, Agents mobiles… applets : le SGBD peut se trouver sur une autre machine : mais serveur Web et middleware au même endroit facilite l utilisation de clients « légers »

207 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 207 Architecture 3-tiers Application ou Applet Client BD Serveur TCP / RMI / CORBA / Agent Middleware JDBC SGBD

208 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 208 Scénario d utilisation #1 Java appli JDBC Appli. Driver (I ou II) JDBC DriverManager BD SGDBR BD Server Client Intranet Architecture 2-tiers et application

209 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 209 Java applet JDBC Applet Driver (III ou IV) JDBC DriverManager BD SGDBR Server Client Intranet Internet Web server Architecture 2-tiers et applet Scénario d utilisation #2

210 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 210 Java applet / application BD SGDBR Application Server Client Intranet/ Internet Web server Architecture 3-tiers JDBC Appli. Driver JDBC DriverManager BD SGDBR Database Server Middleware server Intranet Scénario d utilisation #3

211 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 211 Les pilotes JDBC Il existe 4 types de pilote:

212 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 212 Driver de type I (pont vers ODBC) Le driver accède à un SGBD en passant par les drivers ODBC (standard Microsoft) via un pont JDBC-ODBC : les appels JDBC sont traduits en appels ODBC presque tous les SGBD sont accessibles (monde Windows) nécessite l emploi d une librairie native (code C) ne peut être utilisé par des applets (sécurité) est fourni par SUN avec le JDK 1.1 sun.jdbc.odbc.JdbcOdbcDriver

213 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 213 ODBC de Microsoft Open DataBase Connectivity permet d accéder à la plupart des SGBD dans le monde Windows définit un format de communication standard entre les clients Windows et les serveurs de bases de données est devenu un standard de fait du monde Windows tous les constructeurs de SGBD fournissent un driver ODBC

214 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 214 Driver de type II (Native-API) Driver d API natif : fait appel à des fonctions natives (non Java) de l API du SGBD gère des appels C/C++ directement avec la base fourni par les éditeurs de SGBD et généralement payant (question de performance) ne convient pas aux applets (sécurité) interdiction de charger du code natif dans la mémoire vive de la plate-forme d exécution

215 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 215 Driver de type III (Net-protocol) Pilote « tout Java » ou « 100% Java » interagit avec une API réseau générique et communique avec une application intermédiaire (middleware) sur le serveur le middleware accède par un moyen quelconque (par exple JDBC si écrit en Java) aux différents SGBD portable car entièrement écrit en Java pour applets et applications

216 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 216 Driver de type IV (Native-protocol) Driver « 100% Java » mais utilisant le protocole réseau du SGBDR interagit avec la base de données via des sockets généralement fourni par léditeur aucun problème d exécution pour une applet si le SGBDR est installé au même endroit que le serveur Web sécurité pour l utilisation des sockets : une applet ne peut ouvrir une connexion que sur la machine ou elle est hébergée

217 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 217 Types de drivers et applets Une application Java peut travailler avec tous les types de drivers Pour une applet : type I ou II : impossible une applet ne peut pas charger à distance du code natif (non Java) sur son poste d exécution type III : possible si le serveur middleware se situe au même endroit que le serveur Web (car communication par sockets avec l applet) type IV : possible si le SGBDR installé au même endroit que le serveur Web

218 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 218 Etapes dutilisation de JDBC 1. Création dune instance de pilote JDBC 2. Définition de lURL de connexion 3. Création dune connexion vers un SGBDR avec linstance du pilote 4. Création dune ou +eurs instructions 5. Exécution de la requête. 6. Récupération et traitement des lignes du jeu de résultat 7. Fermeture du jeu de résultat 8. Fermeture et Déconnexion de la BD

219 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 219 Enregistrer le driver JDBC Méthode forName() de la classe Class : Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Class.forName("oracle.jdbc.driver.OracleDriver"); quand une classe Driver est chargée, elle doit créer une instance d elle même et s enregistrer auprès du DriverManager certains compilateurs refusent cette notation et demande plutôt : Class.forName("driver_name").newInstance();

220 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 220 URL de connexion Accès à la base via un URL de la forme : jdbc: : ;param=valeur,... qui spécifie : l utilisation de JDBC le driver ou le type de SGBDR l identification de la base locale ou distante avec des paramètres de configuration éventuels nom utilisateur, mot de passe,... Exemples : String url = "jdbc:odbc:maBase" ; String url = " ";

221 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 221 Connexion à la base Méthode getConnexion() de DriverManager 3 arguments : l URL de la base de données le nom de l utilisateur de la base son mot de passe Connection connect = DriverManager.getConnection(url,user,password); le DriverManager essaye tous les drivers qui se sont enregistrés (chargement en mémoire avec Class.forName ()) jusqu à ce quil trouve un driver qui peut se connecter à la base

222 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 222 Création d un Statement L objet Statement possède les méthodes nécessaires pour réaliser les requêtes sur la base associée à la connexion dont il dépend 3 types de Statement : Statement : requêtes statiques simples PreparedStatement : requêtes dynamiques pré-compilées (avec paramètres d entrée/sortie) CallableStatement : procédures stockées A partir de l objet Connexion, on récupère le Statement associé : Statement req1 = connexion.createStatement(); PreparedStatement req2 = connexion.prepareStatement(str); CallableStatement req3 = connexion.prepareCall(str);

223 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 223 Exécution d une requête (1/3) 3 types d exécution : executeQuery() : pour les requêtes (SELECT) qui retournent un ResultSet (tuples résultants) executeUpdate() : pour les requêtes (INSERT, UPDATE, DELETE, CREATE TABLE, DROP TABLE) qui retournent un entier (nombre de tuples traités) execute() : pour requêtes inconnus. Renvoie true si la requête a donné lieu à la creation d un objet ResultSet

224 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 224 Exécution d une requête (2/3) executeQuery() et executeUpdate() de la classe Statement prennent comme argument une chaîne ( String ) indiquant la requête SQL à exécuter : Statement st = connexion.createStatement(); ResultSet rs = st.executeQuery( "SELECT nom, prenom FROM clients " + "WHERE nom='itey ORDER BY nom"); int nb = st.executeUpdate( "INSERT INTO dept(DEPT) " + "VALUES(06)");

225 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 225 Exécution d une requête (3/3) 2 remarques : le code SQL n est pas interprété par Java. c est le pilote associé à la connexion (et au final par le moteur de la base de données) qui interprète la requête SQL si une requête ne peut s exécuter ou quune erreur de syntaxe SQL a été détectée, l exception SQLException est levée le driver JDBC effectue d abord un accès à la base pour découvrir les types des colonnes impliquées dans la requête puis un 2ème pour l exécuter..

226 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 226 Traiter les données retournées L objet ResulSet (retourné par l exécution de executeQuery() ) permet d accéder aux champs des tuples sélectionnés Seules les données demandées sont transférées en mémoire par le driver JDBC Il faut donc les lire "manuellement" et les stocker dans des variables pour un usage ultérieur

227 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 227 Types de données JDBC Le driver JDBC traduit le type JDBC retourné par le SGBD en un type Java correspondant Le XXX de getXXX() est le nom du type Java correspondant au type JDBC attendu chaque driver a des correspondances entre les types SQL du SGBD et les types JDBC Le programmeur est responsable du choix de ces méthodes SQLException générée si mauvais choix

228 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 228 Cas des valeurs nulles Pour repérer les valeurs NULL de la base : utiliser la méthode wasNull() de ResultSet renvoie true si l on vient de lire un NULL, false sinon les méthodes getXXX() de ResultSet convertissent une valeur NULL SQL en une valeur acceptable par le type d objet demandé : les méthodes retournant un objet ( getString(), getObject() et getDate() ) retournent un " null " Java les méthodes numériques ( getByte(), getInt(), etc) retournent " 0 " getBoolean() retourne " false "

229 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 229 Correspondance des types Java / SQL SQLJava CHARString VARCHARString LONGVARCHARString NUMERICjava.math.BigDecimal DECIMALjava.math.BigDecimal BITboolean TINYINTbyte SMALLINTshort INTEGERint BIGINTlong REALfloat FLOATdouble DOUBLEdouble BINARYbyte[] VARBINARYbyte[] LONGVARBINARYbyte[]

230 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 230 Le résultat : ResultSet Il se parcourt itérativement ligne par ligne par la méthode next() retourne false si dernier tuple lu, true sinon chaque appel fait avancer le curseur sur le tuple suivant initialement, le curseur est positionné avant le premier tuple exécuter next() au moins une fois pour avoir le premier while(rs.next()) {// Traitement de chaque tuple} impossible de revenir au tuple précédent ou de parcourir l ensemble dans un ordre aléatoire dans API 1.1

231 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 231 Le résultat : ResultSet Les colonnes sont référencées par leur numéro ou par leur nom L accès aux valeurs des colonnes se fait par les méthodes de la forme getXXX() lecture du type de données XXX dans chaque colonne du tuple courant int val = rs.getInt(3) ; // accès à la 3e colonne String prod = rs.getString("PRODUIT") ;

232 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 232 Le résultat : ResultSet Statement st = connection.createStatement(); ResultSet rs = st.executeQuery( "SELECT a, b, c, FROM Table1 » ); while(rs.next()) { int i = rs.getInt("a"); String s = rs.getString("b"); byte[] b = rs.getBytes("c"); }

233 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 233 Déplacement dans un ResultSet rs.first(); rs.beforeFirst(); rs.next(); rs.previous(); rs.afterLast(); rs.absolute( n ); rs.relative( n );

234 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 234 Insertion de lignes rs.moveToInsertRow(); rs.updateString("Nom", Ben Salah"); rs.updateInt("Age", 24); rs.insertRow(); rs.first();

235 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 235 Insertion de lignes Exemple Statement st = conn.createStatement(); int nb = st.executeUpdate( "INSERT INTO personne(Nom,Age) " + "VALUES ('" + nom + "', " + age + ") ); System.out.println(nb + " ligne(s) insérée(s)"); st.close(); Ce principe est aussi utilisable pour les instructions UPDATE et DELETE.

236 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 236 Modification d'un « ResultSet » Modification rs.updateString("Nom", Augustin"); rs.updateInt("Age", 24); rs.updateRow(); Destruction: rs.deleteRow();

237 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 237 Fermer les différents espaces Pour terminer proprement un traitement, il faut fermer les différents espaces ouverts sinon le garbage collector s en occupera mais moins efficace Chaque objet possède une méthode close() : resultset.close(); statement.close(); connection.close();

238 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 238 Requêtes pré-compilées L objet PreparedStatement envoie une requête sans paramètres à la base de données pour pré-compilation et spécifiera le moment voulu la valeur des paramètres plus rapide qu un Statement classique le SGBD analyse quune seule fois la requête (recherche d une stratégie d exécution adéquate) pour de nombreuses exécutions d une même requête SQL avec des paramètres variables

239 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 239 Création d une requête pré-compilée La méthode prepareStatement() de l objet Connection crée un PreparedStatement : PreparedStatement ps = c.prepareStatement("SELECT * FROM ? " + "WHERE id = ? "); les arguments dynamiques sont spécifiés par un " ? " ils sont ensuite positionnés par les méthodes setInt(), setString(), setDate(), … de PreparedStatement setNull() positionne le paramètre à NULL (SQL) ces méthodes nécessitent 2 arguments : le premier (int) indique le numéro relatif de l argument dans la requête le second indique la valeur à positionner

240 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 240 Exécution dune requête pré-compilée PreparedStatement ps = c.prepareStatement( "UPDATE emp SET sal = ? WHERE name = ?"); int count; for(int i = 0; i < 10; i++) { ps.setFloat(1, salary[i]); ps.setString(2, name[i]); count = ps.executeUpdate(); }

241 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 241 Validation de transaction : Commit Utiliser pour valider tout un groupe de transactions à la fois Par défaut : mode auto-commit un "commit " est effectué automatiquement après chaque ordre SQL Pour repasser en mode manuel : connection.setAutoCommit(false); L application doit alors envoyer à la base un "commit" pour rendre permanent tous les changements occasionnés par la transaction : connection.commit();

242 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 242 Annulation de transaction : Rollback De même, pour annuler une transaction (ensemble de requêtes SQL), l application peut envoyer à la base un "rollback" par : connection.rollback(); restauration de létat de la base après le dernier "commit"

243 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 243 Exceptions SQLException est levée dès qu une connexion ou un ordre SQL ne se passe pas correctement la méthode getMessage() donne le message en clair de l erreur renvoie aussi des informations spécifiques au gestionnaire de la base comme : SQLState code d erreur fabricant SQLWarning : avertissements SQL

244 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 244 La persistance des objet La persistance dobjets désigne le fait que des objets individuels peuvent survivre au processus de lapplication. Ils peuvent être enregistrés dans un entrepôt de données et récupérés par la suite. Le mappage Objet/Relationnel (ORM) désigne la persistance automatisée et transparente dobjets dans une application Java vers les tables dune base de données relationnelle à laide des méta données décrivant le mapping entre les objets et la base de données.

245 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 245 Stratégies de persistance JDBC Framework de persistance du type Hibernate/JDO/Castor EJB Entity Avec persistance CMP Avec persistance BMP EJB Session avec JDBC JPA

246 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 246 Gestion de la correspondance objet/relationnel 30% du code java est consacré à gérer la mise en rapport SQL/JDBC et la non correspondance entre le modèle objet et le modèle relationnel Gestion des associations Correspondances de types Granularité Les outils et frameworks ORM réduisent grandement le code qui permet cette correspondance et facilitent donc les adaptations mutuelles des deux modèles.

247 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 247 ORM (Object Relationnel Mapping) Cest une technique de mapping dune représentation des données dun modèle objet vers un modèle relationnel de base de données et inversement. Quatre éléments constituant une solution ORM : 1. Une API pour effectuer les opérations CRUD (Create, Read, Update, delete) de base sur les objets des classes persistantes. 2. Un langage ou une API pour spécifier des requêtes qui se réfèrent aux classes et aux propriétés des classes. 3. Un système pour spécifier des métadonnées de mapping. 4. Une technique pour limplémentation du mapping objet/relationnel permettant dinteragir avec des objets transactionnels pour effectuer des vérifications brutes, rechercher des associations lâches et implémenter dautres fonctions doptimisation.

248 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 248 ORM (Object Relationnel Mapping) Productivité Réduction sensiblement le temps de développement. Maintenabilité Utilisation dun tampon entre les deux modèles pour isoler les modifications mineurs de chaque modèle. Performance Utilisation dun grand nombre doptimisation.

249 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 249 Exemple : Couche daccès aux données Il existe différentes possibilités pour implémenter la couche accès aux données. Le développeur peut diviser en tiers dotés de fonctionnalités spécifiques La couche [JDBC] est la couche standard utilisée en Java pour accéder à des bases de données. Elle isole la couche [dao] du SGBD qui gère la base de données. On peut théoriquement changer de SGBD sans changer le code de la couche [dao]. Couche Interface Couche Métier Couche daccès aux données (DAO) Couche JDBC Base de données

250 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 250 Couche Hibernate Objets image de la BD Couche daccès aux données (DAO) Couche JDBC Pour isoler la couche [dao] des aspects propriétaires des SGBD. Une solution est celle du Framework Hibernate ou (JPA, TopLink dans JEE) La couche [Hibernate] vient se placer entre la couche [dao] écrite par le développeur et la couche [Jdbc] Hibernate est un ORM (Object Relational Mapping), un outil qui fait le pont entre le modèle relationnel des bases de données et celui des objets manipulés par Java. Le développeur ne voit plus la couche [Jdbc] ni les tables de la BD. Il ne voit que l'image objet de BD, fournie par la couche [Hibernate]. Le pont entre les tables de la BD et les objets manipulés par la couche [dao] est fait principalement de deux façons : par des fichiers de configuration de type XML par des annotations Java dans le code, technique disponible depuis le JDK 1.5 Base de données Solution ORM: Hibernate

251 EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011| Page 251 Références Je ne donne ici que les références que jestime les plus claires, les plus pédagogiques ou alors incontournables. Cest donc en quelque sorte un best of. CORBA / DCOM : Un exemple pédagogique permettant de bien comprendre les interactions entre les différentes coouches de CORBA : Lun des meilleurs sites de tutoriels CORBA (en français) : Une FAQ très succincte et claire sur DCOM EJB : La référence Java EE 5 Development using Glassfish application server, de David Heffelfinger (PACKT Publishing) : Très bon livre, clair et très orienté cas pratiques. J2EE best practices, de Darren Broemmer, (Wiley) : un classique. MOM : Un condensé signé Ada Diaconescu, précis, bien présenté, agréable à parcourir. SOA : Lessentiel de ce quil faut savoir sur les SOA. Persistance


Télécharger ppt "Jacques Augustin Nov- Jan 2012 Cours dArchitecture des Systèmes d'Information EFREI."

Présentations similaires


Annonces Google