|
|
avr
22
2006
|
Performances des EJB, Transformation des invocations distantes en appels locaux |
|
|
|
Conception -
Patterns
|
|
Ecrit par Kamal AOUDA
|
|
22-04-2006 |
|
Performances des EJB, Transformation des invocations distantes en appels locaux
L’invocation des méthodes distantes d’un EJB (remote methods) est un
processus complexe qui fait appel à des opérations pénalisantes pour le temps de
réponse et le débit de l’application. Cette invocation se fait typiquement via
le protocole RMI-IIOP. Pour bien comprendre ses retombées sur la performance il
est important d’expliquer son mode de fonctionnement.
RMI (Remote Method Invocation) est une API qui permet à un client de manipuler
des objets distants c'est-à-dire des objets placés sur une JVM différente de
celle sur laquelle il se trouve. Parce que l’API cache au client toute la
complexité technique nécessaire pour invoquer les objets distants, leur
manipulation se fait comme s’ils se trouvaient sur la même JVM.
Initialement les connexions et les transferts de données dans RMI étaient
effectués via TCP/IP grâce à un protocole propriétaire (JRMP, Java Remote Method
Protocol). A partir de la version 1.3 de Java 2 ce protocole a été remplacé par
l’Internet Inter-Orb Protocol(IIOP) pour permettre aux EJB de communiquer avec
les applications CORBA.
Concrètement lorsqu’un client invoque la méthode distante d’un EJB il fait en
premier lieu appel à un objet proxy appelé stub. Ce dernier clone localement
toutes les méthodes de l’objet distant. Il est capable via des lookup JNDI de
trouver le chemin vers l’objet distant. Comme le montre la figure 40 la
transmission de données se fait par le truchement d’une architecture en couches
inspirée du modèle OSI.
• La couche de référence (RRL, Remote Reference Layer) fournit au stub les
informations et les services nécessaires pour localiser l’EJB distant.
• Le skeleton se charge de déléguer les invocations reçues du stub vers les EJB
distants.
• La gestion des connexions et le transport des données se fait via le protocole
TCP (Les packages java.net.Socket et java.net.SocketServer assurent
implicitement cette fonction).
Figure 40: Modèle en couches RMI-IIOP [183]
Fort heureusement les EJB disposent de méthodes locales en plus de leurs
méthodes distantes. Cette dualité permet de mettre en œuvre le pattern « session
façade » grâce auquel les invocations distantes sont transformées en appels
locaux. Ainsi au lieu d’invoquer directement les méthodes distantes de chaque
EJB le client s’adresse à un objet intermédiaire placé sous la même JVM. Ce
dernier se charge ensuite d’appeler les méthodes locales de l’EJB pour lui
déléguer la requête reçue du client. L’objet intermédiaire est mis en ouvre à
l’aide d’un stateless session bean. Il permet de réduire le nombre d’invocations
EJB/EJB et clients/EJB (cf. figure 41).
Figure 41: diagramme de classe du session façade [184]
Le session façade n’élimine pas les
invocations RMI-IIOP. Il permet seulement de réduire leur nombre. Cela nous
amène encore une fois à vanter les mérites des servlets en tant que composante
charnière de l’architecture MVC. En effet si le développeur arrive à les
substituer au session bean qui implémente la façade les invocations RMI-IIOP
seront complètement éliminées du workflow.
Notes de bas de page
[182] Source: introduction à RMI,
http://www.commentcamarche.net/rmi/rmiintro.php3
[183] Source : Core J2EE Patterns - Session Façade,
http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html
|
|
Dernière mise à jour : ( 03-08-2006 )
|
|
|
Accueil 
Conception 
