417
Architectures distribuées Objectifs version support : 1.0

Architectures distribuées

Embed Size (px)

DESCRIPTION

Présentation des concepts d'architectures distribuées

Citation preview

Page 1: Architectures distribuées

Architectures distribuéesObjectifs

version support : 1.0

Page 2: Architectures distribuées

antislashn.org Architectures distribuées - Objectifs 0 - 2 / 5

Objectifs

● Acquérir une connaissance globale des modèles d'architecture distribuée

● Positionner les principaux langages, API, frameworks dans les architectures distribuées

● Connaître le vocabulaire lié aux architectures distribuées

● Tester divers solutions : GWT, JBoss, ServiceMix, ...

Page 3: Architectures distribuées

antislashn.org Architectures distribuées - Objectifs 0 - 3 / 5

Chapitres

● 01 – Introduction

● 02 – Couche Web

● 03 – N tiers

● 04 – XML

● 05 – Java EE

● 06 – Web services

● 07 – Rich Internet Application

● 08 – Service Oriented Application

● 09 – Répartition de charge et haute disponibilité

● 10 – Quelques serveurs Java EE

Page 4: Architectures distribuées

antislashn.org Architectures distribuées - Objectifs 0 - 4 / 5

copyleft

Support de formation créer par

Franck SIMON

http://www.franck-simon.com

Page 5: Architectures distribuées

antislashn.org Architectures distribuées - Objectifs 0 - 5 / 5

copyleft

Cette œuvre est mise à disposition sous licence Attribution

Pas d'Utilisation Commerciale

Partage dans les Mêmes Conditions 3.0 France.

Pour voir une copie de cette licence, visitez http://creativecommons.org/licenses/by-nc-sa/3.0/fr/

ou écrivez à

Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA.

Page 6: Architectures distribuées

Architectures distribuéesIntroduction

Page 7: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 2 / 18

Historique

● Les architectures informatiques suivent un cycle régulier de centralisation / décentralisation● 1960 : mainframes● 1990 : architectures client/serveur

– protocoles de communication type CORBA● 1995 : explosion du web● 2005 : RIA

Page 8: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 3 / 18

Historique

source : Cloud computing et SaaS - Dunod

Page 9: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 4 / 18

Évolution des architectures

● Classiquement une application peut être divisée en trois niveaux● la couche de présentation

– IHM, GUI● la couche applicative

– les traitements● l'accès aux données

● Ce principe n'est qu'un découpage abstrait● les trois couches peuvent être imbriquées ou réparties

Page 10: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 5 / 18

Évolution des architectures

Présentation

Traitements

Données

Gestion de la présentation

Logique de présentation

Logique des traitements

Gestion des traitements

Logique des données

Gestion des données

Noyau de l'application

Page 11: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 6 / 18

Modèles de répartition

● Gartner Group classifie les différents modèles de répartition

Données

Traitements

Présentation

Présentation

Présentationdistribuée

Présentationdistribuée

Données

Traitements

Présentation

Présentationdistante

Données

Traitements

Présentation

Gestion distantedes données

Données

Traitements

Présentation

Traitementsdistribués

Traitements

Données

Traitements

Présentation

Traitementsdistribués

Traitements

Données

Traitements

Présentation

Donnéesdistribués

Données

Données

Traitements

Présentation

Données et traitementsdistribués

Données

Traitements

réseau

serv

eur

clie

nt

Page 12: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 7 / 18

Modèles de répartition

● Le client serveur est un modèle 2 tiers● Le découpage précédent illustre sous forme

simplifiée la structure possible d'une application● la réalité est plus complexe

– architectures multi-niveaux● le serveur peut-être client d'un autre serveur

– prise en compte des applications existantes● legacy

Page 13: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 8 / 18

Architecture trois-tiers

● Les limites de l'architecture deux-tiers● frontal complexe et non standard

– généralement sous Windows– à déployer

● middleware non standard

● La solution serait● utilisation d'un poste client très simple● communication avec le serveur via un protocole

standard

Page 14: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 9 / 18

Architecture trois-tiers

● Principes de base● les données sont gérées de manière centralisée● la présentation est gérée par le poste client● la logique applicative est gérée par un serveur

intermédiaire

● Premières tentatives● introduction d'un serveur d'application centralisé

– dialogue avec les clients par un protocole propriétaire

Page 15: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 10 / 18

Serveur transactionnel

● Issu des technologies IBM des années 1970● mise à disposition à grande échelle d'applications en

mode texte● plusieurs écrans se succèdent avant qu'une

modification soit réellement effectuée

● Le serveur héberge un moteur transactionnel● met en relation le client avec un ensemble de serveurs

de données

Page 16: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 11 / 18

Serveur transactionnel

● permet de garantir la règle ACID● Atomicité

– la transaction ne peut pas être partiellement effectuée● Cohérence

– la transaction fait passer la base d'un état cohérent à un autre état cohérent

● Isolation– un transaction n'est pas affectée par le résultat des autres

transactions● Durée

– les modifications de la transaction sont durablement garantie

Page 17: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 12 / 18

Serveur transactionnel

client

IHM

API moniteurtransactionnel

Serveur

API moniteurtransactionnel

Service 1

API 1

API 1

Service 2

API 2

API 2

protocole 1

protocole 2

Page 18: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 13 / 18

Architecture trois tiers

● Répartition des traitements● 1er tiers : affichage et traitement locaux

– contrôles de surface, mises en forme des données, …

● 2ème tiers : traitements applicatifs globaux pris en charge par le serveur d'application

● 3ème tiers : base de données

1er tiers 2éme tiers 3éme tiers

présentation

traitementslocaux

traitementsglobaux données

Page 19: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 14 / 18

Architecture trois tiers

● Internet révolutionne l’architecture● corrige les excès du client lourd

– la partie applicative est centralisée sur le serveur

● Le serveur HTTP devient central● problème de dimensionnement de serveur● gestion de la montée en charge● complexité de la maintenance des applications● gestion des sessions● le serveur est fortement sollicité

Page 20: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 15 / 18

Architecture trois tiers

● Du mainframe en mode texte au mainframe en mode graphique : retour à la case départ

source : Serveurs d'applications - Eyrolles

Page 21: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 16 / 18

Architectures N-tiers

● Permet de pallier aux limitations du 3 tiers● distribution plus libre de la logique applicative● répartissions de la charge

● N tiers pour la distribution de l'application entre de multiples services● et non pas la multiplication des niveaux de service

● Utilise des composants● chaque composant rend un service clairement identifié● concepts orientés objets

Page 22: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 17 / 18

Architectures N-tiers

● Complexité de réutilisation

source : Serveurs d'applications - Eyrolles

Page 23: Architectures distribuées

antislashn.org Architectures distribuées - Introduction 01 - 18 / 18

Architecture N-tiers

● Solution Oracle / Sun● EJB : Enterprise Java Bean

– s'exécutent côté serveur● JavaBean (POJO)

– objets métiers

● Solution Microsoft● modèle de communication COM● DCOM étend COM pour les architectures distribuées

Page 24: Architectures distribuées

Architectures distribuéesCouche Web

Page 25: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 2 / 62

Internet et le web

● Internet● inter net

– liens entre des réseaux hétérogènes– réseau de réseaux

● les réseaux sont reliés entre-eux par le protocole TCP/IP

● il n'existe pas d'administration internet– comme pour un réseau téléphonique

Page 26: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 3 / 62

TCP/IP

● Couches réseau

Application

Présentation

Session

Présentation

Transport

Présentation

Liaison

Réseau

Physique

7

6

5

4

3

2

1

HTTPFTPDNS

TCP, UDP, SCTP

IP

Ethernet, Token Ring, ...

ADSL, RTC, ...

modèle OSI Pile TCP/IP

Page 27: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 4 / 62

Protocole IP

● IP – Internet Protocol● protocole non fiable

– assure l'acheminement au mieux● ne se préoccupe pas du contenu envoyé● fournit une méthode pour délivrer le contenu à destination

– pas de garantie sur les paquets envoyés● corruption de données, ordre d'arrivée

● L'adresse IP est un numéro attribué à chaque équipement connecté

Page 28: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 5 / 62

Protocole IP

● IP v4● adresse sur 32 bits

* image provenant de Wikipedia Commons

Page 29: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 6 / 62

Protocole IP

● IP v6● adresse sur 128 bits

* image provenant de Wikipedia Commons

Page 30: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 7 / 62

Protocole TCP

● TCP - Transmission Control Protocol● protocole de transport fiable● orienté connexion● délivre toutes les données correctement et en

séquence

● TCP (comme UDP) utilise le concept de port pour identifier l'application● à chaque extrémité (client / serveur) est associé un

numéro de port sur 16 bits

Page 31: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 8 / 62

Protocole TCP

● Structure d'un segment TCP

Page 32: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 9 / 62

Protocole TCP

● Fonctionnement en 3 phases● établissement de la connexion● transfert des données● fermeture de la connexion

● La perte d'un segment est gérée par TCP● mécanisme de temporisation et retransmission

Page 33: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 10 / 62

Protocole UDP

● UDP – User Datagram Protocol● en-tête plus simple que TCP

● permet de transférer les données très rapidement● perte occasionnelle de données tolérable● exemples d'utilisation :

– DNS – Domain Name System– TFTP – Trivial File Transfert Protocol

Page 34: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 11 / 62

Le protocole HTTP

● HTTP – HyperText Transfert Protocol● protocole client-serveur inventé par Tim Berners-Lee

– avec le langage HTML et les adresses Web● port 80 par défaut● HTTPS – variante sécurisée (port 443)● actuellement HTTP 1.1

– depuis janvier 1997– RFC 2068 et 2616

Page 35: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 12 / 62

Protocole HTTP

● Protocole sans état● le client envoie une requête

– qui comporte une commande : méthode HTTP

● le serveur lui répond

Page 36: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 13 / 62

Le protocole HTTP

● Les méthodes HTTP

● GET : demande de ressource● POST : soumission de données au serveur en vue d'un

traitement– formulaire HTLM

● OPTIONS : permet d’obtenir les méthodes supportées par le serveur

● CONNECT : utilisation d'un proxy comme tunnel de communication

● TRACE : demande au serveur de retourner ce qu'il a reçu● PUT : demande de remplacer ou d'ajouter une ressource● DELETE : demande la suppression d'une ressource

Page 37: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 14 / 62

Protocole HTTP

● HTTP permet l'identification● BASIC

– mot de passe passé en claire (base 64)● DIGEST

– souvent utilisé avec un hash MD5

● Utilisation possible du mode CLIENT-CERT● authentification mutuelle par échange de certificat

Page 38: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 15 / 62

Technologies web

● Pour créer une application web il est nécessaire de mettre en œuvre un ensemble de technologies● HTTP et TCP/IP● HTML

– différentes versions– représentation par le navigateur sous forme de DOM

● CSS● JavaScript● et autres langages

– XML, XSL, XUL, Java, Flex, ...

Page 39: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 16 / 62

Technologies web

● Difficultés des applications web● créer une application homogène avec des

technologies hétérogènes● tenir compte des différentes versions de navigateur● évolution rapide des demandes des utilisateurs

– en fonctionnalités supplémentaires– en fréquentation du site => montée en charge– en fluidité d'utilisation

● IHM limitée● nécessité d'un framework

Page 40: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 17 / 62

HTML

● Utilisé dans les navigateurs HTML est un langage de description des pages web

● HTML pour Hyper Text Markup Language● n'est pas un langage de programmation● basé sur un ensemble fini d'éléments

● Le navigateur interprète le document HTML et l'affiche comme une page web

● Les extensions standards pour les documents HTML sont htm et html● index.html ou index.html sont souvent les pages par défaut

d'un site web

Page 41: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 18 / 62

HTML

● Un tag élément HTML est constitué● d'une balise d'ouverture (start tag)

– qui peut contenir des attributs● d'un corps d'élément

– qui peut être vide, contenir du texte et/ou d'autre éléments● d'une balise de fermeture (end tag)

● Une balise est entourée par les caractères < et >● Normalement toute balise ouverte devrait-être fermée

● il existe une écriture simplifiée pour les balises sans corps– <p />

Page 42: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 19 / 62

HTML

<a href="autre_page.html">

</a>

Lien vers autre page

balise d'ouverture

corps de l'élément

balise de fermeture

attribut avec sa valeur entre " ou '

Page 43: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 20 / 62

HTML

● Structure d'un document HTML

● <html>…</html> décrit la page web● <head>…</head> contient des informations pour le

document● <bopdy>…</body> est le contenu visible de la page

<html><head>

<title>Page minimaliste</title></head><body>

<h2>Hello, world</h2></body>

</html>

Page 44: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 21 / 62

HTML

● Évolution de HTML● 1989 -> 1992

– description HTML informelle● 1993

– HTML 1.0 non officiel– langage en pleine évolution– NCSA MOSAIC invente la balise IMG et FORM

● 1994– apports de Netscape Navigator en terme de présentation– début de CSS (Cascading Style Sheet)

Page 45: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 22 / 62

HTML

● Évolution de HTML● 1995 -> 1996

– le W3C propose un brouillon de spécification HTML– RFC 1866 décrivant HTML 2.0 est finalisée fin 1995

● 1997– la spécification HTML 3.2 est publié le 3 Janvier 1997– la spécification HTML 4.0 est publiée le 18 Décembre 1997

● variante stricte (strict) qui exclut les éléments et attributs de présentation devant être remplacés par des styles CSS

● variante transitoire (transitional) étend la variante stricte en reprenant les éléments et attributs de présentation

● variante frameset qui normalise les jeux de cadres

Page 46: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 23 / 62

HTML

● Évolution de HTML● 2000 - 2006

– le développement de HTML est officiellement abandonné par le W3C au profit de XHTML

– création du WHATWG (Web Hypertext Application Technology Working Group) pour relancer le développement HTML face à la proposition du W3C

● 2007 à 2012– le W3C relance HTML pour

● faire évoluer HTML pour décrire la sémantique des documents● parvenir à un langage extensible via XML● enrichir les IHM : menus, champs associés à des types, …

– les travaux du WHATWG sont adoptés par le W3C comme point de départ de la spécification HTML 5

Page 47: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 24 / 62

HTML

● Juillet 2012● Ian Hickson (fondateur du WHATWG) prend ses

distances avec le W3C– désaccord sur la décision du W3C de découper HTML 5 en

sous -spécifications● API 2D canvas, gestion des événements, …

● le WHATWG fait évoluer sa branche de HTML 5– baptisée "Living Standard"– veut imposer une évolution de la spécification en phase avec

le marché● en moyenne il y a une mise à jour toutes les 6 semaines de Chrome

et Firefox

Page 48: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 25 / 62

HTML

● HTML 4.01 strict

● HTML 4.01 transitional

● HTML 4.01 frameset

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN" "http://www.w3.org/TR/html4/strict.dtd"><html>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd"><html>

Page 49: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 26 / 62

HTML

● XHTML 1.0 strict

● XHTML 1.0 transitional

● XHTML 1.0 frameset

● XHTML 1.1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd"><html xmlns="http://www.w3.org/1999/xhtml">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml11.dtd"><html xmlns="http://www.w3.org/1999/xhtml">

Page 50: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 27 / 62

HTML

● HTML 5● Simplification de la syntaxe

<!DOCTYPE html><html lang="fr">

Page 51: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 28 / 62

HTML

● De base les interactions avec le serveur sont très pauvres

– par rapport aux IHM classiques● clic sur une lien

– balise <a href="...">

● envoi d'un formulaire– balise <form … >

Page 52: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 29 / 62

HTML

● Ancres● élément <a> (anchor)

– hyper lien avec l'attribut href● appel d'une autre page● appel d'un index dans une autre page, ou la même page● l'attribut target peut indiquer une autre fenêtre ou onglet

● index avec l'attribut name– accessible par un hyperlien précisant l'index par #

Page 53: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 30 / 62

HTML

● Ancres

<a href="autre_page.html">Autre page</a><br /><a href="autre_page.html" target="_blank">Autre page dans un autre fenêtre</a><br /><a href="#label" target="_blank">Même page, sur un label</a><br />

...

<br /><a name="label">label</a><br />

Page 54: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 31 / 62

HTML

● Les formulaires <form> contiennent des champs <input>

● Les champs permettent à l'utilisateur d'entrer des valeurs● toutes considérées comme des champs texte● pas de vérification de validité● chaque champ peut être accompagné par une balise <label>

Page 55: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 32 / 62

HTML

● l'attribut name correspond au nom du champ tel qu'il pourra être récupéré côté serveur

● l'attribut id permettra de récupérer l'élément en JavaScript

● vrai pour tous les éléments● unique dans la page

● l'attribut value correspond à la valeur affichée et/ou saisie dans le champ

● manipulable en JavaScript● passée en association avec le nom du champ au

serveur lorsque le formulaire est envoyé

<form><label for="nom">Nom</label><input name="nom" id="nom" /><br /><label for="prenom">Prénom</label><input name="prenom" id="prenom" /><br /><input type="submit" value="Envoyer" />

</form>

Page 56: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 33 / 62

HTML

● Attributs de l'élément <form>● action : url vers laquelle le formulaire sera envoyé● method : méthode d'envoi des champs du formulaire

– GET : passage par l'URL

– POST : envoie dans le corps HTTP

● enctype : définit la méthode d'encodage du formulaire– application/x-www-form-urlencoded par défaut – pour les envoie de fichier doit être multipart/form-data

http://localhost:8080/formulaires/traitement.jsp?nom=LAGAFFE&prenom=Gaston

http://localhost:8080/formulaires/traitement.jsp

Page 57: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 34 / 62

HTML

● Types de l'élément <input>● déterminé par l'attribut type

– button : bouton cliquable pour le support JavaScript– checkbox : cases à cocher– file : permet la saisie d'un fichier à envoyer vers le serveur– hidden : champ caché– image : bouton de soumission avec image– password : champ caché à la saisie– radio : boutons de sélection exclusifs (doivent avoir la même

valeur d'attribut name)– reset : bouton de remise à zéro des champs du formulaire– submit : bouton d'envoi du formulaire– text (par défaut) : champ texte

Page 58: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 35 / 62

HTML

● Un formulaire peut aussi contenir les éléments● <select>

– liste déroulante à choix simple– ou liste à choix multiple

● <textarea> champ texte multi-lignes

● D'autres types sont introduits par HTML 5● date, time, ...

Page 59: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 36 / 62

HTML

● Champ <select>● les sélections multiples seront généralement

