Jacques augustin nov jan 2012
This presentation is the property of its rightful owner.
Sponsored Links
1 / 249

Jacques Augustin Nov- Jan 2012 PowerPoint PPT Presentation


  • 93 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Jacques Augustin Nov- Jan 2012

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Jacques augustin nov jan 2012

Jacques Augustin Nov- Jan 2012

Cours d’Architecture des Systèmes d'Information

EFREI


Sommaire

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


Jacques augustin nov jan 2012

Introduction


Introduction

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


Introduction1

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.


Introduction2

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.


Introduction3

Introduction

Cartographie du SI

Diagramme illustrant toutes les briques d’un système d’information.


Introduction4

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?


Jacques augustin nov jan 2012

Conception et modélisation


Design patterns d finition

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.


Diff rents types de patterns

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.


Classification des patterns

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


Exemple de pattern

Exemple de pattern

Patterns : exemple

Le pattern Singleton

Ce modèle créateur permet de s'assurer que la classe n'aura qu'une seule instance, accessible par un point d'entrée unique (une méthode) bien déterminé.

Implémentation

L’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).


Exercice

Exercice

Singleton

Un singleton sert à contrôler le nombre d'instances d'une classe présent à un moment donné. C'est souvent très pratique pour les classes sans état et effectuant toujours les mêmes traitements.

Un singleton est construit grâce à des méthodes de classes. Ces méthodes appartiennent à une classe et peuvent être accédées indépendamment de l'objet.

Compléter le code suivant pour implémenter correctement le pattern Singleton

public CanvasFactory {

/** Donnée de classe contenant l'instance courante */

private ??? CanvasFactory instance = new CanvasFactory();

/** Constructeur privé interdisant l'instanciation en dehors de cette classe */

??? CanvasFactory () {}

/** Singleton de la classe courante */

public ??? CanvasFactory getInstance() {

??? ;

}

...

}

Typiquement l'usage de la classe CanvasFactory se fera ainsi :

CanvasFactory cf = CanvasFactory.getInstance();


Le pattern architectural mvc

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.


Le pattern architectural mvc1

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.


Le pattern architectural mvc2

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)


Le pattern architectural mvc3

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 correspondant

En outre, le contrôleur intervient également pour la sélection d'une vue (une par fonctionnalité) conformément à la cinématique (cheminement) définie pour le traitement des actions.


Le pattern architectural mvc4

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).


Le pattern architectural mvc5

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).


La mise en uvre des patterns

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.


Jacques augustin nov jan 2012

C.O.R.B.A.


Corba principe simplifi

CORBA - Principe simplifié

Client

Serveur

Objet

Objet

Middleware


Qu est ce que c o r b a

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


Objectifs de corba

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.


Le bus corba

Le bus CORBA

Le bus CORBA = ORB

NT

UNIX

UNIX

PC

PC

Sparc


La vue r elle du bus corba

La vue réelle du bus CORBA

Réseau TCP/IP

ORB

PC/NT

ORB

PC/UNIX

ORB

Sparc/UNIX

NT

UNIX

UNIX

PC

PC

Sparc


Architecture de corba

Architecture de CORBA

IDL


Serveur et objets

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.


Composants

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


Objet corba

Objet CORBA


Le langage idl corba

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();

};


La compilation idl

La compilation IDL

  • Une description IDL est compilée pour générer les amorces nécessaires au mécanisme RPC.

souche

Génération de l'amorce cliente

description

IDL

Génération de l'amorce serveur

squelette


Intervention des amorces c o r b a

Intervention des amorces C.O.R.B.A.

Client Java

Objet C++

Protocole IIOP

Souche Java

Squelette C++

ORB Java

PC/NT

ORB

PC/UNIX

ORB C++

Sparc/UNIX

NT

UNIX

UNIX

PC

PC

Sparc


Souche cot client

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)


Squelette c t serveur

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)


L identit d un objet c o r b a

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.

Les références d'objets sont

le moyen d'accès à un objet.

serveur


L adaptateur d objets

L'adaptateur d'objets

Serveur

Objet A

Objet B

Squelette A

Squelette B

Client

Adaptateur d'objets

