2
Conception d'une application
Model-Driven Beans (MDB) n Identifier les éléments fonctionnels de l'application
pour les regrouper au sein d’unités
n Estimer les interactions entre unités
n Définir le schéma d’organisation de l’application
Ex : en POO, les
unités sont des
Marie-Pierre Gervais objets
M2 Miage
EC FSR Application
3 4
Rappel poly 1
Schémas d’organisation d’une AR
Schéma d’organisation client-serveur
n AR : Plusieurs unités réparties qui interagissent n Le client : entité qui demande l’exécution d’un service
n Schémas d’organisation : manière d’organiser les n Le serveur : entité qui réalise le service
interactions n Indépendance interface-réalisation
Organisation client-serveur -> polys 1 à 4
n Interaction synchrone (dans le schéma de base) : le
n
client est bloqué en attente de la réponse
n Organisation à files d’attente Organisation
« par message » n Client et serveur sont sur deux machines distinctes
n Organisation à événements
n Pas nécessairement
n Organisation à mémoire partagée Interface = spéc. du service
n Organisation pair à pair prog.
requête serveur
n Organisation à code mobile prog. rés (code, contexte
client eau
réponse d’exécution,
ressources)
5 6
Caractéristiques des organisations message (producteur-
« par message »
schéma d'organisation de l'appli RPC (client-serveur)
consommmateur)
techno JMS (MDB) EJB
réseau local
n Émetteur et récepteur de msg n’ont pas besoin langages hétérogènes des parties non
d’être disponibles au même moment nb de destinataires d'une émission un ou plusieurs
n Emetteur et récepteur n’ont pas besoin de se obligation de dispo simultanée des deux
connaître (le client n’a pas la réf d’itf du serveur) parties
synchrone / asynchonre
non => asynchrone oui => synchrone
n Emetteur et récepteur doivent connaître le format émetteur connaît récepteur non oui (ITF !)i
du message et la destination à utiliser (la BAL) interaction = demande d'exécution d'un
service
non oui
serveur avec / sans état (mémorisation ou
Les deux. Fourni en natif par la
non de l'état du client entre deux
techno (stateless, stateful)
=> faible couplage entre les entités interagissantes (en requêtes successives => session)
Les deux. Si avec, forcément
opposition avec le client-serveur) serveur avec / sans données rémanentes
(mémorisation ou non de l'état du serveur)
stateful. Isolation (pas de partage
entre clients ≠, ou alors utilisation
Ex : un compteur, un distributeur de
d'un session singleton et/ ou de
jetons, etc
données persistentes (BD)
7 8
Schéma d’organisation par files d’attente
Schéma d’organisation par files d’attente
Point-to-point messaging
n Point-to-Point messaging
n Communication entre les processus par files
d’attente
n Interactions asynchrones entre processus
n Pas notion de demande d’exécution de service
n Mise en file des messages de processus producteurs pour
des processus consommateurs
n Possibilité de files à priorité
n Possibilité de retrait de la file sur temporisateur Producteur Consommateur
n Bus à messages : MOM (Message-Oriented Middleware)
n Ex : IBM MQSeries, JMS (Java Message Service)
n Chaque msg a exactement un consommateur
n Pas de dépendance temporelle entre producteur et
consommateur du msg
9 10
Schéma d’organisation à événements
Schéma d’organisation à événements
Publish/subscribe messaging
n Publish/subscribe messaging
n Un processus publie (produit) un type d’événements
n Un processus s’abonne à (consomme) un type d’événements
n Gestionnaire d’événements
n Connaît les consommateurs Consommateur
n Quand un producteur publie, c’est lui qui transmet aux consommateurs
n Fournisseurs et abonnés ne se connaissent pas
n Interactions asynchrones par échanges de messages
n Schéma qui repose souvent sur un MOM
Producteur
n Exemples : JMS (Java Message Service), Event Service de
Corba Consommateur
Un msg peut avoir +sieurs consommateurs
Dépendance temporelle entre abonnés et
producteur du msg (l’abonné ne lit que les msg produit APRÈS son
abonnement, pas les antérieurs)
11 12
JMS API Quand utiliser JMS ?
n Messaging standard that allows Java application to n Si l’application à développer a des entités
create, send, receive, and read messages n Qui sont faiblement couplées
n It enables distributed communication that is loosely n Une entité ne dépend pas d’informations détenues dans une
interface d’une autre entité (par ex, pour faciliter leur
coupled, reliable, and asynchronous remplacement)
n Reliable : JMS garantit que le msg est délivré une fois et n Qui peuvent être en exécution indépendamment les unes
une seule des autres sans que cela empêche leurs interactions
n MAIS JMS ne garantit pas l’ordre d’arrivée des msg n Enclient-serveur, les deux entités doivent être actives (running)
simultanément pour interagir
n Qui ont une logique métier ne nécessitant pas une réponse
immédiate (et un blocage en attente de cette réponse) lors
de l’envoi d’une info
13 14
Architecture d’une application JMS Message-Driven Beans : Définition
n Les éléments formant une application JMS sont nA message-driven bean combines features of a
Le système JMS : implantation de la spécification JMS session bean and a message listener, allowing a
n
business component to receive messages
n Les « clients » JMS : programmes Java/composants asynchronously.
Java EE qui utilisent le système JMS pour produire et Ces msg sont des messages JMS
n
consommer des messages JMS
Les messages JMS : objets représentant les informations n UnMessage-Driven Bean permet de faire des
n
échangées entre clients (utilisateurs) JMS producteurs et applications Java EE au schéma d’organisation :
clients (utilisateurs) JMS consommateurs n À file d’attente = Point-to-Point : mode QUEUE
n Objets administrés : objets JMS pré-configurés créés par n À événement = Publish/subscribe : mode TOPIC
un administrateur pour l’usage des clients JMS n Dans ces deux cas, le bean est le consommateur de
producteurs/consommateurs msg
15 16
Overview Caractéristiques des MDB
nA message-driven bean is an asynchronous message n They execute upon receipt of a single client message
consumer n They are invoked asynchronously
n A message-driven bean is invoked by the container as n They are relatively short-lived
a result of the arrival of a JMS message
n They do not represent directly shared data in the
Le bean est notifié par le conteneur
n
database, but they can access and update this data
nA message-driven bean has no business interface
n They can be transaction-aware
n Pas du client-serveur => Les clients n’invoquent pas de
méthodes d’un message-driven n Ils sont sans état (comme des beans stateless)
nAmessage-driven bean instance is an instance of a
message-driven bean class MAIS CE NE SONT PAS DES
BEANS SESSION !
! PAS du CLIENT-SERVEUR
17 20
Cycle de Vie Développement d’un MDB
Le cycle de vie d’un Message-Driven Bean est entièrement géré par le n Une seule classe à développer : celle du bean
conteneur n Doit implanter l’interface
jakarta.jms.MessageListener
n Doit être annoté @MessageDriven
n This
annotation contains a mappedName element that specifies the
JNDI name of the destination from which the bean will consume
messages
n Doit être public, non final et non abstract
n Ne doit pas définir de méthode finalize()
n Doit définir la méthode onMessage(Message)
n Peut injecter une ressource MessageDrivenContext
21 22
La méthode onMessage(Message m) Exemple
n This method contains the business logic that handles
the processing of the message
n It is the message-driven bean’s responsibility to parse the
message and perform the necessary business logic
n1 seul argument en entrée : le message entrant, de BAL
type jakarta.jms.Message (Destination)
n Le type retour doit être void
n Cette méthode est invoquée par le conteneur pour
notifier le bean de la disponibilité d’un msg
23 24
Exemple Complément : MessageDrivenContext
import jakarta.ejb.*; No n Ressource qui fournit des méthodes additionnelles
import jakarta.jms.*; D m
en
reg esti de la
ist nat
pour la gestion de transactions (interface
ré i
da on
ns
MessageDrivenContext)
@MessageDriven(mappedName = "uneBAL")
n À utiliser quand le bean utilise des transactions (donc
JN
DI
public class SimpleMessageBean implements des entités)
MessageListener {
n Exemple
n Permet d’invoquer la méthode setRollbackOnly pour
gérer des exceptions
public void onMessage(Message inMessage) {
// implantation de la méthode
}
}
25 26
Exemple Étapes de déploiement d’un MDB
import ..
import jakarta.annotation.Resource; No n Compilation du .java => .class
en De m de Idem que pour un
r
@MessageDriven(mappedName = "uneBAL") gis stina la
e
tré tio n Packaging du .class => .jar session bean
d n
public class SimpleMessageBean implements ans JN n AVANT DE DÉPLOYER !!! : IL FAUT CRÉER DES
MessageListener { DI
OBJETS ADMINISTRÉS JMS s’ils n’existent pas
@Resource private MessageDrivenContext mdc; déjà
n Objets JMS pré-configurés créés par un administrateur
public void onMessage(Message inMessage) { pour l’usage des clients JMS
try { n Connection Factory
// implantation du traitement n Destination Resource (la BAL)
}
catch (JMSException e) { n Ensuite, on peut déployer comme d’habitude le .jar
e.printStackTrace();
mdc.setRollbackOnly();
}
}
}
27 28
Notion d’objets administrés Création des objets administrés
n Connection Factory n Définition
de scripts utilisant la commande asadmin
n Objet utilisé par tout client JMS pour créer une connexion pour créer la connectionFactory et la destination
à un système JMS
n Client JMS : un producteur de msg, un consommateur de msg
n asadmin create-jms-resource --restype
jakarta.jms.QueueConnectionFactory
n Ici, client JMS = le MBD, consommateur de msg uneConnectionFactory
n Destination resource n asadmin create-jms-resource --restype
n Objet utilisé pour tout client JMS pour déposer/retirer jakarta.jms.Queue --property Name=TheQueue
les msg qu’il produit/consomme uneBAL
n De type « QUEUE » si point-to-point messaging
n De type « TOPIC » si publish/subscribe messaging n On peut aussi utiliser l’interface Web d’administration du
=> C’est la BAL serveur Java EE…
29 30
Déployer un code consommateur :
Côté producteur
MDBdemo
nÀ récupérer sur CEL n Parconvention et habitude, on appelle le producteur
de msg (qui seront consommés par un MDB) un
« client » :-)
n Créer les objets administrés : dans cet exemple :
n Mais on n’est pas en client-serveur !
n La connectionFactory doit OBLIGATOIREMENT s’appeler
uneConnectionFactory et être de type Queue n Vu du producteur, un message-driven bean n’est que
n La BAL doit OBLIGATOIREMENT s’appeler uneBAL, être le destinataire d’une file de messages
de type Queue et avoir une destination physique nommée n Le producteur n’a aucune visibilité sur le bean
TheQueue
n Puisqu’on n’est pas en client-serveur…
n … Et que le bean n’a pas d’interface
n Respecterces spéc car elles sont utilisées dans le n Le bean est entièrement masqué
code du producteur (cf ci-après)
n Construire (ant jar) et déployer
31 32
Vue du producteur Le modèle de programmation JMS
Objets Côté consommateur
Administrés (MDB), l’instanciation des
(OA) OA n’est pas du ressort
Producteur Destination du développeur
Instances
MDB
Bean
Container
33 34
Côté producteur Complément sur les objets administrés
n Récupération par JNDI de : n Connection
n La connection Factory n Encapsule une connexion virtuelle avec un système JMS
n La destination n Peut se voir comme une socket entre le « client » et le système
JMS
n Pas de conteneur pour instancier : n Session
n La connexion n Objet contextuel pour produire (resp. consommer) les msg
n La session
n Message producer
n Le producteur de msg
=> obligé de le faire par programme n Objet créé par une session et utilisé pour envoyer les msg
à une Destination
n On écrit dans un programme producteur de msg des
instructions relatives à ces instanciations
35
Exemple de Producteur
import jakarta.jms.*;
import javax.naming.InitialContext;
public class Producteur {
public static void main(String[] args) {
// initialisation des variables
…
try {
InitialContext ctx = new InitialContext();
cf = (ConnectionFactory)
ctx.lookup("uneConnectionFactory");
queue = (Queue) ctx.lookup("uneBAL");
}catch (Exception ex) {};
cx = cf.createConnection();
session = cx.createSession(false,
Session.AUTO_ACKNOWLEDGE);
messageProducer =
session.createProducer(queue);
message = session.createTextMessage();
message.setText("This is my message");
messageProducer.send(message);
…
}}