accessibles côtés serveur sous forme d'un tableau– en Java : request.getParameterValues("langages");

Civilité<select name="civilite">

<option value="M">M</option><option value="Mme" selected="selected">Mme</option><option value="Mlle">Mlle</option>

</select><br />Langages<br /><select name="langage" multiple="multiple">

<option value="C">C</option><option value="Cplus">C++</option><option value="Csharp">C #</option><option value="java">Java</option>

</select>

Page 60: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 37 / 62

HTML

● HTML 5 comporte de nouveaux éléments● canvas : zone dans laquelle il est possible de dessiner

– syntaxe et fonctions proche de Java– dispose des figures de base : rectangle, courbes de Bézier, arc, etc.

● audio et video: support des flux audio et vidéo– avec attributs comme start, stop, autoplay, …

● section : permet de diviser un document en parties sémantiques● implémentation de XForms

– avec des types date, time, number, …● HTML 5 est différemment supporté par les navigateurs

● continuelle évolution● cf. sites comme http://www.findmebyip.com/litmus/

Page 61: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 38 / 62

CSS

● Les styles CSS (Cascading Style Sheet) permettent de séparer la forme et le contenu● avant l'utilisation des styles CSS la mise en forme des

pages HTML était effectuée grâce aux balises HTML de présentation

● Les intérêts sont nombreux :● mutualisation des style de l'ensemble d'un site● chargement unique des feuilles de style par mise en

cache par le navigateur● adaptation au média

Page 62: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 39 / 62

CSS

● Syntaxe de base● sélecteur {propriété:valeur; propriété:valeur}

– exemple : H2{color:blue; font: 18px }

● Mise ne place des styles en interne<html><head>

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><style type="text/css">

p{color: blue;text-decoration: underline;font-size: 16pt;

}</style>

</head><body>

<p>Style paragraphe</p></body></html>

déclaration du style dans l'en-tête

le sélecteur correspond à la balise p

le navigateur applique le style

Page 63: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 40 / 62

CSS

● Feuille de style externe

● Style intra-ligne

<html><head>

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

<link rel="StyleSheet" type="text/css" href="styles.css"></head><body>

<p class="toto">Bonjour</p></body></html>

.toto{color: red;font-weight: bold;

}

styles.css

<p style="color: blue;font-style: italic">Autre style</p>

Page 64: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 41 / 62

CSS - règles

● Une règle est composé d'un sélecteur et d'un bloc de déclarationsélecteur {propriété:valeur; propriété:valeur}

● Le sélecteur identifie le style● presque tous les éléments HTML sont des sélecteurs

potentiels● des noms de sélecteurs peuvent être créés

– le nom est précédé par un point● Des commentaires peuvent être insérés

● entre /* et */

Page 65: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 42 / 62

CSS - règles

● Sélecteur classe● il est possible d'ajouter une classe à un sélecteur● il est aussi possible d'utiliser # pour spécifier l'id d'un

élément

<html><head>

<style type="text/css">p.cadre {

border: 1px;border-style: solid;border-color: blue;

}</style>

</head><body>

<p>Texte non encadré</p><p class="cadre">Texte encadré</p>

</body></html>

Page 66: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 43 / 62

CSS - règles

● Les pseudo-classes sont des classes spécifiques permettant d'obtenir des effets sur des éléments sans passer par l'attribut class

● :first-child

● :link, :visited● :hover, :active, :focus● :lang

<html><head>

<style type="text/css">a:VISITED {color: blue;}a:LINK { color:blue;}a:ACTIVE { color:blue;}a:HOVER { color:red;}

</style></head><body>

<a href="#">Lien</a></body></html>

Page 67: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 44 / 62

CSS - règles

● Les pseudo-éléments permettent d'agir sur du contenu impossible à identifier en HTML

● :first-line

● :first-letter

● :afer, :before● Règles spéciales

● @import● @media● @page

Page 68: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 45 / 62

CSS – blocs et lignes

● On distingue deux types d'éléments● les éléments blocs comme <h1>, <div>, <li>, …

– après la création d'un bloc il y a un retour à la ligne● les éléments en ligne : <a>, <img>, <span>

– après la création de l'élément il n'y a pas de retour à la ligne

● Certaines propriétés de style ne sont applicables que sur un type d'élément

● vertical-align s'applique sur les éléments en ligne

Page 69: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 46 / 62

CSS - blocs

● Un bloc(box) permet de définir la surface sur laquelle sont appliquées des propriétés● le contenu des éléments d'un document est inséré

dans un bloc– les blocs peuvent être imbriquées

● Chaque bloc est composée de plusieurs rectangles ayant des noms et des rôles spécifiques● les marges (margin)● les bordures (border)● la boîte de remplissage (padding)● la boîte de contenu (content)

Page 70: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 47 / 62

CSS - blocs

top (haut)

left (gauche)

marge (margin)

bordure (border)

remplissage (padding)

contenu (content)

limite des marges

limite des bordures

limite de la boîte de remplissage

limite de la boîte de contenu

Page 71: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 48 / 62

CSS – unités de mesure

● Une unité de mesure est composée d'un nombre suivi d'une abréviation indiquant l'unité

● Unités de longueurs relatives● em : relatif à la taille de caractère employé dans

l'élément parent (1.2em vaut 120%)● ex : relatif à la hauteur du caractère employé dans

l'élément parent● px : relatif à la résolution du support visuel

Page 72: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 49 / 62

CSS – unités de mesure

● Unités de longueurs absolues● in : pouce (inch)

● cm : centimètre

● mm : millimètre

● pt : point (1pt = 1/72in)

● pc : pica (1pc = 12pt)

● Les pourcentages (%) sont relatifs à d'autre valeurs

Page 73: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 50 / 62

CSS

● Une couleur peut être définie par● un nom : aqua, black, fuschia, gray, green, lime, …● un code couleur RGB : #RRGGBB

– RR, GG, BB sont exprimés en hexa de 0 à FF● une fonction rgb

– rgb(r,g,b) où r, g et b sont un nombre entre 0 et 255

– rgb(r%,g%,b%) où r%, g% et b% sont le pourcentage de chaque couleur

Page 74: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 51 / 62

JavaScript

● JavaScript est un langage de programmation● interprété● norme ECMA 262

– utilisable dans de nombreux environnements– système d’exploitation– navigateur– serveur– etc.

● Nous nous intéresserons ici à l ’utilisation de JavaScript dans le navigateur

Page 75: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 52 / 62

JavaScript

Intégration de JavaScript au langage HTML● par la balise <script>

● <script type="text/javascript">…</script>

● pour inclure directement les instruction JavaScript● <script type="text/javascript" src="fichier.js"></script>

● pour l ’inclusion de fichier contenant du code JavaScript● inclusion dans un attribut d ’événement d ’un élément

HTML● <a href=" … " onclick ="alert(‘ toto ’) ;">…</a>

Page 76: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 53 / 62

JavaScript

JavaScript n ’est pas un langage Objet● le langage possède des fonctions● JavaScript peut manipuler des instances de

classe● il est possible de créer des classes

JavaScript possède des classes intrinsèques● Date, String, Array, Math, ...

JavaScript utilise des objets liés à l’environnement dans lequel il est exécuté● window, navigator, document, ...

Page 77: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 54 / 62

JavaScript

La syntaxe de base de JavaScript se rapproche de celle de Java● même construction des instructions● même opérateurs de base● même construction de boucles, tests, gestion des

exception● ATTENTION : les classes ne se construisent pas

de la même manière

Page 78: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 55 / 62

JavaScript

JavaScript interagit avec le DOM du navigateurLa tendance actuelle est de créer du JavaScript "non intrusif"● la partie HTML ne comporte que du HTML● la mise en place de la gestion des événements

par JavaScript est codée en JavaScript● pas d ’affectation aux attributs d ’événement (onxxx)

Page 79: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 56 / 62

JavaScript

Un événement est un changement d'état de l'environnement qui peut être intercepté par JavaScript● click sur un élément, clavier, souris, …

Un objet Event est créé par le navigateur et mis à disposition du code JavaScript● cette mise à disposition est différente en fonction des

navigateurs

Des informations sur l'objet Event peuvent être récupérés via les propriétés de cet objet

Page 80: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 57 / 62

Les plugins

● Tout ce qui n'est pas nativement évaluer par le navigateur fait appel à des plugins● en fonction du type MIME du document

– pdf, video, audio, ...

Page 81: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 58 / 62

Serveur web

● Le serveur web doit restituer la réponse● ressource statique

– fichier html, image, pdf , etc.– un serveur http suffit

● apache, IIS

● ressources dynamiques– la ressource doit être générée dynamiquement côté serveur

● interrogation de base de données pour restituer la page

– un langage de programmation est associé● PHP, Java, VB, C#, JavaScript, ...

Page 82: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 59 / 62

Serveur web

INTERNET

SERVEURWEB

apacheIIS...

ressourcesstatiques

SI

moteur descript

scripts

Page 83: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 60 / 62

PHP

● Exemple PHP

<html> <head> <title>Exemple</title> </head> <body> Date courante : <?php print(Date("l F d, Y")); ?> </body></html>

Page 84: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 61 / 62

Java

● Exemple JSP

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%><html> <head> <title>Exemple</title> </head> <body>

<% date = new Date() %> Date courante : <%=date%> </body></html>

Page 85: Architectures distribuées

antislashn.org Architectures distribuées – couche web 02 - 62 / 62

ASP

● Exemple VB

<html><head><title>Exemple</title></head><body>

Date courante : <%=Date()%></body>

</html>

Page 86: Architectures distribuées

Architectures distribuéesArchitectures N tiers

Page 87: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 2 / 29

Serveur d'applications

● Logiciel qui offre un contexte d'exécution pour des composants applicatifs● les composants sont hébergés sur le serveur● les composants sont conformes à une spécification

– EJB, COM

● Le serveur gère des problématiques transversales aux applications● accès concurrents, sécurité, transactions, …● permet au développeur de se concentrer sur le code

métier

Page 88: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 3 / 29

Serveur d'applications

● Les clients des serveurs d'applications peuvent être● d'autres serveurs● des clients lourds● des clients légers● ...

Page 89: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 4 / 29

Serveur d'applications

● Exemple : Excel Service

source : Microsoft

Page 90: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 5 / 29

Serveur d'applications

● Exemple : Java EE

source : Oracle

Page 91: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 6 / 29

Serveur d'applications

● Exemple : WebDev

source : PC Soft

Page 92: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 7 / 29

Serveur d'applications

● Exemple : Zope

source : www.zope.org

Page 93: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 8 / 29

Serveur d'applications

● Quelques solutions libres● JBoss, JOnAS, GlassFish, Apache Geronimo● Zope

● Quelques solutions propriétaires● Oracle WebLogic, IBM WebSphere● Borland Application Server● Microsoft .NET● Sysbase EAServer● PC Soft WebDev

Page 94: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 9 / 29

Serveur d'applications

● Le serveur d'application fournit un environnement d'exécution et un ensemble de services● gestion des ressources

– connexion aux bases de données, pooling– connexion aux application tiers : MOM, connecteurs– ...

● sécurité– authentification, gestion des droits

● disponibilité– redirection transparente vers un autre serveur en cas de

plantage

Page 95: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 10 / 29

Serveur d'applications

● Outils complémentaires● console d'administration

– facilitant le paramétrage du serveur– gestion des applications

● atelier de développement– offre au développeur le moyen de réaliser simplement les

application, de les tester

Page 96: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 11 / 29

EAI

● Enterprise Application Integration● Architecture permettant à des applications

hétérogènes d'échanger des messages● EAI va gérer les flux inter-applicatifs

– notion de workflow● le middleware ne fait que véhiculer les flux entre les applications

– prend en charge la traduction des données entre les applications

Page 97: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 12 / 29

SOA

● Service Oriented Architecture● Architecture de médiation

● les services sont des composants logiciels

● Popularisé avec l'utilisation des web services● commerce électronique, B2B, B2C, …● souvent basé sur les plateformes .Net ou Java EE

● Consiste en une collection de services qui interagissent et communiques entre eux

Page 98: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 13 / 29

SOA

source : Wikipedia Commons

Page 99: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 14 / 29

SOA et ESB

● Enterprise Service Bus● L'implémentation de SOA est basée sur un bus de