Souche A

Le bus C.O.R.B.A. ( O.R.B. )


L adaptateur d objets1

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)


Les communications avec corba

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++


Normalisation des communications

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)


L annuaire c o r b a

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.


Compilation d une description idl

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


Concept de mapping

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


D velopper les objets corba

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).


D veloppement de notre premier objet corba

Développement de notre premier objet CORBA

public class PremierImpl extends PremierPOA

{

public void affiche( String message )

{

System.out.println( message );

}

}

L'implantation hérite

du squelette.

La seule obligation est de ne pas oublier l'héritage du squelette.

Ensuite, il faut tout simplement fournir le code des opérations

décrites dans l'interface IDL.

!


D velopper le serveur

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


Initialiser l orb

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 );

      // …

      }


Initialiser l adaptateur d objets

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();


Poamanager poa

POAManager & POA


Cr er et enregistrer l objet corba

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 );


Echanger une r f rence d objet

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.


Le code du serveur

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(); }

}

}


D velopper le client

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.


Conversion de r f rences d objets

Conversion de références d'objets

object_to_string

org.omg.CORBA.Object

Premier

string_to_object

Conversion

org.omg.CORBA.Object

La conversion consiste à utiliser une fonction spécifique

appelée « narrow ».


Les classes helpers

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 ) { //… }

    //...

    }


Le code du client

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(); }

}

}


Ex cuter l application

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.


Synth se

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.


Corba tp

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?


Corba tp1

CORBA - TP

Classe HelloServer.java

import HelloApp.*;

import org.omg.CosNaming.*;

import org.omg.CosNaming.NamingContextPackage.*;

import org.omg.CORBA.*;

import org.omg.PortableServer.*;

import org.omg.PortableServer.POA;

import java.util.Properties;

class HelloImpl extends HelloPOA {

private ORB orb;

public void setORB(ORB orb_val) {

orb = orb_val;

}

// implement sayHello() method

public String sayHello() {

return "\nHello EFREI !\n";

}

// implement shutdown() method

public void shutdown() {

orb.shutdown(false);

}

}


Corba tp2

CORBA - TP

Classe HelloServer.java (suite)

public class HelloServer {

public static void main(String args[]) {

try{

// create and initialize the ORB

ORB orb = ORB.init(args, null);

// get reference to rootpoa & activate the POAManager

POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));

rootpoa.the_POAManager().activate();

// create servant and register it with the ORB

HelloImpl helloImpl = new HelloImpl();

helloImpl.setORB(orb);

// get object reference from the servant

org.omg.CORBA.Object ref = rootpoa.servant_to_reference(helloImpl);

Hello href = HelloHelper.narrow(ref);

// get the root naming context

// NameService invokes the name service

org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService");

// Use NamingContextExt which is part of the Interoperable

// Naming Service (INS) specification.

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);


Corba tp3

CORBA - TP

Classe HelloServer.java (suite)

// bind the Object Reference in Naming

String name = "Hello";

NameComponent path[] = ncRef.to_name( name );

ncRef.rebind(path, href);

System.out.println("HelloServer prêt et en attente ...");

// wait for invocations from clients

orb.run();

}

catch (Exception e) {

System.err.println("ERROR: " + e);

e.printStackTrace(System.out);

}

System.out.println(« Arrêt de HelloServer...");

}

}


Corba tp4

CORBA - TP

3. Construisons l’objet client

Que devrait contenir cet objet?

Quel est son rôle?


Corba tp5

CORBA - TP

Classe HelloClient.java

import HelloApp.*;

import org.omg.CosNaming.*;

import org.omg.CosNaming.NamingContextPackage.*;

import org.omg.CORBA.*;

public class HelloClient

{

static Hello helloImpl;

public static void main(String args[])

{

try{

// create and initialize the ORB

ORB orb = ORB.init(args, null);

// get the root naming context

org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService");

// Use NamingContextExt instead of NamingContext. This is

// part of the Interoperable naming Service.

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);


Corba tp6

CORBA - TP

Classe HelloClient.java (suite)

// resolve the Object Reference in Naming

String name = "Hello";

helloImpl = HelloHelper.narrow(ncRef.resolve_str(name));

System.out.println("Obtained a handle on server object: " + helloImpl);

System.out.println(helloImpl.sayHello());

helloImpl.shutdown();

} catch (Exception e) {

System.out.println("ERROR : " + e) ;

e.printStackTrace(System.out);

}

}

}


