Les threads Dans un environnement mutlti-tâches, plusieurs processus peuvent s'exécuter en parallèle. Dans une application mutli-threads, plusieurs activités.

Présentation au sujet: "Les threads Dans un environnement mutlti-tâches, plusieurs processus peuvent s'exécuter en parallèle. Dans une application mutli-threads, plusieurs activités."— Transcription de la présentation:

1 Les threads Dans un environnement mutlti-tâches, plusieurs processus peuvent s'exécuter en parallèle. Dans une application mutli-threads, plusieurs activités peuvent s'exécuter en parallèles. Par exemple plusieurs fonctions d'une application peuvent s'exécuter en même temps. Un « thread » est également appelé activité ou processus léger.

2 Un processus multi-threads
Notion de threads Un processus avec un seul thread Un processus multi-threads Thread 1 Thread 2 Thread 3 Il faut voir une processus comme le code correspondant au programme. Le thread est l'entité qui exécute le code. Toute application comporte au moins un thread appelé « thread pincipal ».

3 Définir un thread Définir un thread revient à créer une activité d'exécution pour un processus. La définition d'un thread revient à créer une classe qui hérite de « java.lang.Thread ». Le fait de créer une instance de la classe qui implante « java.lang.Thread » n'entraîne pas la création d'un thread. Pour créer un thread, on doit appeler la méthode « start » L'appel à « start » entraîne la création du thread et le début de son traitement qui commence par la méthode « run ».