services● ESB est une évolution des EAI (Enterprise

Application Integration● ESB propose une intégration distribuée via l'utilisation

de conteneurs de services– interfaces normalisées : SOAP, JMS, ...

Page 100: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 15 / 29

Web services

● Service exposé sur le web● plusieurs technologies possibles

– REST (Representational State Transfert)– SOAP (Simple Object Access Protocol)

● Concepts de base● basé sur HTTP● fournit une interopérabilité entre des applications

hétérogènes● utilise des standards et protocoles ouverts

Page 101: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 16 / 29

WOA

● Web Oriented Architecture● Implémentation SOA qui utilise le web comme

support de service● Tous les services doivent être exposés sur le web

● problème potentiel de performance

Page 102: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 17 / 29

Cloud computing

● Déport vers des serveurs distants les stockages et traitements qui traditionnellement sont localisés sur les serveurs locaux ou poste de l'utilisateur● forme d'infogérance

– l'emplacement des données n'est pas connu des clients

● Trois formes de cloud computing● cloud privé interne● cloud privé externe

– la gestion est externalisé chez un prestataire● cloud publique

Page 103: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 18 / 29

ORB

● Object Request Broker● appartient à la famille des middlewares

● Bibliothèques de fonctions implémentant un bus logiciel● les objets communiquent de manière transparente sur

le réseau– invocation à distance de la méthode d'un objet

● Deux ORB peuvent communiquer via IIOP● Internet Inter-ORB Protocol

Page 104: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 19 / 29

CORBA

● Common Object Request Broker Architecture● standard maintenu par l'OMG● CORBA est une spécification basée sur la technologie

objet● indépendant des langages

● Exposition des services par IDL● Interface Definition Language● compilation vers le langage cible

Page 105: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 20 / 29

CORBA

source : Wikipedia Commons

Page 106: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 21 / 29

RMI

● Remote Method Invocation● technologie Java● sur le principe des ORB● concurrence avec CORBA

● API Java d'invocation des méthodes distantes● mécanisme d'appel des méthodes d'objets Java

s'exécutant sur des JVM différentes● repose sur des classe Serializable● couche de transport propriétaire JRMP

– Java Remote Method Invocation basé sur TCP/IP

Page 107: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 22 / 29

RMI

Client Serveur

Stub

Serveurde noms

remiregistry

Skeleton

applicliente

objetdistant

Serveurd'objets

1 - exposer

2 - publier3 - interroger

4 - récupérer

5 – appel de méthode

6 – sérialisation desparamètres

7 – appel de la méthode

8 – valeur de retour9 – sérialisationdu résultat

10 - retour

Page 108: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 23 / 29

DCOM

● Distributed Component Object Model● technologie Microsoft● complété par .Net remoting, puis WCF (Windows

Communication Foundation)

● Permet la communication entre des composants logiciels distribués sur le réseau

Page 109: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 24 / 29

MOM

● Message Oriented Middleware● Architecture permettant l'échange de message

entre applications via le réseau● permet un couplage faible entre applications

● Deux modes de focntionnement● point à point● par abonnement

Page 110: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 25 / 29

MOM

● Fonctionnement point à point– un producteur de message envoie un message– le message est lu par un consommateur– une fois lu le message est retiré de la file d'attente

A

Producteur

B

Queue A

Queue B Consommateur B

Consommateur AA

B

Page 111: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 26 / 29

MOM

● Fonctionnement par abonnement

● Publish Subscrite

● les applications consommatrices de message s'abonnent à un sujet (topic)

● les messages restent dans la file d'attente jusqu'à ce que tous les abonnés aient lu le message

A

Producteur

B

Topic A

Topic B Consommateur

ConsommateurA

B

B

abonnement

abonnement

Page 112: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 27 / 29

MOM

● Caractéristiques● transport des messages

– un message est constitué d'une en-tête et d'un corps qui contient les données

● communication asynchrone– gestion des messages par file d'attente

● routage des messages entre MOM● transformation des données pour adaptation aux

applications réceptrice● persistance des messages● fiabilité : envoi d'un accusé de réception du message

Page 113: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 28 / 29

Google Protocol Buffer

● projet protobuf● projet Google

– développé pour des besoins RPC internes– cf. : http://code.google.com/p/protobuf/

● Protocole de sérialisation léger● pas de XML, binaire ou texte

● Basé sur l'exposition des structures par des fichiers proto● puis compilation vers C++, Java ou Python

Page 114: Architectures distribuées

antislashn.org Architectures distribuées – N tiers 03 - 29 / 29

En résumé

ApplicationA

ApplicationB

middleware

ORB

MOM

EAI

ESBSOA

WOA

EAI : Enterprise Application IntegrationSOA : Service Oriented ArchitectureWOA : Web Oriented ArchitectureESB : Entreprise Service BusORB : Object Request BrokerMOM : Message Oriented Midddleware

Page 115: Architectures distribuées

Architectures distribuéesXML

Page 116: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 2 / 44

XML - introduction

● XML : eXtensible Markup Language● langage à balises

– dérivé de SGML (Standard Generalized Markup Language)● prévu pour structurer les données

– HTML est aussi un langage à balises, mais utilisé pour l'affichage des pages Web

● les balises ne sont pas définies– contrairement à HTML où le nom des balises et des attributs

est défini● spécification du consortium W3C

Page 117: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 3 / 44

XML - introduction

● La spécification XML est très simple● une multitude d'autres spécifications viennent

compléter cette spécification de base

● Des API simplifient la manipulation par programme des documents XML● SAX : Simple API for XML● DOM : Document Object Model

● Des outils permettent de vérifier la syntaxe XML● les parsers

Page 118: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 4 / 44

XML - introduction

● XML est lisible● juste du texte structuré par les balises

● XML ne fait rien, mais il s'est imposé comme un standard● fichiers de configuration● échange de données● description de protocole● structuration de données● sérialisation● etc.

Page 119: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 5 / 44

XML - introduction

● Exemples de fichiers XML

<carnet-adresse><societe>

<nom>Toto and co</nom><adresse>rue de Paris</adresse>

</societe><personne>

<nom>Dupond</nom><societe>Toto and co</societe>

</personne><personne>

<nom>Lagaffe</nom><societe>Toto and co</societe>

</personne></carnet-adresse>

<carnet-adresse><societe>

<nom>Toto and co</nom><adresse>rue de Paris</adresse><personne>

<nom>Dupond</nom></personne><personne>

<nom>Lagaffe</nom></personne>

</societe></carnet-adresse>

Page 120: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 6 / 44

XML - introduction

● Le document XML forme un arbre● dans les exemples précédents la racine de cet arbre

est l'élément <carnet-adresse>

● Chaque élément peut avoir des attributs et un contenu● le contenu peut-être du texte et/ou d'autres éléments

Page 121: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 7 / 44

XML - syntaxe

● Un document XML est constitué● d'un prologue (optionnel)

● de l'instance du document– au minimum une racine

● élément qui encapsule tout le reste● un document XML vide n'est pas un fichier vide

<?xml version="1.0" encoding="UTF-8"?>

Page 122: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 8 / 44

XML - syntaxe

● Constitution d'un élément● balise d'ouverture

– qui contient les éventuels attributs● corps de l'élément

– qui contient du texte et/ou d'autres éléments● balise de fermeture● un élément qui ne contient rien peut être fermé

aussitôt

<message type="email">

</message>

<br></br> <br />

Page 123: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 9 / 44

XML - syntaxe

● Les éléments doivent être inclus les uns dans les autres● sans chevauchement des balises d'ouverture et

fermeture● seule la racine n'est pas incluse dans un autre élément

<a><b></b>

</a>

<a><b></a>

</b>

Page 124: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 10 / 44

● XML est "case sensitive"● Les valeurs des attributs doivent être entre

guillemets ou apostrophes● Les espaces sont préservés en XML● Commentaire XML

● débute par <!--● fini par -->● les commentaires ne peuvent pas être imbriqués

<!-- ceci est un commentaire XML -->

Page 125: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 11 / 44

XML - syntaxe

● Certains caractères ont un usage spécial : les entités● 5 entités prédéfinies

● une entité peut aussi correspondre à un caractère particulier, un fichier, une suite de caractères– correspond à une "unité de stockage"

&lt ; >

&gt ; <

&amp ; &

&apos ; ' (apostrophe)

&quot ; " (guillemets)

Page 126: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 12 / 44

XML - syntaxe

● Le nom d'un élément ou attribut● peut contenir des lettres, des chiffres, et les caractères

– tiret bas _– tiret -– point .– deux points :

● doit débuter par une lettre ou le tiret bas _● ne doit pas débuter par le mot xml

– que ce soit en minuscule ou majuscule● ne peut pas contenir d'espace

Page 127: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 13 / 44

XML – les parsers

● Les parsers sont des applications qui analysent les documents XML● vérifient si le document est bien formé (well formed)

– le document respect alors la syntaxe de base XML● peuvent vérifié si le document est valide (valid)

– le document est bien formé et valide par rapport à son schéma

● DTD ou XML Schema

● remplacent les entités par leur contenu

Page 128: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 14 / 44

XML – les parsers

● Certaines parties du document ne doivent pas être analysés par les parsers● JavaScript d'un document XHTML par exemple● les sections sont alors maquées comme CDATA

– commence par <![CDATA[

– fini par ]]><script>

<![CDATA[function minimum(a,b){

if(a<b)return a ;

elsereturn b ;}

]]></script>

Page 129: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 15 / 44

XML – espaces de nommage

● Des éléments de même noms peuvent se trouver dans même document XML, mais avec des significations différentes

● les éléments <nom> ont des structures et une signification différente

● on associe alors les éléments à un espace de nom– cette association est effectuée dans la racine– mot clé xmlns : suivi par le nom de l'espace de nommage

et une URI (Uniform Resource Identifier)

<societe><nom>Dupond and co</nom></societe><salarie><nom num="123">Gaston LAGAFFE</nom></salarie>

Page 130: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 16 / 44

XML – espaces de nommage

● Exemple

<soc :carnet-adressesxmlns:soc="http://www.antislahsn.org/catalogue/societe"xmlns:ctc="http://www.antislahsn.org/catalogue/contact">

<societe><nom>Dupond and co</nom>

</societe><salarie>

<ctc:nom num="123">Gaston LAGAFFE</ctc:nom></salarie>

</soc:carnet_adresses>

Page 131: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 17 / 44

XML – espaces de nommage

● La racine peut avoir un espace de nommage par défaut● xmlns n'est pas suivi d'un nom pour l'espace de

nommage

<carnet-adressesxmlns="http://www.antislahsn.org/catalogue/societe"xmlns:ctc="http://www.antislahsn.org/catalogue/contact">

<societe><nom>Dupond and co</nom>

</societe><salarie>

<ctc:nom num="123">Gaston LAGAFFE</ctc:nom></salarie>

</carnet_adresses>

Page 132: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 18 / 44

XML – espaces de nommage

● Les espaces de nommage jouent un rôle important dans les schémas● les spécifications des fichiers de configuration des

serveurs sont formés de plusieurs schémas provenant d'espaces de nommage différents

<web-appxmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns="http://java.sun.com/xml/ns/javaee"xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"id="WebApp_ID" version="2.5">

…</web-app>

Page 133: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 19 / 44

XML – les schémas

● Dans les faits, les noms des éléments et attributs d'un fichier XML sont fixés

● de manière informelle● ou de manière formelle par les schémas

● Plusieurs spécifications existent

● XML Schema– la plus utilisée maintenant, spécification du W3C

● DTD : Document Type Definition– historiquement première spécification

– de moins en moins utilisé, sauf pour des schémas très simples

● Relax NG– alternative à XML Schema, utilisé par OpenDocument

Page 134: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 20 / 44

DTD

● La DTD permet de définir la structure du document XML, en déclarant les éléments et les attributs● la DTD peut aussi contenir

– des déclarations d'entités– des déclarations de notations

● spécifie le format de données non XML, binaire ou texte

– des commentaires

Page 135: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 21 / 44

DTD

● La DTD est liée au document XML par la directive SGML <!DOCTYPE >● elle peut être interne au document XML

● elle peut être externe au document XML

● peut être un mixte des deux

<!DOCTYPE racine [declarations DTD] >

<!DOCTYPE racine SYSTEM "file.dtd" >

<!DOCTYPE racine PUBLIC "fpi" "url" >

<!DOCTYPE racine SYSTEM "file.dtd" [autres declarations DTD] >

Page 136: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 22 / 44

DTD

● Généralement les DTD sont externes au document XML● peut être SYSTEM

– DTD privée à une entreprise, disponible via un chemin fichier

● ou PUBLIC– DTD publique disponible via internet– définie par un FPI (Format Public Identifier) qui est associée

à une URL

● Les diapositives suivantes présentent la structure de base des DTD● cf. la spécification pour plus de détails

Page 137: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 23 / 44

DTD

● Exemple de DTD externe (extraits)

● et déclaration dans le fichier XML

<?xml version="1.0" encoding="UTF-8"?><!ELEMENT carnet-adresses (contact*,entreprise*)><!ELEMENT contact (civilite,nom,prenom,telephones?,emails?,adresse?)><!ELEMENT telephones (telephone)*>

...

<!ELEMENT ville (#PCDATA)><!ELEMENT pays (#PCDATA)>...<!ATTLIST adresse type (prive|pro) #REQUIRED>

<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE carnet-adresses SYSTEM "carnet-adresses.dtd"><carnet-adresses>...

Page 138: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 24 / 44

DTD

● Déclaration des éléments● l'élément racine est déclaré dans < !DOCTYPE … >● chaque élément est ensuite déclaré dans<!ELEMENT ...>

● Un élément défini son contenu● liste d'éléments fils● vide : EMPTY● chaîne de caractère : #PCDATA● n'importe quel contenu : ANY

Page 139: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 25 / 44

DTD

● Liste ordonnée d'élément fils

● Choix d'un élément

● Nombre d’occurrences● par défaut : 1 occurrence● + : 1 à n fois● * : 0 à n fois● ? : 0 ou 1 fois

<!ELEMENT carnet-adresses (entreprise,contact) >

<!ELEMENT carnet-adresses (entreprise | contact) >

<!ELEMENT carnet-adresses (entreprise*,contact*) >

Page 140: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 26 / 44

DTD

● Les attributs sont déclarés dans <!ATTLIST ...>● on y retrouve

– le nom de l'attribut– l'élément auquel il appartient– son type– sa déclaration par défaut

<!ATTLIST contact entreprise IDREF #IMPLIED><!ATTLIST entreprise id ID #REQUIRED><!ATTLIST telephone type (fixe_prive|portable_prive|fixe_pro|portable_pro|fax_prive|fax_pro) #REQUIRED><!ATTLIST email type (prive|pro) #REQUIRED><!ATTLIST adresse type (prive|pro) #REQUIRED>

Page 141: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 27 / 44

DTD

● Principaux types d'attributs● CDATA : chaîne de caractères

● ID : identifiant unique dans le document XML

● IDREF : référence à un attribut de type ID● IDREFS : référence à une liste d'attributs de type ID

– séparateur : espace

● autres types possibles : énumération, ENTITY, ENTITIES, NMTOKEN, NMTOKENS, NOTATION– cf. la spécification pour plus de précision

Page 142: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 28 / 44

DTD

● La DTD est très simple à lire● Mais

● non XML● peu modularisable● peu typée

● XML Schema remédie aux défauts des DTD● mais plus complexe à lire, et à écrire

Page 143: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 29 / 44

XML Schema

● Recommandation du W3C● Définit la structure d'un document XML de

manière plus complète qu'une DTD● typage des données● espaces de nommage● syntaxe XML● création de types personnalisés

● Plus complexe à écrire d'une DTD● un outil constitue une aide appréciable

– XMLSpy, Oxygen, EditiX, éditeurs des EDI

Page 144: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 30 / 44

XML Schema

● Exemple (extrait)<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified"attributeFormDefault="unqualified"><xs:element name="carnet-adresses">

<xs:complexType><xs:sequence>

<xs:element ref="contact" minOccurs="0" maxOccurs="unbounded"/><xs:element ref="entreprise" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType>

</xs:element>…</xs:schema>

<?xml version="1.0" encoding="ISO-8859-1"?><carnet-adresses

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="carnet-adresses.xsd">

…</carnet-adresses>

Page 145: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 31 / 44

XML Schema

● L'écriture d'un XML Schema est plus complexe qu'une DTD● les outils permettent un développement du schema de

manière graphique

Page 146: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 32 / 44

XML Schema

● Élément racine du XML Schema

● décrit la version utilisée● peut décrire des espaces de nommage

● Un élément peur être● un élément simple

– sans élément fils, sans attribut● un élément complexe

– avec un (des) élément(s) fils– et/ou un (des) attribut(s)

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

Page 147: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 33 / 44

XML Schema

● Définition d'un élément simple● contient un contenu typé

– pas d'élément fils– pas d'attribut– xs:string par défaut

<xs:element name="nom" type="xs:string"/>

Page 148: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 34 / 44

XML Schema

● Définition d'un élément complexe● définition des éléments fils

– sequence : liste ordonnée

– choice : un seul des éléments fils doit être présent

– all : liste non ordonnée

<xs:element name="carnet-adresses"><xs:complexType>

<xs:sequence><xs:element ref="contact" minOccurs="0" maxOccurs="unbounded"/><xs:element ref="entreprise" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType>

</xs:element>

Page 149: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 35 / 44

XML Schema

● Définition des attributs d'un élément complexe● définition après les éléments fils

<xs:element name="entreprise"><xs:complexType>

<xs:sequence><xs:element name="raison_sociale" type="xs:string"/><xs:element ref="adresse"/><xs:element name="web"/>

</xs:sequence><xs:attribute name="id" type="xs:ID" use="required"/>

</xs:complexType></xs:element>

élément fils définit dans l'élément père

l'élément fils référencie un élément définitailleurs dans le fichier

Page 150: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 36 / 44

XML Schema

● XML Schema dispose d'un ensemble de types simples● cf. page suivante● est utilisé par certains web services● possibilité de créer ses propre types

– par restriction sur des valeurs d'un type simple● avec les facettes : valeurs mini, maxi, tailles mini, maxi, …● des expressions régulières● des énumérations

– par extension d'un type existant

Page 151: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 37 / 44

XML Schema

Page 152: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 38 / 44

XML Schema

● Définition d'un type personnalisé● s'appuie sur un type existant

<xs:simpleType name="type_numero_telephone"><xs:restriction base="xs:string">

<xs:pattern value="([0-9]{2}[ -]?){4}[0-9]{2}"/></xs:restriction>

</xs:simpleType>

Page 153: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 39 / 44

XML Schéma

● Utilisation des espaces de nom● attributs définis dans l'élément <Schema ...>

– elementFormDefault="qualified"● les éléments sont situé dans l'espace de nommage cité, ou par

défaut

– attributeFormDefault="unqualified"● les attributs sont dans l'espace de nom de l'élément

Page 154: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 40 / 44

XML Schema

● Un schema peut être constitué de plusieurs documents● insertion simple

– tous les éléments sont inclus dans le même espace de nommage que le schema récepteur

● insertion avec espace de nommage– les éléments inclus possède un espace de nommage

différent du schema récepteur

<xs:include schemaLocation="autreSchema.xsd"/>

<xs:include nameSpace="autre.namespace"schemaLocation="autreSchema.xsd"/>

Page 155: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 41 / 44

XML Schema<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="n1" attributeFormDefault="qualified">

<xs:element name="personne"> <xs:complexType> <xs:sequence> <xs:element name="nom"/> <xs:element name="prenom"/> <xs:element name="age" type="xs:int"/> </xs:sequence> </xs:complexType> </xs:element></xs:schema>

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="n2"> <xs:element name="personne"> <xs:complexType> <xs:sequence> <xs:element name="civilite"/> <xs:element name="nom"/> <xs:element name="prenom"/> </xs:sequence> </xs:complexType> </xs:element></xs:schema>

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:na1="n1" xmlns:na2="n2" elementFormDefault="qualified">

<xs:import namespace="n1" schemaLocation="name1.xsd"/> <xs:import namespace="n2" schemaLocation="name2.xsd"/> <xs:element name="contacts"> <xs:complexType> <xs:sequence> <xs:element ref="na1:personne"></xs:element> <xs:element ref="na2:personne"></xs:element> </xs:sequence> </xs:complexType> </xs:element></xs:schema>

Page 156: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 42 / 44

XML – quelques spécifications

● XPath● langage de sélection de portions de document XML

● XSL – eXtensible Stylesheet Language● langage de description de feuille de style● utilisé avec un processeur XSLT pour transformer un

document XML en au autre document en lui appliquant le style décrit dans la feuille de style

● XQuery● langage de requête sur des documents XML

Page 157: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 43 / 44

XML – quelques spécifications

● SVG – Scalable Vector Graphic● format de données de description de graphiques

vectoriels

● SMIL – Synchronized Multimedia Integration Language● langage de création de présentation multimédia

● MathML● langage permettant l'affichage des symboles

mathématiques

Page 158: Architectures distribuées

antislashn.org Architectures distribuées – XML 04 - 44 / 44

XML - ressources

● Sites webs● http://www.w3.org/● http://www.w3schools.com/● http://www.quackit.com/xml/

Page 159: Architectures distribuées

Architectures distribuéesJava EE

Page 160: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 2 / 117

Introduction

● Le développement d'applications doit répondre à de nombreuses problématiques● rapidité du développement● prise en compte de l'évolution de l'application● montée en charge des connexions● sécurisation

● Java EE – Java Enterprise Edition● réponse Sun – Oracle au développement d'applications

distribuées en entreprise

Page 161: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 3 / 117

Introduction

● Java EE● ensemble d'API

– facilite la réutilisation– réduction du temps de développement– "automatisation" des facettes techniques des l'application

distribuées● sous le contrôle du JCP (Java Community Process)

– maintient la cohérence de l'ensemble des spécifications Java– via les JSR (Java Specification Request)

Page 162: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 4 / 117

Introduction

● Le développeur se concentre sur le cœur métier de l'application● utilisation du langage Java● en général codage de POJO

– Plain Old Java Object

● Java EE simplifie le déploiement et la mise en place des aspects techniques de l'application● sécurisation, montée en charge, transactions● par un modèle déclaratif

– fichiers XML ou annotations

Page 163: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 5 / 117

Introduction

● Exemple de POJOpublic class Ville implements Serializable{

private String codePostal;private String nom;

public Ville(){}public Ville(String nom, String codePostal){

this.codePostal = codePostal;this.nom = nom;

}

public String getCodePostal(){return codePostal;

}public void setCodePostal(String codePostal){

this.codePostal = codePostal;}

public String getNom(){return nom;

}public void setNom(String nom){

this.nom = nom;}

}

propriétés privées

constructeur par défaut

méthodes getteur / setteurpour chaque propriété privée

classe sérialisablepeut posséder un SerialVersionID

Page 164: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 6 / 117

Introduction

● Simplification du code par injection des ressources● il n'est plus nécessaire de trouver les objets dans un

contexte JNDI avant de les utiliser– Java Naming and Directory Interface

● injection de dépendance via les annotations

InitialContext ctx = new InitialContext();ILocalVilleFacade bean = (ILocalVilleFacade)ctx.lookup(jndiName);

@EJB private ILocalVilleFacade bean;

Page 165: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 7 / 117

Introduction

● Java EE favorise une architecture N tiers● tiers client sur la machine cliente

– client léger, ou client lourd (swing)● sur le serveur Java EE

– couche web– couche métier– couche SI

Page 166: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 8 / 117

Introduction

● Application N tiers

Page 167: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 9 / 117

Serveur Java EE

● Un serveur Java EE est constitué de conteneurs– conteneur Web– conteneur EJB

● Un conteneur gère le cycle de vie des applications qui y sont déployées● et donc des objets codés par le développeur

● Le conteneur fournit des services● sécurité, transaction , recherche JNDI, connectivité,

transactions, sources de données, etc,

Page 168: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 10 / 117

Serveur Java EE

Page 169: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 11 / 117

Déploiement des applications Java EE

● Les applications Java EE peuvent être déployées sous forme● d'archive web : fichier .war (web archive)● d'archive jar : fichier .jar (java archive)● d'archive ear : fichier .ear (enterprise archive)

Page 170: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 12 / 117

Équipe Java EE

● Les modules Java EE permettent également une distribution des responsabilités au sein de l'équipe de développement● développement de la couche métier

– les EJB, la couche de persistance● développement de la couche web● développement des applications swing● équipe de déploiement et d’administration des

serveurs

Page 171: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 13 / 117

Java EE - les technologies

● Technologies dans les couches applicatives

Page 172: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 14 / 117

Java EE - les technologies

● Couche métier : EJB – Enterprise Java Bean● EJB Session : interaction avec le client

– sans état (stateless) : service métier● calcul d'un taux d'intérêt

– avec état (stateful) : objet métier● panier d'achat● pas de persistance en base

● EJB MDB (Message Driven Bean)– gestion de le réception de messages en mode asynchrone– architecture MOM (Message Oriented Middleware)

● utilise JMS (Java Message Service)

Page 173: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 15 / 117

Java EE - les technologies

● Couche Web● servlet : classe Java invoquée lors des requêtes HTTP● JSP (JavaServer Page) : page compilée par le serveur

pour répondre aux requêtes HTTP– comparable aux technologies PHP, ASP, …

● JSF (JavaServer Faces) : framework de construction de la couche web– composants graphiques sophistiqués

● validation des formulaires, gestion des événements, gestion de la navigation entre les pages, ...

Page 174: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 16 / 117

Java EE - les technologies

● Couche de persistance● JPA (Java Persistence API)

– remplace les EJB entités de la version EJB 2– utilisable aussi avec JSE

● liaison déclarative entre le modèle métier et le modèle de données– annotations ou fichier XML

● langage de requêtes orienté objet

Page 175: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 17 / 117

Java EE - les technologies

● Les services● transaction : JTA (Java Transaction API)● web services● injection de ressources

– JSR 316 : Managed Bean● injection de ressources, intercepteurs, méthodes callback sur le

cycle de vie

– JSR 299 : CDI (Context and Dependency Injection)● utilisation des EJB dans la technologie JSF

● Java EE Connector Architecture– adaptateurs de ressources pour les SI tiers

Page 176: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 18 / 117

Java EE - les technologies

● Les services● JavaMail API : service d'envoi de mails● JAAS (Java Authentification and Authorization Service)

– gestion de groupes d’utilisateurs, de leur authentification et de leurs droits

● et bien d'autres– JMS, JNDI, JDBC, ...

Page 177: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 19 / 117

Java EE - les EJB

● Java EE utilise les EJB (Java Enterprise Beans) pour coder la couche métier● appelés aussi beans, enterprise beans

● Les beans sont gérés par le conteneur d'EJB● permet l'accès de manières transparentes aux

services du conteneur– transaction, sécurité

● Le client du bean n'invoque jamais directement les méthodes du composant

Page 178: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 20 / 117

Java EE - les EJB

● Les EJB sont utilisés si● votre application doit être évolutive

– en terme de fonctionnalités– en terme de type de clients utilisé– en terme de montée en charge

● votre application doit utiliser les transactions● votre application doit être sécurisée

Page 179: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 21 / 117

Java EE - les EJB

● Les types d'EJBs● les EJB de session

– Avec ou sans état (Stateless ou Stateful)● dialoguent avec le client

● les EJBs orientés message– Message-driven– consommateurs de messages dans les architectures

MOM (Middlewares Orientés Messages)

● Les EJB 2 entités ont été remplacés par les entités JPA

Page 180: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 22 / 117

Java EE – les EJB

● Le conteneur gère l'accès aux méthodes de l'EJB● permet de vérifier la sécurité, les transactions, etc

● Le client dialogue avec un proxy (stub)● interface exposant les méthodes accessible par le

client– en mode local – dans la même JVM que le serveur

● passage des paramètres par référence

– en mode distant (remote) – via le réseau● utilisation de RMI et de la sérialisation● passage des paramètres par copie

Page 181: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 23 / 117

Java EE – les EJB

● Pour être disponible, l'EJB est inscrit dans un annuaire JNDI● le serveur y inscrit l'interface exposant les méthodes

de l'EJB

● Le client récupère un stub en interrogeant l'annuaire JNDI● par une méthode lookup("nomJndiEjb")● par injection via l'annotation @EJB● le nom est différents en fonction du stub distant ou

local

Page 182: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 24 / 117

Java EE – les EJB

● Une fois le stub récupéré, le client appel les méthodes métiers● le conteneur EJB va vérifier la validité des appels

– le client n'invoque pas directement les méthodes du composant

Client ProxyClient Proxy EJB

Page 183: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 25 / 117

Java EE – les EJB

SERVEUR JEE

ConteneurServlet/JSP

Conteneur EJB

EJBInterpos ition loc ale

Interposition distante

stub

Client distantJava SE

(possède aussi un stub)

servlet

NavigateurHTTP

RMI

Page 184: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 26 / 117

Java EE – les EJB

● Rôle des beans de session● ce sont les intermédiaires entre les applications

clientes et les entités– les beans entités accèdent aux données

● permettent de fournir des services aux applications clientes– récupération d'une liste de produit– vérification d'une quantité en stock– enregistrement d'un profil

Page 185: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 27 / 117

Java EE – les EJB

● Il existe deux types de beans de session● les Session Beans Stateless

– collection de service dont chacun correspond à une méthode du bean

– pas d'état de conservé entre deux appels de méthode● Les Session Beans Stateful

– notion de session entre le client et le serveur– chaque instance du bean stateful est lié à un client

Page 186: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 28 / 117

Java EE – les EJB

● Conditions d'utilisation d'un bean de session● à un instant donné, seulement un client a accès à

l'instance du bean de session● non persistance de l'état du bean

– existe pour quelques heures● le service peut aussi être accessible par Web Service

– bean stateless uniquement

● le bean stateful permet en plus de représenter une interaction entre le bean et un client

Page 187: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 29 / 117

Java EE – les EJB

● Bean stateless

● fonctionne en mode déconnecté– plusieurs clients utilisent une même instance– le client invoque une méthode (service) qui retourne un

résultat● aucun état conservé au sein du bean entre deux appels

● utilisé pour des services ne nécessitant pas de suivi entre deux appels– service autonome

● service de calcul d'intérêt● service de conversion monétaire

Page 188: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 30 / 117

Java EE – les EJB

● Bean stateless

1 instancede bean stateless

N clients

Page 189: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 31 / 117

Java EE – les EJB

● Cycle de vie d'un bean stateless

● le conteneur va :– instancier le bean– injecter les dépendances éventuelles

● annotations @EJB, @Resource– appeler les méthodes de type callback

interceptors● annotées avec @PostConstruct,...

Page 190: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 32 / 117

Java EE – les EJB

● Cycle de vie d'un bean stateless

N'existe pas

Pool des méthodes prêtes

Appel du callback PreDestroy1 – newInstance()2 – injection des dépendances3 – appel du callback PostConstruct

Page 191: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 33 / 117

Java EE – les EJB

● Bean stateful

● maintient un état conversationnel avec le client qui l'utilise– un client est associé à une instance de bean

stateful– une méthode peut lire et modifier des propriétés du

bean● utilisé pour des services nécessitant d'avoir un

suivi entre deux appels de méthode– gestion d'un caddie d'achat– gestion d'une inscription sur plusieurs écrans

Page 192: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 34 / 117

Java EE – les EJB

● Bean stateful

N clients

1 instance

1 instance

1 instance

Page 193: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 35 / 117

Java EE – les EJB

● Cycle de vie du bean stateful

● le conteneur va :– instancier le bean– injecter les dépendances éventuelles

● annotations @EJB, @Resource– appeler les méthodes de type callback

interceptors● annotées avec @PostConstruct,...

Page 194: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 36 / 117

Java EE – les EJB

N'existe pas

Méthodes prêtes Passif

Timeout

Timeout

callback PrePassivate

1- newInstance()2 - injection des dépendances3 - appel du callback PostConstruct4 – appel méthode init()

callback PrePassivate

callback PreDestroy

Page 195: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 37 / 117

Java EE – les EJB

● Codage d'un bean de session

● coder les interfaces présentant les méthodes accessibles– une interface pour les méthodes accessibles en

local● appel direct en mémoire● le client est dans la même JVM que le bean● automatique à partir de Java EE 6

– une interface pour les méthodes accessibles à distance (remote)

● appel par RMI

Page 196: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 38 / 117

Java EE – les EJB

● Codage d'un bean de session● les interfaces sont marquées avec les

annotations @Remote ou @Local– package javax.ejb

● l'annotation peut ne pas être présente sur l'interface et reportée sur la classe d'implémentation– l'interface y est alors précisée

● @Remote(value={IRemoteCalcul.class})

Page 197: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 39 / 117

Java EE – les EJB

● Codage d'un bean de session

● la classe d'implémentation du bean– hérite des interfaces– est annotée par @Stateless ou @Stateful

● l'exemple suivant montre la structure d'un Session Bean stateless, il est constitué– d'une super-interface ICalcul– des interfaces d'exposition des méthodes métiers IRemoteCalcul et IlocalCalcul

– de la classe d'implémentation CalculBean

Page 198: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 40 / 117

Java EE : couche de persistance

● Les spécifications EJB 3 ne traitent pas directement de la couche de persistance● la couche de persistance était mise en place avec

EJB2 par les CMP (Container Managed Persistence) et BMP (Bean Managed Persistence)

● La couche de persistance est spécifiée par JPA● Java Persistence API

● JPA peut-être utilisée au sein d'un serveur ou dans une application autonome

Page 199: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 41 / 117

Java EE – les EJB

● Exemple de code

[email protected]

41

public interface ICalcul{

public int additionner(int a, int b);public int soustraire(int a, int b);public int multiplier(int a, int b);public int diviser(int a, int b);

}

import javax.ejb.Remote;

@Remotepublic interface IRemoteCalcul extends ICalcul{}

import javax.ejb.Local;

@Localpublic interface ILocalCalcul extendsICalcul{

public String[] getOperationsDsiponibles();}

import javax.ejb.Stateless;

@Statelesspublic class CalculBean implements ILocalCalcul, IRemoteCalcul{ … }

EJB 3

Page 200: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 42 / 117

Java EE – les EJB

● Déploiement du bean● compilation des classes● création d'un fichier archive JAR

– Calcul.jar

● copie du fichier JAR dans le répertoire de déploiement de votre serveur– JBoss : .../server/default/deploy

Page 201: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 43 / 117

Java EE – les EJB

● Pour utiliser un bean de session , le client doit récupérer une référence

● Si le client est un client autonome, la recherche est effectuée via un contexte JNDI

● Si le client est dans la même machine virtuelle que le serveur, ou s'il est lancé via l'ACC (Application Client Container), l'annotation @EJB est utilisable

Page 202: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 44 / 117

Java EE – les EJB

● Exemple de recherche par le contexte JNDI● l'annotation @EJB permet d'éviter ce code

try{

InitialContext ctx = new InitialContext();IRemoteCalcul calcul = (IRemoteCalcul) ctx.lookup("CalculBean/remote");System.out.println(calcul.additionner(10,25));

}catch (NamingException e){

e.printStackTrace();}

Page 203: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 45 / 117

Java EE – les EJB

● Le codage d'un stateful reste équivalent à celui d'un stateless● utilisation de l'annotation @Stateful

● Le conteneur EJB ne pouvant pas déterminer la fin de l’utilisation d'un stateful, il faut que le client appel une méthode marquée par @Remove● sinon le conteneur lance un timeout

● Attention : à chaque appel de la méthode lookup(...) une instance de bean est crée

Page 204: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 46 / 117

Java EE – les EJB

● Les intercepteurs

● les beans de session supportent les intercepteurs suivants :

– @PostConstruct : invoqué après l'injection des dépendances

– @PreDestroy : invoqué au moment ou l'instance est détruite

– @PrePassivate : invoqué avant la passivation (stateful uniquement)

– @PostActivate : invoqué lorsque le bean est réactivé (stateful uniquement)

● la signature des méthodes est :– public void methode(InvocationContext ctx)

Page 205: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 47 / 117

Java EE – les EJB

● Des intercepteurs peuvent aussi être utilisés sur les appels des méthodes métiers● les méthodes d'interceptions ont la signature :

– public Object methode(InvocationContext ctx) throws Exception

● elles sont annotées par @AroundInvoke...@AroundInvokepublic Object interception(InvocationContext ctx) throws Exception{

System.out.println("<<< Avant appel de "+ctx.getMethod().getName());Object result = ctx.proceed();System.out.println("<<< Après appel de "+ctx.getMethod().getName());return result;

}...

Page 206: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 48 / 117

Java EE – les EJB

● Bean MDB● Message Driver Bean● rôle de traitement des messages

– consommateur de messages● le codage du MDB sous-entend qu'il existe un

producteur de messages– une autre application– un autre module de la même application

Page 207: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 49 / 117

Java EE – les EJB

● Cycle de vie d'un MDB

N'existe pas

Pool des méthodes prêtes

Appel du callback PreDestroy1 – newInstance()2 – injection des dépendances3 – appel du callback PostConstruct

timeout

exécution de la méthode

méthodes message listener

Page 208: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 50 / 117

Java EE – les EJB

● Codage d'un MDB● l'annotation @MessageDriven marque la

classe– l'attribut name permet de fixer le nom du MDB– un attribut activationConfig permet de

configurer les propriétés du MDB● type de destination● nom JNDI de la destination

● l'implémentation de l'interface MessageListener est nécessaire si le MDB travaille avec JMS

Page 209: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 51 / 117

Java EE – les EJB

● Codage d'un MDB

@MessageDriven(name="ReceptionCommande",activationConfig={

@ActivationConfigProperty(propertyName="destinationType",propertyValue="javax.jms.Queue"),

@ActivationConfigProperty(propertyName="destination",propertyValue="queue/B"),

@ActivationConfigProperty(propertyName="acknowledgeMode",propertyValue="Auto-acknowledge")})

public class ReceptionCommande implements MessageListener{

@Resource private MessageDrivenContext ctx;

public void onMessage(Message message){

System.out.println("<<< Confirmation de commande a reçu " + message);}

}

Page 210: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 52 / 117

Java EE – les EJB

● Service Timer

● permet l'appel retardé de méthode● permet la planification de tâches● utilisable sur les bean stateless ou orienté message

● Utilisation du service Timer● définir la méthode devant être appelée par le Timer● annotée avec @Timeout● une seule méthode par classe

● signature : void <nomMethode>(Timer timer)● accéder au service Timer et le créer

Page 211: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 53 / 117

Java EE – les EJB

● Codage de la méthode appelée par le timer

● Accès au service

@Timeoutpublic void envoyerMail(Timer timer){

System.out.println(">>>> ENVOI MAIL");}

@Resource TimerService timerService;

Page 212: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 54 / 117

Java EE : couche de persistance

● JPA nécessite une implémentation de persistance● Hibernate 3● TopLink Essential● Openjpa

● Eclipselink

● Les serveurs Java EE fournissent une implémentation par défaut

Page 213: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 55 / 117

Java EE : couche de persistance

● Objectifs de JPA● fournir une vue orientée Java de la persistance

– approche standardisée– utilisation des meilleurs concepts de Hibernate,

JDO● travailler avec des POJO● supporter les concepts objets

– polymorphisme, héritage● éliminer le codage des requêtes SQL

– requêtes en JPQL

Page 214: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 56 / 117

Java EE : couche de persistance

● JPA implémente la couche d'accès aux données● retourne des objets du domaine comme réponse aux

requêtes● persiste les objets du domaine

Application

JPA

objets

Bases de données

mappingconfig

Page 215: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 57 / 117

Java EE : couche de persistance

● Le mapping est effectué à l'aide d'annotations sur le POJO● peut aussi être effectué dans un fichier XML

@Entitypublic class Contact {

@Id@GeneratedValue(strategy=GenerationType.AUTO)private int id;private String civilite;private String nom;private String prenom;

…}

Page 216: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 58 / 117

Java EE : couche de persistance

● La configuration est effectuée via le fichier META-INF/persistence.xml

<persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd" version="1.0"> <persistence-unit name="jpa"> <provider>org.hibernate.ejb.HibernatePersistence</provider> <properties> <property name="hibernate.show_sql" value="false"/> <property name="hibernate.format_sql" value="false"/>

</persistence>

Page 217: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 59 / 117

Java EE : couche de persistance

● Développement avec JPA● écrire la classe Java qui suit la spécification

JavaBean– fournir un constructeur sans argument– chaque propriété est associée à des méthodes

get/set● fournir une propriété représentant la clé

primaire– c'est avec cette propriété que l'ORM maintient le

lien entre l'instance et l'enregistrement en base

Page 218: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 60 / 117

Java EE : couche de persistance

● Développer avec JPA● annoter la classe avec @Entity● annoter les propriétés

– l'identifiant avec @Id– par défaut toutes les propriétés sont persistées

● annoter avec @Transient si une propriété ne doit pas être persistée

● les annotations peuvent être mises sur les propriétés ou les méthodes get/set

Page 219: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 61 / 117

Java EE : couche de persistance

● Développer avec JPA● au minimum deux annotations sont nécessaires

– @Entity pour marquer la classe– @Id pour l'identifiant

● par défaut le nom de la classe correspond au nom de la table– sinon utiliser l'annotation @Table

● par défaut les noms des colonnes correspondent aux nom des propriétés– sinon utiliser l'annotation @Column

Page 220: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 62 / 117

Java EE : couche de persistance

● L'utilisation de JPA nécessite une interaction avec un EntityManager● fournit les opérations de création, recherche, mise à

jour et de suppression● une instance d'EntityManager est fournie par le

serveur– par injection avec l'annotation @PersistenceContext

● si JPA est utilisé dans une application autonome il faut utiliser un EntityManagerFactory

Page 221: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 63 / 117

Java EE : couche de persistance

● Le fichier persistence.xml définit :● le nom de l'unité de persistance

– élément <persistence-unit>● la classe implémentant JPA

– élément <provider>● la connexion à la source de données

– via JNDI sur le serveur, avec les éléments <jta-data-source> ou <non-jta-data-source>

– ou par les propriétés fournies à l'implémentation de JPA, avec les éléments <properties> et <property>

Page 222: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 64 / 117

Java EE : couche de persistance

● Récupération d'un EntityManager dans une application autonome● on précise le nom de l'unité de persistance définie

dans le fichier persistence.xml

● La récupération d'un EntityManager peut-être effectuée par injection dans un EJB

EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpa");em = emf.createEntityManager();

@PersistenceContext(unitName="jpa") private EntityManager em;

Page 223: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 65 / 117

Java EE : couche de persistance

● Toutes les opérations effectuées sur l'EntityManager doivent être effectuées dans une même transaction

public void save(Contact contact){

EntityTransaction transaction = em.getTransaction();transaction.begin();em.persist(contact);transaction.commit();

}

Page 224: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 66 / 117

Java EE : couche de persistance

● Opérations de base sur l'EntityManager

● sauvegarde des entités avec persist(…)● récupération d'un objet par son identifiant : find(…)

● suppression d'une entité en base : remove(…)● mise à jour de la base avec l'objet : merge()● mise à jour de l'objet avec la base : refresh()● les modifications sur les objets sont propagées

vers la base lors du commit sur la transaction

Page 225: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 67 / 117

Java EE : couche de persistance

● Cycle de vie des entités

transient

managed

detached

remove()persist()

merge()refresh()

sortie du contexte(servlet,client lourd, …)

instance

new()

find()query()

Page 226: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 68 / 117

Java EE : couche de persistance

● JPA gère les différentes relations entre les classes● objets embarqués● liaisons entre classe

– 1-to-1 , 1-to-n, n-to-n– en tenant compte de la visibilité entre les classes

● liaison unidirectionnelle ou bidirectionnelle

● héritage entre classes– plusieurs stratégies de gestion des tables en base

Page 227: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 69 / 117

Java EE : couche de persistance

● Exemple de mapping 1-to-n● les associations plusieurs-vers-un sont

déclarées au niveau de la propriété avec l'annotation @ManyToOne

<<entity>>Contact

idcivilitenomprenom

<<entity>>Adresse

idruecodePostalville

1*X

Page 228: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 70 / 117

Java EE : couche de persistance

● La liaison est décrite dans la classe Contact

@Entitypublic class Contact {

@Id@GeneratedValue(strategy=GenerationType.AUTO)private int id;private String civilite;private String nom;private String prenom;@ManyToOne(cascade=CascadeType.ALL)@JoinColumn(name="ke_adresse")private Adresse adresse;

…}

Page 229: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 71 / 117

Java EE : couche de persistance

● Langage JPQL : Java Persistence Query Language

● langage similaire à SQL– mais JPQL permet une approche objet du

requêtage● SQL est basé sur la connaissance des structures de la

base● JPQL est basé sur la connaissance du modèle objet

● la recherche des adresses est effectuée par– SELECT * FROM table_adresses en SQL– from Adresse en JPQL

Page 230: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 72 / 117

Java EE : couche de persistance

● Exemple de création d'une requête JPQL● ici une requête nommée mise en place par annotation

● utilisation de la requête

…@NamedQueries({

@NamedQuery(name="CDAudio.getParArtiste",query="from CDAudio cd where cd.artiste = :artiste")

})public class CDAudio extends Produit{…

public List<CDAudio> getCDAudiosParArtiste(String artiste){

Query query = em.createNamedQuery("CDAudio.getParArtiste");query.setParameter("artiste", artiste);return query.getResultList();

}

Page 231: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 73 / 117

Java EE – couche web

● Application Web● ensemble des ressources nécessaires au bon

fonctionnement d'un site Web

– pages HTML, JSP, classes compilées des servlets, images, fichiers PDF, etc

● une application Web Java est prise en charge par un conteneur de Servlet/JSP

– Tomcat est l'implémentation de référence● projet de la fondation Apache● vérifier la version de Tomcat en fonction des

spécifications servlet/JSP utilisées

Page 232: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 74 / 117

Java EE – couche web

● Une application Web peut être déployée dans une archive

● WAR (Web Archive)

● l'archive peut être incluse dans une archive EAR (Enterprise Archive)

– seulement dans les serveur d'application● JBoss, WebSphere, WebLogic, Geronimo, GlassFish, ...● pas sous Tomcat

Une application Web Java doit obéir à une structure de répertoire

racine de l'application

répertoire obligatoire, contient le fichier descripteur web.xml

contient les classes compilées de l'application

contient les librairies tierces

Page 233: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 75 / 117

Java EE – couche web

● Technologies utilisées● servlet – classe java compilée

– possède des méthodes callback correspondant aux méthodes HTTP

● JSP (JavaServer Page) – HTML + Java– page traduite en servlet, puis compilée par le serveur

● taglib – couche technique permettant d'ajouter des éléments personnalisés aux JSP

● EL (Expression Language) – permet l'accès aux objets de la page dans des expressions

● JSF (JavaServer Faces) – framework de développement de site web

Page 234: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 76 / 117

Java EE – couche web

● Composants d'un conteneur de servlet / JSP

Server

Service

Connector HTTP

Connector AJP

Connector HTTPS

port 8080

port 8443

port 8009

Engine

Host

Context Context

Page 235: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 77 / 117

Java EE – couche web

● Fichier web.xml● descripteur de déploiement standard de l'application web

– mis en place dans le répertoire WEB-INF de l'application– élément racine <web-app>

● Contient les déclarations

– des servlets– des listeners– des filtres– des paramètres– etc

Page 236: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 78 / 117

Java EE – couche web

● Les servlets● héritent de la classe HttpServlet● possèdent des méthodes en doXxx

– Xxx correspond à une méthode HTTP● POST → doPost(...), GET → doGet(...), etc.

public class HelloServlet extends HttpServlet {

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException

{PrintWriter out = response.getWriter();out.println("<html><head></head>");out.println("<body>");out.println("<h2>Hello world !!!</h2>");out.println("</body></html>");

}}

Page 237: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 79 / 117

Java EE – couche web

● La servlet● doit-être déclarée dans le fichier WEB-INF/web.xml● ceci consiste à :

– associer la classe de la servlet avec un nom qui servira d'alias

– associer des URL avec le nom de la servlet– l'appel de la ressource associée à la servlet sera du type– http://hote:port/<nom application>/<url servlet>

● exemple : http://localhost:8080/test/hello

Page 238: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 80 / 117

Java EE – couche web

● Les servlets... <servlet> <servlet-name>HelloServlet</servlet-name> <servlet-class>test.servlet.HelloServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>HelloServlet</servlet-name> <url-pattern>/HelloServlet</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>HelloServlet</servlet-name> <url-pattern>/hello</url-pattern></servlet-mapping>...

Page 239: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 81 / 117

Java EE – couche web

● La servlet doit être compilée● la classe compilée doit être déployée dans le répertoire

WEB-INF/classes● les outils de développement automatisent les étapes de création

et de compilation

● L'application doit être déployée sur le serveur● par copie du répertoire racine dans le répertoire de déploiement● par copie de l'archive dans le répertoire de déploiement● par l'outil de développement● par l'interface de gestion du serveur

Page 240: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 82 / 117

Java EE – couche web

● Le conteneur gère le cycle de vie de la servlet● instanciation, appel des méthodes

instanciation de la classe

init()service()

destroy()

requête HTTP servlet chargé ?

non

oui

classe changée

?non

oui

déchargement de l'instance

Page 241: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 83 / 117

Java EE – couche web

● Les servlets● les méthodes doXXX ont toutes la même signature

public void doGet(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException

● les paramètres reçus encapsulent la requête et la réponse

– HttpServletRequest permet de récupérer les informations de la requête HTTP

– HttpServletResponse permet de manipuler la réponse HTTP renvoyée

Page 242: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 84 / 117

Java EE – couche web

● JSP● utiliser uniquement des servlets implique le mélange

de code Java et de code HTML– lisibilité réduite– maintenance difficile

● une page JSP est un document texte basé sur du HTML contenant des éléments JSP– la base du document peut-être aussi du XHTML, XML, SVG,

WML– l'extension de la page JSP est jsp

Page 243: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 85 / 117

Java EE – couche web

● JSP – syntaxe standard

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <title>Test JSP</title></head><body> <% String message = "Hello world"; %> <h2><%=message %></h2></body></html>

Page 244: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 86 / 117

Java EE – couche web

● JSP – syntaxe XML<?xml version="1.0" encoding="ISO-8859-1" ?><jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"> <jsp:directive.page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1" /> <jsp:text> <![CDATA[ <?xml version="1.0" encoding="ISO-8859-1" ?> ]]> </jsp:text> <jsp:text> <![CDATA[ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> ]]> </jsp:text>

<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /><title>Insert title here</title></head><body><jsp:scriptlet>String message = "bonjour";</jsp:scriptlet><h2><jsp:expression>message</jsp:expression></h2></body></html></jsp:root>

Page 245: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 87 / 117

Java EE – couche web

● Contrairement à une servlet le développeur n'a pas à s'occuper de la compilation et du déploiement d'une page JSP

● la page JSP est considérée comme une ressource du site, à l'instar des pages HTML

● Le conteneur gère le cycle de vie de la page JSP● traduction de la page vers un source Java● compilation du source● instanciation de la classe● appel de la méthode service(...)

Page 246: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 88 / 117

Java EE – couche web

● JSP – cycle de vie

page JSP

changée ?

traduction de la JSP en Java

compilation de la classe

classe chargée

?

déchargement de l'instance

instanciation de la classe

service(...)

requête HTTP

réponse HTTP

oui

non

oui

non

Page 247: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 89 / 117

Java EE – couche web

● JSP – syntaxe de base● commentaires

– ne sont pas envoyés au navigateur– syntaxe standard : <%-- commentaire --%>

● déclaration– déclare des variables ou méthodes pour la page– attention : les objets serveurs ne sont pas utilisables dans

les déclarations– sera traduite par des propriétés et méthodes de classe

● syntaxe standard : <%! code java%>

Page 248: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 90 / 117

Java EE – couche web

● JSP – syntaxe● expression

– évalue l'expression et l'envoie dans le flux de sortie– attention : pas de point virgule après l'expression– syntaxe standard : <%= expression %>

● scriptlet– fragment de code java– sera exécutée côté serveur– peut utiliser des éléments déclarés et des objets serveurs– syntaxe standard : <% code java%>

Page 249: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 91 / 117

Java EE – couche web

● JSP – objets implicites

objet scope utilisation principale

request requête même que HttpServletRequest

response page même que HttpServletResponse

pageContext page manipulation d'attributs

session session manipulation d'attributs

application application manipulation d'attributs

out page flux de sortie

config page récupération de paramètres de configuration

exception page dans page d'erreur uniquement, instance d'Exception

Page 250: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 92 / 117

Java EE – couche web

● Les listeners● lors des constructions et destructions de session des

événements sont générés par le conteneur– interface HttpSessionListener

● le listener doit être déclaré dans le fichier web.xml de l'application

public class SessionListener implements HttpSessionListener { public void sessionCreated(HttpSessionEvent evt) { System.out.println("Debut de session pour "+evt.getSession().getId()); }

public void sessionDestroyed(HttpSessionEvent evt) { System.out.println("Fin de session pour "+evt.getSession().getId()); }}

<listener> <listener-class>test.servlet.SessionListener</listener-class> </listener>

Page 251: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 93 / 117

Java EE – couche web

● Les listeners● le conteneur peut nous avertir lors des phases de

démarrage et de repli de l'application– interface ServletContextListener

● le listener doit être déclaré dans le fichier web.xml de l'application

<listener> <listener-class>test.servlet.ApplicationListener</listener-class> </listener>

public class ApplicationListener implements ServletContextListener {

public void contextInitialized(ServletContextEvent evt) { System.out.println("DEBUT APPLICATION"); }public void contextDestroyed(ServletContextEvent evt) {System.out.println("FIN APPLICATION"); }}

Page 252: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 94 / 117

Java EE – couche web

● EL (Expression Language)● simplifie la manipulation des expressions dans les

pages JPS● permet d'accéder simplement aux objets des différents

contextes● forme générale : ${expression}

– peut-être composée de plusieurs termes séparés par des opérateurs : ${exp1 OP exp2} ou ${OP exp}

– permet de simplifier l'accès aux propriétés d'un objet● ${objet.propriete} ou ${objet[index]}

– au lieu de <%=objet.getPropriete()%>

Page 253: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 95 / 117

Java EE – couche web

● Les tag lib● éléments personnalisés évalués par le conteneur● objectif : enlever le code Java des pages JSP

– remplacement par des tag : boucle, test, …● un certain nombre de tags a été spécifié et a donné naissance à

la JSTL (Java Standard Tag Lib)● les librairies JSTL sont identifiées par

– une librairie : un jar– une URI– un préfixe d'utilisation dans la page JSP

Page 254: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 96 / 117

Java EE – couche web

● La librairie est déclarée dans la page JSP

● Exemple d'utilisation

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %><%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %><%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %><%@ taglib uri="http://java.sun.com/jsp/jstl/sql" prefix="sql" %><%@ taglib uri="http://java.sun.com/jsp/jstl/xml" prefix="xml" %>

...<c:forEach items="${ destination.dates}" var="sejour" varStatus="st">

<c:if test="${st.count % 2 == 0 }"><c:set var="couleur" value="LightSteelBlue"/>

</c:if><c:if test="${st.count % 2 != 0 }">

<c:set var="couleur" value="white"/></c:if><fmt:setLocale value="fr" />

...

Page 255: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 97 / 117

Java EE – couche web

● En plus des fonctionnalités de base la JSTL permet● la manipulation XML● les requêtes SQL● la localisation

● EL est utilisable dans les tag● L'enrichissement de EL et des librairies permet

d'arriver à JSF

Page 256: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 98 / 117

Java EE – couche web

● JSF : frameworks serveur de composants de présentation, utilisé pour le développement d'application Web

● JSF est défini dans la spécification JSR 127 (Java Specification Request)

– version 1.0 parue en Mars 2004● plusieurs implémentations sont proposées

– Sun, IBM, Oracle, MyFaces (open source), etc.● respecte une architecture MVC

– utilise des classes pour le contrôleur et le traitement de requête● inclut la validation des entrées côté serveur

– la vue est construite par des balises personnalisées JSP et le langage à expression JSF (JSF-EL : JSF Expression Language)

– pas de support pour le modèle

Page 257: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 99 / 117

● JSF – présentation● au démarrage du serveur, le composant JSF FacesServlet lit

le fichier faces-config.xml

– faces-config.xml décrit le flux applicatif entre les pages et les beans managés

– FacesServlet achemine la requête vers un bean managé

– le bean managé● délègue les appels métiers aux objets de la couche

modèle● donne le contrôle à la vue appropriée

– les pages JSP● les pages JSP sont créées par le développeur

Page 258: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 100 / 117

Java EE – couche web● JSF préconise l'utilisation des composants graphiques (UI pour User Interface)

● une page HTML est une collection de composants graphiques comme peut l'être un JPanel

● chaque composant peut posséder sa propre collection de gestionnaires d'événements

● Composants graphiques :

● UIForm, UIInput, UISelect: composants d'un formulaire HTML

● UICommand: bouton de soumission et lien hypertexte

● UIOutput, UIMessage: affichage des messages et des erreurs

● UIData, UIColumn: affichage des tables HTML

● UIPanel: regroupement de composants, comme un JPanel

● UIGraphic: images

● L'API peut être étendue pour créer ses propres composants

● comme les composants de Java Swing

Page 259: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 101 / 117

Java EE – couche web

● JSF fonctionne au sein d'une application Web● la spécification Sun doit être respectée● le fichier web.xml permet la prise en compte de JSF

fichier de configuration pour JSF

Page 260: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 102 / 117

Java EE – couche web

● JSF – fichier web.xml

<?xml version="1.0" encoding="UTF-8"?><web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xmlns=http://java.sun.com/xml/ns/javaeexmlns:web=http://java.sun.com/xml/ns/javaee/web-app_2_5.xsdxsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"id="WebApp_ID" version="2.5">

<display-name>Inscription</display-name><servlet>

<servlet-name>Faces Servlet</servlet-name><servlet-class>javax.faces.webapp.FacesServlet</servlet-class><load-on-startup>1</load-on-startup>

</servlet><servlet-mapping>

<servlet-name>Faces Servlet</servlet-name><url-pattern>/faces/*</url-pattern>

</servlet-mapping><welcome-file-list>

<welcome-file>index.jsp</welcome-file></welcome-file-list>

</web-app>

servlet de gestion des mécanismes JSF

mapping des JSP avec la servlet JSF

Page 261: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 103 / 117

Java EE – couche web

● Le traitement des JSF repose sur une certain nombre de tâches

● extraction des données de la requête, validation des données, exécution de la logique métier, etc.

● JSF fournit une approche logique

● tout le travail de base est effectué par JSF

– le développeur peut se consacrer à la logique métier et au rendu HTML

Page 262: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 104 / 117

Java EE – couche web

● Les requêtes suivent le cycle de traitement suivant :

1.rétablissement de la vue – reconstruction de l'arborescence des composants

2.récupération des données de requête

3.traitement des validations

4.mise à jour des valeurs du modèle

5.appel de la logique métier

6.création du rendu de la réponse

Page 263: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 105 / 117

Java EE – couche web

● JSF - traitements

Page 264: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 106 / 117

Java EE – couche web

● JSF – cycle de vie

Page 265: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 107 / 117

Java EE – couche web

● JSF – cycle de vie : rétablissement de la vue● lors de cette étape, une représentation de la vue client est construite côté

serveur

– créée et sauvée dansjavax.faces.context.FacesContext

– sauvegarde les données de la requête

UIViewRoot

HtmlForm

HtmlMessage

HtmlInputText

HtmlMessage

HtmlInputText

HtmlMessage

HtmlInputText

HtmlMessage

HtmlSelectOneMenu

HtmlCommandButtonUISelectItem UISelectItem UISelectItem

Page 266: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 108 / 117

Java EE – couche web

● JSF – cycle de vie : récupération des données de la requête● chaque nœud de la vue côté serveur est mis à jour avec

les données correspondantes au côté client

– ce processus est nommé decoding– sauvegarde côté serveur au format String

● les composants possédant un attribut value implémentent ValueHolder

– par exemple, HTML label, select

Page 267: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 109 / 117

Java EE – couche web

● JSF – cycle de vie : récupération des données de la requête (suite)● les composants avec un value en saisie implémentent EditableValueHolder

– par exemple, HTML text, password, textarea● les composants à l'origine d'actions (buttons) implémentent ActionSource

– par exemple, boutons HTML submit

Page 268: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 110 / 117

Java EE – couche web

● JSF – cycle de vie : traitement des validations● d'abord les données sont converties dans le types

appropriés● ensuite, si une validation est requise, elle est appliquée

– la validation est demandée par un attribut de la page JSP

– un composant qui n'est pas validé positionne sa propriété valid à false

● FacesMessage est ajouté à FacesContext

Page 269: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 111 / 117

Java EE – couche web

● JDF – cycle de vie : mise à jour du modèle● si une donnée est correctement convertie et validée, elle

est utilisée pour mettre à jour la propriété du bean managée à laquelle elle est liée

Page 270: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 112 / 117

Java EE – couche web

● JSF – cycle de vie : appel de la logique métier● JSF diffuse les événements vers des listeners● les listeners s'exécutent, en invoquant du code applicatif

– en fonction du résultat du code applicatif, le listener renvoie un règle de navigation

● définit quelle page doit être utilisée pour le rendu de la réponse

Page 271: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 113 / 117

Java EE – couche web

● JSF – cycle de vie : création du rendu● deux tâches doivent être entreprises

1.renvoyer le rendu vers l'utilisateur

2.sauver l'état de la vue afin de la restituer dans la phase rétablissement de la vue si celle-ci est demandée de nouveau

● sauvegarde dans le contexte session● JSF utilise l'objet HttpSession des applications Web en

Java

Page 272: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 114 / 117

Java EE – couche web

● JSF – les beans managés● POJO qui conservent l'état des données de l'application

– leur cycle de vie est géré par le conteneur– ils possèdent un constructeur par défaut, sans

argument– les propriétés suivent les conventions de nommage

JavaBean● ils sont enregistrés dans un fichier de configuration pour

pouvoir être utilisés par l'application JSF● les bean sont utilisables dans toute page JSP via le

langage EL

– en lecture et écriture

Page 273: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 115 / 117

Java EE – couche web

● JSF – modèle de navigation● JSF possède un gestionnaire de navigation qui contrôle le

flux applicatif● les règles de navigation peuvent être statiques ou

dynamiques● ces règles sont définies dans le faces-config.xml

● chaque règle de navigation possède un <from-view-id> qui identifie la vue source

Page 274: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 116 / 117

Java EE – couche web

● JSF – modèle de navigation (suite)● la destination est indiquée par un ou plusieurs éléments, <navigation-case> décrivant la vue suivante

– <from-action>: identifie à quelle méthode action s'applique la règle de navigation

● nécessaire si plus d'une méthode retourne un from-outcome associé

– <from-outcome>: valeur de type String retournée par une méthode action identifiant le cas de navigation à utiliser

– <to-view-id>: page qui sera envoyée à l'utilisateur pour le<from-outcome>

Page 275: Architectures distribuées

antislashn.org Architectures distribuées – Java EE 05 - 117 / 117

Java EE

● Pour résumer

Page 276: Architectures distribuées

Architectures distribuéesLes web services

Page 277: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 2 / 42

Introduction

● Web service● service permettant l'échange de données entre

systèmes et applications hétérogènes● ensemble de fonctionnalités exposées sur Internet ou

sur un intranet● le web service est donc avant tout un service accessible

via le réseau internet– via le protocole HTTP (ou HTTPS)– ne présuppose en rien d'une technologie ou d'un protocole

particulier

Page 278: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 3 / 42

Introduction

● Approche technologiques possibles● web services de type WS-*

– reposent sur l'utilisation de SOAP et WSDL● WS-* pour l'ensemble des spécifications utilisées

● web services de type REST– Representational State Transfert– repose sur l'utilisation des méthodes HTTP

Page 279: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 4 / 42

REST

● REST : Representation State Transfert● style d'architecture de services Web qui part du

principe que HTTP suffit pour invoquer un service web (au sens exposé sur le web)

– en utilisant l'ensemble des méthodes HTTP (GET, POST, PUT, DELETE), et sans utiliser SOAP et XML-RPC

● REST n'est pas une spécification, c'est un pattern de communication

● l'information échangée peut être sous forme POX, JSON, YAML

Page 280: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 5 / 42

REST

● JSON : JavaScript Object Notation● format d'échange "humain compatible" (human

readable)● RFC 4627● souvent utilisé pour la sérialisation et la transmission

d'objets en Ajax{

"civilite":"M","prenom":"Gaston","nom":"LAGAFFE","adresse":{

"rue":"Rue de Bruxelles","ville":"Paris","codePostal":"75000"

}}

Page 281: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 6 / 42

REST

● POX : Plain Old XML● format d'échange XML utilisant la spécification de base

de XML– sans y mêler d'autre spécifications

<?xml version="1.0" encoding="ISO-8859-1"?><identite>

<civilite>M</civilite><prenom>Gaston</prenom><nom>LAGAFFE</nom><adresse>

<rue>Rue de Bruxelles</rue><ville>Paris</ville><code-postal>75000</code-postal>

</adresse></identite>

Page 282: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 7 / 42

REST

● YAML : YAML Ain't Markup Language● l'idée de base est de structurer l'information pour que

celle-ci soit lisible par l'homme et analysable sans ambiguïté par une machine

# identitécivilite: Mnom: Gastonprenom: LAGAFFEadresse:

rue: Rue de Bruxellesville: PariscodePostal: 75000

Page 283: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 8 / 42

Communication via SOAP

client

annuaire des web services

UDDI

point d'accès

implémentation interne en Java, C#, …, ou autre

WSDL

4 – réponse SOAP

3 – requête SOAP

1 – localisation du service

2 – demande du WSDL

Page 284: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 9 / 42

Définitions

● WSDL – Web Service Description language● la version 2.0 est une recommandation du W3C● les versions précédentes n'ont pas été approuvées par le W3C

● décrit un web service– protocole de communication : SOAP RPC ou SOAP orienté

message– méthodes invocables, paramètres, type de retour– localisation du service

● description abstraite des opérations possibles et des messages

Page 285: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 10 / 42

Définitions

● SOAP● Simple Object Access Protocol si en mode RPC

(Remote Procedure Call)● Service Oriented Architecture Protocole si en mode

message● permet la transmission de messages entre objets

distants

Page 286: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 11 / 42

SOAP

● SOAP● protocole de communication● communication entre applications● format d'échange de messages● indépendant de tout langage● basé sur XML● recommandation du W3C

Page 287: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 12 / 42

SOAP

● SOAP est un document XML composé● d'une enveloppe <Enveloppe> identifiant le document

XML comme un message SOAP● d'une en-tête facultative <Header>● d'un corps de message obligatoire <Body> contenant

les informations de requête ou de réponse– qui peut contenir un éventuellement élément <Fault>

contenant la description des erreurs● de la description du type d'encodage utilisé pour la

sérialisation et la dé-sérialisation des données– attribut encodingStyle

Page 288: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 13 / 42

SOAP

● L'enveloppe SOAP est elle-même incluse dans la partie body du protocole de transmission● HTTP par exemple

<soapenv:Enveloppe…xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/>

</soapenv:Enveloppe>

<soapenv:Header>

</soapenv:Header>

<soapenv:Body>

</soapenv:Body>

facultatif

obligatoirepeut contenir un élément<Fault>

Page 289: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 14 / 42

SOAP

Application cliente du web service

Java, C#, PHP, …

proxy SOAP client

langage vers XML

construction requête SOAP

XML vers langage

décodage réponse SOAP

Applicationweb service

Java, C#, PHP, …

proxy SOAP serveur

langage vers XML

construction réponse SOAP

XML vers langage

invocation

décodage requête SOAP

Page 290: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 15 / 42

SOAP

● SOAP définit plusieurs méthodes pour envoyer en XML les données échangées entre les applications● RPC : Remote Procedure Call

– appel de méthode– le corps du message SOAP contient le nom de la méthode à

invoquer● et les paramètres envoyés

● Document (message)– échange de messages– pas de règle de format du corps du message SOAP

Page 291: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 16 / 42

SOAP

● SOAP définit aussi le type d'encodage pour la sérialisation et la dé-sérialisation

● encoded

– règle d'encodage définie par SOAP 1.1● sous la référence "section 5 encoding"

– spécifie comment les objets, structures, tableaux, graphes sont sérialisés

● literal – les données sont sérialisées en accord avec un schéma

XML● aucune règle prédéfinie● en pratique utilisation de la spécification du W3C XMLSchema

Page 292: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 17 / 42

SOAP RPC

● Approche aisée pour le développement● car utilise par défaut le mode encoding

● Il s'agit d'un appel d'une méthode distante en passant tous les paramètres nécessaires● le proxy SOAP client sérialise les paramètres et l'appel

vers le format XML● le transport des informations est effectué via HTTP● le proxy SOAP serveur dé-sérialise les paramètres de

l'appel et invoque la méthode dans le langage natif

Page 293: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 18 / 42

SOAP RPC

● La valeur de retour de la méthode invoquée est prise en charge par la couche SOAP serveur● même mécanisme que pour l'appel de la méthode

– sérialisation par la couche SOAP serveur, et dé-sérialisation par la partie SOAP client

● SOAP – RPC autorise aussi l'encodage littéral– envoie d'une partie d'arbre XML par exemple– la couche SOAP n'a alors qu'un paramètre à

sérialiser

Page 294: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 19 / 42

SOAP RPC

● Requête SOAP-RPC

<soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/xmlns:ns0=http://metier.antislashn.orgxmlns:xsd=http://www.w3.org/2001/XMLSchemaxmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body><ns0:getHello>

  <nom soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/xsi:type="xsd:string">toto</nom>

  </ns0:getHello>  </soapenv:Body></soapenv:Envelope>

appel de la méthodegetHello

encodage utilisé

passage du paramètre

Page 295: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 20 / 42

SOAP-RPC

● Réponse SOAP-RPC

<soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/xmlns:xsd=http://www.w3.org/2001/XMLSchemaxmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body><ns1:getHelloResponse xmlns:ns1=http://metier.antislashn.org

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><getHelloReturn xsi:type="xsd:string">Hello, toto</getHelloReturn>

</ns1:getHelloResponse> </soapenv:Body></soapenv:Envelope>

encodage utilisé

retour de la méthodegetHello

Page 296: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 21 / 42

SOAP-Document

● Le consortium W3C préconise l'utilisation de SOAP Document

● La couche SOAP envoie le document complet au serveur sans attendre le résultat de retour

● Le message peut contenir n'importe quel type de données XML

● En mode Document le développeur peut choisir :● le mode de transport : HTTP, SMTP, MOM, …

● la sérialisation

● format de l'enveloppe SOAP

● en pratique les proxys fournissent un mode fonctionnement par défaut

Page 297: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 22 / 42

SOAP-Document

● L'élément <Body> contient une ou plusieurs parties● il n'y a pas de règle de format sur ce que le <Body> doit

contenir– la seule règle est l'accord entre le client et le web service sur

le contenu– les frameworks type Axis rendent transparente l'utilisation du

mode Document● les proxys client et serveur sont générés symétriquement par le

framework

Page 298: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 23 / 42

SOAP-Document

● Requête SOAP-Document

<soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/xmlns:q0=http://metier.antislashn.orgxmlns:xsd=http://www.w3.org/2001/XMLSchemaxmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body><q0:getHello><q0:nom>toto</q0:nom>

</q0:getHello></soapenv:Body>

</soapenv:Envelope>

appel de la méthodegetHello

passage du paramètrepas de précision sur l'encodage

Page 299: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 24 / 42

SOAP-Document

● Réponse SOAP-Document

<soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/xmlns:xsd=http://www.w3.org/2001/XMLSchemaxmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body><getHelloResponse xmlns="http://metier.antislashn.org"><getHelloReturn>Hello, toto</getHelloReturn>

</getHelloResponse></soapenv:Body>

</soapenv:Envelope>

retour de la méthode getHellopas d'encodage précisé

Page 300: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 25 / 42

SOAP : retour d'erreur

● En cas d'erreur, la réponse peut contenir des erreurs HTTP ou SOAP● Une erreur SOAP contient l'élément <Fault>

qui contient :– <Code> code d'erreur (obligatoire)– <Reason> explication sur l'erreur (obligatoire)– <Node> nœud SOAP source de l'erreur (facultatif)– <Role> rôle du nœud SOAP (facultatif)– <Detail> informations supplémentaires (facultatif)

Page 301: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 26 / 42

SOAP : gestion des attachements

● Une URI peut être précisée● Un flux binaire codé en base 64● Utilisation de SOAP Message with Attachment

● MIME pour web services● transmet les flux par SOAP en utilisant MIME/Multipart

● Utilisation de WS-Attachments● Utilisation de XOP (XML-Binary Optimized

Packaging)

Page 302: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 27 / 42

WSDL

● WSDL pour Web Service Description Language● document XML● décrit un web service● localise le web service● spécification du consortium W3C

Page 303: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 28 / 42

WSDL : structure

● Un Web service est décrit par les éléments principaux :● <types> : types de données du web service

● <message> : les messages utilisés par le web service

– en entrée et en sortie, avec précision des paramètres

● <portType> : interface, opérations abstraites proposées par le web service

● <binding> : liaison avec l'implémentation concrète du service, protocoles et formats d'échange

● <service> : adresse du service, le plus souvent une URL invoquant un service SOAP

– comporte un ensemble de ports (endpoints)

Page 304: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 29 / 42

WSDL : <portType>

● Définit l'interface du web service

● Les opérations qui sont prises en charge par le web service

● les messages qui participent à l'invocation complète de l'opération

● une opération peut être comparée à une fonction

● C'est le point d'entrée du web service● Peut être comparé à une librairie de fonctions

Page 305: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 30 / 42

WSDL : <portType>

● Types d'opérations applicables● One-way : opération recevant un message et ne

retournant pas de réponse● Request-response : opération recevant une requête et

retournant une réponse– la plus courante

● Solicit-response : opération pouvant envoyer une requête et attendre une réponse

● Notification : opération pouvant envoyer un message et n'attendant pas de réponse

Page 306: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 31 / 42

WSDL : <binding>

● Définit le format et le protocole du message● <binding> a deux attributs

– name : nom du binding– type : port du binding

● <soap:binding> liaison avec l'implémentation– style : format (rpc ou document)– transport : protocole utilisé

● <operation> définit les opérations exposées– pour chaque opération une action SOAP est définie

Page 307: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 32 / 42

WSDL

● En général les WSDL sont générés par les frameworks, ou les outils de développement● à partir de Java EE 5 et en utilisant les annotations le

serveur génère le WSDL

● Le WSDL décrit l'utilisation du web service, il est donc différent selon le SOAP utilisé

● rpc ou document● encoded ou literal

Page 308: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 33 / 42

WSDL pour SOAP-RPC

● Extrait <message>

<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions targetNamespace=http://metier.antislashn.org

xmlns:apachesoap=http://xml.apache.org/xml-soapxmlns:impl=http://metier.antislashn.orgxmlns:intf=http://metier.antislashn.orgxmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<wsdl:message name="getHelloRequest"><wsdl:part name="nom" type="xsd:string" />

</wsdl:message><wsdl:message name="getHelloResponse"><wsdl:part name="getHelloReturn" type="xsd:string" />

</wsdl:message>……

</wsdl:definitions>

type d'encodage

déclaration des messages etdes paramètres

Page 309: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 34 / 42

WSDL pour SOAP-RPC

● Extrait <portType>

<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions targetNamespace=http://metier.antislashn.org

xmlns:apachesoap=http://xml.apache.org/xml-soapxmlns:impl=http://metier.antislashn.orgxmlns:intf=http://metier.antislashn.orgxmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/xmlns:xsd="http://www.w3.org/2001/XMLSchema">

…<wsdl:portType name="Hello"><wsdl:operation name="getHello" parameterOrder="nom"><wsdl:input message="impl:getHelloRequest" name="getHelloRequest" /><wsdl:output message="impl:getHelloResponse" name="getHelloResponse" />

</wsdl:operation></wsdl:portType> …

</wsdl:definitions>

description des opérationsdisponibles sur le web service

Page 310: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 35 / 42

WSDL pour SOAP-RPC

● Extrait <binding><?xml version="1.0" encoding="UTF-8"?><wsdl:definitions targetNamespace=http://metier.antislashn.org

…<wsdl:binding name="HelloSoapBinding" type="impl:Hello"><wsdlsoap:binding style="rpc"transport="http://schemas.xmlsoap.org/soap/http" />

<wsdl:operation name="getHello"><wsdlsoap:operation soapAction="" /><wsdl:input name="getHelloRequest"><wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"namespace="http://metier.antislashn.org" use="encoded" />

</wsdl:input><wsdl:output name="getHelloResponse"><wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"namespace="http://metier.antislashn.org" use="encoded" />

</wsdl:output></wsdl:operation>

</wsdl:binding>…

</wsdl:definitions>

encodage utilisé

Page 311: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 36 / 42

WSDL pour SOAP-RPC

● Extrait <service>

<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions targetNamespace=http://metier.antislashn.org

…<wsdl:service name="HelloService"><wsdl:port binding="impl:HelloSoapBinding" name="Hello"><wsdlsoap:address location="http://localhost:8080/hellows/services/Hello" />

</wsdl:port></wsdl:service>

…</wsdl:definitions>

lien avec le binding

url du web service

Page 312: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 37 / 42

WSDL pour SOAP-Document

● Extrait <types>

<wsdl:definitions targetNamespace=http://metier.antislashn.orgxmlns:apachesoap=http://xml.apache.org/xml-soapxmlns:impl=http://metier.antislashn.orgxmlns:intf=http://metier.antislashn.orgxmlns:wsdl=http://schemas.xmlsoap.org/wsdl/xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<wsdl:types>

</wsdl:types>

…</wsdl:definitions>

déclaration des types utiliséscf. slide suivant

Page 313: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 38 / 42

WSDL pour SOAP-Document

● Extrait <types>…

<schema elementFormDefault="qualified"targetNamespace=http://metier.antislashn.orgxmlns="http://www.w3.org/2001/XMLSchema">

<element name="getHello"><complexType><sequence><element name="nom" type="xsd:string" /></sequence>

</complexType></element><element name="getHelloResponse"><complexType><sequence><element name="getHelloReturn" type="xsd:string" /></sequence>

</complexType></element>

</schema>…

utilisation des typesspécifiés par XMLSchema

Page 314: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 39 / 42

WSDL pour SOAP-Document

● Extrait <message>

<wsdl:definitions targetNamespace=http://metier.antislashn.orgxmlns:apachesoap=http://xml.apache.org/xml-soapxmlns:impl=http://metier.antislashn.orgxmlns:intf=http://metier.antislashn.orgxmlns:wsdl=http://schemas.xmlsoap.org/wsdl/xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/xmlns:xsd="http://www.w3.org/2001/XMLSchema">

…<wsdl:message name="getHelloRequest"><wsdl:part element="impl:getHello" name="parameters" />

</wsdl:message><wsdl:message name="getHelloResponse"><wsdl:part element="impl:getHelloResponse" name="parameters" />

</wsdl:message>

…</wsdl:definitions>

Page 315: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 40 / 42

WSDL pour SOAP-Document

● Extrait <portType>

<wsdl:definitions targetNamespace=http://metier.antislashn.orgxmlns:apachesoap=http://xml.apache.org/xml-soapxmlns:impl=http://metier.antislashn.orgxmlns:intf=http://metier.antislashn.orgxmlns:wsdl=http://schemas.xmlsoap.org/wsdl/xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/xmlns:xsd="http://www.w3.org/2001/XMLSchema">

…<wsdl:portType name="Hello"><wsdl:operation name="getHello"><wsdl:input message="impl:getHelloRequest" name="getHelloRequest" /><wsdl:output message="impl:getHelloResponse" name="getHelloResponse" />

</wsdl:operation></wsdl:portType>

…</wsdl:definitions>

Page 316: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 41 / 42

WSDL pour SOAP-Document

● Extrait <binding>

<wsdl:definitions targetNamespace=http://metier.antislashn.org…<wsdl:binding name="HelloSoapBinding" type="impl:Hello"><wsdlsoap:binding style="document"transport="http://schemas.xmlsoap.org/soap/http" />

<wsdl:operation name="getHello"><wsdlsoap:operation soapAction="" /><wsdl:input name="getHelloRequest"><wsdlsoap:body use="literal" />

</wsdl:input><wsdl:output name="getHelloResponse"><wsdlsoap:body use="literal" />

</wsdl:output></wsdl:operation>

</wsdl:binding>…</wsdl:definitions>

encodage utilisé

Page 317: Architectures distribuées

antislashn.org Architectures distribuées – web services 06 - 42 / 42

Développement d'un web service

● En règle général, nous pouvons partir● du WSDL pour créer le code

– méthodes de classe ou fonction● du code pour créer le WSDL

● Les frameworks automatisent le développement● génération du WSDL● génération des classes proxy côtés serveur et client

Page 318: Architectures distribuées

Architectures distribuéesRich Internet Application

Page 319: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 2 / 29

Introduction

● RIA – Rich Internet Application● terme introduit en 2002 par Macromédia● application web offrant des caractéristiques similaires

aux applications traditionnelles– interactivité– vitesse d'exécution

● une RIA peut être exécutée– dans un navigateur– sur une machine, dans un sandbox

● environnement sécurisé

Page 320: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 3 / 29

Évolution des IHM

● 1ère génération : terminaux passifs● affichage de caractères sur 20 à 25 lignes et 80 à 150 colonnes

● 2ème génération : ordinateurs personnels● IHM baptisée "client lourd"● ergonomie "user friendly" et "wysiwyg"

● 3ème génération : navigateur● interpréteur IHM universel● baptisé "client léger"● ergonomie limitée

● 4ème génération : interfaces riches● mariage de multimédia, interactivité et arts graphiques● se répand sur les écrans : ordinateurs, téléphones, téléviseurs, …

Page 321: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 4 / 29

Concepts

● Une interface riche devrait offrir les caractéristiques suivantes :

1.exécution de l'IHM sur le terminal

2.optimisation des échanges entre client et serveur

3.assemblage dynamique de composants multimédias (widgets) animés et interactifs partageant les mêmes données

4.adaptation à une grande variété d'appareils à écran : ordinateur, TV, téléphone, …

Page 322: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 5 / 29

Concepts

● Les interfaces riches peuvent s'appuyer sur les architectures suivantes :1. le lourd enrichi

• basé sur un client lourd qui dialogue avec un serveur• automatiquement chargé et mis à jour

2. le léger enrichi• basés sur AJAX• plus de 200 frameworks recensés par ajaxpatterns.org

3. le moteur XML• XML est utilisé pour décrire l'IHM

4. le riche pur• type Flex2 d'Adobe

5. le document électronique• manipulation d'un document XML connecté à une architecture SOA

● XFoms du W3C, Infopath de Microsoft, document lifecycle d'Adobe, …

Page 323: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 6 / 29

Application web

● Les applications web traditionnelles s'articulent autour :● de traitements exécutés sur le serveur● de clients légers chargés de réaliser la présentation

des résultats des traitements

● Schématiquement le client envoie des données aux serveur, le serveur renvoie une page au client● en dehors de quelques traitements pour les

formulaires

Page 324: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 7 / 29

Application web

● Application web traditionnelle

Navigateur Serveur

génération de lapremière page

url demandée

affichage pagetraitements etgénération page

affichage page

affichage page

traitements etgénération page

1ére requête

envoi page complète

envoi page complète

envoi page complète

requête + données

requête + données

Page 325: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 8 / 29

Client enrichi

● Afin d'améliorer l'interactivité avec l'utilisateur les RIA font effectuer un certains nombre de traitements côté client.

● Les RIA nécessitent donc un une technologie de traitement, voir de persistance, côté client● applet, ActiveX● JavaScript● Adobe Flash - Flex● frameworks RIA

Page 326: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 9 / 29

Client enrichi

● JavaScript est devenu le standard pour le développement de client enrichi● pour des raisons de compatibilité, licence, etc.● avec le développement Ajax

– avec l'objet XMLHttpRequest

● avec l'enrichissement des fonctionnalités de navigateurs– persistance côté client léger

● malgré les différences entre navigateurs sur la gestion des événements, le DOM, ...

Page 327: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 10 / 29

Client enrichi

● Il est complexe de maintenir la cohérence d'une application Ajax● niveaux de compatibilité● architecture client-serveur fragile

● Nécessité d'utiliser un framework● bibliothèque extensible de widgets● bibliothèque d’algorithmes de comportement● cf. JQuery, GWT, JSF, ASP.NET MVC, …

Page 328: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 11 / 29

Ajax

● Asynchronous Javascript XML● Nouvelle manière de concevoir les applications

web● basée sur divers technologies

– HTML, DOM, CSS, JavaScript

● objet XMLHttpRequest– permet d'envoyer une requête au serveur en JavaScript

● sans passer par l'utilisateur

– une fonction callback est invoquée tout le long de la réponse du serveur

● mode asynchrone

Page 329: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 12 / 29

Ajax

● Application Ajax

Navigateur Serveur

génération de lapage + javascript

url demandée

page+

JavaScript

traitements etenvoi de fragments

1ére requête

envoi page complète

envoi données

requête + données

moteur Ajax

le moteur Ajaxmodifie le DOM

Page 330: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 13 / 29

Ajax

● La classe XMLHttpRequest permet d'envoyer une requête HTTP vers le serveur et d'en contrôler la réception● la manière de récupérer une instance diffère selon les

navigateurs– sous IE 6 et moins :

● var reqAjax = new ActiveXObject('Microsoft.XMLHTTP');

– sous autres navigateurs et à partir de IE 7● var reqAjax = new XMLHttpRequest();

● l'utilisation de l'instance est ensuite homogène

Page 331: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 14 / 29

Ajax

● Étapes de gestion d'une requête vers le serveur● récupérer une instance de XMLHttpREquest● brancher une fonction de surveillance de la réponse sur

l'événement onreadystatechange● ouvrir la connexion vers la ressource

– méthode open(...)● envoyer la requête

– méthode send(...)● surveiller l'état de la réponse dans la fonction callback● traiter la réponse lorsque celle-ci est reçue

– propriété responseText ou responseXML

Page 332: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 15 / 29

Ajax

● Exemple de code JavaScript● récupération d'un objet XMLHttpRequest (extrait)

if (window.XMLHttpRequest) { req = new XMLHttpRequest();} else if (window.ActiveXObject) { req = new ActiveXObject("Microsoft.XMLHTTP");}if (req) { req.onreadystatechange = processReqChange; req.open("GET", url, true); req.send(null);}

req est déclaré plus haut dans la page

branchement de la fonction callback

Page 333: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 16 / 29

Ajax

● Exemple de code JavaScript● surveillance de la réponse XMLHttpRequest (extrait)

function processReqChange(){ var ready=req.readyState; var data=null; if (ready==READY_STATE_COMPLETE){ data=req.responseText; }else{ data="loading...["+ready+"]"; } toConsole(data);}

variable globale valant 4ATTENTION : pas de gestion d'erreur HTTP

Page 334: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 17 / 29

JQuery

● Parmi les nombreuses bibliothèques JavaScript JQuery se détache nettement● repris par les projets Google, Amazon, …● projet "vivant"● bibliothèque pour les mobiles

● Bibliothèque JavaScript côté client● pas un framework complet● facilite le travail sur le DOM et les requêtes Ajax● masque les différences entre navigateurs

Page 335: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 18 / 29

JQuery

● Exemple Ajax<html>

<head><meta charset="ISO-8859-1"><title>Formation jQuery</title><script type="text/javascript" src="jquery.js"></script><script>

$(document).ready(function(){$.ajax({

url: 'test.html',success: function(data){

$('#conteneur').html(data);},error: function(xhr,status,error){

console.log(status);console.log(error);

},});

});</script>

</head><body>

<div id="conteneur"></div></body>

</html>

objet JQuery

console JavaScriptdu navigateur

Page 336: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 19 / 29

Flex

● Solution de création et déploiement d’applications RIA● création par Macromédia en 2004● reprise par Adobe en 2006

● Solution multi-plateformes● technologie lecteur Flash● programmation via MXML et ActionScript 3

– MXML : description de l'IHM– Action Script : langage de programmation côté client et

serveur basé sur ECMAScript

Page 337: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 20 / 29

Silverligth

● Solution Microsoft multi-plateforme● plugin pour les navigateurs● projet Moonligth sous Linux

● Utilise les langages XAML et .NET● XAML : déclaration des IHML● .NET : langage de programmation côté client et

serveur

● Peut-être utilisée hors du navigateur

Page 338: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 21 / 29

Java Web Start

● Solution construite sur Java SE● Applications exécutées dans un environnement

sécurisé "sandbox"● limitations sur les connectivités réseau et les accès

fichiers

● Permet de lancer des applications● à partir d'un navigateur, via un lien● à partir du gestionnaire d'applications de Java Web

Start● à partir d'icônes sur le bureau

Page 339: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 22 / 29

Java Web Start

● Pas de procédure d'installation complexe● Au lancement d'une application Java Web Start se

connecte au serveur pour déterminer si une nouvelle version existe● l'application existe en cache après le premier

téléchargement● garantit l'exécution de la version la plus récente

– pas de mise à jour complexe des applications● fichier jnlp

– Java Network Launching Protocol – JSR 56

Page 340: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 23 / 29

Java Web Start

● Un serveur Web est nécessaire pour le déploiement

● Ajouter au serveur Web le type MIME jnlp● associer l'extension jnpl au contenuapplication/x-java-jnlp_file

– par ajout de la ligne dans le fichier conf/mimes.types pour Apache

application/x-java-jnlp_file jnlp● par ajout d'un type de fichier dans IIS

Page 341: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 24 / 29

Java Web Start

● Création de l'application et packaging dans un fichier jar

public class HelloFrame extends JFrame {public HelloFrame(){

super("Démo Java Web Start");getContentPane().add(new JLabel("Hello, world"));setDefaultCloseOperation(EXIT_ON_CLOSE);setLocationRelativeTo(null);pack();setVisible(true);

}}

public class Main {public static void main(String[] args) {

new HelloFrame();}

}

Page 342: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 25 / 29

Java Web Start

● Création du fichier jnlp

<?xml version="1.0" encoding="UTF-8"?><jnlp spec="1.0+" codebase="http://localhost/jaws/" href="hello.jnlp">

<information><title>Hello pour JNPL</title><vendor>antislashn.org</vendor>

</information>

<resources><j2se version="1.5+" href="http://java.sun.com/products/autodl/j2se" /><jar href="http://localhost/jaws/hello.jar" />

</resources>

<application-desc main-class="org.antislashn.formation.webstart.hello.Main" /></jnlp>

Page 343: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 26 / 29

Java Web Start

● Pour notre exemple, les fichiers hello.jar et hello.jnlp sont copiés dans le répertoire jaws du site web

● Une page html permet de charger le lien● pour être exécutée l'application doit-être signée<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html> <head> <meta http-equiv="content-type" content="text/html; charset=windows-1250"> <meta name="generator" content="PSPad editor, www.pspad.com"> <title>Applications Java Web Start</title> </head> <body> <h2>Applications Java Web Start disponibles</h2> <a href="hello.jnlp">Hello world</a> </body></html>

Page 344: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 27 / 29

GWT

● Google Web Toolkit● ensemble d'outils Google● solution globale de développement web

– un seul langage de développement : Java● débogage côté client et serveur en Java

– le compilateur GWT traduit l'application en● HTML, CSS, JavaScript pour le côté client● servlets pour le côté serveur

● Ensemble de widgets pouvant être étendus● respecte les spécifications du W3C

Page 345: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 28 / 29

GWT

● Développement● utilisation d'un IDE● utilisation d'un plugin dans le navigateur

● Déploiement ● sur un serveur Java EE

– profil web● sur Google App Engine

Page 346: Architectures distribuées

antislashn.org Architectures distribuées – RIA 07 - 29 / 29

Autres frameworks

● JavaFX● solution Sun / Oracle● version 1 annoncée en Décembre 2008● constitué de JavaFX Script et JavaFX Mobile

● Quicktime● framework multimédia développé par Apple

Page 347: Architectures distribuées

Architectures distribuéesService Oriented Architecture

Page 348: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 2 / 45

Concepts

● Architecture de médiation● modèle d'interaction applicative● mise en œuvre de services

● Moyen d'intégrer divers systèmes d'information● chaque ressource informatique est un service● l'invocation d'un service est indépendante de son

implémentation

● La principale technique d'invocation est SOAP● basé sur XML et HTTP

Page 349: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 3 / 45

Concepts

* image provenant de Wikipedia Commons

Page 350: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 4 / 45

Concepts

● L'application devient un ensemble de services qui dialoguent par messages

● Le service est une unité de traitement qui possède les caractéristiques suivantes :● large granularité (coarse grained)● interface● localisable● couplage faible (loosely coupled)● synchrone et/ou asynchrone

Page 351: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 5 / 45

Concepts

● Interopérabilité● technologie permettant de faire communiquer

facilement des mondes différents– Microsoft– PHP– Java– C/C++

Page 352: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 6 / 45

Concepts● Une architecture SOA nécessite :

● un annuaire de services – UDDI (Unified Description Discovery and Integration) par exemple

pour un SOA orienté Web services

● la description des interfaces des services– WSDL pour les web services

● l'invocation du service– SOAP pour les web services

● un format d'échange de données– XML par exemple

● transport des données– HTTP

Page 353: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 7 / 45

Concepts

● L'architecture SOA peut être complétée par● un bus de service (ESB – Enterprise Service Bus)

– basé sur les patterns EIP (Enterprise Integration Pattern)● la gestion de la sécurité● l'orchestration des services pour constituer des

processus métiers– exemple : langage WS-BEPL

● Web Service - Business Process Execution Language

● la gestion transactionnelle

Page 354: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 8 / 45

Concepts

● Le service est une unité atomique● composant clé de SOA● fonctionnalité bien définie

– composant autonome– ne dépendant d'aucun contexte ou service

● Le service doit● publier un ensemble d'opération via des interfaces● être autonome : pas de notion d'état● respecter un contrat● correspondre à des fonctions mutualisables au sein de

l'entreprise

Page 355: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 9 / 45

Problématique

● Dans les contextes B2B de plus en plus de services sont exposés aux partenaires, fournisseurs, …● les entreprises doivent garantir la qualité des services

qu'elles exposent

● De nombreux facteurs impactent indirectement l'organisation des SI● concurrence, acquisition, fusion, évolution des

législations, …

Page 356: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 10 / 45

Problématique

● Le SI de l'entreprise est constitué d'applications et de données historiques● elles constituent l'héritage de l'entreprise (legacy)● parties hétérogènes et spécialisées par métier● manque de vision globale sur le SI● manque de transversalité

● L'EAI consiste à développer des connecteurs spécifiques permettant la communication inter-applicative● EAI – Enterprise Application Integration

Page 357: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 11 / 45

Problématique

● SOA est perçu différemment selon le public● pour la direction générale SOA est la stratégie IT elle-

même permettant au SI de s'adapter aux demandes dans un cadre délais / coût / fiabilité– IT : Information Technology – utilisation de l'informatique et

des télécoms● pour le service juridique SOA est source de

responsabilité avec les échanges avec les partenaires● pour les utilisateurs métier, SOA exprime l'organisation

et les processus de gestion● pour l'architecte IT SOA représente l'organisation

globale du système

Page 358: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 12 / 45

Contexte technologique

● Les acteurs majeurs décisionnels de l'entreprise sont-ils identifiés ?

● Le système d'information de l'entreprise comporte-t-il plusieurs technologies ?

● Les outils sous-jacents à la mise en œuvre de SOA disposent-ils des connecteurs nécessaires ?

● Oracle Application, Lotus Notes, Microsoft CRM, HP OpenView, ...

Page 359: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 13 / 45

SOA

● Typologie d'un démarche SOA

source : IT-expert n°88 - 2010

Page 360: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 14 / 45

WOA

● WOA : Web Oriented Architecture● extension du principe SOA aux applications orientées

Web● peut-être vue comme une implémentation allégée de

SOA● utilise le navigateur comme partie de la couche de

présentation● peut utiliser SOAP ou REST et POX pour les

interactions entre les serveurs

Page 361: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 15 / 45

EAI

● EAI : Enterprise Application Integration● doit permettre l'interopérabilité et l'organisation de

l'information entre des applications hétérogènes● mise en place d'une architecture dans laquelle les

différentes applications vont pouvoir communiquer entre-elles.

● développement de connecteurs (middleware) pour interfacer les applications par utilisation de protocoles de communications

Page 362: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 16 / 45

RIA

● RIA – Rich Internet Application● application pouvant être exécutée dans un navigateur,

ou localement dans un environnement sécurisé (sandbox)

● pas d'installation requise, approche ULC (Ultra Ligth Client)

● ensemble de technologies– JavaScript, AJAX

– applets Java, Adobe Flash

– Java Web Start, Adobe Integration Runtime, Microsoft Click One

Page 363: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 17 / 45

Cloud Computing

● Cloud Computing● utilisation des capacité de stockage et de calcul des

machines et serveurs répartis sur internet● permet l'utilisation en ligne de logiciels

– Google apps, Microsoft Dynamics CRM, …● utilisation de l'espace de stockage

– Amazon Simple Storage Device, …● architecture portant à controverse

– l'utilisateur est dépossédé des ses applications (Richard Stallman)

Page 364: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 18 / 45

SOA et urbanisation

● La démarche SOA propose une stratégie● modélisation de couches abstraites pour cacher les

technologies sous-jacentes● vue logique des services

● La notion de service est essentielle● mise à disposition d'acteurs de fonctionnalités métier● le service a un sens au point de vue métier● la consommation du service est indépendante de son

implémentation

Page 365: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 19 / 45

SOA et urbanisation

● Urbanisation● métaphore de la cité

– une rationalisation du SI peut passer par la démarche dite "d’urbanisation ", qui :

● propose de comparer un SI à une ville, comprenant des– zones, quartiers, ilots

● l’urbanisation des SI porte sur :– les processus métiers – les communications inter-applicatives– la mise en place des référentiels transverses

● identification des données dupliquées dans l'entreprise

Page 366: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 20 / 45

SOA et urbanisation

● Problématiques● évolution des stratégies d'entreprise

– regroupements, fusions, rachats, ...● complexité d'intégration des SI

– augmentation de l'effet spaghetti– augmentation des coûts

● Objectif● le SI accompagne le changement d'entreprise pour le

meilleur rapport coûts/délais/qualité– utilisation des outils d'EAI (Intégration d'applications d'entreprise)

Page 367: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 21 / 45

SOA et urbanisation

● Urbaniser, c'est diriger la transformation continue du système d'information pour le simplifier durablement

● Règles de base● une application doit appartenir à un seul bloc● les dépendances doivent respecter un cohérence forte

et un couplage faible– entre applications– entre les modules d'une application– entre les composants d'un module

Page 368: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 22 / 45

SOA et urbanisation

● Découpage du SI en modules autonomes● de tailles de plus en plus petite

– zones– quartier, et îlots– blocs fonctionnels

● zones d'échange entre chaque module (zone,quartier,...)– découplage des différents modules– évolution indépendante des modules

Page 369: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 23 / 45

SOA et urbanisation

● Règles de découpage

1.séparation entre back-office et front-office

2.découpage par processus et métier• zones : Décisionnel, Support et Métier

3.séparation des canaux d'accès à l'information (site Web, SMS, ..) des canaux du métier "Relation Client"

• deux nouvelles zones du front-office• Acquisition/Restitution et Relations avec les tiers

4.isolation des partages entre back et front office• zone d'intégration et de données partagées

Page 370: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 24 / 45

SOA et urbanisation

● Exemple de découpage d'une partie du SI d'une banque● ensemble des zones d'activités opérationnelles

– zone : Production Bancaire– quartier : Gestion des crédits– îlot :Gestion des crédits immobiliers– bloc fonctionnel : Gestion des impayés

Page 371: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 25 / 45

Bus de messages

● Le bus de messages fournit● un mécanisme de communication● un langage commun pour les contrats

– WSDL par exemple● une infrastructure assurant le transport● un protocole d'échange de messages● une sécurisation des échanges

– fiabilité, confidentialité si nécessaire, …

Page 372: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 26 / 45

Contrat de service

● Le contrat peut couvrir certaines obligations résultant d'une négociation● SLA : Service Level Agrement

– définit la qualité du service● peut contenir des mesures de performances

– pourcentage de de fautes (ABA – Abandon Rate)● pourcentage d'appels raccrochés durant une attente

– temps moyen d'attente (ASA – Average Speed to Answer)– …

Page 373: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 27 / 45

Plateforme SOA

PORTAIL

application composite

application composite

application composite

MOTEURBMP

SAM

bus demessages

SOAannuaire

des services

conteneur de services

plateforme d'administration

accès aux données

Page 374: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 28 / 45

Plateforme SOA

● SAM : Service Activity Monitoring● contrôle la qualité de service● console avec suivi des services

● Annuaire des services● permet de connaître les services existants

● BPM : Business Process Management● peut compléter SOA● existe en dehors de SOA dans une approche orientée

processus

– décrit les activités des processus et les invoquent automatiquement

Page 375: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 29 / 45

SOA – les outils

● La fabrication d'une plateforme SOA nécessite un ensemble d'outils● peut-on le qualifier d'usine à logicielle ?● peut-être utilisé dans une démarche MDA (Model

Driven Architecture)

● Les outils :● EAI, ESB, orchestration

Page 376: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 30 / 45

EAI

● Appels inter-applicatifs sans EAI● plusieurs protocoles sont utilisés● les applications sont

codées dans deslangages différents– Java, C++, VB, …

● les plateformes d'exécutionssont différentes– linux, windows

Application 1Application 2

Application 4

Application 3

Page 377: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 31 / 45

EAI

● Appels inter-applicatifs avec EAI

Application 1

Application 2

Application 3 Application 4

EAI

Page 378: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 32 / 45

EAI - fonctionnalités

● Les connecteurs● interfacent l'EAI et les applications● assurent le transit des données

– les données sont appelées ASBO● Application Specific Business Object● en français : OMS (Objets de Métier Spécifiques)

– le connecteur scrute les événements de l'application et transmet les données à l'EAI

– le connecteur fournit à l'application des données provenant de l'EAI

Page 379: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 33 / 45

EAI - fonctionnalités

● Les ASBO● Application Specific Business Object● reflètent les données de l'application

– noms de champ, formats, …

● sont mis en correspondance pour être transformés en données standard à l'EAI– les BO (Business Objetc) sont standards à l'EAI

● les BO reflètent un modèle de données global● sont transmis à des traitements appelés collaborations

Page 380: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 34 / 45

EAI - fonctionnalités

● Les collaborations● logique de traitement à appliquer aux BO avant

transmission à l'application cible● complète les informations

– recherche dans une autre application– vérification de la validation des données– …

Page 381: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 35 / 45

EAI - fonctionnalités

● La couche de transport● achemine les données entre les applications● implémentations divers

– échange de fichiers par ftp– échange de messages par MOM– appels de services par SOAP– …

Page 382: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 36 / 45

EAI – exemple de fonctionnement

● Une application A crée un article en base de données● un trigger capture l'événement et archive l'article créé dans une

table d'événements avec la donnée associée● Un connecteur scrute la table des événements toutes les

10 secondes● le nouvel événement est découvert● le connecteur récupère la donnée associée, crée un ASBO et

l'associe à une clef "create"● l'ASBO est transformé en un BO

● passage de l'objet de l'application A en un modèle générique à l'entreprise

● Un collaborateur C récupère le BO et l'envoie vers l'application B

Page 383: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 37 / 45

EAI – exemple de fonctionnement

Application A

création

EAI

connecteurinterrogationrégulière

transformation

ASBO

Application B

connecteur

BO

collaborateur

transformation

ASBO

Page 384: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 38 / 45

EAI et ESB

● EAI est un pattern d'intégration● plusieurs implémentations

● ESB - Enterprise Service Bus● implémentation d'EAI (Enterprise Application

Integration)● structuré sous forme de bus

– interopérable avec d'autres bus type ESB● structure et centralise les appels entre les différentes

applications

Page 385: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 39 / 45

EAI et ESB

● ESB cache deux concepts différents● le pattern d'architecture qui établit une couche

d'intermédiation au sein du SI– rôle de fournisseur de services– les services se basent sur des applications existantes– les services sont utilisés via des connecteurs

● le produit logiciel

Page 386: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 40 / 45

EAI et ESB

● Architecture type d'un socle SOA

source : IT-expert n°88 - 2010

Page 387: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 41 / 45

EAI et ESB

● Différentes approches EAI/ESB

source : IT-expert n°88 - 2010

Page 388: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 42 / 45

ESB – les bonnes pratiques

● Granularité adaptée● prendre en compte les cas d'usage métier

● Ne pas systématiser les web services● ne pas mettre tous les services sous forme de web

service– problème de performance (HTTP et SOAP)

● Bien identifier les besoins propres à l'entreprise● exigences fonctionnelles et non fonctionnelles● ne pas plaquer un outil / solution existant sans avoir

clairement établi le besoin métier

Page 389: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 43 / 45

EAI et ESB

● Quelques ESB● OpenESB

– Sun, open source, intégré à GlassFish, basé sur JBI● ServiceMix

– Apache, open source, intégré à Geronimo, basé sur JBI● JBossESB

– JBoss, open source, basé sur JBI● Petals

– Object Web, open source, intégré à Jonas, basé sur JBI● Synapse

– Apache – Axis2, open source, basé sur HTTP

Page 390: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 44 / 45

EAI

● ServiceMix

Page 391: Architectures distribuées

antislashn.org Architectures distribuées – SOA 08 - 45 / 45

BPEL

● Business Process Execution Language● langage de programmation destiné à orchestrer

l'exécution de processus d'entreprise– basé sur XML– une orchestration est une collaboration entre deux ou

plusieurs services

● conçu pour intégrer un nombre important d'applications publiées sous forme de services– sans dépendance de plateforme et langage– intégration automatique

Page 392: Architectures distribuées

Architectures distribuéesHaute disponibilité

Page 393: Architectures distribuées

antislashn.org Architectures distribuées – haute disponibilité 09 - 2 / 13

Définitions

● Haute disponibilité● taux de disponibilité d'un équipement, service, logiciel● le taux de haute disponibilité est souvent exprimé en

pourcentage● différentes techniques permettent d'arriver à un taux de

haute disponibilité– redondance des matériels– mise en cluster– plans de secours– mode dégradé– sécurisation des données– ...

Page 394: Architectures distribuées

antislashn.org Architectures distribuées – haute disponibilité 09 - 3 / 13

Définitions

● Haute disponibilité

source : Wikipedia

Page 395: Architectures distribuées

antislashn.org Architectures distribuées – haute disponibilité 09 - 4 / 13

Définitions

● Répartition de charge (Load balancing)● gestion tour à tour des requêtes entrantes vers un

groupe de serveurs– grappe d'ordinateur (cluster)– différentes politiques de gestion sont disponibles

● la gestion de l'équilibrage peut être matériel ou logiciel– le module Apache mod_jk par exemple

● il peut être nécessaire de gérer l’affinité de session– dans le cadre des sessions HTTP

Page 396: Architectures distribuées

antislashn.org Architectures distribuées – haute disponibilité 09 - 5 / 13

Définitions

● Répartition de charge

source : Wikipedia Commons

Page 397: Architectures distribuées

antislashn.org Architectures distribuées – haute disponibilité 09 - 6 / 13

Définitions

● Basculement sur incident (fail-over)● capacité d'un équipement à basculer automatiquement

d'un équipement vers un autre● différentes gestions

– actif-actif via la répartition de charge● tous les équipements sont actifs

– actif-passif● l'équipement secondaire est en mode veille tant que l'équipement

principal fonctionne correctement

● problématiques– gestion des sessions, de l'état interne des applications, etc.

Page 398: Architectures distribuées

antislashn.org Architectures distribuées – haute disponibilité 09 - 7 / 13

Définitions

● cluster● grappe de serveurs, partition, ou ferme● chaque serveur est un nœud sur cluster● objectifs

– augmenter la disponibilité– facilité la montée en charge– permettre la répartition de charge– facilité la gestion des ressources

Page 399: Architectures distribuées

antislashn.org Architectures distribuées – haute disponibilité 09 - 8 / 13

Stratégies de répartition de charge

● Quelques stratégies● random

– à chaque requête un serveur est choisi au hasard● random once

– à la première requête le serveur est choisi au hasard, puis conservé pour les requêtes suivantes

● round robin– itération entre les serveurs à chaque requête

● stratégie personnalisée– par logiciel, appel d'une fonction callback pour le choix du

serveur

Page 400: Architectures distribuées

antislashn.org Architectures distribuées – haute disponibilité 09 - 9 / 13

Stratégies de répartition de charge

● Un poids peut-être affecté à un serveur● un serveur dont le poids est 2 recevra deux fois plus

de requêtes

● Gestion des sessions● pour qu'une session HTTP soit prise en compte par le

répartiteur il est nécessaire d'activer l'affinité de session

● ajout d'un jeton dans l'URL ou par cookie

Page 401: Architectures distribuées

antislashn.org Architectures distribuées – haute disponibilité 09 - 10 / 13

Gestion du cluster

● Pour les applications distribuées un simple cluster ne suffit pas

● Il faut prendre en compte l'état des applications● nécessite que l'état de l'application soit répliquée sur

tout ou partie des serveurs● peut nécessiter l'utilisation de caches supplémentaires

Page 402: Architectures distribuées

antislashn.org Architectures distribuées – haute disponibilité 09 - 11 / 13

Cluster cyclique

● La réplication des états n'est pas totale

Nœud A

Données : ASauvegarde : D

Nœud D

Données : DSauvegarde : C

Nœud C

Données : CSauvegarde : B

Nœud B

Données : BSauvegarde : A

réplication

réplicationréplication

réplication

Nœud A

Données : A + DSauvegarde : C

Nœud D

Données : DSauvegarde : C

Nœud C

Données : CSauvegarde : B

Nœud B

Données : BSauvegarde : A

réplication

réplication

réplication

Page 403: Architectures distribuées

antislashn.org Architectures distribuées – haute disponibilité 09 - 12 / 13

Cluster avec cache

● Là aussi des stratégies sont à définir● mode de réplication

– synchrone, asynchrone, sur les entités, ...● gestion des transactions

– sérialisation,  lecture sur commit, ...● stratégie d'invalidation

– dans quelle condition enlever un élément du cache– prévenir les autres caches du cluster de l'invalidation

● gestionnaire de transaction

Page 404: Architectures distribuées

antislashn.org Architectures distribuées – haute disponibilité 09 - 13 / 13

Conclusion

● Si de grands principes existent, il n'y a pas de solution toute faite pour gérer la haute disponibilité● voir la technologie utilisée

– .NET , Java EE● voir le produit

– JBoss, WebLogic, …● étudier les retours d'expériences

– conférences, forum, sites dédiés, …

Page 405: Architectures distribuées

Architectures distribuéesQuelques serveurs Java EE

Page 406: Architectures distribuées

antislashn.org Architectures distribuées – serveurs Java EE 10 - 2 / 13

L'offre serveurs Java EE

● Java EE est une spécification● Il y donc de nombreuses implémentations

● commerciales ou non

● Afin de vérifier l'implémentation des spécifications les serveurs sont certifiés● par rapport à un niveau de la spécification

– Java 2 EE 1.4, Java EE 5, Java EE 6– par rapport à un profile depuis Java EE 6

● web ou full

● cf. http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html

Page 407: Architectures distribuées

antislashn.org Architectures distribuées – serveurs Java EE 10 - 3 / 13

L'offre serveurs Java EE

● Les différentes implémentations peuvent utiliser les mêmes librairies ou conteneurs● Tomcat pour le conteneur servlet/JSP● implémentation de la couche de persistance, des web

services, …

Page 408: Architectures distribuées

antislashn.org Architectures distribuées – serveurs Java EE 10 - 4 / 13

L'offre serveurs Java EE● Produits commerciaux présentés

● Oracle : WebLogic● IBM : WebSphere

– existe en version communautaire

● Produits libres présentés● Apache Tomcat● Jetty● JBoss● Geronimo● JOnAs● GlassFish

Page 409: Architectures distribuées

antislashn.org Architectures distribuées – serveurs Java EE 10 - 5 / 13

Apache Tomcat

● Projet Apache● site : http://tomcat.apache.org/

● Implémentation de références pour les spécifications de conteneur servlet/JSP● ce n'est pas un serveur d'application Java EE

● Administration simple● le plus souvent à "la main"● console d'administration minimaliste

– console manager

Page 410: Architectures distribuées

antislashn.org Architectures distribuées – serveurs Java EE 10 - 6 / 13

Jetty

● Projet issu de codehaus foundation● site : http://jetty.codehaus.org/jetty/● repris par la fondation Eclipse depuis 2009

● Alternative à Tomcat● Supporte aussi

● WebSocket– canal bidirectionnel et full-duplex sur socket TCP

● en cours d'élaboration

● SDPY– protocole expérimental conçu par Google

Page 411: Architectures distribuées

antislashn.org Architectures distribuées – serveurs Java EE 10 - 7 / 13

JBoss

● Projet JBoss● repris par Red Hat● existe en version communautaire

– http://www.jboss.org/● ou commerciale

– http://www.redhat.com/products/jbossenterprisemiddleware/application-platform/

● JBoss est porteur de nombreux autres projets● Hibernate● JBoss Cache● ...

Page 412: Architectures distribuées

antislashn.org Architectures distribuées – serveurs Java EE 10 - 8 / 13

JBoss

● Serveur très utilisé● administrations, assurances

● Console d'administration depuis la version 7● mais encore minimaliste

Page 413: Architectures distribuées

antislashn.org Architectures distribuées – serveurs Java EE 10 - 9 / 13

Geronimo

● Projet Apache● site : http://geronimo.apache.org/● peu utilisé dans l'industrie

– IBM finance le projet– la version communautaire de WebSphere est basée sur

Geronimo

● Possède une vraie console d'administration

Page 414: Architectures distribuées

antislashn.org Architectures distribuées – serveurs Java EE 10 - 10 / 13

JOnAS

● Projet du consortium OW2● site : http://jonas.ow2.org/xwiki/bin/view/Main/WebHome

● INRIA, France Télécom, Bull

● Semble peu utilisé dans l'industrie● N'est pas certifié Java EE 6

● au mois d'Aout 2012

Page 415: Architectures distribuées

antislashn.org Architectures distribuées – serveurs Java EE 10 - 11 / 13

GlassFish

● Serveur open source de Oracle● site : http://glassfish.java.net/fr/

● Semble être une alternative intéressante à JBoss● commence à être utiliser par certaines administration

● Possède une véritable console d'administration

Page 416: Architectures distribuées

antislashn.org Architectures distribuées – serveurs Java EE 10 - 12 / 13

WebLogic

● Serveur commercial de Oracle● site : http://www.oracle.com/technetwork/middleware/weblogic/overview/index.html

● première version en 1995 par WebLogic Inc.

– rachat par BEA System en 1998– puis par Oracle en 2008

Page 417: Architectures distribuées

antislashn.org Architectures distribuées – serveurs Java EE 10 - 13 / 13

WebSphere

● Produit IBM● existe en version commerciale

– site : http://www-01.ibm.com/software/webservers/appserv/was/● et communautaire

– site : http://www.ibm.com/developerworks/downloads/ws/wasce/–