Corba tp7

CORBA - TP

4. Compilons les différents éléments

Compilation de l’interface IDL

idlj -fall Hello.idl

Compilation des classes générées suite à la compilation de l’interface

javac -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


Conclusions

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..


Jacques augustin nov jan 2012

DCOM


Introduction5

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, …).


Le mod le de dcom

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.

Composant

Client

Com

Run time

Com

Run time

Client

Composant

Service

Sécurité

DCE

RPC

Service

Sécurité

DCE

RPC

LPC

LPC


L architecture de dcom

L’architecture de DCOM

  • 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.

Com

Run time

Com

Run time

Client

Composant

Service

Sécurité

DCE

RPC

Service

Sécurité

DCE

RPC

Pile de protocoles

Pile de protocoles

Réseau


Propri t s de dcom

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.

DCOM

Interface

usager

Client

Validation

COM

COM

COM

Validation

Accès BD

Traitement

DCOM

DCOM


Les interfaces dcom

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

Pointeur

vers l'objet

Fonction

d'interface

Implantations

des fonctions


R f rences d objets

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).


Les objets dcom

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, …)

IUnknown

Interface A

Objet

DCOM

Interface B

Interface C


Les serveurs dcom

Les serveurs DCOM

  • Un serveur est un ensemble d'objets référencés par leur CLSID.

  • Les serveur dispose d'une Class Factory qui crée des objets et retourne leurs pointeurs.

  • Le serveur effectue les tâches suivantes:

    • Implante Class Factory (IClassFactory) pour la création d'instances de classes

    • Enregistre les classes qu'il offre

    • Active une libraire de classes

    • ...

Objet

DCOM

Interfaces

de l'objet

Class

Factory

IClassFactory


La r partition avec dcom

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


Architecture des applications dcom

Architecture des applications DCOM

Processus serveur local

Processus client

In-Process

Object

Objet

local

Stub

COM

Serveur local

In-Process Server

LRPC

Local

Object

Proxy

Client

Machine distante

Processus serveur distant

COM

Remote

Object

Proxy

Objet

local

Stub

RPC

COM

Serveur local

DCOM


L interface iunknown

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.

QueryInteface

AddRef

Objet IUnknown

Release


Cr ation d objets

Création d'objets

  • Le scénario suivant illustre le mécanisme de création des objets

Client

API de DCOM

IClassFactory

CoGetClassObject

CoRegisterClassObject

IMyInterface

Create

CreateInstanceLic

Obtention des services

Release

Release

CoRevokeClassObject


Jacques augustin nov jan 2012

Enterprise Java Beans : l’essentiel


Objet distribu rmi

Objet distribué (rmi)


Middleware explicite

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

}


Middleware implicite

Middleware implicite


Architecture 3 tiers

Architecture 3-tiers


Les enterprise javabeans

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


Les enterprise javabeans1

Les Enterprise JavaBeans


Objectifs des ejb

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


Division des responsabilit s

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


Les enterprise beans

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


Les enterprise beans1

Les Enterprise Beans


Les types de beans

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.


Session bean

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)


Exemple de session bean

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;

}

}


L interface

L’interface

L’interface décrit le contrat avec les clients

import javax.ejb.Remote;

@Remote

public interface SimpleSession

{

public String getMessage();

}


Le descripteur de d ploiement

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>


Le client

Le client

import javax.ejb.EJB;

public class SessionBeanClient

{

@EJB

private staticSimpleSessionsimpleSession;

private voidinvokeSessionBeanMethods()

{

System.out.println(simpleSession.getMessage());

System.out.println("\nSimpleSessionis of type: "

+ simpleSession.getClass().getName());

}

public staticvoid main(String[] args)

{

new SessionBeanClient().invokeSessionBeanMethods();

}

}


Les entity beans deprecated

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.


Exemple d entity bean cmp deprecated