4 Un exemple de thread public class monThread extends java.lang.Thread {
// … public void run() // Traitement du thread. } // ... La sortie de la méthode « run » met fin à la vie du Thread.

5 Exemple d'utilisation d'un thread
public class ExempleThread extends java.lang.Thread { public static int threadCompteur = 0; public int numThread = 0; public int count = 5; public ExempleThread() numThread = ThreadCompteur++; System.out.println("Création du thread n°" + numThread ); } public void run() while ( count != 0 ) System.out.println("Thread n°" + numThread + " , compteur = " + count-- ); public static void main( String [] args ) for ( int i=0; i<3; i++ ) new ExempleThread().start(); System.out.println("Tous les threads sont lancés");

6 A l'exécution... Création du thread n°1 Création du thread n°2
Thread n°1, compteur = 5 Thread n°2, compteur = 5 Thread n°2, compteur = 4 Thread n°2, compteur = 3 Thread n°3, compteur = 5 Thread n°1, compteur = 4 Tous les threads sont lancés Thread n°3, compteur = 4 ... L'ordonnancement est imprévisible.

7 Interruption et reprise d'un Thread
On peut interrompre un thread par l'intermédiaire de l'opération « suspend ». Pour relancer l'exécution d'un thread, on fait appel à la méthode « resume ». On peut également marquer une pause dans l'exécution d'un thread en employant l'opération « sleep ». Enfin, un thread peut attendre la fin d'un autre thread en appliquant l'opération « join » sur le thread en question.

8 Autre opérations d'un thread
Pour arrêter un thread on utilise l'opération « stop » : public final void stop(); Pour connaître la priorité d'un thread, on emploi la méthode « getPriority » : public final int getPriority(); De plus, pour fixer la priorité d'un thread, on utilise « setPriority » : public final void setPriority(int newPriority);

9 Comment récupérer le thread courant ?
Lorsqu'une méthode est exécutée, elle peut l'être par plusieurs threads. Pour connaître le thread courant, elle peut utiliser l'opération « currentThread » : public static Thread currentThread(); A partir de la référence vers le thread récupéré, on peut appliquer toutes les opérations traditionnelles aux threads. L'opération « currentThread » peut être également utilisée pour récupérer le thread principal.

10 Accès concurrents Que se passe t'il si plusieurs threads accèdent à la même méthode ou à la même ressource au même instant ? Comportement imprévisible selon les applications problématique des accès concurrents Pour qu'une méthode ne soit pas utilisée par plus d'un thread à la fois, il faut la spécifier « synchronized » : synchronized type_de_retour nom_methode ( liste des paramètres ) Un même thread pourra tout de même appeler récursivement cette opération.

11 Les verrous Un verrou ( en anglais « mutex » ) est un concept qui lorsqu'il est activé empêche les threads qui n'ont pas activés le verrou d'utiliser le code verrouillé. Tant que le verrou n'est pas levé, seul un thread peut être actif dans le code verrouillé. Chaque objet java peut servir de verrou. Comment créer une zone verrouillée ? On applique « synchronized » sur un objet.

12 Exemple de verrou java.lang.Object verrou = new java.lang.Object();
synchronized ( verrou ) { // Zone verrouillée. } On pourrait très bien écrire : synchronized ( this )

13 L'interface « java.lang.Runnable »
Pour définir un thread, on peut également implanter l'interface « java.lang.Runnable » plutôt que d'hériter de « java.lang.Thread » Cette interface définie l'opération « run » qui doit être implantée et qui correspond à la méthode appelée au lancement du thread. Pour créer un thread à partir d'une classe qui implante « Runnable », on doit créer une instance de « java.lang.Thread » qui prenne en paramètre une référence vers cette classe. public Thread(Runnable target); On ne peut pas appliquer les opération de « Thread » directement sur une classe qui implante « Runnable ».

14 Exemple de thread utilisant « Runnable »
public class monThread implements Runnable { public void run() { // … } public static void main( String [] args ) Thread t = new Thread( new monThread() ); t.start(); }

15 Le JDK 1.2 et les opérations sur les threads
Plusieurs opérations sont notés « deprecated » dans le JDK 1.2. En particulier les opérations « suspend » et « resume » ne doivent plus être utilisées. Utiliser à la place une synchronisation à partir d'un verrou. De plus, l'opération « stop » est également déconseillée au profit de l'utilisation d'une variable : public void run() { while ( stop != true ) { // … } } public void stop() { stop = true; }

16 Les threads démons Lorsqu'une application créée un thread, celle-ci reste bloquée tant que le thread ne meurt pas. Pour éviter cela, il est possible de signaler qu'un thread joue le rôle de démon. Lorsqu'une application termine, tous les threads démons sont alors stoppés. Pour signaler le fait qu'un thread est un démon, on doit lui appliquer l'opération « setDaemon » : public final void setDaemon(boolean on);

17 Courage c'est la dernière fois...
Développer une application qui comporte deux threads. Les threads partageront la même ressource dont l'interface est : interface Ressource { public void ouvrir(); public void fermer(); public boolean est_ouvert(); } Les threads travailleront de la façon suivante : un premier qui applique ouvrir puis fermer sur la ressource commune, un second qui applique fermer puis ouvrir sur la ressource. chaque thread doit vérifier l'état de la ressource après chaque traitement. Les traitements sont infinis.

18 X. BLANC & J. DANIEL Xavier.Blanc@lip6.fr , Jerome.Daniel@der.edf.fr
Java RMI X. BLANC & J. DANIEL ,

19 Principe de Java RMI Java RMI pour Java Remote Method Invocation
C’est un façon pour faire communiquer deux classes situés sur deux machines différentes. Une classe située dans une machine virtuelle appelle la méthode d’une classe située dans une autre machine virtuelle. Java RMI est une architecture Sun (contrairement à CORBA

20 Architecture de Java RMI
Client Serveur Stub Skeleton Remote Reference Layer Transport Layer

21 Obtention du stub à l’exécution
Il faut disposer du stub de l’objet pour pouvoir invoquer des méthodes à distance. Si on ne dispose pas du stub, il est possible de l’obtenir au moment de l’utilisation de l’objet. La classe implantant le stub est rechercher en locale Si la classe n’est pas trouvée en locale, on la cherche sur le site distant Le stub est transmis au poste client puis chargé par le client lui-même Ce mécanisme est automatiquement géré par Java.

22 Définir une interface distante Java
Une interface distante décrit un objet distant. Elle doit hériter de java.rmi.Remote Cette interface identifie le décrit le type des objets répartis Toute les méthodes qui constituent l’interface distante doivent pouvoir générer une exception de type RemoteException

23 Exemple d’interface Import java.rmi.*;
public interface Calculatrice extends Remote { public add(int a, int b) throws RemoteException; }

24 Implanter une interface
On définie une classe qui implante l’interface distante. Cette classe doit hériter de UnicastRemoteObject import java.rmi.*; import java.rmi.server.*; public class CalculatriceImpl extends UnicastRemoteObject Implements Calculatrice { public int add(int a, int b) throws RemoteException { return a+b;} }

25 Rendre accessible un serveur
Pour cela on doit : créer un manager de sécurité ajouter le serveur a ceux disponible sous Java RMI (bind) public static void main(String args[]) { try { System.setSecurityManager(new RMISecurityManager()); CalculatriceImpl calc = new CalculatriceImpl(); String nom =   "Calculatrice"; Naming.rebind(nom.calc); } catch (Exception ex) {…}

26 Générer le stub et le skeleton
Pour cela, on utilise le compilateur rmic fourni avec Java. Les arguments de rmic sont identiques à ceux de javac La génération du stub et du skeleton s ’effectue à partir de la classe d’implantation rmic CalculatriceImpl

27 Développer un client Le client est une classe traditionnelle qui va utiliser le service de désignation de Java RMI pour retrouver le serveur auquel il souhaite accéder. Le service de désignation va retourner une référence sur l’objet (RemoteObject) qui devra être convertie vers l’objet que l’on souhaite utiliser (cast). L’opération qui retourne le serveur prend en paramètre une sorte d ’URL (//host/name).

28 Exemple de client Import java.rmi.*; public class CalculatriceClient {
public static void main(String args[]) { String serverName =   "Calculatrice"; CalculatriceInterface calc; try { calc = (CalculatriceInterface) Naming.lookup(serveurName.toString()); System.out.println("  6+2=  "+calc.add(6,2); } catch (RemoteException ex) {…} catch (Exception e) {…}

29 Exécuter l’application répartie
On doit en premier lieux, lancer le service de désignation de Java RMI (rmiregistry) sur la machine ou se situ le serveur Ce service doit connaître l’endroit où les classes sont accessibles (c’est à dire que le CLASSPATH doit être positionné avent le lancement de l’utilitaire. On lance ensuite le serveur, puis le client

30 Exercice Créer une classe accessible à distance. Cette classe sera une pile.

31 Sérialisation des objets
La sérialisation est un mécanisme utilisé pour l’encodage et décodage des paramètres lors d’un appel distant. En particulier, dans le cas ou l’on devrait passer une structure de données particulière lors d’un appel, notre structure devrait supporter la notion de sérialisation pour pouvoir être transmise (c ’est à dire implanter l’interface java.io.Serializable).

32 Les exceptions avec Java RMI
Toutes les méthodes d’une interface doivent signaler l’exception RemoteException car: il peut survenir un problème lors d’une communication client/serveur : dans ce cas, c’est RMI qui généra cette exception. Toutes les exceptions définies par l’utilisateur devront hériter de la classe RemoteException.

33 Garbage collector d’objets distants
De façon à maintenir une cohérence dans la modèle Java. Java RMI dispose d’un mécanisme de garbage collection d’objets distants Ce mécanisme utilise un algorithme complexe qui maintient un liste de toutes les références à des objets distants. Un protocole entre les références d ’objets permet l’incrémentation et la décrémentation des références. Ainsi, RMI assure un compteur de référence pour chaque objet distant, lorsque le compteur arrive à 0, l’objet est alors détruit. La méthode finalize est bien entendue appelée au moment de la destruction de l ’objet.

34 EJB 2.0 Enterprise Java Bean ™ Xavier BLANC

35 Plan Introduction Architecture Développement Transaction Security
Session Entity Message Driven Bean Transaction Security Environnement Ejb-jar Best pratices Conclusion

36 1 - Introduction

37 1 - Introduction Goals EJB architecture will be the standard for building distributed object-oriented business application in Java. EJB architecture will make possible to build distributed applications by combining components developed using tools from different vendors. EJB architecture will make it easy to write applications (without knowing the low-level details). EJB will follow the WORA™ EJB Architecture will adress the development, deployment, and runtime aspects of an enterprise application’s life cycle. …

38 Exemple d’utilisation
1 - Introduction Exemple d’utilisation Bean façade fournissant tous les services (création commande, achat produit, …) Beans représentant les données (commande, produit, …) Sécurité Transaction Portabilité Server EJB Server EJB Mainframe / BD Clients (Java, Web, CORBA).

39 2 - Architecture

40 2 - Architecture Overview Enterprise JavaBean is an architecture for component based distributed computing Enterprise Beans are components of distributed transaction-oriented enterprise applications

41 Component characteristics
2 - Architecture Component characteristics An enterprise bean typically contains business logic that operates on the enterprise’s data. An enterprise bean’s instances are created and managed at runtime by a Container. An enterprise bean can be customized at deployment time by editing its environment entries. Various services information, such as a transaction and security attributes, are separate from the enterprise bean class. This allows the services information to be managed by tools during application assembly and deployment. Client access is mediated by the Container in which the enterprise Bean is deployed.

42 Types de Roles Bean provider Application assembler Deployer
2 - Architecture Types de Roles Bean provider Application assembler Deployer System administrator EJB server provider EJB container provider Development Production EJB Architecture

43 Types de Bean Session Bean : réalise une tache au nom du client
2 - Architecture Types de Bean Session Bean : réalise une tache au nom du client Stateful : Bean avec état (1 bean par utilisateur) Stateless : Bean sans état (1 bean pour plusieurs utilisateurs) Entity Bean : représente une donnée (pérenne) de l’entreprise Message Driven Bean : Communication par message (lien vers JMS)

44 Local vs Remote Bean Afin d’améliorer les performances, l’architecture EJB contient (à partir de la version 2.0) des beans locaux. Un bean local n’est accessible que si le client est dans la même JVM. Attention : Passage des paramètres par référence.

45 Enterprise bean instances
2 - Architecture EJB Contracts Client-View Client Enterprise bean instances Component Contract Container EJB Server Deployment Descriptor

46 Client-view (Local / Remote)
2 - Architecture Client-view (Local / Remote) Identité du composant Le container fournit une identité unique par composant Home interface Le container fournit des opérations de gestion de composants : Create, Remove, Find … Component interface Le container permet aux clients d’invoquer les méthodes du composants Metadata (Remote only) Invocation dynamique Handle (Remote only)

47 2 - Architecture Component Contract Le session bean provider doit suivre les règles d’implémentation. Le conteneur doit déléguer les appels des clients vers les beans et fournir les services utilisés par le bean. L’entity bean provider doit suivre les règles d’implémentation. Le conteneur doit déléguer les appels des clients vers les beans, fournir les services utilisés par le bean et gérer automatiquement la persistance. Le message driven bean provider doit suivre les règles d’implémentation. Le conteneur doit retourner les messages vers les beans correspondant.

48 Deployment descriptor
2 - Architecture Deployment descriptor Un ejb-jar est le format standard de packaging de beans Contient les classes du beans Contient un descripteur de déploiement (sous format XML)

49 3 - Développement 3-1 Session Bean

50 3.1 – Session Bean Overview For a client, a session object is a non-persistent object that implements some business logic running on the server. One way to think of a session object is as a logical extension of the client program that runs on the server. A session object is not shared among multiple clients.

51 3.1 – Session Bean Client View Un client accède à un Bean à travers son interface (RemoteInterface ou LocalInterface) L’objet qui implante l’interface est construit par le conteneur (EJBObject ou EJBLocalObject) existe dans un container a une identité n’est pas persistant Plusieurs objets peuvent exister dans un même conteneur

52 3.1 – Session Bean Client View La création d’une instance de bean se fait par l’intermédiaire de la Home Interface Le container exporte la référence de la Home Interface grâce à JNDI La Home Interface permet aussi de chercher et de supprimer les instances

53 Client View 3.1 – Session Bean EJBObject Client EJBHome EJB 1
EJBLocalObject EJBLocalHome EJB 2

54 Récupération de la Home
3.1 – Session Bean Récupération de la Home La récupération de la Home se fait via JNDI. //Preparation du context JNDI Context iniCtx = new InitialContext(); //Obtention de la référence d’objet Object ref = iniCtx.loohup("java.comp/env/ejb/monBean"); //Cast (si Local alors cast à la Java) MonBeanHome home = (MonBeanHome) PortableRemoteObject.narrow(obj, MonBeanHome.class);

55 Création d’une instance
3.1 – Session Bean Création d’une instance La Home interface doit fournir une ou plusieurs méthodes de création d’instances create<Method> (ces méthodes sont à la charge du Bean Provider) //Obtention de la Home (voir slide précédent) MonBeanHome home; //Appel d’une méthode create MonBean bean = home.create(); //MonBean bean = home.createName("xavier");

56 3.1 – Session Bean Utilisation du Bean L’utilisation du bean se fait par des appels classiques. //Création du Bean (voir slide précédent) MonBean bean; //Appel d’une méthode XXX bean.getProductPrice("sourie");

57 3.1 – Session Bean Handle Un Handle est un objet qui représente une référence vers un bean. Il est possible de stocker un Handle sur mémoire secondaire pour récupérer plus tard la référence d’un bean. Méthodes : handle.getEJBObject(); // pour retrouver la référence bean.getHandle(); //pour obtenir un handle

58 Suppression Deux façons existent pour supprimer un bean :
3.1 – Session Bean Suppression Deux façons existent pour supprimer un bean : remove(); // directement sur le bean remove(Handle h); // sur la Home

59 3.1 – Session Bean Cycle de vie STATEFUL STATELESS

60 3.1 – Session Bean Component Contract Une instance de Session Bean représente une session entre le client et l’application. Ses champs contiennent l’état de la session. Typiquement une instance de Session Bean lit et écrit des données dans une base de données (via des Entity Bean). La vie de l’instance de Session Bean correspond à la vie du client.

61 3.1 – Session Bean Component Contract Un container gère la mémoire de son environnement de travail. Pour cela, il peut stocker les beans sur un autre support. Chacun des bean doit donc implanter deux fonctions. Une fonction ejbPassivate appelée lors du transfert du bean sur un autre support. Une fonction ejbActivate appelée lors du transfert du bean vers le container.

62 3.1 – Session Bean Component Contract Afin de facilité les stratégies de passivation, deux sortes de Session Bean ont été définies: STATEFUL: Avec état. Tout le contenu du Bean doit être sauvegardé. STATELESS: Sans état. Le contenu du Bean n’a pas à être sauvegardé.

63 3.1 – Session Bean SessionContext Lors d’une création d’instance, le conteneur associe à chaque instance un contexte de session (interface SessionContext) Cet objet permet de : Récupérer une référence vers l’objet ou vers la Home Récupérer les informations relatives à la sécurité (Principal) Récupérer les information relatives aux transactions (UserTransaction, RollBack mode). Le Bean Provider doit offrir les méthodes nécessaires à l’enregistrement de cet objet.

64 Création d’une Instance de Session Bean Stateful
Client EJB Home EJB Object Context Instance create(args) new new new setSessionContext() ejbCreate(args)

65 3.1 – Session Bean Cycle de Vie STATEFUL

66 Création d’une Instance de Session Bean Stateless (1/2)
Client EJB Home EJB Object Context Instance Create() new

67 Création d’une Instance de Session Bean Stateless (2/2)
Container Context Instance new new setSessionContext() ejbCreate()

68 3.1 – Session Bean Cycle de vie STATELESS

69 Developpement Session Bean
Trois classes à développer La classe d’implémentation du bean Interface du bean (Local ou Remote) Home Interface (Local ou Remote) Dans les AGL, il suffit souvent de développer la classe d’implémentation du bean.

70 Classe d’implémentation
3.1 – Session Bean Classe d’implémentation Doit implanter javax.ejb.SessionBean. ejbPassivate(), ejbActivate(), ejbRemove(), setSessionContext() Doit être public et pas abstract pas final. Doit disposer d’un constructeur public sans paramètre. Ne doit pas définir de méthode finalize(). Doit implanter les méthodes ejbCreate<Method>(). Doivent être public Ne doivent pas être final ou static Les arguments doivent être valide RMI/IIOP Doivent retourner void Peuvent retourner l’exception java.ejb.CreateException Doit implanter les méthodes business. Ne doivent pas avoir un nom qui commence par ejb

71 Interface Remote Doit hériter de javax.ejb.EJBObject
3.1 – Session Bean Interface Remote Doit hériter de javax.ejb.EJBObject Les méthodes de l’interface doivent correspondre aux méthodes business accessibles à distance de la classe d’implémentation. Doivent retourner l’exception java.rmi.RemoteException

72 Home Remote Doit hériter de javax.ejb.EJBHome
3.1 – Session Bean Home Remote Doit hériter de javax.ejb.EJBHome Les méthodes de la Home doivent correspondre aux méthodes ejbCreate<Method> de la classe d’implémentation. Doivent retourner l’exception javax.ejb.CreateException

73 Interface Local Doit hériter de javax.ejb.EJBLocalObject
3.1 – Session Bean Interface Local Doit hériter de javax.ejb.EJBLocalObject Aucune méthode ne doit retourner l’exception java.rmi.RemoteException Les méthodes de l’interface doivent correspondre aux méthodes business accessibles de la classe d’implémentation.

74 Home Local Doit hériter de javax.ejb.EJBLocalHome
3.1 – Session Bean Home Local Doit hériter de javax.ejb.EJBLocalHome Aucune méthode ne doit retourner l’exception java.rmi.RemoteException Les méthodes de la Home doivent correspondre aux méthodes ejbCreate<Method> de la classe d’implémentation.

75 3.1 – Session Bean Exemple public class CalculatriceBean implements javax.ejb.SessionBean { /** Méthodes business. */ public double add(double v1,double v2) {return v1+v2;} public double sub(double v1,double v2) {return v1-v2;} public double mul(double v1,double v2) {return v1*v2;} public double div(double v1,double v2) {return v1/v2;} /** Méthodes de creation. */ public void ejbCreate() {} /** Méthodes de l'interface SessionBean. */ public void ejbActivate() {} public void ejbPassivate() {} public void ejbRemove() {} public void setSessionContext(SessionContext sc) {this.sc = sc;} protected SessionContext sc; }

76 Exemple import javax.ejb.EJBObject; import java.rmi.RemoteException;
3.1 – Session Bean Exemple import javax.ejb.EJBObject; import java.rmi.RemoteException; public interface CalculatriceRemote extends EJBObject { public double add(double v1,double v2) throws RemoteException; public double sub(double v1,double v2) throws RemoteException; public double mul(double v1,double v2) throws RemoteException; public double div(double v1,double v2) throws RemoteException; }

77 Exemple import javax.ejb.EJBHome; import javax.ejb.CreateException;
3.1 – Session Bean Exemple import javax.ejb.EJBHome; import javax.ejb.CreateException; import javax.ejb.RemoveException; public interface CalculatriceHome extends EJBHome { public CalculatriceRemote create() throws CreateException; }

78 A vous de jouer Donner des exemples de beans STATEFUL et STATELESS
3.1 – Session Bean A vous de jouer Donner des exemples de beans STATEFUL et STATELESS Définissez leurs classes Vos critiques ?

79 3 - Développement 3-2 Entity Bean

80 3.2 – Entity Bean Overview For a client, an entity bean is a component that represents an object-oriented view of some entities stored in a persistent storage, such as a database, or entities that are implemented by an existing enterprise application.

81 3.2 – Entity Bean Client View Les principes de la vue cliente des Entity Bean sont basés sur les principes de la vue cliente des Session Bean Les instances sont créées via la Home La home est accessible via JNDI Le client accède aux beans via leur interface Identité des objets … La différence fondamentale est que les Entity Bean représentent des données pérennes. Leur durée de vie est infinie.

82 Architecture 3.2 – Entity Bean EJBObject EJBHome EJB 1 Client
EJBLocalObject EJBLocalHome EJB 2

83 3.2 – Entity Bean Trouver un bean Une Home définit une ou plusieurs méthodes find<Method> pour retrouver des entity beans ou des ensembles d’entity beans. La méthode findByPrimaryKey() est toujours fournie. Le type de la clé peut être n’importe quel type conforme à RMI/IIOP

84 3.2 – Entity Bean Vie d’un Entity Bean

85 3.2 – Entity Bean Component Contract Un Entity Bean est une réification d’une donnée. La durée de vie de la donnée est infinie. Un Entity Bean est fortement lié avec une BD. La persistance d’un bean peut être : gérée par le conteneur : CMP gérée par le bean lui-même : BMP

86 Component Contract : CMP
3.2 – Entity Bean Component Contract : CMP Pour gérer la persistance par le conteneur : Les champs persistant d’un Entity Bean CMP doivent être spécifiés dans le descripteur de déploiement. <cmp-field><field-name>nom</field-name></cmp-field> Des relations entre Entity Bean de type 1:1, 1:* et *:* peuvent être spécifiées dans le descripteur de déploiement. Utilisation de EJB QL pour générer les méthodes ejbFind<Method> et ejbSelect<Method>. Le conteneur fait appel aux méthodes ejbStore et ejbLoad du bean lors d’un passage à la mémoire secondaire. Ces dans ces méthodes que le bean provider doit recalculer les propriétés éphémères du bean.

87 Component Contract : BMP
3.2 – Entity Bean Component Contract : BMP La persistance est entièrement à la charge du bean provider. Le lien avec la BD est donc entièrement à la charge du bean provider. Le bean peut être sauvegardé à n’importe quel moment (après chaque appel de méthode). Lorsque le conteneur a besoin de sauvegarder le bean, il fait appel aux méthodes ejbLoad et ejbStore

88 3.2 – Entity Bean EntityContext Lors d’une création d’instance, le conteneur associe à chaque instance un contexte de session (interface EntityContext) Cet objet permet de : Récupérer une référence vers l’objet ou vers la Home Récupérer les informations relatives à la sécurité (Principal) Récupérer les information relatives aux transactions (UserTransaction, RollBack mode). Le Bean Provider doit offrir les méthodes nécessaires à l’enregistrement de cet objet.

89 3.2 – Entity Bean Cycle de vie : CMP

90 3.2 – Entity Bean Cycle de vie : BMP

91 3.2 – Entity Bean EJB QL Langage pour la spécification des méthodes find<Method> et select<Method>. Compilé vers des langages cible de BD (SQL, …) Utilise les informations définies dans le descripteur de déploiement (champs persitents et relations). Exclusivement Entity Bean CMP.

92 EJB QL Exemples Find all orders : SELECT OBJECT(o) FROM Order o
3.2 – Entity Bean EJB QL Exemples Find all orders : SELECT OBJECT(o) FROM Order o Find all orders that need to be shipped in CA SELECT OBJECT(o) FROM Order o WHERE o.shipping_address.state=‘CA’

93 Entity Bean & Transaction
Remarquons que les Entity Beans sont souvent utilisés par plusieurs clients en parallèle. Il faut donc faire attention aux problèmes de cohérence. Donc il faut utiliser les mécanismes de transaction proposés par EJB.

94 Developpement Entity Bean
Classes à développer La classe d’implémentation du bean La classe de la PrimaryKey Interface du bean (Local ou Remote) Home Interface (Local ou Remote) Dans les AGL, des wizards permettent de construire des EJB Entity à partir de shéma de BD et réciproquement.

95 Classe d’implémentation CMP
3.2 – Entity Bean Classe d’implémentation CMP Doit implanter javax.ejb.EntityBean Doit être public et abstract Doit disposer d’un constructeur public sans paramètre. Ne doit pas définir de méthode finalize(). Doit implanter les méthodes ejbCreate<Method>() et ejbPostCreate(). Doivent être public Ne doivent pas être final ou static Les arguments doivent être valide RMI/IIOP Doivent retourner le type de la clé primaire Peuvent retourner l’exception java.ejb.CreateException Doit disposer d’accesseur abstract pour les champs persistent (get, set). Ne doit pas définir de méthode ejbFind<Method>, celles-ci seront générées. Doit définir les méthodes ejbSelect<Method> abstract

96 Classe d’implémentation BMP
3.2 – Entity Bean Classe d’implémentation BMP Doit implanter javax.ejb.EntityBean Doit être public et pas abstract Doit disposer d’un constructeur public sans paramètre. Ne doit pas définir de méthode finalize(). Doit implanter les méthodes ejbCreate<Method>() et ejbPostCreate(). Doivent être public Ne doivent pas être final ou static Les arguments doivent être valide RMI/IIOP Doivent retourner le type de la clé primaire Peuvent retourner l’exception java.ejb.CreateException Doit disposer d’accesseur abstract pour les champs persistent (get, set). Doit définir les méthodes ejbFind<Method>, public.

97 Interface Remote Doit hériter de javax.ejb.EJBObject
3.2 – Entity Bean Interface Remote Doit hériter de javax.ejb.EJBObject Les méthodes de l’interface doivent correspondre aux méthodes business accessibles à distance de la classe d’implémentation. Doivent retourner l’exception java.rmi.RemoteException

98 Home Remote Doit hériter de javax.ejb.EJBHome
3.2 – Entity Bean Home Remote Doit hériter de javax.ejb.EJBHome Les méthodes de la Home doivent correspondre aux méthodes ejbCreate<Method> de la classe d’implémentation. Doivent retourner l’exception javax.ejb.CreateException Les méthodes de la Home doivent correspondre aux méthodes ejbFind<Method> de la classe d’implémentation Doivent retourer l’exception javax.ejb.FinderException

99 Interface Local Doit hériter de javax.ejb.EJBLocalObject
3.2 – Entity Bean Interface Local Doit hériter de javax.ejb.EJBLocalObject Les méthodes de l’interface doivent correspondre aux méthodes business accessibles à distance de la classe d’implémentation.

100 Home Local Doit hériter de javax.ejb.EJBLocalHome
3.2 – Entity Bean Home Local Doit hériter de javax.ejb.EJBLocalHome Les méthodes de la Home doivent correspondre aux méthodes ejbCreate<Method> de la classe d’implémentation. Doivent retourner l’exception javax.ejb.CreateException Les méthodes de la Home doivent correspondre aux méthodes ejbFind<Method> de la classe d’implémentation Doivent retourer l’exception javax.ejb.FinderException

101 Exemple (CMP) 3.2 – Entity Bean <cmp-field>
<field-name>nom</field-name> </cmp-field> <field-name>solde</field-name> public abstract class CompteBean implements javax.ejb.EntityBean { /** Setters/getters pour l'acces aux données du bean. */ public abstract String getNom(); public abstract double getSolde(); public abstract void setNom(String nom); public abstract void setSolde(double solde); /** constructeur **/ public Compte() {super();} /** Méthodes de l'interface Home. */ public String ejbCreate(String nom) throws CreateException { setNom(nom); setSolde(0.0); return nom; } public void ejbPostCreate(String nom) { } /** Méthodes de l'interface EntityBean. */ public void ejbActivate() {} public void ejbPassivate() {} public void ejbRemove() {} public void ejbLoad() {} public void ejbStore() {} public void setEntityContext(EntityContext sc) {this.sc = sc;} public void unsetEntityContext() {} protected EntityContext sc; }

102 Exemple (CMP) import javax.ejb.EJBObject;
3.2 – Entity Bean Exemple (CMP) import javax.ejb.EJBObject; import javax.ejb.RemoveException; public interface Compte extends EJBObject{ public String getNom() throws RemoveException; public double getSolde() throws RemoveException; public void setNom(String nom) throws RemoveException; public void setSolde(double solde) throws RemoveException; }

103 Exemple (CMP) 3.2 – Entity Bean import javax.ejb.EJBHome;
import javax.ejb.CreateException; import javax.ejb.RemoveException; public interface CompteHome extends javax.ejb.EJBHome{ /*create */ public String create(String nom) throws CreateException, RemoteException; /*find*/ public Compte findByPrimaryKey(String key) throws FinderException, RemoteException }

104 A vous de jouer Donner des exemple d’Entity Bean
Définissez leurs classes CMP ou BMP ? Vos critiques ?

105 3 - Développement 3-3 Message Driven Bean

106 Overview A message-driven bean is an asynchronous message consumer.
A message-driven bean is invoked by the container as a result of the arrival of a JMS message. A message-driven bean has neither a home nor a component interface. A message-driven bean instance is an instance of a message-driven bean class.

107 3.3 – Message Driven Bean Client View Pour un client, un driven message bean n’est que le destinataire d’une queue de messages. Le client n’a aucune visibilité sur le bean Le bean est entièrement masqué.

108 Client View 3.3 – Message Driven Bean Client Destination Instances
Container

109 Obtenir un destinataire JMS
3.3 – Message Driven Bean Obtenir un destinataire JMS Une Queue JMS est souvent enregistrée dans JNDI Obtenir un destinataire revient à rechercher une référence JNDI : Context initialContext = new InitialContext(); Queue stockInfoQueue = (javax.jms.Queue) initialContext.lookup (“java:comp/env/jms/stockInfoQueue”);

110 3.3 – Message Driven Bean Component Contract Le cycle de vie d’un Message Driven Bean est entièrement géré par le conteneur Le conteneur doit notifier le Message Driven Bean lorsque celui-ci reçoit un message (onMessage) Un Message Driven Bean peut être abonné (via descripteur de déploiement) : à une queue à un topic

111 MessageDrivenContext
3.3 – Message Driven Bean MessageDrivenContext Lors d’une création d’instance, le conteneur associe à chaque instance un contexte de session (interface MessageDrivenContext) Cet objet permet de : Récupérer les informations relatives à la sécurité (Principal) Récupérer les information relatives aux transactions (UserTransaction, RollBack mode). Le Bean Provider doit offrir les méthodes nécessaires à l’enregistrement de cet objet.

112 3.3 – Message Driven Bean Cycle de Vie

113 Développement Driven Message Bean
3.3 – Message Driven Bean Développement Driven Message Bean Une seule classe à développé : celle du bean Doit implanter l’interface javax.ejb.MessageDrivenBean Doit implanter l’interface javax.jms.MessageListener Doit être public, non final et non abstract Doit disposer d’un constructeur public sans argument. Ne doit pas définir de méthode finalize() Doit définir une méthode ejbCreate() Doit définir la méthode onMessage(Message)

114 Exemple 3.3 – Message Driven Bean
public class MonMessageDrivenBean implements javax.ejb.MessageDrivenBean , javax.jms.MessageListener { public MonMessageDrivenBean() {} //From MessageDrivenBean public void ejbRemove() {} public ejbCreate() {} protected MessageDrivenContext ctx; public void setMessageDrivenContext(MessageDrivenContext ctx) {this.ctx = ctx;} //From MessageListener void onMessage(Message message) {//Business} }

115 A vous de jouer Donnez des exemple de MDB Vos critiques ?
3.3 – Message Driven Bean A vous de jouer Donnez des exemple de MDB Vos critiques ?

116 4 - Transaction

117 4 – Transaction Overview Transactions are a proven technique for simplifying application programming. Transactions free the application programmer from dealing with the complex issues of failure recovery and multi-user programming. If the application programmer uses transactions, the programmer divides the application’s work into units called transactions. The transactional system ensures that a unit of work either fully completes, or the work is fully rolled back. Furthermore, transactions make it possible for the programmer to design the application as if it ran in an environment that executes units of work serially.

118 Les transactions dans EJB
Le support des transactions réparties est une caractéristique principale de l’architecture EJB. Les aspects transactionnels sont : Soit gérés par le serveur EJB Utilisation de javax.transaction.UserTransaction Commit RollBack Soit par le bean lui même. La gestion par le serveur EJB est totalement transparent. Description dans le descripteur de déploiement

119 4 – Transaction Granularité Spécification dans le descripteur de déploiement de la granularité SUPPORTS NOT_SUPPORTED REQUIRED REQUIRES_NEW MANDATORY BEAN_MANAGED: transactions à la charge du bean Pour le bean appelant soit il s'exécute dans une transaction soit il s'exécute en dehors de tout contexte transactionnel <container-transaction> <method> <ejb-name> EmployeRecord </ejb-name> <method-name>*</method-name> </method> <trans-attribute> Required </trans-attribute> </container-transaction>

120 4 – Transaction Supports si l'appelant a une transac. ouverte, l'appelé s’exécute dans ce contexte sinon aucune transac. n’est ouverte Appelant Appelé Appelant Appelé

121 NOT_SUPPORTED L'appelé ne supporte pas les transactions
en cas d’utilisation dans 1 transac., celle-ci est suspendue Appelant Appelé Appelant Appelé

122 4 – Transaction REQUIRED si l'appelant a une transac. ouverte, l'appelé s’exécute dans ce contexte sinon le conteneur commence une nouvelle transac. Appelant Appelé Appelant Appelé

123 REQUIRES_NEW une nouvelle transac. est systématiquement créée Appelant
4 – Transaction REQUIRES_NEW une nouvelle transac. est systématiquement créée Appelant Appelé Appelant Appelé

124 4 – Transaction MANDATORY si l'appelant a une transac. ouverte, l'appelé s’exécute dans ce contexte sinon une erreur est générée Appelant Appelé Appelant Appelé Erreur

125 5 - Sécurité

126 5 – Sécurité Overview Lessen the burden of the application developer (i.e. the Bean Provider) for securing the application by allowing greater coverage from more qualified EJB roles. The EJB Container provider provides the implementation of the security infrastructure; the Deployer and System Administrator define the security policies. Allow the security policies to be set by the Application Assembler or Deployer rather than being hard-coded by the Bean Provider at development time. Allow the enterprise bean applications to be portable across multiple EJB Servers that use different security mechanisms.

127 5 – Sécurité La Sécurité dans EJB L’architecture de l’Entreprise de Java Bean permet de transférer la gestion de la sécurité au niveau du serveur. La sécurité au sein des Java Bean inclus: Un accès à l’API de sécurité de Java (java.security) pour gérer localement la sécurité. Une description aux niveau de l’archive (XML) pour que le serveur gère la sécurité.

128 Sécurité par le Container
Il est possible de spécifier des règles d’accès pour chacune des méthodes. Ceci se fait par l’intermédiaire du descripteur XML Description de rôles Description des règles de sécurités

129 Déclaration XML de rôle
5 – Sécurité Déclaration XML de rôle <security-role> <description> blabla </description> <role-name> employe </role-name> </security-role> …

130 Déclaration XML de règles
5 – Sécurité Déclaration XML de règles <method-permission> <role-name> employe </role-name> <method> <ejb-name> EmployeServ </ejb-name> <method-name>*</method-name> </method> </method-permission>

131 5 – Sécurité La Sécurité dans EJB L’architecture Entreprise Java Bean utilise le package de sécurité du langage Java : java.security. Le package n’est pas décrit dans la norme, celle-ci nous renvoie à Java. La classe java.security.Principal est plus précisément utilisée pour identifier un client.

132 5 – Sécurité La Sécurité locale Un bean a accès aux informations du serveur via son contexte. Celui-ci offre donc deux fonctions pour permettre à un bean d’obtenir l’identité d’un client. getCallerPrincipal() IsCallerInRole(String role_name)

133 5 – Sécurité Référence des rôle Si bean référence un rôle (isUserInRole()) : <security-role-ref> <description> blabla </description> <role-name> employe </role-name> </security-role-ref>

134 5 – Sécurité Déploiement C’est lors du déploiement qu’il faut relier les rôles avec les mécanismes de sécurité Roles avec user NT Roles avec user LDAP …

135 6 - Environnement

136 6 – Environnement Overview The Application Assembler and Deployer should be able to customize an enterprise bean’s business logic without accessing the enterprise bean’s source code. Most enterprise beans must access resource managers and external information. The key issue is how enterprise beans can locate external information without prior knowledge of how the external information is named and organized in the target operational environment. The enterprise bean environment mechanism attempts to address both of the above issues.

137 6 – Environnement JNDI Pour obtenir une ressource, il est vivement conseillé d’utiliser JNDI (l’enfer des ClassLoader) L’espace de nom java:/comp/env est alloué pour chaque EJB. // Obtain the enterprise bean’s environment naming context. Context initCtx = new InitialContext(); Context myEnv = (Context)initCtx.lookup("java:comp/env");

138 Variables d’environnement
Il est possible de définir des variables d’environnement du bean (!= OS) Le nom et le type de ces variables doivent être spécifiés dans le descripteur de déploiement (la valeur est optionnelle) <env-entry> <description>BlaBlaBla.</description> <env-entry-name>maxExemptions</env-entry-name> <env-entry-type>java.lang.Integer</env-entry-type> <env-entry-value>15</env-entry-value> </env-entry>

139 EJB Il est possible de définir des références entre Bean.
6 – Environnement EJB Il est possible de définir des références entre Bean. Le nom et le type du bean doivent être spécifiés dans le descripteur de déploiement. Il est conseillé de préfixer le nom par ‘ejb’

140 EJB <ejb-ref> <description>Blablabla</description>
6 – Environnement EJB <ejb-ref> <description>Blablabla</description> <ejb-ref-name>ejb/MaRefBean1</ejb-ref-name> <ejb-ref-type>Entity</ejb-ref-type> <home>fr.jussieu.MonBeanHome</home> <remote>fr.jussieu.MonBean</remote> </ejb-ref>

141 Autres types de ressources
6 – Environnement Autres types de ressources Vers les BD Connection Factory Vers les Queue ou Topic JMS …

142 7 - ejb jar

143 7 – ejb-jar Overview The ejb-jar file format is the contract between the Bean Provider and the Application Assembler, and between the Application Assembler and the Deployer.

144 Items Un ejb-jar est un fichier jar qui contient :
Le descripteur de déploiement Les classes des Beans Bean, Home, Remote Les autres ressources nécessaires

145 Descripteur de déploiement
7 – ejb-jar Descripteur de déploiement Fichier XML valide qui décrit un ensemble de beans Pour chaque bean Nom du bean, Classes du bean, Type (Entity, Session) Caractéristiques pérennes (pour les Entity) Caractéristiques Transactionnelles Caractéristiques Sécurité Environnement

146 7 – ejb-jar Echanges L’Ejb-jar est l’élément d’échange entre outils (analyse, développement, déploiement, …). Les EJB peuvent donc être considéré comme des composants sur étagères.

147 8 – Best Practices

148 8 – Best Practices Sensibilisation L’architecture EJB facilite grandement la tache des développeurs en automatisant fortement certaines techniques (répartition, sécurité, transaction, environnement). Mais, il est important de bien comprendre les mécanismes sous-jacent pour maitriser la bête : Cas de l’exception org.omg.CORBA.COMM_FAILURE

149 Design Pattern, Framework
8 – Best Practices Design Pattern, Framework Afin de minimiser les communications client/server il est intéressant de construire une copie locale d’un bean Entity, d’effectuer plusieurs opérations en local et de transmettre la copie lorsque cela est nécessaire : AccessBean Afin de ne pas mettre tout le traitement dans un bean, il est intéressant de construire une classe Business et de faire en sorte que le Bean ne soit qu’un objet de délégation (évolution) …

150 L’Etat du marché Jusqu’à EJB 1.1 Aujourd’hui EJB 2.0
8 – Best Practices L’Etat du marché Jusqu’à EJB 1.1 pas d’Entity Bean (surtout pas CMP) pas de sécurité EJB 101 Damnations (article) Aujourd’hui EJB 2.0 ???

151 9 - Conclusion

152 Success Story ? Succès commercial => Oui
9 – Conclusion Success Story ? Succès commercial => Oui Projets (J2EE) Servlet, EJB, BD / CICS Plateforme de + en + efficace WebSphere IBM, Weblogic BEA, Oracle, JBoss Des inconvénients (structurels ?) Performance, Monté en charge Stabilité (jeunesse du standard) Un concurrence Inexistante jusqu’à il y a un an .Net & Web Services

153 Références Spécifications Livres Articles
9 – Conclusion Références Spécifications EJB Specification (version 2.0 Livres Mastering EJB 2.0 EJB Design Pattern Articles EJB’s 101 Damnations (Dino Fancellu, Robin Sharp, Matt Stephens)

154 Xavier Blanc Xavier.Blanc@lip6.fr
Web Services Xavier Blanc

155 Plan Principes XML (Notions) SOAP WSDL UDDI Axis Conclusion

156 Définition Les Web Services sont des services offerts via le web.
Par exemple, un client demande le prix d’un article en envoyant un message sur le web. Ce message contient la référence de l’article. Le Web Service va recevoir la référence, effectuer le traitement du service et renvoyer le prix au client via un autre message.

157 Pourquoi un nouveau middleware
Principes Pourquoi un nouveau middleware

158 Limitations des middleware
Passage à large échelle : Web Protocoles hétérogènes IIOP, RMI, DCOM Firewall Pas d’ouverture des services Notion de moteur de recherche inexistante Trop de contraintes sur le client ! Doit posséder les souches Difficulté de construire dynamiquement

159 Limitations des middleware
Inconvénients Intrinsèques Complexité CORBA : IDL, Mapping, … EJB : Container, JNDI, … Pérennité : remise en question CORBA, EJB, .Net, … Prix Plates-formes Compétences

160 Solutions existantes Modification du Protocole Passerelles
RMI / IIOP Passerelles CORBA vers DCOM Portage d’applications existantes difficile Solutions non standards

161 Approche Envisagée Un nouveau Protocole : SOAP
Basé sur XML Portabilité, Hétérogénéité Porté sur des protocoles large échelle existants HTTP, SMTP, … Paradigme orienté service : WSDL Définition de services offerts (en XML) Découverte automatique des services (dynamicité) : UDDI Référentiel de Web Service (Pages Jaunes, Vertes, Blanches)

162 Ex : ModFact UDDI SOAP / HTTP IIOP SOAP / SMTP
Le serveur doit savoir recevoir des messages SOAP (sur HTTP ou SMTP). Il effectue les traitements correspondant (ici délégation vers CORBA). Les clients doivent savoir envoyer des messages SOAP (sur HTTP ou SMTP) SOAP / HTTP IIOP SOAP / SMTP Application existante classique (ici CORBA) UDDI Exportation du Web Service dans le référentiel UDDI Utilisation de UDDI pour construire dynamiquement des client

163 SOAP Protocole d’échange de messages (client / serveur)
Basé entièrement sur XML Standard W3C (Initiative IBM et Microsoft) Actuellement SOAP 1.1 Concepts Message = Enveloppe ( Header + Body ) Extensibilité Porté sur HTTP, SMTP, …

164 WSDL Langage de définition de Web Services Basé entièrement sur XML
Standard W3C (Initiative IBM et Microsoft) Actuellement WSDL 1.1 Définition de l’interface, de l’URL et du port du Web Service. Utilise le système de typage de XML Schéma

165 UDDI Référentiel de définitions Web Service
Permet de construire dynamiquement des clients Recommandation OASIS Référentiel défini lui-même en WSDL Référentiel Public / Privé

166 Notions nécessaires pour les Web Services
XML Notions nécessaires pour les Web Services

167 Exemple de document XML
<livre> <titre> le super livre </titre> <chapitre> <numero> 1 </numero> <titre> titre du chapitre 1 </titre> <contenu> blabla blabla </contenu> </chapitre> <chapitre> … </chapitre> </livre>

168 Principes Ensemble non fini de balises
L’utilisateur peut créer de nouvelles balises Définition de grammaires : XML est un Meta-Langage MathML, NewsML, XMI, Doc, Slides, … Séparation de la forme et du fond Un document XML peut être constitué de deux entités (le fond et la forme)

169 Grammaire Deux façons de définir une grammaire XML : DTD XML Schéma
Langage de définition de grammaire XML Largement utilisé Expression faible (type, structure) XML Schéma Langage XML de définition de grammaire XML De + en + utilisé Expression puissante (type, structure, héritage) Un document XML est dit valide lorsqu’il est conforme à une grammaire

170 Espaces de noms Mécanismes permettant de partitionner les balises XML (permet d’avoir deux fois le même nom de balise) Un espace de nom est défini dans n’importe quelle balise par l’attribut xmlns et par une URI. Dans un document XML, un espace de noms est identifié par un nom logique, les balises appartenant à cet espace doivent alors être préfixée par ce nom logique. Ex : <meta:body xmlns:meta="

171 XML est un succès ! Standard W3C
La syntaxe XML ne contient que peu de mot clef: Simplicité XML est indépendant des plates-formes: Portabilité XML est un méta-langage, il est possible de créer ses propres balises: Extensibilité Outils disponibles (et gratuits) Largement utilisé pour les échanges inter-applications

172 A vous de jouer ! Pouvez-vous définir un document XML qui représente un message Client/Serveur ? Quelles sont les informations que ce message doit contenir ? Comment échanger ce message ? Quels sont les problèmes soulevés ?

173 Simple Object Access Protocol Version 1.1
SOAP Simple Object Access Protocol Version 1.1

174 Abstract SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework.

175 Exemple de message StockQuote est un ensemble de services qui permet d’obtenir des informations sur des actions boursières. GetLastTradePrice est le service qui permet de connaître la dernière valeur d’une action. Cet exemple présente un échange de messages entre un client qui veut savoir la valeur de l’action « DIS ».

176 Exemple de message POST /StockQuote HTTP/1.1
Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope   xmlns:SOAP-ENV="   SOAP-ENV:encodingStyle=" <SOAP-ENV:Body>     <m:GetLastTradePrice xmlns:m="Some-URI">         <symbol>DIS</symbol>     </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Propre au portage sur HTTP

177 Exemple de message HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope   xmlns:SOAP-ENV="   SOAP-ENV:encodingStyle=" <SOAP-ENV:Body>     <m:GetLastTradePriceResponse xmlns:m="Some-URI">         <Price>34.5</Price>     </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Propre au portage sur HTTP

178 Analyse de l’exemple Des Balises Utilisateur Un Namespace Utilisateur
GetLastTradePriceResponse Symbol Price Un Namespace Utilisateur xmlns:m="Some-URI" Des Balises SOAP Enveloppe Body Un Namespace SOAP xmlns:SOAP-ENV=" Des informations dans la partie HTTP

179 Namespace SOAP Le namespace des balises SOAP
Le namespace de l’encodage SOAP

180 Structure d’un message SOAP
Framework Structure d’un message SOAP Un message SOAP est contenu dans une balise Envelope Une Envelope peut contenir une balise Header Une Header peut contenir n’importe quel ensemble de balises. Ces balises doivent appartenir à des namespaces. Une Envelope doit contenir une balise Body Un Body peut contenir n’importe quelle ensemble de balises. Ces balises peuvent appartenir à des namespaces. Un Body peut contenir des balises Fault qui permettent d’identifier des erreurs.

181 SOAP Header Mécanisme d’extension du protocol SOAP
Framework SOAP Header Mécanisme d’extension du protocol SOAP La balise Header est optionnelle Si la balise Header est présente, elle doit être le premier fils de la balise Envelope La balise Header contient des entrées Une entrée est n’importe quelle balise incluse dans un namespace

182 SOAP Header Example <SOAP-ENV:Header>
Framework SOAP Header Example <SOAP-ENV:Header> <t:Transaction xmlns:t="some-URI"> 5 </t:Transaction> </SOAP-ENV:Header>

183 SOAP Body Le Body contient le message à échanger
Framework SOAP Body Le Body contient le message à échanger La balise Body est obligatoire La balise Body doit être le premier fils de la balise Envelope (ou le deuxième si il existe une balise Header) La balise Body contient des entrées Une entrée est n’importe quelle balise incluse optionnellement dans un namespace Une entrée peut être une Fault.

184 SOAP Fault Balise permettant de signaler des cas d’erreur.
Framework SOAP Fault Balise permettant de signaler des cas d’erreur. La balise Fault contient les balises suivantes faultcode : un code permettant d’identifier le type d’erreur Client, Server, VersionMismatch, MustUnderstand faultstring : une explication en langage naturel faultactor : une information identifier l’initiateur de l’erreur detail : Définition précise de l’erreur.

185 Encoding Encodage Un message SOAP contient des données typées. Il faut donc définir un moyen d’encoder ces données. Vocabulaire SOAP : Value (valeur d’une donnée) Simple value (string, integers,etc) Compound value (array, struct, …) Type (d’une value) Simple Type Compound Type

186 Encodage L’encodage c’est la représentation de valeurs sous forme XML.
Encoding Encodage L’encodage c’est la représentation de valeurs sous forme XML. Le décodage c’est la construction de valeurs à partir d’XML L’XML qui représente les valeurs a une structure qui dépend du type des valeurs Il faut donc définir le type Soit mécanisme définit par l’utilisateur Soit utilisation d’XML Schéma (préconisé)

187 Simple Types Type (XML Schema) <element name="age" type="int"/>
Encoding Simple Types Type (XML Schema) <element name="age" type="int"/> <element name="color"> <simpleType base="xsd:string"> <enumeration value="Green"/> <enumeration value="Blue"/> </simpleType> </element> Valeurs <age>45</age> <color>Blue</color> Type XML Schema Construction de Type XML Schema

188 Encoding Simple Types La définition d’un XML Schéma pour tout type peut être fastidieux SOAP a défini deux façons de préciser le type d’une valeur sans définir le Schéma XML: <SOAP-ENC:int>45</SOAP-ENC:int> <cost xsi:type="xsd:float">29.5</cost>

189 Encoding Compound Types Une structure est un type composé dans lequel les membres sont accessibles uniquement grâce à des noms différents. Un tableau est un type composé dans lequel les membres sont accessibles uniquement grâce à leur position.

190 Struct Type (XML Schéma) <element name="Person">
Encoding Struct Type (XML Schéma) <element name="Person"> <complexType> <element name="name" type="xsd:string"/> <element name="age" type="xsd:int"/> </complexType> <element> Valeur <Person> <name>Xavier</name> <age>30</age> </Person>

191 Array Le type est directement précisé grâce aux balises SOAP:
Encoding Array Le type est directement précisé grâce aux balises SOAP: <myFavoriteNumbers SOAP-ENC:arrayType="xsd:int[2] "> <SOAP-ENC:int>3</SOAP-ENC:int> <SOAP-ENC:int>4</SOAP-ENC:int> </myFavoriteNumbers>

192 SOAP avec HTTP SOAP peut être facilement porté sur Http.
Convention SOAP avec HTTP SOAP peut être facilement porté sur Http. Convient au mode Request/Response de Http Le message SOAP est mis dans une requête POST avec un content-type text/xml Définition d’un header http : SOAPAction Utilisation des codes http (2xx, 4xx, 5xx)

193 SOAP avec HTTP POST /StockQuote HTTP/1.1
Convention SOAP avec HTTP POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope   xmlns:SOAP-ENV="   SOAP-ENV:encodingStyle=" <SOAP-ENV:Body>     <m:GetLastTradePrice xmlns:m="Some-URI">         <symbol>DIS</symbol>     </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

194 SOAP avec HTTP HTTP/1.1 500 Internal Server Error
Convention SOAP avec HTTP HTTP/ Internal Server Error Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope   xmlns:SOAP-ENV=" <SOAP-ENV:Body>     <SOAP-ENV:Fault>         <faultcode>SOAP-ENV:Server</faultcode> <faultstring>Server Error</faultstring>     </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

195 SOAP & RPC Pour faire un RPC SOAP, il faut:
Convention SOAP & RPC Pour faire un RPC SOAP, il faut: L’URI de l’objet cible Le nom de la méthode Les paramètres de la méthode SOAP s’appuie sur le protocole d’en dessous (http) pour l’URI de l’objet. Le nom de la méthode et les paramètres sont encodés dans le message SOAP sous forme de structure.

196 SOAP & Document L’approche RPC est de moins en moins préconisée
Convention SOAP & Document L’approche RPC est de moins en moins préconisée On préfère maintenant utiliser l’approche Document qui consiste à envoyer des document XML dans les messages SOAP sans convention particulière.

197 A vous de jouer ! Comparer SOAP par rapport à CORBA ?
IDL ? IIOP ? SOAP est-il dédié uniquement au RPC ? Si non, à quoi d’autre ? Quel est l’intérêt de porter SOAP sur d’autres protocoles ?

198 Web Services Description Language Version 1.1
WSDL Web Services Description Language Version 1.1

199 Présentation Une description WSDL :
Décrit le type d’un service web (méthodes, types des paramètres) Cette description peut être comparée à la description IDL CORBA, elle peut servir à générer automatiquement des amorces. Décrit les aspects techniques d’implantation d’un service web (quel est le protocole utilisé, quel est le l’adresse du service) Cette description sert à se connecter concrètement à un service web.

200 Balises Une description WSDL est un document XML qui commence par la balise definition et contient les balises suivantes : types: cette balise décrit les types utilisés message: cette balise décrit la structure d’un message échangé portType: cette balise décrit un ensemble d’opérations (interface d’un service web) operation: cette balise décrit une opération réalisée par le service web. Une opération reçoit des messages et envois des messages. binding: cette balise décrit le lien entre un protocole (http) et un portType. service: cette balise décrit un service comme un ensemble de ports. port: cette balise décrit un port au travers duquel il est possible d’accéder à un ensemble d’opérations. Un port référence un Binding

201 Balises (avec XML Spy) Utilisé pour sectionner des descriptions WSDL

202 types Description en utilisant XML Schema. <wsdl:types>
<xs:schema targetNameSpace=" xmlns:xs=" <xs:element name="personne"> <xs:complexType> <xs:sequence> <xs:element name="nom" type="xs:string" /> <xs:element name="prenom" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> </wsdl:types>

203 message Les messages sont envoyés entre deux interlocuteurs (ex: une opération reçoit des message et envoie des messages. Un message est composé de plusieurs part Deux façons de définir des part Soit une part est un élément de type simple Soit une part est un élément XML dont le type est défini dans un XML Schema

204 message Part de type simple Part qui utilise un XML Schema
<wsdl:message name="personneMsg"> <wsdl:part name="nom" type="xsd:string" /> <wsdl:part name="prenom" type="xsd:string" /> </wsdl:message> Part qui utilise un XML Schema <wsdl:part name="personne" element="exemple:personne" /> Défini dans un XML Schema

205 portType Un portType permet d’identifier (nommer) de manière abstraite un ensemble d’opérations. <wsdl:portType name="descriptionPersonnes" > <wsdl:operation name="getPersonne" > … </wsdl:operation> <wsdl:operation name=“setPersonne" > </wsdl:portType>

206 operation WSDL définit 4 types d’opération :
One-Way : lorsque les opérations reçoivent des messages mais n’en n’envoient pas Request-response : lorsque les opérations reçoivent des messages puis renvoient des messages Solicit-response : lorsque les opérations envoient des messages puis en reçoivent Notification : lorsque les opérations envoient des messages mais n’en reçoivent pas

207 operation Quelque soit le type d’opération la définition est sensiblement la même : Une opération : Reçoit des messages : <wsdl:input …> Envoie des messages : <wsdl:output …> ou <wsdl:fault …> La présence et l’ordre des input/outputs/fault dépendent du type de l’opération.

208 operation <wsdl:operation name="operation_name">
<wsdl:input name="nom_optionel" message="nom_message" /> </wsdl:operation> <wsdl:output name="nom_optionel" message="nom_message" /> <wsdl:fault name="nom_optionel" message="nom_message" />*

209 binding WSDL permet de lier une description abstraite (portType) à un protocole. Chacune des opérations d’un portType pourra être liée de manière différente. Le protocole SOAP est un des protocole qui peut être utilisé. D’autres binding sont standardisés par WSDL : HTTP et MIME.

210 binding <wsdl:binding name="binding_name"
Un Binding : peut être identifié par un nom : name identifie le portType : type <wsdl:binding name="binding_name" type="nom du portType" > … </wsdl:binding>

211 binding SOAP Pour préciser que le binding est de type SOAP, il faut inclure la balise suivante : <soap:binding transport="uri" style="soap_style" /> Transport définit le type de transport pour utiliser SOAP/HTTP Style définit la façon dont sont créer les messages SOAP de toutes les opérations rpc : Encodage RPC défini par SOAP RPC document : Encodage sous forme d’élément XML

212 binding SOAP Pour chaque opération du portType :
il faut préciser l’URI de l’opération : soapAction Il est aussi possible de repréciser la façon dont sont créés les messages SOAP : style Pour chaque message de chaque opération, il faut définir comment sera créé le message SOAP

213 Exemple <wsdl:binding type="descriptionPersonnes" >
<soap:binding transport=" style="rpc" /> <wsdl:operation name="getPersonne"> <soap:operation soapAction=" /> <wsdl:input> <soap:body use="encoded" encodingStyle="schemas.xmlsoap.org/soap/encoding"/> </wsdl:input> <wsdl:output> </wsdl:output> </wsdl:operation> </wsdl:binding>

214 service Un service est un ensemble de ports Un port a un portType
Dans le cadre de SOAP, un port à une adresse (qui correspond à l’adresse http) <wsdl:service name=“MonService"> <wsdl:port binding="intf:MonServiceSoapBinding"> <soap:address location=" </wsdl:port> </wsdl:service>

215 A vous de jouer Comparer WSDL à IDL ?
Expliquer les dépendances entre SOAP et WSDL ? Quel est le point le plus délicat lors d’un passage à une implémentation ?

216 Universal Description Discovery and Integration Version 3.0
UDDI Universal Description Discovery and Integration Version 3.0

217 Introduction Web services are meaningful only if potential users may find information sufficient to permit their execution. The focus of Universal Description Discovery & Integration (UDDI) is the definition of a set of services supporting the description and discovery of (1) businesses, organizations, and other Web services providers, (2) the Web services they make available, and (3) the technical interfaces which may be used to access those services. Based on a common set of industry standards, including HTTP, XML, XML Schema, and SOAP, UDDI provides an interoperable, foundational infrastructure for a Web services-based software environment for both publicly available services and services only exposed internally within an organization.

218 Rôles Un référentiel UDDI joue 3 rôles :
Pages blanches : le référentiel comporte des informations sur les fournisseurs de services. Pages Jaunes : le référentiel comporte des critères de catégorisation de services. Pages vertes : le référentiel comporte des informations techniques (WSDL). Les services d’un référentiel UDDI sont des Web Services !

219 Exemple Le référentiel UDDI de microsoft est accessible à Il est possible de parcourir ce référentiel à l’aide d’un navigateur pour : Rechercher un service. Ajouter un service au référentiel.

220 Exemple : search Façons de rechercher un service.
Nous allons rechercher les Web Services de la société Amazon.

221 Exemple : search AmazonBusiness propose un Web Service
Ce Web Service s’appelle GetBookPrice

222 Référentiels Type Accès Public : Privé ou d’entreprise Défini en WSDL
Microsoft : uddi.microsoft.com IBM : HP : uddi.hp.com SAP : udditest.sap.com Privé ou d’entreprise Accès Défini en WSDL JAXR définit une API pour naviguer dans un référentiel UDDI

223 A vous de jouer Quel est la place d’UDDI dans les Web Services ?
Comparer les référentiels UDDI avec les moteurs de recherche style Yahoo et Google ? Quel est l’intérêt des référentiels UDDI d’entreprise ?

224 Axis Version 1.3

225 Introduction Implantation OpenSource de SOAP1.1 Communauté Apache
Java Communauté Apache Apache, Tomcat, Xerces, Struts, Cocoon Support Server Servlet qui reçoit et envoie des messages SOAP HTTP (pont SMTP) Support Client API pour envoyer des messages SOAP sur HTTP et SMTP

226 Servlet (Notion) Une Servlet est un objet Java qui fonctionne en mode requête/reponse Une Servlet http est une serlvet qui est capable de traiter des requête http et qui est capable de renvoyer des réponses http. Un moteur (container) de Servlet est une application qui reçoit des requêtes http et qui les transmet aux Servlet Tomcat (couplage avec Apache), Websphere (couplage avec IBM http Server), Weblogic …

227 Architecture (Serveur)
Axis fournit une Servlet (AxisServlet) qui reçoit des message SOAP sur http et qui transforme l’appel en un appel de méthode classique Java Développer un Web Service revient alors à développer un objet Java et à enregistrer ses méthodes auprès de la Servlet AxisServlet. Les clients envoient alors leurs messages SOAP sur http à AxisServlet. Pour SMTP les clients envoient leurs messages par mail à un démon. Le démon reçoit ces messages et les renvoie sur http à AxisServlet.

228 Architecture (Serveur)
La Servlet AxisServlet reçoit et renvoie les messages SOAP et transmet aux objets Java correspondant Les Objets Java effectuent les services. Ils sont des objets Java classiques. AxisServlet SOAP/HTTP Moteur de Servlet Le client envoie des messages SOAP/HTTP JVM Objets Java et Servlet sont dans la même JVM (pas de répartition).

229 Développement d’un Web Service
Développer une classe Java public class MyFirstWebService { public final String BOOK1 = "La méthode"; public final String BOOK2 = "Le Macroscope"; public int getPrice(String bookTitle) { if (bookTitle.compareTo(BOOK1)==0) { return 15; } else if (bookTitle.compareTo(BOOK2)==0) { return 20; else return 300;

230 Déploiement un Web Service
Elaborer un descripteur SOAP de votre classe <deployment xmlns="             xmlns:java="   <service name="MyFirstWebService" provider="java:RPC">   <parameter name="className«  value="MyFirstWebService"/>   <parameter name="allowedMethods" value="*"/>   </service> </deployment> Exporter le descripteur java org.apache.axis.client.AdminClient deploy.wsdd

231 Déploiement un Web Service
Le fichier jws sont les équivalents des jsp pour les Web Service. Construction d’un fichier jws à partir d’une classe java: Copy MyFirstWebService.java /…/MyFirstWebService.jws

232 Le Client à partir du WSDL
Génération d’un ensemble de classes facilitant l’envoi de message SOAP: java org.apache.axis.wsdl.WSDL2Java file.wsdl Classes générées: Pour les Type Pour les PortType Pour les Binding Pour les Port Pour les Service

233 Le Client à partir du WSDL
Construction du client : Instancier un Service Obtenir un Port à partir du Service Utiliser les méthodes du Port Construire les paramètres en fonction des Types

234 Obtention du WSDL de l’exemple
Sous axis, dans un navigateur, mettre l’adresse du Web Service suivie de ?WSDL

235 Les classes générées à partir de l’exemple
MyFirstWebService.java MyFirstWebServiceService.java MyFirstWebServiceLocator.java MyFirstWebServiceBindingStub.java

236 Un exemple de Client public class Client {
public static void main(String[] args) { try { MyFirstWebServiceService service = new MyFirstWebServiceServiceLocator(); MyFirstWebService port = service.getMyFirstWebService(); String st = ""; int price = port.getPrice(st); System.out.println("Le prix est : "+price); } catch (Exception ex) { ex.printStackTrace(); }

237 A vous de jouer Comparer cette approche avec CORBA ?
A quoi sert le WSDL ? Comment se fait le mapping avec un langage de programmation ?

238 Web Service : Un nouveau Buzz Word ?
Conclusion Web Service : Un nouveau Buzz Word ?

239 Conclusion Avantages : Inconvénients :
Des standards simples (SOAP, WSDL, UDDI) Multi Protocole / Multi OS / Multi Langage Paradigme de Service Des outils (éditeurs et moteurs) Inconvénients : Typage (pas de consensus) Performance Jeunesse (Sécurité, Transaction,…)

240 Références SOAP : http://www.w3.org/TR/SOAP/
WSDL : UDDI : Apache SOAP :