View
52
Download
5
Category
Preview:
DESCRIPTION
Jacques Augustin Nov- Jan 2012. Cours d’Architecture des Systèmes d'Information EFREI. Sommaire. Introduction Rôle de l’architecte de systèmes d’information Architecture et intégration de systèmes Cartographie du SI Considérations stratégiques Conception et modélisation Middlewares - PowerPoint PPT Presentation
Citation preview
Jacques Augustin Nov- Jan 2012
Cours d’Architecture des Systèmes d'InformationEFREI
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 2
Sommaire Introduction
Rôle de l’architecte de systèmes d’information 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 l’outil Hibernate Interaction avec les systèmes de gestion de bases de données Problématique particulière des migrations de données
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 3
Introduction
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 d’architecture de systèmes d’information.
► 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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 5
Introduction
► Architecture de systèmes d’information
► 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 d’un architecte
► Concevoir les différentes briques du système d’information et s’assurer de leur interopérabilité. Il veille aussi à l’évolution de ces briques.
► Il doit s’assurer d’une bonne orchestration de ces briques en termes de qualité, performance, de flexibilité et de sécurité.
► Positionnement stratégique par rapport au fonctionnement de l’entreprise.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 6
Introduction
► Architecture et intégration de systèmes
► L’intégration de systèmes est avant tout une démarche logicielle.
► L’architecte va plus loin que l’intégrateur en intégrant des paramètres d’urbanisation, des règles d’entreprise, des contraintes d’harmonisation et de sécurité.
► Les compétences de l’architecte 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 l’entreprise.
► 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 d’information.
► Il a une connaissance rigoureuse et exacte de la cartographie du système d’information.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 7
Introduction► Cartographie du SI
► Diagramme illustrant toutes les briques d’un système d’information.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 8
Introduction
► Considérations stratégiques
L’architecte 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 l’existant?
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 9
Conception et modélisation
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 l’emploi 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.
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.
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 s’applique à 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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 13
Exemple de pattern
► Patterns : exemple
► Le pattern SingletonCe 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émentationL’instance unique est conservée comme membre de classe (protégé pour permettre l’hé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 d’entrée est une méthode publique statique (ne nécessitant heureusement la création préalable d’aucune instance de singleton).
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 14
Exercice
► SingletonUn 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();
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.
► D’une 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 d’une 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.
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.
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 d’information relative à la façon d’afficher les informations qu’il contient. Le modèle est donc indépendant de la représentation des données et est facilement portable d’un 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)
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, c’est-à-dire ce que l'utilisateur voit. Elle constitue en fait le dispositif d’introduction des données dans le système. Les événements (clics de souris, sélection dans un menu, …) déclenchés par l’utilisateur 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
correspondantEn 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.
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).
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 d’associer plusieurs représentations visuelles pour un même modèle (vues de plusieurs faces d’un 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, … – d’un 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).
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 s’il 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.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 22
C.O.R.B.A.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 23
CORBA - Principe simplifié
Middleware
Objet
Client Serveur
Objet
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
http://www.omg.org
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.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 26
PC Sparc
NT
PC
UNIX UNIX
Le bus CORBA
Le bus CORBA = ORB
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 27
La vue réelle du bus CORBA
PC Sparc
NT
PC
UNIX UNIX
ORBPC/NT
ORBPC/UNIX
ORBSparc/UNIX
Réseau TCP/IP
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 28
Architecture de CORBA
IDL
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.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 30
30
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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 31
31
Objet CORBA
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();
};
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.
descriptionIDL
Génération de l'amorce cliente souche
Génération de l'amorce serveur squelette
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 34
Intervention des amorces C.O.R.B.A.
PC Sparc
NT
PC
UNIX UNIX
ORB JavaPC/NT
ORBPC/UNIX
ORB C++Sparc/UNIX
Protocole IIOP
Souche Java
Client Java
Squelette C++
Objet C++
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 d’entrée de
l’invocation Décode les paramètres de sortie et le résultat
► Souche statique Une par type d’objet serveur à invoquer Identique aux talons clients RPC Générée à la compilation à partir de l’interface IDL
► Souche dynamique Souche générique construisant dynamiquement tout type de
requêtes Permet d’invoquer des objets serveurs que l’on découvre à
l’exécution (i.e. dont on ne connaît pas l’interface à la compilation : Référentiel d’interfaces)
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 d’entrée des invocations prépare les paramètres de sortie et le résultat
► Squelette statique un par type d’objet serveur invocable identique aux talons serveurs RPC généré à la compilation à partir de l’interface IDL
► Squelette dynamique squelette générique prenant en compte dynamiquement tout
type de requêtes permet de créer à l’exécution des classes d’objets serveurs (i.e.
que l’on ne connaissait pas à la compilation)
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 sontle moyen d'accès à un objet.
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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 39
L'adaptateur d'objets
► Fonctions Interface entre les objets CORBA et l’ORB Enregistrement et recherche des implantations d’objets Génération de références pour les objets Gestion de l’instanciation des objets serveurs Activation des processus dans le serveur Aiguillage des invocations de méthodes vers les objets serveurs
► Différents type d’adaptateur BOA (Basic Object Adapter) POA (Portable Object Adapter)
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++
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 41
Normalisation des communications
► Protocoles d’interopé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 d’encodage des données IOR : Interoperable Object References (références d’objets)
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.
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
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
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).
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éritedu squelette.
La seule obligation est de ne pas oublier l'héritage du squelette.Ensuite, il faut tout simplement fournir le code des opérationsdécrites dans l'interface IDL.
!
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
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 );
// …
}
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 d’objet RootPOA
POA rootpoa = POAHelper.narrow(orb.resolve_initial_references
(«RootPOA»));
et Activer le POA Manager
rootpoa.the_POAManager().activate();
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 50
POAManager & POA
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 s’appelle 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 );
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.
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(); }
}}
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.
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écifiqueappelée « narrow ».
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 ) { //… }//...
}
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(); }
}}
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.
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.
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 l’interface 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 l’objet serveur
► Que devrait contenir cet objet?► Quel est son rôle?
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 61
CORBA - TPClasse 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); }}
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 62
CORBA - TPClasse 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);
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 63
CORBA - TPClasse 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...");
}}
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 64
CORBA - TP
3. Construisons l’objet client
► Que devrait contenir cet objet?► Quel est son rôle?
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 65
CORBA - TPClasse 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);
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 66
CORBA - TPClasse 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); }
}
}
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 67
CORBA - TP
4. Compilons les différents éléments
► Compilation de l’interface IDLidlj -fall Hello.idl
► Compilation des classes générées suite à la compilation de l’interfacejavac -Xlint *.java HelloApp/*.java
5. Démarrer l’ORB start orbd -ORBInitialPort 1050
6. Démarrer l’objet serveur start java HelloServer -ORBInitialPort 1050 -ORBInitialHost localhost
7. Lancer l’objet client java HelloClient -ORBInitialPort 1050 -ORBInitialHost localhost
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 68
Conclusions
► Solution non propriétaire
► Standard
► Libre choix de l’implémentation et du langage
► Solution fonctionnelle d’interopérabilité
► Plusieurs implémentations libres et open-source
► Mais.. Mise en œuvre assez complexe..
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 69
DCOM
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, …).
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 d’un client et les achemine vers le composant dans un autre processus.
Client Composant
ComRun time
ComRun time
Client Composant
Service Sécurité
Service Sécurité
DCE RPC
DCE RPC
LPC LPC
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 72
L’architecture de DCOM
ComRun time
ComRun time
Client Composant
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
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 l’emplacement d’une 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 BDValidation
Validation
Traitement
COM
COM COM
DCOM
DCOM
DCOM
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
Fonctiond'interface
Pointeur vers l'objet
Implantations des fonctions
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).
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
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 ...
ObjetDCOM
ClassFactory
IClassFactory
Interfaces de l'objet
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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 79
Architecture des applications DCOM
RemoteObject Proxy
In-ProcessObject
In-Process Server
DCOM
COM
Client
Stub Objetlocal
COM Serveur local
LocalObject Proxy
Stub Objetlocal
COM Serveur local
Processus serveur local
Processus serveur distant
Machine distante
LRPC
RPC
Processus client
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
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
Release
CoRevokeClassObject
Create
Client API de DCOM IClassFactory
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 82
Enterprise Java Beans : l’essentiel
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 83
Objet distribué (rmi)
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
}
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 85
Middleware implicite
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 86
Architecture 3-tiers
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 87
Les Enterprise JavaBeans
► Spécification d’une architecture permettant la création d’applications distribuées Implantations de la spec :
WebLogic, Jonas,IBM Websphere, Jboss
► Composant développé pour être exécuté sur un serveur d’EJB Ne pas confondre avec un Java bean
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 88
Les Enterprise JavaBeans
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 89
Objectifs des EJB
► Fournir une plate-forme standard pour la construction d’applications distribuées en Java
► Simplifier l’écriture de composants serveurs
► Portabilité
► Considérer le développement, le déploiement et l’exécution des applications
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 l’environnement permettant l’exécution des beans
► Le fournisseur de serveur EJB Fournit l’environnement d’exécution pour un ou plusieurs conteneurs
► L’assembleur d’application
► Le déployeur (installateur)
► L’administrateur
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
► L’interface et l’implantation du bean doivent être conforme à la spécification EJB
► Les clients peuvent être Une servlet Une applet Un autre bean
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 92
Les Enterprise Beans
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 l’application 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 l’utilisation de l’API JPA pour le mapping Objet-Relationnel.
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)
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 95
Exemple de Session bean
import javax.ejb.Stateless;@Stateless
public class SimpleSessionBean implements SimpleSession
{private String message = “Je suis un session bean !";public String getMessage(){return message;}}
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 96
L’interface
L’interface décrit le contrat avec les clients
import javax.ejb.Remote;
@Remote
public interface SimpleSession
{
public String getMessage();
}
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
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE application PUBLIC"-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN""http://java.sun.com/dtd/application_1_3.dtd"><application><display-name>savecustomer_ear</display-name><module><web><web-uri>daosessionbeanwebclient.war</web-uri><context-root>/daosessionbeanwebclient</context-root></web></module><module><ejb>daosessionbean.jar</ejb></module></application>
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 98
Le client
import javax.ejb.EJB;public class SessionBeanClient{@EJBprivate 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();}}
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 99
Les entity beans(deprecated)
► Implantation d’objets 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.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 100
Exemple d’entity 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() { }}
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;
}
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 102
Interface de l’Entity 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;
}
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 103
Le descripteur de l’entity bean <entity> <display-name>Book</display-name> <ejb-name>Book</ejb-name> <home>BookHome</home> <remote>Book</remote> <ejb-class>BookEJB</ejb-class> <persistence-type>Container</persistence-type> <prim-key-class>java.lang.String</prim-key-class> <reentrant>False</reentrant> <cmp-field><field-name>title</field-name></cmp-field> <cmp-field><field-name>author</field-name></cmp-field> <cmp-field><field-name>price</field-name></cmp-field>
<primkey-field>title</primkey-field> <query> <description></description> <query-method> <method-name>findByAuthor</method-name> <method-params><method-param>java.lang.String</method-param></method-params> </query-method> <ejb-ql>select distinct object(b) from Book b where b.author=?1</ejb-ql> </query></entity>
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 l’interface onMessage()
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 javax.jms.TextMessage;@MessageDriven(mappedName = "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();}}
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 106
Paquetage d’application
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 107
Déploiement
► Création d’un paquetage contenant Les classes des beans Le fichier de description Les fichiers de configuration spécifique au serveur D’autres librairies
► Mise en place dans le serveur (outils spécifique ou déploiement à chaud)
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 l’exception des adaptations des serveurs
► Réutilisation/Composition Il faut quand même programmer
► Indépendance par rapport aux vendeurs Migration pas toujours évidente d’une plate-forme à une autre
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 109
Bénéfices d’un serveur d’EJB
► 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 d’objet distribué
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 110
Middlewares Orientés Messages (MOM)
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 111
Pourquoi la messagerie?
► Couplage fort Le client dépend de l’interface 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 l’envoi de la requête et l’arrivée de la réponse
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.
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
Récepteur
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
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)
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
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
Récepteur
Queue de distribution
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.
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
Récepteur
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
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 d’efforts de normalisation Une API par vendeur Conceptions différentes (ex. utilisation des ressources) Fonctionnalités différentes
► Difficultés Limitation de l’interopé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 l’infrastructure
(objets et API) Advanced Message Queueing Protocol (AMQP) –un standard ouvert pour l’interopérabilité
de middlewares à message écrits en différents langages et pour différentes plates-formes
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 122
Architecture Orientée Services
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 d’interaction applicative mettant en œuvre des connexions en couplage faible entre divers composants logiciels.
► Il s’agit d’une vision d’un système destinée à traiter toute application comme un fournisseur de services.
► Objectif: Décomposition d’une fonctionnalité en un ensemble de fonctions basiques, appelées services.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 125 125
► 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 d’un message d’entrée et d’un autre de réponse.
Les services
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 l’enchaînement (fonction d’orchestration).
► Un service doit être activable à distance indépendamment de sa technologie. L’activation se fait par l’envoi (et la réception) d’un message XML
► L’appel au service fonctionne quelque soit le langage et les système d’exploitation du consommateur (utilisateur du service)
Les services
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 127
► Un service expose un contrat d’utilisation (déclaration des messages d’entrée et de réponse du traitement offert, déscription des standards et protocoles techniques utilisés pour l’activation du service).
► Le service doit exposer une interface d’utilisation 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
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
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 l’ordre 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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 130
► Implémentation possible des services métiers
► C’est 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 l’enchaînement (fonction d’orchestration).
Expose un contrat d’utilisation
Les Web services
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 131
Standards de l’architecture (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).
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 132
Standards de l’architecture (II)
Les standards sont un élément clé d’une SOA, ils assurent l’interopérabilité
Transporte
SOAPW3C
Simple ObjectAccess Protocol
Spec pour Repository/Registry
UDDIMicrosoft, IBM, HP
Universal DescriptionDiscovery and Integration
WSDLW3C
Web ServicesDescription Language
Décrit le contrat
BPELOasis
Business ProcessExecution Language
Les trois piliers des Services Web
Décrit les processus métier
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, …
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 134
Structure d’un message SOAP
► Un message SOAP est contenu dans une balise Envelope
Une Envelope peut contenir une balise Header Une Header peut contenir n’importe quel ensemble de
balises. Ces balises doivent appartenir à des namespaces.
Une Envelope doit contenir une balise Body Un Body peut contenir n’importe quelle ensemble de
balises. Ces balises peuvent appartenir à des namespaces. Un Body peut contenir des balises Fault qui permettent
d’identifier des erreurs.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 135
SOAP Header
Mécanisme d’extension 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 n’importe quelle balise incluse dans un namespace
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 136
SOAP Header Example
<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI">5
</t:Transaction>
</SOAP-ENV:Header>
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 n’importe quelle balise incluse
optionnellement dans un namespace► Une entrée peut être une Fault.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 138
SOAP Fault
► La balise Fault, permettant de signaler des cas d’erreur, contient les balises suivantes :
faultcode : un code permettant d’identifier le type d’erreur
Client, Server, VersionMismatch, MustUnderstand
faultstring : une explication en langage naturel faultactor : une information identifier l’initiateur de
l’erreur detail : Définition précise de l’erreur.
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 d’encoder ces données.
► Vocabulaire SOAP : Value (valeur d’une donnée)
Simple value (string, integers,etc) Compound value (array, struct, …)
Type (d’une value) Simple Type Compound Type
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 140
Encodage
► L’encodage c’est la représentation de valeurs sous forme XML.
► Le décodage c’est la construction de valeurs à partir d’XML
► L’XML 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 l’utilisateur Soit utilisation d’XML Schéma (préconisé)
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 141
Simple Types
► Type (XML Schema)<element name="age" type="int"/><element name="color">
<simpleType base="xsd:string"><enumeration value="Green"/><enumeration value="Blue"/>
</simpleType></element>► Valeurs<age>45</age><color>Blue</color>
Type XML Schema
Construction de Type XML Schema
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 142
Simple Types
► La définition d’un XML Schéma pour tout type peut être fastidieux
► SOAP a défini deux façons de préciser le type d’une valeur sans définir le Schéma XML: <SOAP-ENC:int>45</SOAP-ENC:int> <cost xsi:type="xsd:float">29.5</cost>
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.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 144
Struct
► Type (XML Schéma)<element name="Person"><complexType>
<element name="name" type="xsd:string"/><element name="age" type="xsd:int"/>
</complexType><element>
► Valeur<Person>
<name>Xavier</name><age>30</age>
</Person>
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 d’un header http : SOAPAction Utilisation des codes http (2xx, 4xx, 5xx)
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 146
Questions
► Comparer SOAP par rapport à CORBA ? IDL ? IIOP ?
► Quel est l’intérêt de porter SOAP sur d’autres protocoles ?
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 l’interface, de l’URL et du port du Web Service.
► Utilise le système de typage de XML Schéma
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 148
WSDLDescription
Une description WSDL :
► Décrit le type d’un 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 d’implantation d’un service web (quel est le protocole utilisé, quel est le l’adresse du service)Cette description sert à se connecter concrètement à un service web.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 149
WSDLBalises
► 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 d’un message échangé portType: cette balise décrit un ensemble d’opérations (interface
d’un 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
d’accéder à un ensemble d’opérations. Un port référence un Binding
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 150
WSDLBalises
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 151
types
► Description en utilisant XML Schema.<wsdl:types>
<xs:schema targetNameSpace="http://www.exemple.fr/personne.xsd"xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="personne"> <xs:complexType> <xs:sequence>
<xs:element name="nom" type="xs:string" /> <xs:element name="prenom" type="xs:string" />
</xs:sequence> </xs:complexType>
</xs:element></xs:schema>
</wsdl:types>
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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 153
message
► Part de type simple<wsdl:message name="personneMsg">
<wsdl:part name="nom" type="xsd:string" /><wsdl:part name="prenom" type="xsd:string" />
</wsdl:message>
► Part qui utilise un XML Schema<wsdl:message name="personneMsg">
<wsdl:part name="personne" element="exemple:personne" /></wsdl:message>
Défini dans un Schema XML
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 154
portType
► Un portType permet d’identifier (nommer) de manière abstraite un ensemble d’opérations.
<wsdl:portType name="descriptionPersonnes" ><wsdl:operation name="getPersonne" >
…</wsdl:operation>
<wsdl:operation name=“setPersonne" >…
</wsdl:operation>
</wsdl:portType>
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 155
operation
► WSDL définit 4 types d’opération :
One-Way : lorsque les opérations reçoivent des messages mais n’en n’envoient 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 n’en reçoivent pas
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 156
operation
► Quelque soit le type d’opération la définition est sensiblement la même.
► Une opération : Reçoit des messages : <wsdl:input …> Envoie des messages : <wsdl:output …> ou <wsdl:fault
…>
► La présence et l’ordre des input/outputs/fault dépendent du type de l’opération.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 157
operation
<wsdl:operation name="operation_name"><wsdl:input name="nom_optionel" message="nom_message" />
</wsdl:operation>
<wsdl:operation name="operation_name"><wsdl:output name="nom_optionel" message="nom_message" /><wsdl:input name="nom_optionel" message="nom_message" /><wsdl:fault name="nom_optionel" message="nom_message" />*
</wsdl:operation>
<wsdl:operation name="operation_name"><wsdl:input name="nom_optionel" message="nom_message" /><wsdl:output name="nom_optionel" message="nom_message" /><wsdl:fault name="nom_optionel" message="nom_message" />*
</wsdl:operation>
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 d’un portType pourra être liée de manière différente.
► Le protocole SOAP est un des protocole qui peut être utilisé.
► D’autres binding sont standardisés par WSDL : HTTP et MIME.
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
<wsdl:binding name="binding_name" type="nom du portType" >
…</wsdl:binding>
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 :
<soap:binding transport="uri" style="soap_style" />
► Transport définit le type de transport http://schemas.xmlsoap.org/soap/http
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
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 l’URI de l’opé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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 162
Exemple
<wsdl:binding type="descriptionPersonnes" ><soap:binding
transport="http://schemas.xmlsoap.org/soap/http"style="rpc" />
<wsdl:operation name="getPersonne"><soap:operation soapAction="http://www.exemple.fr/getPersonne" />
<wsdl:input><soap:body use="encoded"
encodingStyle="schemas.xmlsoap.org/soap/encoding"/>
</wsdl:input> <wsdl:output>
<soap:body use="encoded"
encodingStyle="schemas.xmlsoap.org/soap/encoding"/> </wsdl:output>
</wsdl:operation></wsdl:binding>
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 à l’adresse http)
<wsdl:service name=“MonService"><wsdl:port binding="intf:MonServiceSoapBinding">
<soap:address location="http://mda.lip6.fr:8080/axis/services/MonService"/></wsdl:port>
</wsdl:service>
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 ?
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é
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).
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 167
Exemple
► Le référentiel UDDI de microsoft est accessible à http://uddi.microsoft.com
► Il est possible de parcourir ce référentiel à l’aide d’un navigateur pour : Rechercher un service. Ajouter un service au référentiel.
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
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 s’appelle GetBookPrice
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 170
Référentiels
► Type Public :
Microsoft : uddi.microsoft.com IBM : www.ibm.com/services/uddi HP : uddi.hp.com SAP : udditest.sap.com
Privé ou d’entreprise
► Accès Défini en WSDL JAXR définit une API pour naviguer dans un référentiel UDDI
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 171
Questions
► Quel est la place d’UDDI dans les Web Services ?
► Comparer les référentiels UDDI avec les moteurs de recherche style Yahoo et Google ?
► Quel est l’intérêt des référentiels UDDI d’entreprise ?
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 172
BPEL le chef d’orchestre
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 173
Le langage BPEL
► BPEL = Business Process Execution Language
► Standard de l’OASIS
► Norme permettant de décrire des processus en XML
► Propose les fonctions basiques d’un langage de programmation: sequence, flow, loop, switch…
► Identification des instances de Process
► Gestion des transactions longue durée (scope, compensation)
► Gestion des exceptions
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 174
ESB : couche de médiation
► ESB = Enterprise Service Bus
► C’est le point d’entrée vers un service => invocation indirecte du service au travers du bus
► Ce point d’entré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 d’un ESB est de permettre de communiquer de manière simple et standardisée entre des applications hétérogènes
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 175
Quelques manières d’implé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 d’intégration)
► Routeurs Web services tel que WebSphere Web Services Gateway
Selon le type d’implémentation retenu, l’ESB assurera plus ou moins de “services” : le choix dépend des besoins
L’ESB n’est pas obligatoire : mais il est fortement recommandé pour éviter le couplage entre fournisseur et consommateur
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 176
Exemples d’architecture 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 d‘orchestration, parce que pas d’intermédiaire: invocations de services directement pilotées par le code
• Peu de transactions, ou alors les gérer “à la main”
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 177
Moteurs d’exécution de processus
► Plate-forme d’inté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
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 ServerWebSphere 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
Business Analyst
IntegrationDeveloper
Rational Application
Developer
Developer
Service Architect
Service Registrar
GovernanceManager
PerformanceManagerServer Administrator
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 d’exécution Difficile à effectivement implémenter Encore peu de chose sur la contractualisation
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 181
Bases de données & Persistance
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
Relationnel Objet XML
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
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 d’interrogation simple déclaratif SQL
► Organisation des données en Tables (relations): des lignes (enregistrements ou n-uplets) des colonnes (champs ou attributs)
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 184
Modélisation Relationnelle (1)
Champs, attributs, colonnes
Id-D Nom Prénom
1 Dupont
Pierre
2 Durand Paul
3 Masse Jean
…. …….. ……
Relation ou table
Tuples, lignesou n-uplets
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 185
Modélisation Relationnelle (2)
DocteursId-D Nom Prénom
1 Dupont
Pierre
2 Durand Paul
3 Masse Jean
…. …….. ……
VisitesId-D Id-P Id-V Date Prix
1 2 1 15 juin 250
1 1 2 12 août 180
2 2 3 13 juillet
350
2 3 4 1 mars 250
PatientsId-P Nom Prénom Ville
1 Lebeau Jacques Paris
2 Troger Zoe Evry
3 Doe John Paris
4 Perry Paule Valenton
…. ……. ……. …….
PrescriptionsId-V Ligne Id-M Posologie
1 1 12 1 par jour
1 2 5 10 gouttes
2 1 8 2 par jour
2 2 12 1 par jour
2 3 3 2 gouttes
…. …. …. …………
MédicamentsId-M Nom Description
1 Aspegic 1000
……………………………..
2 Fluisédal ……………………………..
3 Mucomyst ……………………………..
…. …….. ……………………………..
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 186
Intégrité et clés
► Propriétés d’inté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
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 d’une table.
► Clé étrangère Une clé étrangère est un ensemble d’une ou de plusieurs
colonnes d’une table qui fait référence à une clé primaire d’une autre table.”
Clés primaire et étrangère
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
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: integer 32 bits smallint 16 bits decimal(m,n) décimal en virgule fixe float 32 bits char(n), varchar(n) chaîne de longueur (max) n date aa/mm/jj time hh:mm:ss.ss
► Les commandes SQL les plus utilisées: create table, create view, create index, ... select, update, insert, delete, commit, abort,..
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 190
La commande create table
► create table <Nom> ( <Attribut> <Type>, …)
[as <Commande Select> ];
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 );
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 191
La commande select
► select <Resultats> from <Tables> where <Conditions>
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 < 21 and Moyenne > 3;
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 192
Les sous-requêtes
► select <Resultats> from <Tables>
where <Conditions Avec Select>;
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)
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 193
La commande insert
► insert into <Table> (A1, A2, …)
values (v1, v2,…)
insert into etudiants
values ('12345', 'Robert', '450-888-999'); insert into cours (NumC)
(select from Suit where NumE='12345');
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 194
La commande delete
► Delete from <table> where <Condition>
delete from cours where Numc='INF-2344'; delete from Suit where NumC not in
(select NumC from Cours);
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 195
La commande update
► update <Table>
set <instructions> where <Condition>
update Etudiant
set Telephone='450-1234-576'
where NumE='1234'; update Etudiant
set NbrCours=NbrCours
where NumE in (select NumE form Suit);
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)
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
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,…).
► C’est 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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 199
Structure d’un 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) {
};
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 200
Les SGBD et l’univers Java
ODBCdriver
JDBC-ODBCbridge driver
JDBCdriverpour
Oracle
JDBC-Netdriver
JDBCdriverpour
Sybase
JDBC DriverManager
Java
Oracle
API JDBC
API Driver JDBC
Protocole YProtocole X
Protocole Z
SybaseOracle Sybase
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 l’utilisation sur le réseau d’un ou plusieurs SGBD à partir d’un 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
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
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
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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 205
Architecture 2-tiers
Application
ou
Applet
JDBC
Client
BD
Serveur
SGBD
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 »
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 207
Architecture 3-tiers
Application
ou
Applet
Client
BD
ServeurTCP / RMI / CORBA / Agent
Middleware
JDBC
SGBD
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
Architecture2-tiers
et application
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
IntranetInternet
Web server
Architecture2-tiers
et applet
Scénario d ’utilisation #2
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
Architecture3-tiers
JDBC Appli. Driver
JDBC DriverManager
BD
SGDBR
Database ServerMiddleware server
Intranet
Scénario d ’utilisation #3
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 211
Les pilotes JDBC
► Il existe 4 types de pilote:
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
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
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
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
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
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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 218
Etapes d’utilisation de JDBC
1. Création d’une instance de pilote JDBC
2. Définition de l’URL de connexion
3. Création d’une connexion vers un SGBDR avec l’instance du pilote
4. Création d’une 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
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();
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:<sous-protocole>:<nom-BD>;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 = "jdbc:oracle:thin:@arabica.info.uqam.ca:1521:o8db";
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 qu’il trouve un driver qui peut se connecter à la base
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);
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
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)");
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 qu’une 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..
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
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
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 "
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 229
Correspondance des types Java / SQL
SQL JavaCHAR String
VARCHAR StringLONGVARCHAR String
NUMERIC java.math.BigDecimalDECIMAL java.math.BigDecimal
BIT booleanTINYINT byte
SMALLINT shortINTEGER int
BIGINT longREAL float
FLOAT doubleDOUBLE doubleBINARY byte[]
VARBINARY byte[]LONGVARBINARY byte[]
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
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") ;
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");
}
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 );
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();
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 235
Insertion de lignesExemple
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.
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();
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();
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 qu’une 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
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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 240
Exécution d’une 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();
}
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();
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"
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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 244
La persistance des objet
► La persistance d’objets désigne le fait que des objets individuels peuvent survivre au processus de l’application. 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 d’objets dans une application Java vers les tables d’une base de données relationnelle à l’aide des méta données décrivant le mapping entre les objets et la base de données.
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
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.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 247
ORM (Object Relationnel Mapping)
► C’est une technique de mapping d’une représentation des données d’un 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 l’implémentation du mapping objet/relationnel permettant d’interagir avec des objets transactionnels pour effectuer des vérifications brutes, rechercher des associations lâches et implémenter d’autres fonctions d’optimisation.
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 d’un tampon entre les deux modèles pour isoler les
modifications mineurs de chaque modèle.
► Performance Utilisation d’un grand nombre d’optimisation.
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 249
Exemple : Couche d’accè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 d’accès aux données
(DAO)Couche JDBC
Base de données
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 250
Couche
Hibernate
Objets image de la BD
Couche d’accè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
EFREI – M1A | Architecture des Systèmes d'Information | Mai – Juillet 2011|
Page 251
RéférencesJe ne donne ici que les références que j’estime les plus claires, les plus pédagogiques ou alors incontournables. C’est donc en quelque sorte un best of.
CORBA / DCOM http://www.sylbarth.com/corba/corba.html : Un exemple pédagogique permettant de bien comprendre les interactions entre
les différentes coouches de CORBA http://corba.developpez.com/ : L’un des meilleurs sites de tutoriels CORBA (en français) http://windows.developpez.com/dcom/t1.html : Une FAQ très succincte et claire sur DCOM
EJB http://www.oracle.com/technetwork/java/javaee/ejb/index.html : 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 www.infres.enst.fr/people/diacones/jms/JMS_v2-INF346-COMASIC.pdf : Un condensé signé Ada Diaconescu, précis, bien
présenté, agréable à parcourir.
SOA http://mbaron.developpez.com/soa/intro/ : L’essentiel de ce qu’il faut savoir sur les SOA.
Persistance http://jguillard.developpez.com/JDBC/ http://download.oracle.com/javase/tutorial/jdbc/basics/index.html http://tahe.developpez.com/java/jpa/
Recommended