Exemple d’entity bean (CMP) (deprecated)

public class BookEJBimplements javax.ejb.EntityBean {

public String author;

public String titlel;

public intprice;

private EntityContextcontext;

public String getTitle() {return title;}

public String getAuthor() {return author;};

public intgetPrice() {return price;}

public voidsetPrice(int_price)

{price=_price;}

public String ejbCreate (String _author, String _title) throwsCreateException {

author=_author;

title=_title;

price=0;

return null;

}

// Méthodes requises par le conteneur

public voidejbPostCreate(String _author,String_title) { }

public voidejbRemove() { }

public voidejbLoad() { }

public voidejbStore() {}

public voidsetEntityContext(EntityContextcontext) {

this.context = context;}

public voidunsetEntityContext() {

context=null; }

public voidejbActivate() { }

public voidejbPassivate() { }

}


Home interface deprecated

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;

}


Interface de l entity bean deprecated

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;

}


Le descripteur de l entity bean

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>


Message driven bean

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()


Exemple de message bean

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();

}

}


Paquetage d application

Paquetage d’application


D ploiement

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)


Int r t des ejb

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


B n fices d un serveur d ejb

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é


Jacques augustin nov jan 2012

Middlewares Orientés Messages (MOM)


Pourquoi la messagerie

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


Middleware orient message

Middleware orienté message

  • Les middlewares orientés messages (MOM) proposent une infrastructure permettant l’échange de messages dans une architecture répartie.


Mom entit s de base

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

Récepteur

Récepteur

Message

MOM

Emetteur

Récepteur


Avantages des mom

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


Les types de mom

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)


Le mod le point to point

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


Queues ptp

Queues PTP

  • Plusieurs producteurs peuvent placer les messages pour divers destinataires dans une queue

    Gestionnaire de files(Serveur MOM)

Récepteur

Queue de distribution

Producteur

Récepteur

Producteur

Récepteur


Le mod le publish subscribe

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.


Sujets de pub sub

Sujets de Pub/Sub

  • La publication et l'abonnement à un sujet découple le producteur et le consommateur

Gestionnaire de sujets (Serveur MOM)

Récepteur

Producteur

Récepteur

Producteur

Récepteur


Le mod le request reply

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


Mom synth se

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


Jacques augustin nov jan 2012

Architecture Orientée Services


Pr sentation

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.


Les services

Les services

  • Sont les composants de base de l'ArchitectureOrientée Services.

  • Consistent en unefonctionoufonctionnalitébiendéfinie.

  • Exposentune interface qui définit le traitementoffertsous la forme d’un message d’entrée et d’un autre de réponse.

125


Les services1

Les services

  • 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 services2

Les services

  • 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 les 4 propri t s principales

Les services Les 4 propriétés principales

Un Service expose un Contrat

Les services communiquent par messages

in

out

  • Un Service estautonome et sans état

  • Les Frontières entre services sontexplicites


Soa et web services

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


Les web services

Les Web services

  • 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


Standards de l architecture i

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).


Standards de l architecture ii

Standards de l’architecture (II)

Les standards sont un élément clé d’une SOA, ils assurent l’interopérabilité

SOAP

W3C

Simple Object

Access Protocol

WSDL

W3C

Web Services

Description Language

UDDI

Microsoft, IBM, HP

Universal Description

Discovery and Integration

BPEL

Oasis

Business ProcessExecution Language

Décrit le contrat

Transporte

Décrit les processus métier

Spec pour Repository/Registry

Les troispiliers des Services Web


Jacques augustin nov jan 2012

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, …


Structure d un message soap

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.


Soap header

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


Soap header example

SOAP Header Example

<SOAP-ENV:Header>

<t:Transaction xmlns:t="some-URI">5

</t:Transaction>

</SOAP-ENV:Header>


Soap body

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.


Soap fault

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.


Encodage

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


Encodage1

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é)


Simple types

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


Simple types1

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>


Compound types

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.


Struct

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>


Soap avec http

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)


Questions

Questions

Comparer SOAP par rapport à CORBA ?

IDL ?

IIOP ?

Quel est l’intérêt de porter SOAP sur d’autres protocoles ?


