Your SlideShare is downloading. ×
0
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Architectures distribuées
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Architectures distribuées

5,318

Published on

Présentation des concepts d'architectures distribuées

Présentation des concepts d'architectures distribuées

Published in: Education
2 Comments
4 Likes
Statistics
Notes
No Downloads
Views
Total Views
5,318
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
249
Comments
2
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Architectures distribuées Objectifs version support : 1.0
  • 2. Objectifs ● Acquérir une connaissance globale des modèles darchitecture 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, ...antislashn.org Architectures distribuées - Objectifs 0-2/5
  • 3. 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 EEantislashn.org Architectures distribuées - Objectifs 0-3/5
  • 4. copyleft Support de formation créer par Franck SIMON http://www.franck-simon.comantislashn.org Architectures distribuées - Objectifs 0-4/5
  • 5. copyleft Cette œuvre est mise à disposition sous licence Attribution Pas dUtilisation 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.antislashn.org Architectures distribuées - Objectifs 0-5/5
  • 6. Architectures distribuées Introduction
  • 7. 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 : RIAantislashn.org Architectures distribuées - Introduction 01 - 2 / 18
  • 8. Historique source : Cloud computing et SaaS - Dunodantislashn.org Architectures distribuées - Introduction 01 - 3 / 18
  • 9. É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 ● laccès aux données ● Ce principe nest quun découpage abstrait ● les trois couches peuvent être imbriquées ou répartiesantislashn.org Architectures distribuées - Introduction 01 - 4 / 18
  • 10. Évolution des architectures Gestion de la présentation Présentation Logique de présentation Noyau de lapplication Logique des traitements Traitements Gestion des traitements Logique des données Données Gestion des donnéesantislashn.org Architectures distribuées - Introduction 01 - 5 / 18
  • 11. Modèles de répartition ● Gartner Group classifie les différents modèles de répartition Présentation Présentation Gestion distante Traitements Données Données et distribuée distante des données distribués distribués traitements distribués Données Données Données Données Données Données serveur Traitements Traitements Traitements Traitements Présentation réseau Données Données client Traitements Traitements Traitements Traitements Présentation Présentation Présentation Présentation Présentation Présentationantislashn.org Architectures distribuées - Introduction 01 - 6 / 18
  • 12. 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 dune application ● la réalité est plus complexe – architectures multi-niveaux ● le serveur peut-être client dun autre serveur – prise en compte des applications existantes ● legacyantislashn.org Architectures distribuées - Introduction 01 - 7 / 18
  • 13. Architecture trois-tiers ● Les limites de larchitecture deux-tiers ● frontal complexe et non standard – généralement sous Windows – à déployer ● middleware non standard ● La solution serait ● utilisation dun poste client très simple ● communication avec le serveur via un protocole standardantislashn.org Architectures distribuées - Introduction 01 - 8 / 18
  • 14. 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 dun serveur dapplication centralisé – dialogue avec les clients par un protocole propriétaireantislashn.org Architectures distribuées - Introduction 01 - 9 / 18
  • 15. Serveur transactionnel ● Issu des technologies IBM des années 1970 ● mise à disposition à grande échelle dapplications en mode texte ● plusieurs écrans se succèdent avant quune 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éesantislashn.org Architectures distribuées - Introduction 01 - 10 / 18
  • 16. 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 dun état cohérent à un autre état cohérent ● Isolation – un transaction nest pas affectée par le résultat des autres transactions ● Durée – les modifications de la transaction sont durablement garantieantislashn.org Architectures distribuées - Introduction 01 - 11 / 18
  • 17. Serveur transactionnel client Service 1 IHM API moniteur API 1 transactionnel protocole 1 Serveur Service 2 API moniteur transactionnel API 2 API 1 API 2 protocole 2antislashn.org Architectures distribuées - Introduction 01 - 12 / 18
  • 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 dapplication ● 3ème tiers : base de données 1er tiers 2éme tiers 3éme tiers présentation traitements traitements données globaux locauxantislashn.org Architectures distribuées - Introduction 01 - 13 / 18
  • 19. 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éantislashn.org Architectures distribuées - Introduction 01 - 14 / 18
  • 20. Architecture trois tiers ● Du mainframe en mode texte au mainframe en mode graphique : retour à la case départ source : Serveurs dapplications - Eyrollesantislashn.org Architectures distribuées - Introduction 01 - 15 / 18
  • 21. 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 lapplication 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 objetsantislashn.org Architectures distribuées - Introduction 01 - 16 / 18
  • 22. Architectures N-tiers ● Complexité de réutilisation source : Serveurs dapplications - Eyrollesantislashn.org Architectures distribuées - Introduction 01 - 17 / 18
  • 23. Architecture N-tiers ● Solution Oracle / Sun ● EJB : Enterprise Java Bean – sexécutent côté serveur ● JavaBean (POJO) – objets métiers ● Solution Microsoft ● modèle de communication COM ● DCOM étend COM pour les architectures distribuéesantislashn.org Architectures distribuées - Introduction 01 - 18 / 18
  • 24. Architectures distribuées Couche Web
  • 25. 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 nexiste pas dadministration internet – comme pour un réseau téléphoniqueantislashn.org Architectures distribuées – couche web 02 - 2 / 62
  • 26. TCP/IP ● Couches réseau modèle OSI Pile TCP/IP 7 Application HTTP 6 Présentation FTP 5 Session DNS 4 Transport TCP, UDP, SCTP 3 Présentation Réseau IP 2 Liaison Ethernet, Token Ring, ... 1 Physique ADSL, RTC, ...antislashn.org Architectures distribuées – couche web 02 - 3 / 62
  • 27. Protocole IP ● IP – Internet Protocol ● protocole non fiable – assure lacheminement 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 darrivée ● Ladresse IP est un numéro attribué à chaque équipement connectéantislashn.org Architectures distribuées – couche web 02 - 4 / 62
  • 28. Protocole IP ● IP v4 ● adresse sur 32 bits * image provenant de Wikipedia Commonsantislashn.org Architectures distribuées – couche web 02 - 5 / 62
  • 29. Protocole IP ● IP v6 ● adresse sur 128 bits * image provenant de Wikipedia Commonsantislashn.org Architectures distribuées – couche web 02 - 6 / 62
  • 30. 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 lapplication ● à chaque extrémité (client / serveur) est associé un numéro de port sur 16 bitsantislashn.org Architectures distribuées – couche web 02 - 7 / 62
  • 31. Protocole TCP ● Structure dun segment TCPantislashn.org Architectures distribuées – couche web 02 - 8 / 62
  • 32. Protocole TCP ● Fonctionnement en 3 phases ● établissement de la connexion ● transfert des données ● fermeture de la connexion ● La perte dun segment est gérée par TCP ● mécanisme de temporisation et retransmissionantislashn.org Architectures distribuées – couche web 02 - 9 / 62
  • 33. 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 dutilisation : – DNS – Domain Name System – TFTP – Trivial File Transfert Protocolantislashn.org Architectures distribuées – couche web 02 - 10 / 62
  • 34. 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 2616antislashn.org Architectures distribuées – couche web 02 - 11 / 62
  • 35. Protocole HTTP ● Protocole sans état ● le client envoie une requête – qui comporte une commande : méthode HTTP ● le serveur lui répondantislashn.org Architectures distribuées – couche web 02 - 12 / 62
  • 36. Le protocole HTTP ● Les méthodes HTTP ● GET : demande de ressource ● POST : soumission de données au serveur en vue dun traitement – formulaire HTLM ● OPTIONS : permet d’obtenir les méthodes supportées par le serveur ● CONNECT : utilisation dun proxy comme tunnel de communication ● TRACE : demande au serveur de retourner ce quil a reçu ● PUT : demande de remplacer ou dajouter une ressource ● DELETE : demande la suppression dune ressourceantislashn.org Architectures distribuées – couche web 02 - 13 / 62
  • 37. Protocole HTTP ● HTTP permet lidentification ● 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 certificatantislashn.org Architectures distribuées – couche web 02 - 14 / 62
  • 38. 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, ...antislashn.org Architectures distribuées – couche web 02 - 15 / 62
  • 39. 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é dutilisation ● IHM limitée ● nécessité dun frameworkantislashn.org Architectures distribuées – couche web 02 - 16 / 62
  • 40. HTML ● Utilisé dans les navigateurs HTML est un langage de description des pages web ● HTML pour Hyper Text Markup Language ● nest pas un langage de programmation ● basé sur un ensemble fini déléments ● Le navigateur interprète le document HTML et laffiche 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 dun site webantislashn.org Architectures distribuées – couche web 02 - 17 / 62
  • 41. HTML ● Un tag élément HTML est constitué ● dune balise douverture (start tag) – qui peut contenir des attributs ● dun corps délément – qui peut être vide, contenir du texte et/ou dautre éléments ● dune 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 />antislashn.org Architectures distribuées – couche web 02 - 18 / 62
  • 42. HTML attribut avec sa valeur entre " ou <a href="autre_page.html"> balise douverture Lien vers autre page </a> corps de lélément balise de fermetureantislashn.org Architectures distribuées – couche web 02 - 19 / 62
  • 43. HTML ● Structure dun document HTML <html> <head> <title>Page minimaliste</title> </head> <body> <h2>Hello, world</h2> </body> </html> ● <html>…</html> décrit la page web ● <head>…</head> contient des informations pour le document ● <bopdy>…</body> est le contenu visible de la pageantislashn.org Architectures distribuées – couche web 02 - 20 / 62
  • 44. 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)antislashn.org Architectures distribuées – couche web 02 - 21 / 62
  • 45. 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 cadresantislashn.org Architectures distribuées – couche web 02 - 22 / 62
  • 46. 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 5antislashn.org Architectures distribuées – couche web 02 - 23 / 62
  • 47. 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 Firefoxantislashn.org Architectures distribuées – couche web 02 - 24 / 62
  • 48. HTML ● HTML 4.01 strict <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> ● HTML 4.01 transitional <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> ● HTML 4.01 frameset <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd"> <html>antislashn.org Architectures distribuées – couche web 02 - 25 / 62
  • 49. HTML ● XHTML 1.0 strict <!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"> ● XHTML 1.0 transitional <!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"> ● XHTML 1.0 frameset <!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"> ● XHTML 1.1 <!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">antislashn.org Architectures distribuées – couche web 02 - 26 / 62
  • 50. HTML ● HTML 5 ● Simplification de la syntaxe <!DOCTYPE html> <html lang="fr">antislashn.org Architectures distribuées – couche web 02 - 27 / 62
  • 51. 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 dun formulaire – balise <form … >antislashn.org Architectures distribuées – couche web 02 - 28 / 62
  • 52. HTML ● Ancres ● élément <a> (anchor) – hyper lien avec lattribut href ● appel dune autre page ● appel dun index dans une autre page, ou la même page ● lattribut target peut indiquer une autre fenêtre ou onglet ● index avec lattribut name – accessible par un hyperlien précisant lindex par #antislashn.org Architectures distribuées – couche web 02 - 29 / 62
  • 53. 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 />antislashn.org Architectures distribuées – couche web 02 - 30 / 62
  • 54. HTML ● Les formulaires <form> contiennent des champs <input> ● Les champs permettent à lutilisateur dentrer 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>antislashn.org Architectures distribuées – couche web 02 - 31 / 62
  • 55. HTML <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> ● lattribut name correspond au nom du champ tel quil pourra être récupéré côté serveur ● lattribut id permettra de récupérer lélément en JavaScript ● vrai pour tous les éléments ● unique dans la page ● lattribut 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éantislashn.org Architectures distribuées – couche web 02 - 32 / 62
  • 56. HTML ● Attributs de lélément <form> ● action : url vers laquelle le formulaire sera envoyé ● method : méthode denvoi des champs du formulaire – GET : passage par lURL http://localhost:8080/formulaires/traitement.jsp?nom=LAGAFFE&prenom=Gaston – POST : envoie dans le corps HTTP http://localhost:8080/formulaires/traitement.jsp ● enctype : définit la méthode dencodage du formulaire – application/x-www-form-urlencoded par défaut – pour les envoie de fichier doit être multipart/form-dataantislashn.org Architectures distribuées – couche web 02 - 33 / 62
  • 57. HTML ● Types de lélément <input> ● déterminé par lattribut type – button : bouton cliquable pour le support JavaScript – checkbox : cases à cocher – file : permet la saisie dun 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 dattribut name) – reset : bouton de remise à zéro des champs du formulaire – submit : bouton denvoi du formulaire – text (par défaut) : champ texteantislashn.org Architectures distribuées – couche web 02 - 34 / 62
  • 58. HTML ● Un formulaire peut aussi contenir les éléments ● <select> – liste déroulante à choix simple – ou liste à choix multiple ● <textarea> champ texte multi-lignes ● Dautres types sont introduits par HTML 5 ● date, time, ...antislashn.org Architectures distribuées – couche web 02 - 35 / 62
  • 59. HTML ● Champ <select> ● les sélections multiples seront généralement accessibles côtés serveur sous forme dun 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>antislashn.org Architectures distribuées – couche web 02 - 36 / 62
  • 60. 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/antislashn.org Architectures distribuées – couche web 02 - 37 / 62
  • 61. CSS ● Les styles CSS (Cascading Style Sheet) permettent de séparer la forme et le contenu ● avant lutilisation 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 lensemble dun site ● chargement unique des feuilles de style par mise en cache par le navigateur ● adaptation au médiaantislashn.org Architectures distribuées – couche web 02 - 38 / 62
  • 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"> déclaration du style dans p{ len-tête color: blue; text-decoration: underline; font-size: 16pt; } </style> </head> le sélecteur correspond à <body> la balise p <p>Style paragraphe</p> </body> le navigateur applique le </html> styleantislashn.org Architectures distribuées – couche web 02 - 39 / 62
  • 63. CSS ● Feuille de style externe <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> styles.css .toto{ color: red; font-weight: bold; } ● Style intra-ligne <p style="color: blue;font-style: italic">Autre style</p>antislashn.org Architectures distribuées – couche web 02 - 40 / 62
  • 64. CSS - règles ● Une règle est composé dun sélecteur et dun bloc de déclaration sé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 */antislashn.org Architectures distribuées – couche web 02 - 41 / 62
  • 65. CSS - règles ● Sélecteur classe ● il est possible dajouter une classe à un sélecteur ● il est aussi possible dutiliser # pour spécifier lid dun é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>antislashn.org Architectures distribuées – couche web 02 - 42 / 62
  • 66. CSS - règles ● Les pseudo-classes sont des classes spécifiques permettant dobtenir des effets sur des éléments sans passer par lattribut class ● :first-child :link, :visited <html> ● <head> <style type="text/css"> a:VISITED {color: blue;} ● :hover, :active, :focus a:LINK { color:blue;} a:ACTIVE { color:blue;} a:HOVER { color:red;} ● :lang </style> </head> <body> <a href="#">Lien</a> </body> </html>antislashn.org Architectures distribuées – couche web 02 - 43 / 62
  • 67. CSS - règles ● Les pseudo-éléments permettent dagir sur du contenu impossible à identifier en HTML ● :first-line ● :first-letter ● :afer, :before ● Règles spéciales ● @import ● @media ● @pageantislashn.org Architectures distribuées – couche web 02 - 44 / 62
  • 68. CSS – blocs et lignes ● On distingue deux types déléments ● les éléments blocs comme <h1>, <div>, <li>, … – après la création dun 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 ny a pas de retour à la ligne ● Certaines propriétés de style ne sont applicables que sur un type délément ● vertical-align sapplique sur les éléments en ligneantislashn.org Architectures distribuées – couche web 02 - 45 / 62
  • 69. 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 dun 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)antislashn.org Architectures distribuées – couche web 02 - 46 / 62
  • 70. CSS - blocs top (haut) marge (margin) bordure (border) remplissage (padding) left (gauche) contenu (content) limite de la boîte limite de la boîte limite des marges de remplissage de contenu limite des borduresantislashn.org Architectures distribuées – couche web 02 - 47 / 62
  • 71. CSS – unités de mesure ● Une unité de mesure est composée dun nombre suivi dune abréviation indiquant lunité ● 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 visuelantislashn.org Architectures distribuées – couche web 02 - 48 / 62
  • 72. 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 à dautre valeursantislashn.org Architectures distribuées – couche web 02 - 49 / 62
  • 73. 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 couleurantislashn.org Architectures distribuées – couche web 02 - 50 / 62
  • 74. 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 navigateurantislashn.org Architectures distribuées – couche web 02 - 51 / 62
  • 75. 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>antislashn.org Architectures distribuées – couche web 02 - 52 / 62
  • 76. 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, ...antislashn.org Architectures distribuées – couche web 02 - 53 / 62
  • 77. 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èreantislashn.org Architectures distribuées – couche web 02 - 54 / 62
  • 78. JavaScript JavaScript interagit avec le DOM du navigateur La 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)antislashn.org Architectures distribuées – couche web 02 - 55 / 62
  • 79. JavaScript Un événement est un changement détat de lenvironnement 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 lobjet Event peuvent être récupérés via les propriétés de cet objetantislashn.org Architectures distribuées – couche web 02 - 56 / 62
  • 80. Les plugins ● Tout ce qui nest pas nativement évaluer par le navigateur fait appel à des plugins ● en fonction du type MIME du document – pdf, video, audio, ...antislashn.org Architectures distribuées – couche web 02 - 57 / 62
  • 81. 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, ...antislashn.org Architectures distribuées – couche web 02 - 58 / 62
  • 82. Serveur web SERVEUR moteur de WEB script INTERNET apache IIS ... scripts SI ressources statiquesantislashn.org Architectures distribuées – couche web 02 - 59 / 62
  • 83. PHP ● Exemple PHP <html> <head> <title>Exemple</title> </head> <body> Date courante : <?php print(Date("l F d, Y")); ?> </body> </html>antislashn.org Architectures distribuées – couche web 02 - 60 / 62
  • 84. 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>antislashn.org Architectures distribuées – couche web 02 - 61 / 62
  • 85. ASP ● Exemple VB <html> <head><title>Exemple</title></head> <body> Date courante : <%=Date()%> </body> </html>antislashn.org Architectures distribuées – couche web 02 - 62 / 62
  • 86. Architectures distribuées Architectures N tiers
  • 87. Serveur dapplications ● Logiciel qui offre un contexte dexé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étierantislashn.org Architectures distribuées – N tiers 03 - 2 / 29
  • 88. Serveur dapplications ● Les clients des serveurs dapplications peuvent être ● dautres serveurs ● des clients lourds ● des clients légers ● ...antislashn.org Architectures distribuées – N tiers 03 - 3 / 29
  • 89. Serveur dapplications ● Exemple : Excel Service source : Microsoftantislashn.org Architectures distribuées – N tiers 03 - 4 / 29
  • 90. Serveur dapplications ● Exemple : Java EE source : Oracleantislashn.org Architectures distribuées – N tiers 03 - 5 / 29
  • 91. Serveur dapplications ● Exemple : WebDev source : PC Softantislashn.org Architectures distribuées – N tiers 03 - 6 / 29
  • 92. Serveur dapplications ● Exemple : Zope source : www.zope.organtislashn.org Architectures distribuées – N tiers 03 - 7 / 29
  • 93. Serveur dapplications ● 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 WebDevantislashn.org Architectures distribuées – N tiers 03 - 8 / 29
  • 94. Serveur dapplications ● Le serveur dapplication fournit un environnement dexé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 plantageantislashn.org Architectures distribuées – N tiers 03 - 9 / 29
  • 95. Serveur dapplications ● Outils complémentaires ● console dadministration – 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 testerantislashn.org Architectures distribuées – N tiers 03 - 10 / 29
  • 96. 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 applicationsantislashn.org Architectures distribuées – N tiers 03 - 11 / 29
  • 97. SOA ● Service Oriented Architecture ● Architecture de médiation ● les services sont des composants logiciels ● Popularisé avec lutilisation 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 euxantislashn.org Architectures distribuées – N tiers 03 - 12 / 29
  • 98. SOA source : Wikipedia Commonsantislashn.org Architectures distribuées – N tiers 03 - 13 / 29
  • 99. SOA et ESB ● Enterprise Service Bus ● Limplé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 lutilisation de conteneurs de services – interfaces normalisées : SOAP, JMS, ...antislashn.org Architectures distribuées – N tiers 03 - 14 / 29
  • 100. 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 ouvertsantislashn.org Architectures distribuées – N tiers 03 - 15 / 29
  • 101. 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 performanceantislashn.org Architectures distribuées – N tiers 03 - 16 / 29
  • 102. Cloud computing ● Déport vers des serveurs distants les stockages et traitements qui traditionnellement sont localisés sur les serveurs locaux ou poste de lutilisateur ● forme dinfogérance – lemplacement des données nest pas connu des clients ● Trois formes de cloud computing ● cloud privé interne ● cloud privé externe – la gestion est externalisé chez un prestataire ● cloud publiqueantislashn.org Architectures distribuées – N tiers 03 - 17 / 29
  • 103. 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 dun objet ● Deux ORB peuvent communiquer via IIOP ● Internet Inter-ORB Protocolantislashn.org Architectures distribuées – N tiers 03 - 18 / 29
  • 104. CORBA ● Common Object Request Broker Architecture ● standard maintenu par lOMG ● 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 cibleantislashn.org Architectures distribuées – N tiers 03 - 19 / 29
  • 105. CORBA source : Wikipedia Commonsantislashn.org Architectures distribuées – N tiers 03 - 20 / 29
  • 106. RMI ● Remote Method Invocation ● technologie Java ● sur le principe des ORB ● concurrence avec CORBA ● API Java dinvocation des méthodes distantes ● mécanisme dappel des méthodes dobjets Java sexécutant sur des JVM différentes ● repose sur des classe Serializable ● couche de transport propriétaire JRMP – Java Remote Method Invocation basé sur TCP/IPantislashn.org Architectures distribuées – N tiers 03 - 21 / 29
  • 107. RMI Client Serveur 3 - interroger Serveur 2 - publier de noms remiregistry appli 4 - récupérer 1 - exposer objet cliente 5 – appel de méthode distant 7 – appel de la méthode 10 - retour Serveur 6 – sérialisation des dobjets paramètres Stub Skeleton 9 – sérialisation 8 – valeur de retour du résultatantislashn.org Architectures distribuées – N tiers 03 - 22 / 29
  • 108. 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éseauantislashn.org Architectures distribuées – N tiers 03 - 23 / 29
  • 109. 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 abonnementantislashn.org Architectures distribuées – N tiers 03 - 24 / 29
  • 110. 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 dattente A Queue A A Consommateur A Producteur B Queue B B Consommateur Bantislashn.org Architectures distribuées – N tiers 03 - 25 / 29
  • 111. MOM ● Fonctionnement par abonnement ● Publish Subscrite ● les applications consommatrices de message sabonnent à un sujet (topic) ● les messages restent dans la file dattente jusquà ce que tous les abonnés aient lu le message abonnement A Topic A A Consommateur abonnement Producteur B B Topic B B Consommateurantislashn.org Architectures distribuées – N tiers 03 - 26 / 29
  • 112. MOM ● Caractéristiques ● transport des messages – un message est constitué dune en-tête et dun corps qui contient les données ● communication asynchrone – gestion des messages par file dattente ● routage des messages entre MOM ● transformation des données pour adaptation aux applications réceptrice ● persistance des messages ● fiabilité : envoi dun accusé de réception du messageantislashn.org Architectures distribuées – N tiers 03 - 27 / 29
  • 113. 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 lexposition des structures par des fichiers proto ● puis compilation vers C++, Java ou Pythonantislashn.org Architectures distribuées – N tiers 03 - 28 / 29
  • 114. En résumé EAI middleware Application WOA B ORB SOA ESB MOM Application A EAI : Enterprise Application Integration SOA : Service Oriented Architecture WOA : Web Oriented Architecture ESB : Entreprise Service Bus ORB : Object Request Broker MOM : Message Oriented Midddlewareantislashn.org Architectures distribuées – N tiers 03 - 29 / 29
  • 115. Architectures distribuées XML
  • 116. 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 laffichage 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 W3Cantislashn.org Architectures distribuées – XML 04 - 2 / 44
  • 117. XML - introduction ● La spécification XML est très simple ● une multitude dautres 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 parsersantislashn.org Architectures distribuées – XML 04 - 3 / 44
  • 118. XML - introduction ● XML est lisible ● juste du texte structuré par les balises ● XML ne fait rien, mais il sest imposé comme un standard ● fichiers de configuration ● échange de données ● description de protocole ● structuration de données ● sérialisation ● etc.antislashn.org Architectures distribuées – XML 04 - 4 / 44
  • 119. 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> <carnet-adresse> </personne> <societe> <personne> <nom>Toto and co</nom> <nom>Lagaffe</nom> <adresse>rue de Paris</adresse> <societe>Toto and co</societe> <personne> </personne> <nom>Dupond</nom> </carnet-adresse> </personne> <personne> <nom>Lagaffe</nom> </personne> </societe> </carnet-adresse>antislashn.org Architectures distribuées – XML 04 - 5 / 44
  • 120. 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 dautres élémentsantislashn.org Architectures distribuées – XML 04 - 6 / 44
  • 121. XML - syntaxe ● Un document XML est constitué ● dun prologue (optionnel) <?xml version="1.0" encoding="UTF-8"?> ● de linstance du document – au minimum une racine ● élément qui encapsule tout le reste ● un document XML vide nest pas un fichier videantislashn.org Architectures distribuées – XML 04 - 7 / 44
  • 122. XML - syntaxe ● Constitution dun élément ● balise douverture <message type="email"> – qui contient les éventuels attributs ● corps de lélément – qui contient du texte et/ou dautres éléments ● balise de fermeture </message> ● un élément qui ne contient rien peut être fermé aussitôt <br></br> <br />antislashn.org Architectures distribuées – XML 04 - 8 / 44
  • 123. XML - syntaxe ● Les éléments doivent être inclus les uns dans les autres ● sans chevauchement des balises douverture et fermeture ● seule la racine nest pas incluse dans un autre élément <a> <a> <b> <b> </b> </a> </a> </b>antislashn.org Architectures distribuées – XML 04 - 9 / 44
  • 124. ● 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 -->antislashn.org Architectures distribuées – XML 04 - 10 / 44
  • 125. XML - syntaxe ● Certains caractères ont un usage spécial : les entités ● 5 entités prédéfinies &lt ; > &gt ; < &amp ; & &apos ; (apostrophe) &quot ; " (guillemets) ● une entité peut aussi correspondre à un caractère particulier, un fichier, une suite de caractères – correspond à une "unité de stockage"antislashn.org Architectures distribuées – XML 04 - 11 / 44
  • 126. XML - syntaxe ● Le nom dun é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 despaceantislashn.org Architectures distribuées – XML 04 - 12 / 44
  • 127. 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 contenuantislashn.org Architectures distribuées – XML 04 - 13 / 44
  • 128. XML – les parsers ● Certaines parties du document ne doivent pas être analysés par les parsers ● JavaScript dun 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 ; else return b ;} ]]> </script>antislashn.org Architectures distribuées – XML 04 - 14 / 44
  • 129. 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 <societe><nom>Dupond and co</nom></societe> <salarie><nom num="123">Gaston LAGAFFE</nom></salarie> ● 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 lespace de nommage et une URI (Uniform Resource Identifier)antislashn.org Architectures distribuées – XML 04 - 15 / 44
  • 130. XML – espaces de nommage ● Exemple <soc :carnet-adresses xmlns: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>antislashn.org Architectures distribuées – XML 04 - 16 / 44
  • 131. XML – espaces de nommage ● La racine peut avoir un espace de nommage par défaut ● xmlns nest pas suivi dun nom pour lespace de nommage <carnet-adresses xmlns="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>antislashn.org Architectures distribuées – XML 04 - 17 / 44
  • 132. 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 despaces de nommage différents <web-app xmlns: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>antislashn.org Architectures distribuées – XML 04 - 18 / 44
  • 133. XML – les schémas ● Dans les faits, les noms des éléments et attributs dun 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 OpenDocumentantislashn.org Architectures distribuées – XML 04 - 19 / 44
  • 134. 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 dentités – des déclarations de notations ● spécifie le format de données non XML, binaire ou texte – des commentairesantislashn.org Architectures distribuées – XML 04 - 20 / 44
  • 135. DTD ● La DTD est liée au document XML par la directive SGML <!DOCTYPE > ● elle peut être interne au document XML <!DOCTYPE racine [declarations DTD] > ● elle peut être externe au document XML <!DOCTYPE racine SYSTEM "file.dtd" > <!DOCTYPE racine PUBLIC "fpi" "url" > ● peut être un mixte des deux <!DOCTYPE racine SYSTEM "file.dtd" [autres declarations DTD] >antislashn.org Architectures distribuées – XML 04 - 21 / 44
  • 136. 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étailsantislashn.org Architectures distribuées – XML 04 - 22 / 44
  • 137. DTD ● Exemple de DTD externe (extraits) <?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> ● et déclaration dans le fichier XML <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE carnet-adresses SYSTEM "carnet-adresses.dtd"> <carnet-adresses> ...antislashn.org Architectures distribuées – XML 04 - 23 / 44
  • 138. 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 ● nimporte quel contenu : ANYantislashn.org Architectures distribuées – XML 04 - 24 / 44
  • 139. DTD ● Liste ordonnée délément fils <!ELEMENT carnet-adresses (entreprise,contact) > ● Choix dun élément <!ELEMENT carnet-adresses (entreprise | contact) > ● Nombre d’occurrences ● par défaut : 1 occurrence ● + : 1 à n fois ● * : 0 à n fois <!ELEMENT carnet-adresses (entreprise*,contact*) > ● ? : 0 ou 1 foisantislashn.org Architectures distribuées – XML 04 - 25 / 44
  • 140. DTD ● Les attributs sont déclarés dans <!ATTLIST ...> ● on y retrouve – le nom de lattribut – 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>antislashn.org Architectures distribuées – XML 04 - 26 / 44
  • 141. DTD ● Principaux types dattributs ● 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 dattributs de type ID – séparateur : espace ● autres types possibles : énumération, ENTITY, ENTITIES, NMTOKEN, NMTOKENS, NOTATION – cf. la spécification pour plus de précisionantislashn.org Architectures distribuées – XML 04 - 27 / 44
  • 142. 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 à écrireantislashn.org Architectures distribuées – XML 04 - 28 / 44
  • 143. XML Schema ● Recommandation du W3C ● Définit la structure dun document XML de manière plus complète quune DTD ● typage des données ● espaces de nommage ● syntaxe XML ● création de types personnalisés ● Plus complexe à écrire dune DTD ● un outil constitue une aide appréciable – XMLSpy, Oxygen, EditiX, éditeurs des EDIantislashn.org Architectures distribuées – XML 04 - 29 / 44
  • 144. 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>antislashn.org Architectures distribuées – XML 04 - 30 / 44
  • 145. XML Schema ● Lécriture dun XML Schema est plus complexe quune DTD ● les outils permettent un développement du schema de manière graphiqueantislashn.org Architectures distribuées – XML 04 - 31 / 44
  • 146. XML Schema ● Élément racine du XML Schema <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> ● 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)antislashn.org Architectures distribuées – XML 04 - 32 / 44
  • 147. XML Schema ● Définition dun élément simple ● contient un contenu typé – pas délément fils – pas dattribut – xs:string par défaut <xs:element name="nom" type="xs:string"/>antislashn.org Architectures distribuées – XML 04 - 33 / 44
  • 148. XML Schema ● Définition dun é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>antislashn.org Architectures distribuées – XML 04 - 34 / 44
  • 149. XML Schema ● Définition des attributs dun élément complexe ● définition après les éléments fils élément fils définit dans lélément père <xs:element name="entreprise"> <xs:complexType> <xs:sequence> <xs:element name="raison_sociale" type="xs:string"/> <xs:element ref="adresse"/> <xs:element name="web"/> lélément fils référencie un élément définit </xs:sequence> ailleurs dans le fichier <xs:attribute name="id" type="xs:ID" use="required"/> </xs:complexType> </xs:element>antislashn.org Architectures distribuées – XML 04 - 35 / 44
  • 150. XML Schema ● XML Schema dispose dun 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 dun type simple ● avec les facettes : valeurs mini, maxi, tailles mini, maxi, … ● des expressions régulières ● des énumérations – par extension dun type existantantislashn.org Architectures distribuées – XML 04 - 36 / 44
  • 151. XML Schemaantislashn.org Architectures distribuées – XML 04 - 37 / 44
  • 152. XML Schema ● Définition dun type personnalisé ● sappuie 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>antislashn.org Architectures distribuées – XML 04 - 38 / 44
  • 153. XML Schéma ● Utilisation des espaces de nom ● attributs définis dans lélément <Schema ...> – elementFormDefault="qualified" ● les éléments sont situé dans lespace de nommage cité, ou par défaut – attributeFormDefault="unqualified" ● les attributs sont dans lespace de nom de lélémentantislashn.org Architectures distribuées – XML 04 - 39 / 44
  • 154. 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 <xs:include schemaLocation="autreSchema.xsd"/> ● insertion avec espace de nommage – les éléments inclus possède un espace de nommage différent du schema récepteur <xs:include nameSpace="autre.namespace" schemaLocation="autreSchema.xsd"/>antislashn.org Architectures distribuées – XML 04 - 40 / 44
  • 155. XML Schema <?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="n1" elementFormDefault="qualified" attributeFormDefault="qualified"> targetNamespace="n2"> <xs:element name="personne"> <xs:element name="personne"> <xs:complexType> <xs:complexType> <xs:sequence> <xs:sequence> <xs:element name="civilite"/> <xs:element name="nom"/> <xs:element name="nom"/> <xs:element name="prenom"/> <xs:element name="prenom"/> <xs:element name="age" type="xs:int"/> </xs:sequence> </xs:sequence> </xs:complexType> </xs:complexType> </xs:element> </xs:element> </xs:schema> </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>antislashn.org Architectures distribuées – XML 04 - 41 / 44
  • 156. 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 XMLantislashn.org Architectures distribuées – XML 04 - 42 / 44
  • 157. 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 laffichage des symboles mathématiquesantislashn.org Architectures distribuées – XML 04 - 43 / 44
  • 158. XML - ressources ● Sites webs ● http://www.w3.org/ ● http://www.w3schools.com/ ● http://www.quackit.com/xml/antislashn.org Architectures distribuées – XML 04 - 44 / 44
  • 159. Architectures distribuées Java EE
  • 160. Introduction ● Le développement dapplications doit répondre à de nombreuses problématiques ● rapidité du développement ● prise en compte de lévolution de lapplication ● montée en charge des connexions ● sécurisation ● Java EE – Java Enterprise Edition ● réponse Sun – Oracle au développement dapplications distribuées en entrepriseantislashn.org Architectures distribuées – Java EE 05 - 2 / 117
  • 161. Introduction ● Java EE ● ensemble dAPI – facilite la réutilisation – réduction du temps de développement – "automatisation" des facettes techniques des lapplication distribuées ● sous le contrôle du JCP (Java Community Process) – maintient la cohérence de lensemble des spécifications Java – via les JSR (Java Specification Request)antislashn.org Architectures distribuées – Java EE 05 - 3 / 117
  • 162. Introduction ● Le développeur se concentre sur le cœur métier de lapplication ● 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 lapplication ● sécurisation, montée en charge, transactions ● par un modèle déclaratif – fichiers XML ou annotationsantislashn.org Architectures distribuées – Java EE 05 - 4 / 117
  • 163. Introduction classe sérialisable ● Exemple de POJO peut posséder un SerialVersionID public class Ville implements Serializable { propriétés privées private String codePostal; private String nom; constructeur par défaut public Ville(){} public Ville(String nom, String codePostal){ this.codePostal = codePostal; this.nom = nom; } méthodes getteur / setteur public String getCodePostal(){ pour chaque propriété privée return codePostal; } public void setCodePostal(String codePostal){ this.codePostal = codePostal; } public String getNom(){ return nom; } public void setNom(String nom){ this.nom = nom; } }antislashn.org Architectures distribuées – Java EE 05 - 5 / 117
  • 164. Introduction ● Simplification du code par injection des ressources ● il nest plus nécessaire de trouver les objets dans un contexte JNDI avant de les utiliser – Java Naming and Directory Interface InitialContext ctx = new InitialContext(); ILocalVilleFacade bean = (ILocalVilleFacade)ctx.lookup(jndiName); ● injection de dépendance via les annotations @EJB private ILocalVilleFacade bean;antislashn.org Architectures distribuées – Java EE 05 - 6 / 117
  • 165. 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 SIantislashn.org Architectures distribuées – Java EE 05 - 7 / 117
  • 166. Introduction ● Application N tiersantislashn.org Architectures distribuées – Java EE 05 - 8 / 117
  • 167. 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,antislashn.org Architectures distribuées – Java EE 05 - 9 / 117
  • 168. Serveur Java EEantislashn.org Architectures distribuées – Java EE 05 - 10 / 117
  • 169. Déploiement des applications Java EE ● Les applications Java EE peuvent être déployées sous forme ● darchive web : fichier .war (web archive) ● darchive jar : fichier .jar (java archive) ● darchive ear : fichier .ear (enterprise archive)antislashn.org Architectures distribuées – Java EE 05 - 11 / 117
  • 170. É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 serveursantislashn.org Architectures distribuées – Java EE 05 - 12 / 117
  • 171. Java EE - les technologies ● Technologies dans les couches applicativesantislashn.org Architectures distribuées – Java EE 05 - 13 / 117
  • 172. Java EE - les technologies ● Couche métier : EJB – Enterprise Java Bean ● EJB Session : interaction avec le client – sans état (stateless) : service métier ● calcul dun taux dintérêt – avec état (stateful) : objet métier ● panier dachat ● 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)antislashn.org Architectures distribuées – Java EE 05 - 14 / 117
  • 173. 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, ...antislashn.org Architectures distribuées – Java EE 05 - 15 / 117
  • 174. 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é objetantislashn.org Architectures distribuées – Java EE 05 - 16 / 117
  • 175. 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 tiersantislashn.org Architectures distribuées – Java EE 05 - 17 / 117
  • 176. Java EE - les technologies ● Les services ● JavaMail API : service denvoi de mails ● JAAS (Java Authentification and Authorization Service) – gestion de groupes d’utilisateurs, de leur authentification et de leurs droits ● et bien dautres – JMS, JNDI, JDBC, ...antislashn.org Architectures distribuées – Java EE 05 - 18 / 117
  • 177. 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 dEJB ● permet laccès de manières transparentes aux services du conteneur – transaction, sécurité ● Le client du bean ninvoque jamais directement les méthodes du composantantislashn.org Architectures distribuées – Java EE 05 - 19 / 117
  • 178. 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éeantislashn.org Architectures distribuées – Java EE 05 - 20 / 117
  • 179. Java EE - les EJB ● Les types dEJBs ● 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 JPAantislashn.org Architectures distribuées – Java EE 05 - 21 / 117
  • 180. Java EE – les EJB ● Le conteneur gère laccès aux méthodes de lEJB ● 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 copieantislashn.org Architectures distribuées – Java EE 05 - 22 / 117
  • 181. Java EE – les EJB ● Pour être disponible, lEJB est inscrit dans un annuaire JNDI ● le serveur y inscrit linterface exposant les méthodes de lEJB ● Le client récupère un stub en interrogeant lannuaire JNDI ● par une méthode lookup("nomJndiEjb") ● par injection via lannotation @EJB ● le nom est différents en fonction du stub distant ou localantislashn.org Architectures distribuées – Java EE 05 - 23 / 117
  • 182. 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 ninvoque pas directement les méthodes du composant Client Proxy Proxy EJBantislashn.org Architectures distribuées – Java EE 05 - 24 / 117
  • 183. Java EE – les EJB SERVEUR JEE Conteneur EJB HTTP Conteneur Interposition locale Navigateur Servlet/JSP servlet stub EJB Interposition Client distant distante Java SE (possède aussi un stub) RMIantislashn.org Architectures distribuées – Java EE 05 - 25 / 117
  • 184. 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 dune liste de produit – vérification dune quantité en stock – enregistrement dun profilantislashn.org Architectures distribuées – Java EE 05 - 26 / 117
  • 185. 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 clientantislashn.org Architectures distribuées – Java EE 05 - 27 / 117
  • 186. Java EE – les EJB ● Conditions dutilisation dun bean de session ● à un instant donné, seulement un client a accès à linstance 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 clientantislashn.org Architectures distribuées – Java EE 05 - 28 / 117
  • 187. 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 dintérêt ● service de conversion monétaireantislashn.org Architectures distribuées – Java EE 05 - 29 / 117
  • 188. Java EE – les EJB ● Bean stateless N clients 1 instance de bean statelessantislashn.org Architectures distribuées – Java EE 05 - 30 / 117
  • 189. Java EE – les EJB ● Cycle de vie dun 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,...antislashn.org Architectures distribuées – Java EE 05 - 31 / 117
  • 190. Java EE – les EJB ● Cycle de vie dun bean stateless Nexiste pas 1 – newInstance() 2 – injection des dépendances Appel du callback PreDestroy 3 – appel du callback PostConstruct Pool des méthodes prêtesantislashn.org Architectures distribuées – Java EE 05 - 32 / 117
  • 191. Java EE – les EJB ● Bean stateful ● maintient un état conversationnel avec le client qui lutilise – 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 davoir un suivi entre deux appels de méthode – gestion dun caddie dachat – gestion dune inscription sur plusieurs écransantislashn.org Architectures distribuées – Java EE 05 - 33 / 117
  • 192. Java EE – les EJB ● Bean stateful N clients 1 instance 1 instance 1 instanceantislashn.org Architectures distribuées – Java EE 05 - 34 / 117
  • 193. 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,...antislashn.org Architectures distribuées – Java EE 05 - 35 / 117
  • 194. Java EE – les EJB Timeout Nexiste pas Timeout 1- newInstance() callback PreDestroy 2 - injection des dépendances 3 - appel du callback PostConstruct 4 – appel méthode init() callback PrePassivate Passif Méthodes prêtes callback PrePassivateantislashn.org Architectures distribuées – Java EE 05 - 36 / 117
  • 195. Java EE – les EJB ● Codage dun 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 RMIantislashn.org Architectures distribuées – Java EE 05 - 37 / 117
  • 196. Java EE – les EJB ● Codage dun bean de session ● les interfaces sont marquées avec les annotations @Remote ou @Local – package javax.ejb ● lannotation peut ne pas être présente sur linterface et reportée sur la classe dimplémentation – linterface y est alors précisée ● @Remote(value={IRemoteCalcul.class})antislashn.org Architectures distribuées – Java EE 05 - 38 / 117
  • 197. Java EE – les EJB ● Codage dun bean de session ● la classe dimplémentation du bean – hérite des interfaces – est annotée par @Stateless ou @Stateful ● lexemple suivant montre la structure dun Session Bean stateless, il est constitué – dune super-interface ICalcul – des interfaces dexposition des méthodes métiers IRemoteCalcul et IlocalCalcul – de la classe dimplémentation CalculBeanantislashn.org Architectures distribuées – Java EE 05 - 39 / 117
  • 198. 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 dun serveur ou dans une application autonomeantislashn.org Architectures distribuées – Java EE 05 - 40 / 117
  • 199. Java EE – les EJB ● Exemple de code 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.Local; import javax.ejb.Remote; @Local public interface ILocalCalcul extendsICalcul @Remote { public interface IRemoteCalcul extends ICalcul public String[] getOperationsDsiponibles(); {} } import javax.ejb.Stateless; @Stateless public class CalculBean implements ILocalCalcul, IRemoteCalcul { … }antislashn.org Architectures distribuées – Java EE 05 - 41 / 117franck.simon@antislashn. EJB 3 41
  • 200. Java EE – les EJB ● Déploiement du bean ● compilation des classes ● création dun fichier archive JAR – Calcul.jar ● copie du fichier JAR dans le répertoire de déploiement de votre serveur – JBoss : .../server/default/deployantislashn.org Architectures distribuées – Java EE 05 - 42 / 117
  • 201. 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 sil est lancé via lACC (Application Client Container), lannotation @EJB est utilisableantislashn.org Architectures distribuées – Java EE 05 - 43 / 117
  • 202. Java EE – les EJB ● Exemple de recherche par le contexte JNDI ● lannotation @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(); }antislashn.org Architectures distribuées – Java EE 05 - 44 / 117
  • 203. Java EE – les EJB ● Le codage dun stateful reste équivalent à celui dun stateless ● utilisation de lannotation @Stateful ● Le conteneur EJB ne pouvant pas déterminer la fin de l’utilisation dun 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éeantislashn.org Architectures distribuées – Java EE 05 - 45 / 117
  • 204. Java EE – les EJB ● Les intercepteurs ● les beans de session supportent les intercepteurs suivants : – @PostConstruct : invoqué après linjection des dépendances – @PreDestroy : invoqué au moment ou linstance 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)antislashn.org Architectures distribuées – Java EE 05 - 46 / 117
  • 205. Java EE – les EJB ● Des intercepteurs peuvent aussi être utilisés sur les appels des méthodes métiers ● les méthodes dinterceptions ont la signature : – public Object methode(InvocationContext ctx) throws Exception ● elles sont annotées par @AroundInvoke ... @AroundInvoke public 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; } ...antislashn.org Architectures distribuées – Java EE 05 - 47 / 117
  • 206. Java EE – les EJB ● Bean MDB ● Message Driver Bean ● rôle de traitement des messages – consommateur de messages ● le codage du MDB sous-entend quil existe un producteur de messages – une autre application – un autre module de la même applicationantislashn.org Architectures distribuées – Java EE 05 - 48 / 117
  • 207. Java EE – les EJB ● Cycle de vie dun MDB Nexiste pas 1 – newInstance() 2 – injection des dépendances Appel du callback PreDestroy 3 – appel du callback PostConstruct Pool des méthodes prêtes méthodes message listener timeout exécution de la méthodeantislashn.org Architectures distribuées – Java EE 05 - 49 / 117
  • 208. Java EE – les EJB ● Codage dun MDB ● lannotation @MessageDriven marque la classe – lattribut 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 ● limplémentation de linterface MessageListener est nécessaire si le MDB travaille avec JMSantislashn.org Architectures distribuées – Java EE 05 - 50 / 117
  • 209. Java EE – les EJB ● Codage dun 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); } }antislashn.org Architectures distribuées – Java EE 05 - 51 / 117
  • 210. Java EE – les EJB ● Service Timer ● permet lappel 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éerantislashn.org Architectures distribuées – Java EE 05 - 52 / 117
  • 211. Java EE – les EJB ● Codage de la méthode appelée par le timer @Timeout public void envoyerMail(Timer timer) { System.out.println(">>>> ENVOI MAIL"); } ● Accès au service @Resource TimerService timerService;antislashn.org Architectures distribuées – Java EE 05 - 53 / 117
  • 212. 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éfautantislashn.org Architectures distribuées – Java EE 05 - 54 / 117
  • 213. 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 JPQLantislashn.org Architectures distribuées – Java EE 05 - 55 / 117
  • 214. Java EE : couche de persistance ● JPA implémente la couche daccès aux données ● retourne des objets du domaine comme réponse aux requêtes ● persiste les objets du domaine Application objets JPA config mapping Bases de donnéesantislashn.org Architectures distribuées – Java EE 05 - 56 / 117
  • 215. Java EE : couche de persistance ● Le mapping est effectué à laide dannotations sur le POJO ● peut aussi être effectué dans un fichier XML @Entity public class Contact { @Id @GeneratedValue(strategy=GenerationType.AUTO) private int id; private String civilite; private String nom; private String prenom; … }antislashn.org Architectures distribuées – Java EE 05 - 57 / 117
  • 216. 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>antislashn.org Architectures distribuées – Java EE 05 - 58 / 117
  • 217. 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 – cest avec cette propriété que lORM maintient le lien entre linstance et lenregistrement en baseantislashn.org Architectures distribuées – Java EE 05 - 59 / 117
  • 218. Java EE : couche de persistance ● Développer avec JPA ● annoter la classe avec @Entity ● annoter les propriétés – lidentifiant 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/setantislashn.org Architectures distribuées – Java EE 05 - 60 / 117
  • 219. Java EE : couche de persistance ● Développer avec JPA ● au minimum deux annotations sont nécessaires – @Entity pour marquer la classe – @Id pour lidentifiant ● par défaut le nom de la classe correspond au nom de la table – sinon utiliser lannotation @Table ● par défaut les noms des colonnes correspondent aux nom des propriétés – sinon utiliser lannotation @Columnantislashn.org Architectures distribuées – Java EE 05 - 61 / 117
  • 220. Java EE : couche de persistance ● Lutilisation de JPA nécessite une interaction avec un EntityManager ● fournit les opérations de création, recherche, mise à jour et de suppression ● une instance dEntityManager est fournie par le serveur – par injection avec lannotation @PersistenceContext ● si JPA est utilisé dans une application autonome il faut utiliser un EntityManagerFactoryantislashn.org Architectures distribuées – Java EE 05 - 62 / 117
  • 221. Java EE : couche de persistance ● Le fichier persistence.xml définit : ● le nom de lunité 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 à limplémentation de JPA, avec les éléments <properties> et <property>antislashn.org Architectures distribuées – Java EE 05 - 63 / 117
  • 222. Java EE : couche de persistance ● Récupération dun EntityManager dans une application autonome ● on précise le nom de lunité de persistance définie dans le fichier persistence.xml EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpa"); em = emf.createEntityManager(); ● La récupération dun EntityManager peut-être effectuée par injection dans un EJB @PersistenceContext(unitName="jpa") private EntityManager em;antislashn.org Architectures distribuées – Java EE 05 - 64 / 117
  • 223. Java EE : couche de persistance ● Toutes les opérations effectuées sur lEntityManager 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(); }antislashn.org Architectures distribuées – Java EE 05 - 65 / 117
  • 224. Java EE : couche de persistance ● Opérations de base sur lEntityManager ● sauvegarde des entités avec persist(…) ● récupération dun objet par son identifiant : find(…) ● suppression dune entité en base : remove(…) ● mise à jour de la base avec lobjet : merge() ● mise à jour de lobjet avec la base : refresh() ● les modifications sur les objets sont propagées vers la base lors du commit sur la transactionantislashn.org Architectures distribuées – Java EE 05 - 66 / 117
  • 225. Java EE : couche de persistance ● Cycle de vie des entités transient new() persist() remove() instance find() query() managed sortie du contexte merge() (servlet, refresh() client lourd, …) detachedantislashn.org Architectures distribuées – Java EE 05 - 67 / 117
  • 226. 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 baseantislashn.org Architectures distribuées – Java EE 05 - 68 / 117
  • 227. 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 lannotation @ManyToOne <<entity>> * 1 <<entity>> Contact X Adresse id id civilite rue nom codePostal prenom villeantislashn.org Architectures distribuées – Java EE 05 - 69 / 117
  • 228. Java EE : couche de persistance ● La liaison est décrite dans la classe Contact @Entity public 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; … }antislashn.org Architectures distribuées – Java EE 05 - 70 / 117
  • 229. 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 JPQLantislashn.org Architectures distribuées – Java EE 05 - 71 / 117
  • 230. Java EE : couche de persistance ● Exemple de création dune requête JPQL ● ici une requête nommée mise en place par annotation … @NamedQueries({ @NamedQuery(name="CDAudio.getParArtiste", query="from CDAudio cd where cd.artiste = :artiste") }) public class CDAudio extends Produit { … ● utilisation de la requête public List<CDAudio> getCDAudiosParArtiste(String artiste) { Query query = em.createNamedQuery("CDAudio.getParArtiste"); query.setParameter("artiste", artiste); return query.getResultList(); }antislashn.org Architectures distribuées – Java EE 05 - 72 / 117
  • 231. Java EE – couche web ● Application Web ● ensemble des ressources nécessaires au bon fonctionnement dun 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 limplémentation de référence ● projet de la fondation Apache ● vérifier la version de Tomcat en fonction des spécifications servlet/JSP utiliséesantislashn.org Architectures distribuées – Java EE 05 - 73 / 117
  • 232. Java EE – couche web ● Une application Web peut être déployée dans une archive ● WAR (Web Archive) ● larchive peut être incluse dans une archive EAR (Enterprise Archive) seulement dans les serveur dapplication – ● JBoss, WebSphere, WebLogic, Geronimo, GlassFish, ... ● pas sous Tomcat Une application Web Java doit obéir à une structure de répertoire racine de lapplication répertoire obligatoire, contient le fichier descripteur web.xml contient les classes compilées de lapplication contient les librairies tiercesantislashn.org Architectures distribuées – Java EE 05 - 74 / 117
  • 233. 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 dajouter des éléments personnalisés aux JSP ● EL (Expression Language) – permet laccès aux objets de la page dans des expressions ● JSF (JavaServer Faces) – framework de développement de site webantislashn.org Architectures distribuées – Java EE 05 - 75 / 117
  • 234. Java EE – couche web ● Composants dun conteneur de servlet / JSP Server Service port 8080 Connector Engine HTTP port 8443 Connector Host HTTPS Context Context Connector port 8009 AJPantislashn.org Architectures distribuées – Java EE 05 - 76 / 117
  • 235. Java EE – couche web ● Fichier web.xml ● descripteur de déploiement standard de lapplication web mis en place dans le répertoire WEB-INF de lapplication – – élément racine <web-app> ● Contient les déclarations – des servlets – des listeners – des filtres – des paramètres – etcantislashn.org Architectures distribuées – Java EE 05 - 77 / 117
  • 236. 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>"); } }antislashn.org Architectures distribuées – Java EE 05 - 78 / 117
  • 237. 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 dalias – associer des URL avec le nom de la servlet – lappel de la ressource associée à la servlet sera du type – http://hote:port/<nom application>/<url servlet> ● exemple : http://localhost:8080/test/helloantislashn.org Architectures distribuées – Java EE 05 - 79 / 117
  • 238. 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> ...antislashn.org Architectures distribuées – Java EE 05 - 80 / 117
  • 239. 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 ● Lapplication doit être déployée sur le serveur ● par copie du répertoire racine dans le répertoire de déploiement ● par copie de larchive dans le répertoire de déploiement ● par loutil de développement ● par linterface de gestion du serveurantislashn.org Architectures distribuées – Java EE 05 - 81 / 117
  • 240. Java EE – couche web ● Le conteneur gère le cycle de vie de la servlet ● instanciation, appel des méthodes non instanciation requête HTTP servlet chargé ? de la classe oui destroy() classe oui changée ? non déchargement de service() init() linstanceantislashn.org Architectures distribuées – Java EE 05 - 82 / 117
  • 241. 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éeantislashn.org Architectures distribuées – Java EE 05 - 83 / 117
  • 242. 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 – lextension de la page JSP est jspantislashn.org Architectures distribuées – Java EE 05 - 84 / 117
  • 243. 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>antislashn.org Architectures distribuées – Java EE 05 - 85 / 117
  • 244. 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>antislashn.org Architectures distribuées – Java EE 05 - 86 / 117
  • 245. Java EE – couche web ● Contrairement à une servlet le développeur na pas à soccuper de la compilation et du déploiement dune page JSP ● la page JSP est considérée comme une ressource du site, à linstar 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(...)antislashn.org Architectures distribuées – Java EE 05 - 87 / 117
  • 246. Java EE – couche web ● JSP – cycle de vie classe non requête HTTP chargée ? oui page oui JSP déchargement de traduction de la changée linstance JSP en Java ? non instanciation de la compilation de la réponse HTTP service(...) classe classeantislashn.org Architectures distribuées – Java EE 05 - 88 / 117
  • 247. 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%>antislashn.org Architectures distribuées – Java EE 05 - 89 / 117
  • 248. Java EE – couche web ● JSP – syntaxe ● expression – évalue lexpression et lenvoie dans le flux de sortie – attention : pas de point virgule après lexpression – 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%>antislashn.org Architectures distribuées – Java EE 05 - 90 / 117
  • 249. 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 dattributs session session manipulation dattributs application application manipulation dattributs out page flux de sortie config page récupération de paramètres de configuration exception page dans page derreur uniquement, instance dExceptionantislashn.org Architectures distribuées – Java EE 05 - 91 / 117
  • 250. 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 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()); } } ● le listener doit être déclaré dans le fichier web.xml de lapplication <listener> <listener-class>test.servlet.SessionListener</listener-class> </listener>antislashn.org Architectures distribuées – Java EE 05 - 92 / 117
  • 251. Java EE – couche web ● Les listeners ● le conteneur peut nous avertir lors des phases de démarrage et de repli de lapplication – interface ServletContextListener 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"); } } ● le listener doit être déclaré dans le fichier web.xml de lapplication <listener> <listener-class>test.servlet.ApplicationListener</listener-class> </listener>antislashn.org Architectures distribuées – Java EE 05 - 93 / 117
  • 252. Java EE – couche web ● EL (Expression Language) ● simplifie la manipulation des expressions dans les pages JPS ● permet daccé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 laccès aux propriétés dun objet ● ${objet.propriete} ou ${objet[index]} – au lieu de <%=objet.getPropriete()%>antislashn.org Architectures distribuées – Java EE 05 - 94 / 117
  • 253. 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 dutilisation dans la page JSPantislashn.org Architectures distribuées – Java EE 05 - 95 / 117
  • 254. Java EE – couche web ● La librairie est déclarée dans la page JSP <%@ 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" %> ● Exemple dutilisation ... <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" /> ...antislashn.org Architectures distribuées – Java EE 05 - 96 / 117
  • 255. 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 ● Lenrichissement de EL et des librairies permet darriver à JSFantislashn.org Architectures distribuées – Java EE 05 - 97 / 117
  • 256. Java EE – couche web ● JSF : frameworks serveur de composants de présentation, utilisé pour le développement dapplication 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èleantislashn.org Architectures distribuées – Java EE 05 - 98 / 117
  • 257. ● 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éveloppeurantislashn.org Architectures distribuées – Java EE 05 - 99 / 117
  • 258. Java EE – couche web ● JSF préconise lutilisation 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 dun 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 ● LAPI peut être étendue pour créer ses propres composants ● comme les composants de Java Swingantislashn.org Architectures distribuées – Java EE 05 - 100 / 117
  • 259. Java EE – couche web ● JSF fonctionne au sein dune 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 JSFantislashn.org Architectures distribuées – Java EE 05 - 101 / 117
  • 260. 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/javaee xmlns:web=http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd servlet de xsi:schemaLocation="http://java.sun.com/xml/ns/javaee gestion des http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" mécanismes JSF 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> mapping des <welcome-file-list> JSP avec la <welcome-file>index.jsp</welcome-file> servlet JSF </welcome-file-list> </web-app>antislashn.org Architectures distribuées – Java EE 05 - 102 / 117
  • 261. 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 HTMLantislashn.org Architectures distribuées – Java EE 05 - 103 / 117
  • 262. Java EE – couche web ● Les requêtes suivent le cycle de traitement suivant : 1.rétablissement de la vue – reconstruction de larborescence 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éponseantislashn.org Architectures distribuées – Java EE 05 - 104 / 117
  • 263. Java EE – couche web ● JSF - traitementsantislashn.org Architectures distribuées – Java EE 05 - 105 / 117
  • 264. Java EE – couche web ● JSF – cycle de vieantislashn.org Architectures distribuées – Java EE 05 - 106 / 117
  • 265. 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 HtmlMessage HtmlMessage HtmlMessage HtmlSelectOneMenu HtmlInputText HtmlInputText HtmlInputText HtmlCommandButton UISelectItem UISelectItem UISelectItemantislashn.org Architectures distribuées – Java EE 05 - 107 / 117
  • 266. 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, selectantislashn.org Architectures distribuées – Java EE 05 - 108 / 117
  • 267. 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 à lorigine dactions (buttons) implémentent ActionSource – par exemple, boutons HTML submitantislashn.org Architectures distribuées – Java EE 05 - 109 / 117
  • 268. Java EE – couche web ● JSF – cycle de vie : traitement des validations ● dabord 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 nest pas validé positionne sa propriété valid à false ● FacesMessage est ajouté à FacesContextantislashn.org Architectures distribuées – Java EE 05 - 110 / 117
  • 269. 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éeantislashn.org Architectures distribuées – Java EE 05 - 111 / 117
  • 270. Java EE – couche web ● JSF – cycle de vie : appel de la logique métier ● JSF diffuse les événements vers des listeners ● les listeners sexé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éponseantislashn.org Architectures distribuées – Java EE 05 - 112 / 117
  • 271. Java EE – couche web ● JSF – cycle de vie : création du rendu ● deux tâches doivent être entreprises 1.renvoyer le rendu vers lutilisateur 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 lobjet HttpSession des applications Web en Javaantislashn.org Architectures distribuées – Java EE 05 - 113 / 117
  • 272. Java EE – couche web ● JSF – les beans managés ● POJO qui conservent létat des données de lapplication 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 lapplication JSF ● les bean sont utilisables dans toute page JSP via le langage EL – en lecture et écritureantislashn.org Architectures distribuées – Java EE 05 - 114 / 117
  • 273. 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 sourceantislashn.org Architectures distribuées – Java EE 05 - 115 / 117
  • 274. 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 sapplique la règle de navigation ● nécessaire si plus dune 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 à lutilisateur pour le <from-outcome>antislashn.org Architectures distribuées – Java EE 05 - 116 / 117
  • 275. Java EE ● Pour résumerantislashn.org Architectures distribuées – Java EE 05 - 117 / 117
  • 276. Architectures distribuées Les web services
  • 277. 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 dune technologie ou dun protocole particulierantislashn.org Architectures distribuées – web services 06 - 2 / 42
  • 278. Introduction ● Approche technologiques possibles ● web services de type WS-* – reposent sur lutilisation de SOAP et WSDL ● WS-* pour lensemble des spécifications utilisées ● web services de type REST – Representational State Transfert – repose sur lutilisation des méthodes HTTPantislashn.org Architectures distribuées – web services 06 - 3 / 42
  • 279. REST ● REST : Representation State Transfert ● style darchitecture de services Web qui part du principe que HTTP suffit pour invoquer un service web (au sens exposé sur le web) en utilisant lensemble des méthodes HTTP (GET, – POST, PUT, DELETE), et sans utiliser SOAP et XML-RPC ● REST nest pas une spécification, cest un pattern de communication ● linformation échangée peut être sous forme POX, JSON, YAMLantislashn.org Architectures distribuées – web services 06 - 4 / 42
  • 280. REST ● JSON : JavaScript Object Notation ● format déchange "humain compatible" (human readable) ● RFC 4627 ● souvent utilisé pour la sérialisation et la transmission dobjets en Ajax { "civilite":"M", "prenom":"Gaston", "nom":"LAGAFFE", "adresse":{ "rue":"Rue de Bruxelles", "ville":"Paris", "codePostal":"75000" } }antislashn.org Architectures distribuées – web services 06 - 5 / 42
  • 281. REST ● POX : Plain Old XML ● format déchange XML utilisant la spécification de base de XML – sans y mêler dautre 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>antislashn.org Architectures distribuées – web services 06 - 6 / 42
  • 282. REST ● YAML : YAML Aint Markup Language ● lidée de base est de structurer linformation pour que celle-ci soit lisible par lhomme et analysable sans ambiguïté par une machine # identité civilite: M nom: Gaston prenom: LAGAFFE adresse: rue: Rue de Bruxelles ville: Paris codePostal: 75000antislashn.org Architectures distribuées – web services 06 - 7 / 42
  • 283. Communication via SOAP annuaire des web services 1 – localisation du service UDDI client 2 – demande du WSDL WSDL 3 – requête SOAP implémentation interne en Java, 4 – réponse SOAP C#, …, ou autre point daccèsantislashn.org Architectures distribuées – web services 06 - 8 / 42
  • 284. Définitions ● WSDL – Web Service Description language ● la version 2.0 est une recommandation du W3C ● les versions précédentes nont 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 messagesantislashn.org Architectures distribuées – web services 06 - 9 / 42
  • 285. 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 distantsantislashn.org Architectures distribuées – web services 06 - 10 / 42
  • 286. SOAP ● SOAP ● protocole de communication ● communication entre applications ● format déchange de messages ● indépendant de tout langage ● basé sur XML ● recommandation du W3Cantislashn.org Architectures distribuées – web services 06 - 11 / 42
  • 287. SOAP ● SOAP est un document XML composé ● dune enveloppe <Enveloppe> identifiant le document XML comme un message SOAP ● dune en-tête facultative <Header> ● dun 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 dencodage utilisé pour la sérialisation et la dé-sérialisation des données – attribut encodingStyleantislashn.org Architectures distribuées – web services 06 - 12 / 42
  • 288. SOAP ● Lenveloppe 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:Header> facultatif </soapenv:Header> obligatoire <soapenv:Body> peut contenir un élément <Fault> </soapenv:Body> </soapenv:Enveloppe>antislashn.org Architectures distribuées – web services 06 - 13 / 42
  • 289. SOAP Application proxy SOAP client cliente du web service langage vers construction XML requête SOAP Java, C#, PHP, … XML vers décodage langage réponse SOAP Application proxy SOAP serveur web service langage vers construction Java, C#, XML réponse SOAP PHP, … XML vers décodage langage requête SOAP invocationantislashn.org Architectures distribuées – web services 06 - 14 / 42
  • 290. 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 SOAPantislashn.org Architectures distribuées – web services 06 - 15 / 42
  • 291. SOAP ● SOAP définit aussi le type dencodage pour la sérialisation et la dé-sérialisation ● encoded – règle dencodage 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 XMLSchemaantislashn.org Architectures distribuées – web services 06 - 16 / 42
  • 292. SOAP RPC ● Approche aisée pour le développement ● car utilise par défaut le mode encoding ● Il sagit dun appel dune méthode distante en passant tous les paramètres nécessaires ● le proxy SOAP client sérialise les paramètres et lappel vers le format XML ● le transport des informations est effectué via HTTP ● le proxy SOAP serveur dé-sérialise les paramètres de lappel et invoque la méthode dans le langage natifantislashn.org Architectures distribuées – web services 06 - 17 / 42
  • 293. 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 lappel de la méthode – sérialisation par la couche SOAP serveur, et dé- sérialisation par la partie SOAP client ● SOAP – RPC autorise aussi lencodage littéral – envoie dune partie darbre XML par exemple – la couche SOAP na alors quun paramètre à sérialiserantislashn.org Architectures distribuées – web services 06 - 18 / 42
  • 294. SOAP RPC ● Requête SOAP-RPC appel de la méthode getHello <soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ xmlns:ns0=http://metier.antislashn.org xmlns:xsd=http://www.w3.org/2001/XMLSchema encodage utilisé xmlns: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> passage du paramètreantislashn.org Architectures distribuées – web services 06 - 19 / 42
  • 295. SOAP-RPC ● Réponse SOAP-RPC encodage utilisé <soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns: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> retour de la méthode getHelloantislashn.org Architectures distribuées – web services 06 - 20 / 42
  • 296. SOAP-Document ● Le consortium W3C préconise lutilisation de SOAP Document ● La couche SOAP envoie le document complet au serveur sans attendre le résultat de retour ● Le message peut contenir nimporte 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 lenveloppe SOAP ● en pratique les proxys fournissent un mode fonctionnement par défautantislashn.org Architectures distribuées – web services 06 - 21 / 42
  • 297. SOAP-Document ● Lélément <Body> contient une ou plusieurs parties ● il ny a pas de règle de format sur ce que le <Body> doit contenir – la seule règle est laccord entre le client et le web service sur le contenu – les frameworks type Axis rendent transparente lutilisation du mode Document ● les proxys client et serveur sont générés symétriquement par le frameworkantislashn.org Architectures distribuées – web services 06 - 22 / 42
  • 298. SOAP-Document ● Requête SOAP-Document appel de la méthode getHello <soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ xmlns:q0=http://metier.antislashn.org xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <q0:getHello> <q0:nom>toto</q0:nom> </q0:getHello> </soapenv:Body> </soapenv:Envelope> passage du paramètre pas de précision sur lencodageantislashn.org Architectures distribuées – web services 06 - 23 / 42
  • 299. SOAP-Document ● Réponse SOAP-Document <soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns: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 getHello pas dencodage préciséantislashn.org Architectures distribuées – web services 06 - 24 / 42
  • 300. SOAP : retour derreur ● En cas derreur, la réponse peut contenir des erreurs HTTP ou SOAP ● Une erreur SOAP contient lélément <Fault> qui contient : – <Code> code derreur (obligatoire) – <Reason> explication sur lerreur (obligatoire) – <Node> nœud SOAP source de lerreur (facultatif) – <Role> rôle du nœud SOAP (facultatif) – <Detail> informations supplémentaires (facultatif)antislashn.org Architectures distribuées – web services 06 - 25 / 42
  • 301. 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)antislashn.org Architectures distribuées – web services 06 - 26 / 42
  • 302. WSDL ● WSDL pour Web Service Description Language ● document XML ● décrit un web service ● localise le web service ● spécification du consortium W3Cantislashn.org Architectures distribuées – web services 06 - 27 / 42
  • 303. 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 limplé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)antislashn.org Architectures distribuées – web services 06 - 28 / 42
  • 304. WSDL : <portType> ● Définit linterface du web service ● Les opérations qui sont prises en charge par le web service ● les messages qui participent à linvocation complète de lopération ● une opération peut être comparée à une fonction ● Cest le point dentrée du web service ● Peut être comparé à une librairie de fonctionsantislashn.org Architectures distribuées – web services 06 - 29 / 42
  • 305. WSDL : <portType> ● Types dopé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 nattendant pas de réponseantislashn.org Architectures distribuées – web services 06 - 30 / 42
  • 306. 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 limplé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éfinieantislashn.org Architectures distribuées – web services 06 - 31 / 42
  • 307. 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 lutilisation du web service, il est donc différent selon le SOAP utilisé ● rpc ou document ● encoded ou literalantislashn.org Architectures distribuées – web services 06 - 32 / 42
  • 308. 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-soap xmlns:impl=http://metier.antislashn.org type dencodage xmlns:intf=http://metier.antislashn.org xmlns: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"> déclaration des messages et des paramètres <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>antislashn.org Architectures distribuées – web services 06 - 33 / 42
  • 309. 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-soap xmlns:impl=http://metier.antislashn.org xmlns:intf=http://metier.antislashn.org xmlns: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"> description des opérations … disponibles sur le web service <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>antislashn.org Architectures distribuées – web services 06 - 34 / 42
  • 310. 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> encodage utilisé … </wsdl:definitions>antislashn.org Architectures distribuées – web services 06 - 35 / 42
  • 311. WSDL pour SOAP-RPC ● Extrait <service> lien avec le binding <?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> … url du web service </wsdl:definitions>antislashn.org Architectures distribuées – web services 06 - 36 / 42
  • 312. WSDL pour SOAP-Document ● Extrait <types> <wsdl:definitions targetNamespace=http://metier.antislashn.org xmlns:apachesoap=http://xml.apache.org/xml-soap xmlns:impl=http://metier.antislashn.org xmlns:intf=http://metier.antislashn.org xmlns: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> déclaration des types utilisés cf. slide suivant … </wsdl:definitions>antislashn.org Architectures distribuées – web services 06 - 37 / 42
  • 313. WSDL pour SOAP-Document ● Extrait <types> … <schema elementFormDefault="qualified" targetNamespace=http://metier.antislashn.org xmlns="http://www.w3.org/2001/XMLSchema"> utilisation des types <element name="getHello"> spécifiés par XMLSchema <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> …antislashn.org Architectures distribuées – web services 06 - 38 / 42
  • 314. WSDL pour SOAP-Document ● Extrait <message> <wsdl:definitions targetNamespace=http://metier.antislashn.org xmlns:apachesoap=http://xml.apache.org/xml-soap xmlns:impl=http://metier.antislashn.org xmlns:intf=http://metier.antislashn.org 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 element="impl:getHello" name="parameters" /> </wsdl:message> <wsdl:message name="getHelloResponse"> <wsdl:part element="impl:getHelloResponse" name="parameters" /> </wsdl:message> … </wsdl:definitions>antislashn.org Architectures distribuées – web services 06 - 39 / 42
  • 315. WSDL pour SOAP-Document ● Extrait <portType> <wsdl:definitions targetNamespace=http://metier.antislashn.org xmlns:apachesoap=http://xml.apache.org/xml-soap xmlns:impl=http://metier.antislashn.org xmlns:intf=http://metier.antislashn.org 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"> <wsdl:input message="impl:getHelloRequest" name="getHelloRequest" /> <wsdl:output message="impl:getHelloResponse" name="getHelloResponse" /> </wsdl:operation> </wsdl:portType> … </wsdl:definitions>antislashn.org Architectures distribuées – web services 06 - 40 / 42
  • 316. 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> encodage utilisé … </wsdl:definitions>antislashn.org Architectures distribuées – web services 06 - 41 / 42
  • 317. Développement dun 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 clientantislashn.org Architectures distribuées – web services 06 - 42 / 42
  • 318. Architectures distribuéesRich Internet Application
  • 319. Introduction ● RIA – Rich Internet Application ● terme introduit en 2002 par Macromédia ● application web offrant des caractéristiques similaires aux applications traditionnelles – interactivité – vitesse dexécution ● une RIA peut être exécutée – dans un navigateur – sur une machine, dans un sandbox ● environnement sécuriséantislashn.org Architectures distribuées – RIA 07 - 2 / 29
  • 320. É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, …antislashn.org Architectures distribuées – RIA 07 - 3 / 29
  • 321. Concepts ● Une interface riche devrait offrir les caractéristiques suivantes : 1.exécution de lIHM 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é dappareils à écran : ordinateur, TV, téléphone, …antislashn.org Architectures distribuées – RIA 07 - 4 / 29
  • 322. Concepts ● Les interfaces riches peuvent sappuyer 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 lIHM 4. le riche pur • type Flex2 dAdobe 5. le document électronique • manipulation dun document XML connecté à une architecture SOA ● XFoms du W3C, Infopath de Microsoft, document lifecycle dAdobe, …antislashn.org Architectures distribuées – RIA 07 - 5 / 29
  • 323. Application web ● Les applications web traditionnelles sarticulent 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 formulairesantislashn.org Architectures distribuées – RIA 07 - 6 / 29
  • 324. Application web ● Application web traditionnelle Navigateur Serveur url demandée 1ére requête génération de la envoi page complète première page affichage page requête + données traitements et envoi page complète génération page affichage page requête + données traitements et envoi page complète génération page affichage pageantislashn.org Architectures distribuées – RIA 07 - 7 / 29
  • 325. Client enrichi ● Afin daméliorer linteractivité avec lutilisateur 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 RIAantislashn.org Architectures distribuées – RIA 07 - 8 / 29
  • 326. 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 lobjet XMLHttpRequest ● avec lenrichissement 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, ...antislashn.org Architectures distribuées – RIA 07 - 9 / 29
  • 327. Client enrichi ● Il est complexe de maintenir la cohérence dune application Ajax ● niveaux de compatibilité ● architecture client-serveur fragile ● Nécessité dutiliser un framework ● bibliothèque extensible de widgets ● bibliothèque d’algorithmes de comportement ● cf. JQuery, GWT, JSF, ASP.NET MVC, …antislashn.org Architectures distribuées – RIA 07 - 10 / 29
  • 328. Ajax ● Asynchronous Javascript XML ● Nouvelle manière de concevoir les applications web ● basée sur divers technologies – HTML, DOM, CSS, JavaScript ● objet XMLHttpRequest – permet denvoyer une requête au serveur en JavaScript ● sans passer par lutilisateur – une fonction callback est invoquée tout le long de la réponse du serveur ● mode asynchroneantislashn.org Architectures distribuées – RIA 07 - 11 / 29
  • 329. Ajax ● Application Ajax Navigateur Serveur url demandée 1ére requête génération de la envoi page complète page + javascript page + JavaScript requête + données traitements et moteur Ajax envoi données envoi de fragments le moteur Ajax modifie le DOMantislashn.org Architectures distribuées – RIA 07 - 12 / 29
  • 330. Ajax ● La classe XMLHttpRequest permet denvoyer une requête HTTP vers le serveur et den 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(); ● lutilisation de linstance est ensuite homogèneantislashn.org Architectures distribuées – RIA 07 - 13 / 29
  • 331. Ajax ● Étapes de gestion dune 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 responseXMLantislashn.org Architectures distribuées – RIA 07 - 14 / 29
  • 332. Ajax ● Exemple de code JavaScript ● récupération dun objet XMLHttpRequest (extrait) if (window.XMLHttpRequest) { req = new XMLHttpRequest(); } else if (window.ActiveXObject) { req = new ActiveXObject("Microsoft.XMLHTTP"); } branchement de la fonction callback if (req) { req.onreadystatechange = processReqChange; req.open("GET", url, true); req.send(null); } req est déclaré plus haut dans la pageantislashn.org Architectures distribuées – RIA 07 - 15 / 29
  • 333. Ajax ● Exemple de code JavaScript ● surveillance de la réponse XMLHttpRequest (extrait) function processReqChange(){ var ready=req.readyState; variable globale valant 4 var data=null; ATTENTION : pas de gestion derreur HTTP if (ready==READY_STATE_COMPLETE){ data=req.responseText; }else{ data="loading...["+ready+"]"; } toConsole(data); }antislashn.org Architectures distribuées – RIA 07 - 16 / 29
  • 334. 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 navigateursantislashn.org Architectures distribuées – RIA 07 - 17 / 29
  • 335. JQuery ● Exemple Ajax <html> <head> <meta charset="ISO-8859-1"> objet JQuery <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); }, }); }); console JavaScript </script> du navigateur </head> <body> <div id="conteneur"></div> </body> </html>antislashn.org Architectures distribuées – RIA 07 - 18 / 29
  • 336. 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 lIHM – Action Script : langage de programmation côté client et serveur basé sur ECMAScriptantislashn.org Architectures distribuées – RIA 07 - 19 / 29
  • 337. 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 navigateurantislashn.org Architectures distribuées – RIA 07 - 20 / 29
  • 338. 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 dun navigateur, via un lien ● à partir du gestionnaire dapplications de Java Web Start ● à partir dicônes sur le bureauantislashn.org Architectures distribuées – RIA 07 - 21 / 29
  • 339. Java Web Start ● Pas de procédure dinstallation complexe ● Au lancement dune application Java Web Start se connecte au serveur pour déterminer si une nouvelle version existe ● lapplication existe en cache après le premier téléchargement ● garantit lexécution de la version la plus récente pas de mise à jour complexe des applications – ● fichier jnlp – Java Network Launching Protocol – JSR 56antislashn.org Architectures distribuées – RIA 07 - 22 / 29
  • 340. Java Web Start ● Un serveur Web est nécessaire pour le déploiement ● Ajouter au serveur Web le type MIME jnlp ● associer lextension jnpl au contenu application/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 dun type de fichier dans IISantislashn.org Architectures distribuées – RIA 07 - 23 / 29
  • 341. Java Web Start ● Création de lapplication 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(); } }antislashn.org Architectures distribuées – RIA 07 - 24 / 29
  • 342. 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>antislashn.org Architectures distribuées – RIA 07 - 25 / 29
  • 343. 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 lapplication 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>antislashn.org Architectures distribuées – RIA 07 - 26 / 29
  • 344. GWT ● Google Web Toolkit ● ensemble doutils 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 lapplication 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 W3Cantislashn.org Architectures distribuées – RIA 07 - 27 / 29
  • 345. GWT ● Développement ● utilisation dun IDE ● utilisation dun plugin dans le navigateur ● Déploiement ● sur un serveur Java EE – profil web ● sur Google App Engineantislashn.org Architectures distribuées – RIA 07 - 28 / 29
  • 346. 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 Appleantislashn.org Architectures distribuées – RIA 07 - 29 / 29
  • 347. Architectures distribuéesService Oriented Architecture
  • 348. Concepts ● Architecture de médiation ● modèle dinteraction applicative ● mise en œuvre de services ● Moyen dintégrer divers systèmes dinformation ● chaque ressource informatique est un service ● linvocation dun service est indépendante de son implémentation ● La principale technique dinvocation est SOAP ● basé sur XML et HTTPantislashn.org Architectures distribuées – SOA 08 - 2 / 45
  • 349. Concepts* image provenant de Wikipedia Commons antislashn.org Architectures distribuées – SOA 08 - 3 / 45
  • 350. Concepts ● Lapplication 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 asynchroneantislashn.org Architectures distribuées – SOA 08 - 4 / 45
  • 351. Concepts ● Interopérabilité ● technologie permettant de faire communiquer facilement des mondes différents – Microsoft – PHP – Java – C/C++antislashn.org Architectures distribuées – SOA 08 - 5 / 45
  • 352. 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 ● linvocation du service – SOAP pour les web services ● un format déchange de données – XML par exemple ● transport des données – HTTPantislashn.org Architectures distribuées – SOA 08 - 6 / 45
  • 353. Concepts ● Larchitecture 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é ● lorchestration des services pour constituer des processus métiers – exemple : langage WS-BEPL ● Web Service - Business Process Execution Language ● la gestion transactionnelleantislashn.org Architectures distribuées – SOA 08 - 7 / 45
  • 354. Concepts ● Le service est une unité atomique ● composant clé de SOA ● fonctionnalité bien définie – composant autonome – ne dépendant daucun contexte ou service ● Le service doit ● publier un ensemble dopération via des interfaces ● être autonome : pas de notion détat ● respecter un contrat ● correspondre à des fonctions mutualisables au sein de lentrepriseantislashn.org Architectures distribuées – SOA 08 - 8 / 45
  • 355. 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 quelles exposent ● De nombreux facteurs impactent indirectement lorganisation des SI ● concurrence, acquisition, fusion, évolution des législations, …antislashn.org Architectures distribuées – SOA 08 - 9 / 45
  • 356. Problématique ● Le SI de lentreprise est constitué dapplications et de données historiques ● elles constituent lhéritage de lentreprise (legacy) ● parties hétérogènes et spécialisées par métier ● manque de vision globale sur le SI ● manque de transversalité ● LEAI consiste à développer des connecteurs spécifiques permettant la communication inter- applicative ● EAI – Enterprise Application Integrationantislashn.org Architectures distribuées – SOA 08 - 10 / 45
  • 357. 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 sadapter aux demandes dans un cadre délais / coût / fiabilité – IT : Information Technology – utilisation de linformatique 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 lorganisation et les processus de gestion ● pour larchitecte IT SOA représente lorganisation globale du systèmeantislashn.org Architectures distribuées – SOA 08 - 11 / 45
  • 358. Contexte technologique ● Les acteurs majeurs décisionnels de lentreprise sont-ils identifiés ? ● Le système dinformation de lentreprise 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, ...antislashn.org Architectures distribuées – SOA 08 - 12 / 45
  • 359. SOA ● Typologie dun démarche SOA source : IT-expert n°88 - 2010antislashn.org Architectures distribuées – SOA 08 - 13 / 45
  • 360. 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 serveursantislashn.org Architectures distribuées – SOA 08 - 14 / 45
  • 361. EAI ● EAI : Enterprise Application Integration ● doit permettre linteropérabilité et lorganisation de linformation entre des applications hétérogènes ● mise en place dune 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 communicationsantislashn.org Architectures distribuées – SOA 08 - 15 / 45
  • 362. RIA ● RIA – Rich Internet Application ● application pouvant être exécutée dans un navigateur, ou localement dans un environnement sécurisé (sandbox) ● pas dinstallation requise, approche ULC (Ultra Ligth Client) ● ensemble de technologies – JavaScript, AJAX – applets Java, Adobe Flash – Java Web Start, Adobe Integration Runtime, Microsoft Click Oneantislashn.org Architectures distribuées – SOA 08 - 16 / 45
  • 363. Cloud Computing ● Cloud Computing ● utilisation des capacité de stockage et de calcul des machines et serveurs répartis sur internet ● permet lutilisation en ligne de logiciels – Google apps, Microsoft Dynamics CRM, … ● utilisation de lespace de stockage – Amazon Simple Storage Device, … ● architecture portant à controverse – lutilisateur est dépossédé des ses applications (Richard Stallman)antislashn.org Architectures distribuées – SOA 08 - 17 / 45
  • 364. 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 dacteurs 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émentationantislashn.org Architectures distribuées – SOA 08 - 18 / 45
  • 365. 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 lentrepriseantislashn.org Architectures distribuées – SOA 08 - 19 / 45
  • 366. SOA et urbanisation ● Problématiques ● évolution des stratégies dentreprise – regroupements, fusions, rachats, ... ● complexité dintégration des SI – augmentation de leffet spaghetti – augmentation des coûts ● Objectif ● le SI accompagne le changement dentreprise pour le meilleur rapport coûts/délais/qualité – utilisation des outils dEAI (Intégration dapplications dentreprise)antislashn.org Architectures distribuées – SOA 08 - 20 / 45
  • 367. SOA et urbanisation ● Urbaniser, cest diriger la transformation continue du système dinformation 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 dune application – entre les composants dun moduleantislashn.org Architectures distribuées – SOA 08 - 21 / 45
  • 368. 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 modulesantislashn.org Architectures distribuées – SOA 08 - 22 / 45
  • 369. 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 daccès à linformation (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 dintégration et de données partagéesantislashn.org Architectures distribuées – SOA 08 - 23 / 45
  • 370. SOA et urbanisation ● Exemple de découpage dune partie du SI dune banque ● ensemble des zones dactivités opérationnelles – zone : Production Bancaire – quartier : Gestion des crédits – îlot :Gestion des crédits immobiliers – bloc fonctionnel : Gestion des impayésantislashn.org Architectures distribuées – SOA 08 - 24 / 45
  • 371. 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, …antislashn.org Architectures distribuées – SOA 08 - 25 / 45
  • 372. Contrat de service ● Le contrat peut couvrir certaines obligations résultant dune 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 dappels raccrochés durant une attente – temps moyen dattente (ASA – Average Speed to Answer) – …antislashn.org Architectures distribuées – SOA 08 - 26 / 45
  • 373. Plateforme SOA application bus de composite messages annuaire SOA des application services PORTAIL composite application conteneur de composite services plateforme dadministration MOTEUR BMP accès aux données SAMantislashn.org Architectures distribuées – SOA 08 - 27 / 45
  • 374. 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 automatiquementantislashn.org Architectures distribuées – SOA 08 - 28 / 45
  • 375. SOA – les outils ● La fabrication dune plateforme SOA nécessite un ensemble doutils ● peut-on le qualifier dusine à logicielle ? ● peut-être utilisé dans une démarche MDA (Model Driven Architecture) ● Les outils : ● EAI, ESB, orchestrationantislashn.org Architectures distribuées – SOA 08 - 29 / 45
  • 376. EAI ● Appels inter-applicatifs sans EAI ● plusieurs protocoles sont utilisés ● les applications sont codées dans des Application 1 Application 2 langages différents – Java, C++, VB, … ● les plateformes dexécutions Application 3 sont différentes – linux, windows Application 4antislashn.org Architectures distribuées – SOA 08 - 30 / 45
  • 377. EAI ● Appels inter-applicatifs avec EAI Application 2 Application 1 EAI Application 3 Application 4antislashn.org Architectures distribuées – SOA 08 - 31 / 45
  • 378. EAI - fonctionnalités ● Les connecteurs ● interfacent lEAI 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 lapplication et transmet les données à lEAI – le connecteur fournit à lapplication des données provenant de lEAIantislashn.org Architectures distribuées – SOA 08 - 32 / 45
  • 379. EAI - fonctionnalités ● Les ASBO ● Application Specific Business Object ● reflètent les données de lapplication – noms de champ, formats, … ● sont mis en correspondance pour être transformés en données standard à lEAI – les BO (Business Objetc) sont standards à lEAI ● les BO reflètent un modèle de données global ● sont transmis à des traitements appelés collaborationsantislashn.org Architectures distribuées – SOA 08 - 33 / 45
  • 380. EAI - fonctionnalités ● Les collaborations ● logique de traitement à appliquer aux BO avant transmission à lapplication cible ● complète les informations – recherche dans une autre application – vérification de la validation des données – …antislashn.org Architectures distribuées – SOA 08 - 34 / 45
  • 381. 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 – …antislashn.org Architectures distribuées – SOA 08 - 35 / 45
  • 382. EAI – exemple de fonctionnement ● Une application A crée un article en base de données ● un trigger capture lévénement et archive larticle 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 lassocie à une clef "create" ● lASBO est transformé en un BO ● passage de lobjet de lapplication A en un modèle générique à lentreprise ● Un collaborateur C récupère le BO et lenvoie vers lapplication Bantislashn.org Architectures distribuées – SOA 08 - 36 / 45
  • 383. EAI – exemple de fonctionnement Application A EAI transformation BO création collaborateur AS BO connecteur connecteur interrogation régulière transformation AS BO Application Bantislashn.org Architectures distribuées – SOA 08 - 37 / 45
  • 384. EAI et ESB ● EAI est un pattern dintégration ● plusieurs implémentations ● ESB - Enterprise Service Bus ● implémentation dEAI (Enterprise Application Integration) ● structuré sous forme de bus – interopérable avec dautres bus type ESB ● structure et centralise les appels entre les différentes applicationsantislashn.org Architectures distribuées – SOA 08 - 38 / 45
  • 385. EAI et ESB ● ESB cache deux concepts différents ● le pattern darchitecture qui établit une couche dintermé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 logicielantislashn.org Architectures distribuées – SOA 08 - 39 / 45
  • 386. EAI et ESB ● Architecture type dun socle SOA source : IT-expert n°88 - 2010antislashn.org Architectures distribuées – SOA 08 - 40 / 45
  • 387. EAI et ESB ● Différentes approches EAI/ESB source : IT-expert n°88 - 2010antislashn.org Architectures distribuées – SOA 08 - 41 / 45
  • 388. ESB – les bonnes pratiques ● Granularité adaptée ● prendre en compte les cas dusage 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 à lentreprise ● exigences fonctionnelles et non fonctionnelles ● ne pas plaquer un outil / solution existant sans avoir clairement établi le besoin métierantislashn.org Architectures distribuées – SOA 08 - 42 / 45
  • 389. 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 HTTPantislashn.org Architectures distribuées – SOA 08 - 43 / 45
  • 390. EAI ● ServiceMixantislashn.org Architectures distribuées – SOA 08 - 44 / 45
  • 391. BPEL ● Business Process Execution Language ● langage de programmation destiné à orchestrer lexécution de processus dentreprise – basé sur XML – une orchestration est une collaboration entre deux ou plusieurs services ● conçu pour intégrer un nombre important dapplications publiées sous forme de services – sans dépendance de plateforme et langage – intégration automatiqueantislashn.org Architectures distribuées – SOA 08 - 45 / 45
  • 392. Architectures distribuées Haute disponibilité
  • 393. Définitions ● Haute disponibilité ● taux de disponibilité dun équipement, service, logiciel ● le taux de haute disponibilité est souvent exprimé en pourcentage ● différentes techniques permettent darriver à un taux de haute disponibilité – redondance des matériels – mise en cluster – plans de secours – mode dégradé – sécurisation des données – ...antislashn.org Architectures distribuées – haute disponibilité 09 - 2 / 13
  • 394. Définitions ● Haute disponibilité source : Wikipediaantislashn.org Architectures distribuées – haute disponibilité 09 - 3 / 13
  • 395. Définitions ● Répartition de charge (Load balancing) ● gestion tour à tour des requêtes entrantes vers un groupe de serveurs – grappe dordinateur (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 HTTPantislashn.org Architectures distribuées – haute disponibilité 09 - 4 / 13
  • 396. Définitions ● Répartition de charge source : Wikipedia Commonsantislashn.org Architectures distribuées – haute disponibilité 09 - 5 / 13
  • 397. Définitions ● Basculement sur incident (fail-over) ● capacité dun équipement à basculer automatiquement dun é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.antislashn.org Architectures distribuées – haute disponibilité 09 - 6 / 13
  • 398. 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 ressourcesantislashn.org Architectures distribuées – haute disponibilité 09 - 7 / 13
  • 399. 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 dune fonction callback pour le choix du serveurantislashn.org Architectures distribuées – haute disponibilité 09 - 8 / 13
  • 400. 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 quune session HTTP soit prise en compte par le répartiteur il est nécessaire dactiver laffinité de session ● ajout dun jeton dans lURL ou par cookieantislashn.org Architectures distribuées – haute disponibilité 09 - 9 / 13
  • 401. 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 lapplication soit répliquée sur tout ou partie des serveurs ● peut nécessiter lutilisation de caches supplémentairesantislashn.org Architectures distribuées – haute disponibilité 09 - 10 / 13
  • 402. Cluster cyclique ● La réplication des états nest pas totale Nœud A Nœud A Données : A Données : A + D réplication réplication réplication Sauvegarde : D Sauvegarde : C Nœud D Nœud B Nœud D Nœud B Données : D Données : B Données : D Données : B Sauvegarde : C Sauvegarde : A Sauvegarde : C Sauvegarde : A réplication réplication réplication réplication Nœud C Nœud C Données : C Données : C Sauvegarde : B Sauvegarde : Bantislashn.org Architectures distribuées – haute disponibilité 09 - 11 / 13
  • 403. 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 dinvalidation – dans quelle condition enlever un élément du cache – prévenir les autres caches du cluster de linvalidation ● gestionnaire de transactionantislashn.org Architectures distribuées – haute disponibilité 09 - 12 / 13
  • 404. Conclusion ● Si de grands principes existent, il ny 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 dexpériences – conférences, forum, sites dédiés, …antislashn.org Architectures distribuées – haute disponibilité 09 - 13 / 13
  • 405. Architectures distribuéesQuelques serveurs Java EE
  • 406. Loffre serveurs Java EE ● Java EE est une spécification ● Il y donc de nombreuses implémentations ● commerciales ou non ● Afin de vérifier limplé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.htmlantislashn.org Architectures distribuées – serveurs Java EE 10 - 2 / 13
  • 407. Loffre 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, …antislashn.org Architectures distribuées – serveurs Java EE 10 - 3 / 13
  • 408. Loffre 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 ● GlassFishantislashn.org Architectures distribuées – serveurs Java EE 10 - 4 / 13
  • 409. Apache Tomcat ● Projet Apache ● site : http://tomcat.apache.org/ ● Implémentation de références pour les spécifications de conteneur servlet/JSP ● ce nest pas un serveur dapplication Java EE ● Administration simple ● le plus souvent à "la main" ● console dadministration minimaliste – console managerantislashn.org Architectures distribuées – serveurs Java EE 10 - 5 / 13
  • 410. 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 Googleantislashn.org Architectures distribuées – serveurs Java EE 10 - 6 / 13
  • 411. 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 ● ...antislashn.org Architectures distribuées – serveurs Java EE 10 - 7 / 13
  • 412. JBoss ● Serveur très utilisé ● administrations, assurances ● Console dadministration depuis la version 7 ● mais encore minimalisteantislashn.org Architectures distribuées – serveurs Java EE 10 - 8 / 13
  • 413. Geronimo ● Projet Apache ● site : http://geronimo.apache.org/ ● peu utilisé dans lindustrie – IBM finance le projet – la version communautaire de WebSphere est basée sur Geronimo ● Possède une vraie console dadministrationantislashn.org Architectures distribuées – serveurs Java EE 10 - 9 / 13
  • 414. 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 lindustrie ● Nest pas certifié Java EE 6 ● au mois dAout 2012antislashn.org Architectures distribuées – serveurs Java EE 10 - 10 / 13
  • 415. 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 dadministrationantislashn.org Architectures distribuées – serveurs Java EE 10 - 11 / 13
  • 416. 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 2008antislashn.org Architectures distribuées – serveurs Java EE 10 - 12 / 13
  • 417. 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/ –antislashn.org Architectures distribuées – serveurs Java EE 10 - 13 / 13

×