Jacques augustin nov jan 2012

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


Wsdl description

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.


Wsdl balises

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


Wsdl balises1

WSDLBalises


Types

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>


Message

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


Message1

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


Porttype

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>


Operation

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


Operation1

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.


Operation2

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>


Binding

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.


Binding1

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>


Binding soap

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


Binding soap1

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


Exemple

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>


Service

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>


Questions1

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 ?


Jacques augustin nov jan 2012

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é


R les

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).


Exemple1

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.


Exemple de recherche de web services

Exemple de recherche de Web services

Façons de rechercher un service.

Nous allons rechercher les Web Services de la société Amazon.


Exemple de recherche de web services1

Exemple de recherche de Web services

AmazonBusiness propose un Web Service

Ce Web Service s’appelle GetBookPrice


R f rentiels

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


Questions2

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 ?


Bpel le chef d orchestre

BPEL le chef d’orchestre


Le langage bpel

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


Esb couche de m diation

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


Quelques mani res d impl menter un esb

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


Exemples d architecture techniques avec vs sans esb

Exemples d’architecturetechniques Avec vs Sans ESB

Sans ESB

AvecESB

  • 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”


Moteurs d ex cution de processus

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


Exemple gamme d outils ibm couvrant le cycle de vie complet

Exemple: Gamme d'outils IBM couvrant le cycle de vie complet

BusinessAnalyst

Service Architect

Developer

IntegrationDeveloper

Service Registrar

GovernanceManager

PerformanceManager

Server Administrator

BusinessAnalyst

WebSphere Business Modeler

Rational Software Architect

Service Specification

BPEL

WSDL

WebSphere Integration Developer

RationalApplication Developer

KPIs

Service Development

WebSphere ServiceRepository&Registry

WebSphere Business Monitor

WebSphere Process ServerWebSphere ESB

WebSphere Business Services Fabric

Service execution & Management


Avantages et inconv nients

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


Jacques augustin nov jan 2012

Bases de données & Persistance


Mod lisation du r el

Modélisation du réel

effectue

Médecin

Visite


Le mod le relationnel

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)


Mod lisation relationnelle 1

Modélisation Relationnelle (1)

Champs, attributs, colonnes

Relation ou table

Tuples, lignes

ou n-uplets


Mod lisation relationnelle 2

Modélisation Relationnelle (2)


Int grit et cl s

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


Cl s primaire et trang re

Clés primaire et étrangère

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.”


Le langage sql

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


Les types de donn es

Les types de données

Les types de données de base sont:

integer32 bits

smallint16 bits

decimal(m,n)décimal en virgule fixe

float32 bits

char(n), varchar(n)chaîne de longueur (max) n

dateaa/mm/jj

timehh:mm:ss.ss

Les commandes SQL les plus utilisées:

create table, create view, create index, ...

select, update, insert, delete, commit, abort,..


La commande create table

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 );


La commande select

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;


Les sous requ tes

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)


La commande insert

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');


La commande delete

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);


La commande update

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);


Les vues

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)


Les transactions en sql

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


Jacques augustin nov jan 2012

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


Structure d un programme

Structure d’un programme

Inclure le support SQL (SQLCA, SQLDA)

main(int argc, char **argv) {

Déclarations

Connexion à la BD

Traitement

Traitement des erreurs

Commit/Abort et Déconnexion

};


Les sgbd et l univers java

Les SGBD et l’univers Java

Java

JDBC DriverManager

API JDBC

API Driver JDBC

JDBC-ODBC

bridge driver

JDBC-Net

driver

JDBC

driver

pour

Oracle

JDBC

driver

pour

Sybase

ODBC

driver

Protocole Z

Protocole Y

Protocole X

Oracle

Sybase

Oracle

Sybase


La couche jdbc

La couche JDBC

  • JDBC Java DataBaseConnectivity .

  • 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


Un mod le 2 couches

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


Mod les de connexion en java

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


Modele 2 tiers

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


Architecture 2 tiers

Architecture 2-tiers

Client

Serveur

Application

ou

Applet

J

D

B

C

SGBD

BD


Modele 3 tiers

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 »


Architecture 3 tiers1

Architecture 3-tiers

Client

Serveur

TCP / RMI / CORBA / Agent

Application

ou

Applet

Middleware

JDBC

SGBD

BD


Sc nario d utilisation 1

Scénario d ’utilisation #1

Java appli

Client

BD

JDBC DriverManager

JDBC Appli. Driver (I ou II)

Intranet

Server

SGDBR

BD

Architecture

2-tiers

et application


Sc nario d utilisation 2

Scénario d ’utilisation #2

Architecture

2-tiers

et applet

Java applet

Client

JDBC DriverManager

JDBC Applet Driver (III ou IV)

Intranet

Internet

SGDBR

Web server

BD

Server


Sc nario d utilisation 3

Scénario d ’utilisation #3

Architecture

3-tiers

Client

Java applet /

application

Intranet/

Internet

Database Server

Middleware server

Web server

JDBC DriverManager

SGDBR

JDBC Appli. Driver

SGDBR

BD

BD

Application Server

Intranet


Les pilotes jdbc

Les pilotes JDBC

Il existe 4 types de pilote:


Driver de type i pont vers odbc

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


Odbc de microsoft

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


Driver de type ii native api

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


Driver de type iii net protocol

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


Driver de type iv native protocol

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


Types de drivers et applets

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


Etapes d utilisation de jdbc

Etapes d’utilisation de JDBC

Création d’une instance de pilote JDBC

Définition de l’URL de connexion

Création d’une connexion vers un SGBDR avec l’instance du pilote

Création d’une ou +eurs instructions

Exécution de la requête.

Récupération et traitement des lignes du jeu de résultat

Fermeture du jeu de résultat

Fermeture et Déconnexion de la BD


Enregistrer le driver jdbc

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();


Url de connexion

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";


Connexion la base

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


Cr ation d un statement

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);


Ex cution d une requ te 1 3

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


Ex cution d une requ te 2 3

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)");


Ex cution d une requ te 3 3

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..


Traiter les donn es retourn es

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


Types de donn es jdbc

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


Cas des valeurs nulles

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 "


Correspondance des types java sql

Correspondance des types Java / SQL


Le r sultat resultset

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


Le r sultat resultset1

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") ;


Le r sultat resultset2

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");

}


D placement dans un resultset

Déplacement dans un ResultSet

rs.first(); 

rs.beforeFirst(); 

rs.next(); 

rs.previous(); 

rs.afterLast(); 

rs.absolute( n ); 

rs.relative( n );


Insertion de lignes

Insertion de lignes

rs.moveToInsertRow();

rs.updateString("Nom", “Ben Salah");

rs.updateInt("Age", 24);

rs.insertRow();

rs.first();


Insertion de lignes exemple

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.


Modification d un resultset

Modification d'un « ResultSet »

Modification

rs.updateString("Nom", “Augustin");

rs.updateInt("Age", 24);

rs.updateRow();

Destruction:

rs.deleteRow();


Fermer les diff rents espaces

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();


Requ tes pr compil es

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


Cr ation d une requ te pr compil e

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


Ex cution d une requ te pr compil e

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();

}


Validation de transaction commit

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();


Annulation de transaction rollback

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"


Exceptions

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


La persistance des objet

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.


Strat gies de persistance

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


Gestion de la correspondance objet relationnel

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.


Orm object relationnel mapping

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 :

Une API pour effectuer les opérations CRUD (Create, Read, Update, delete) de base sur les objets des classes persistantes.

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.

Un système pour spécifier des métadonnées de mapping.

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.


Orm object relationnel mapping1

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.


Exemple couche d acc s aux donn es

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

Couche Interface

Couche Métier

Couche d’accès aux données (DAO)

CoucheJDBC

Base de données

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].


Solution orm hibernate

Solution ORM: Hibernate

Pour isoler la couche [dao] des aspects propriétaires des SGBD. Une solution est celle du Framework Hibernate ou (JPA, TopLink dans JEE)

Base de données

Couche d’accès aux données (DAO)

Objets image

de la BD

Couche Hibernate

CoucheJDBC

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


R f rences

Références

Je 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 DevelopmentusingGlassfish 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/


  • Login