 |
|
15) Informatique distribuée |
|
|
|
|
| Texte original |
|
Traducteur : Jean-Pierre VIDAL, Alban PEIGNIER |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The first few lines do the same as they
do in the server process: the ORB is initialized and a reference to the naming
service server is resolved. Next, we need an object reference for the servant
object, so we pass the stringified object reference to the
resolve( ) method, and we cast the result into an ExactTime
interface reference using the narrow( ) method. Finally, we call
getTime( ).
|
|
Les premières lignes font la même chose que ce qu'elles font dans le
processus serveur : l'ORB est initialisé et la référence vers le service de nommage est résolue.
Ensuite, nous avons besoin d'une référence objet pour l'objet servant, dont nous passons la
référence alphanumérique à la méthode resolve( ), et transformons le résultat
en une interface ExactTime en utilisant la méthode
narrow( ). Enfin, nous appelons getTime( ).
|
|
|
|
Activating the name service process
|
|
Activation du processus du service de nommage
|
|
|
|
|
Finally we have a server and a client
application ready to interoperate. You’ve seen that both need the naming
service to bind and resolve stringified object references. You must start the
naming service process before running either the server or the client. In
JavaIDL, the naming service is a Java application that comes with the product
package, but it can be different with other products. The JavaIDL naming service
runs inside an instance of the JVM and listens by default to network port
900.
|
|
Nous avons enfin un serveur et un client prêts à interopérer. Nous avons pu
voir que tous deux ont besoin du service de nommage pour associer et résoudre les références
alphanumériques. Le processus du service de nommage doit être démarré avant de faire fonctionner
aussi bien le serveur que le client. Dans JavaIDL, le service de nommage est une application Java
fournie avec le produit, mais qui peut être différente dans d'autres produits. Le service de
nommage de JavaIDL fonctionne dans une JVM et écoute par défaut le port réseau 900.
|
|
|
|
Activating the server and the client
|
|
Activation du serveur et du client
|
|
|
|
|
Now you are ready to start your server
and client application (in this order, since our server is transient). If
everything is set up correctly, what you’ll get is a single output line on
the client console window, giving you the current time. Of course, this might be
not very exciting by itself, but you should take one thing into account: even if
they are on the same physical machine, the client and the server application are
running inside different virtual machines and they can communicate via an
underlying integration layer, the ORB and the Naming Service.
|
|
Vos applications serveur et client sont prêtes à démarrer (dans cet ordre,
puisque votre serveur est transient (temporaire)). Si tout est bien en place, vous obtiendrez une
simple ligne de sortie dans la fenêtre console de votre client, indiquant l'heure courante. Bien
sûr, cela ne semble pas très excitant en soit, mais vous devriez prendre en compte une chose : même
si ils sont physiquement sur la même machine, les applications client et serveur fonctionnent dans
des machines virtuelles différents et peuvent communiquer à travers une couche de l'intégration
sous-jacente, l'ORB et le service de nommage.
|
|
|
|
|
This is a simple example, designed to
work without a network, but an ORB is usually configured for location
transparency. When the server and the client are on different machines, the ORB
can resolve remote stringified references using a component known as the
Implementation Repository. Although the Implementation Repository is part
of CORBA, there is almost no specification, so it differs from vendor to
vendor.
|
|
Ceci constitue un exemple simple, destiné à fonctionner sans réseau, mais
un ORB est généralement configuré pour qu'il rende les localisations transparentes. Lorsque le
serveur et le client sont sur des machines différentes, l'ORB peut résoudre des références
alphanumériques en utilisant un composant désigné Implementation Repository. Bien que le
Implementation Repository fasse partie de CORBA, il n'y a quasiment pas de spécification, et donc
il est différent d'un fabricant à l'autre.
|
|
|
|
|
As you can see, there is much more to
CORBA than what has been covered here, but you should get the basic idea. If you
want more information about CORBA, the place to start is the OMG Web site, at
www.omg.org. There you’ll find documentation, white papers,
proceedings, and references to other CORBA sources and
products.
|
|
Ainsi que vous vous en doutez, CORBA représente davantage que ce qui est
montré ici, mais ainsi vous aurez compris l'idée de base. Si vous souhaitez plus d'informations à
propos de CORBA, le premier endroit à visiter est le site Web de l'OMG : http://www.omg.org. Vous y trouverez la documentation, les white papers
et les références vers les autres sources et produits pour CORBA.
|
|
|
|
Java Applets and CORBA
|
|
Les Applets Java et CORBA
|
|
|
|
|
Java applets can act as CORBA clients.
This way, an applet can access remote information and services exposed as CORBA
objects. But an applet can connect only with the server from which it was
downloaded, so all the CORBA objects the applet interacts with must be on that
server. This is the opposite of what CORBA tries to do: give you complete
location transparency.
|
|
Les applets Java peuvent se comporter comme des clients CORBA. Par ce
biais, une applet peut accéder à des informations et des services distants publiés sous la forme
d'objets CORBA. Mais une applet ne peut se connecter qu'au serveur depuis lequel elle a été
téléchargée, aussi tous les objets CORBA avec lesquels l'applet interagit doivent être situés sur
ce serveur. C'est l'opposé de ce que CORBA essaye de faire : vous offrir une totale transparence de
localisation.
|
|
|
|
|
This is an issue of network security. If
you’re on an intranet, one solution is to loosen the security restrictions
on the browser. Or, set up a firewall policy for connecting with external
servers.
|
|
C'est une question de sécurité réseau. Si vous êtes sur un intranet, la
solution est d'éliminer les restrictions de sécurité du navigateur. Ou, de mettre en place une
politique de firewall pour la connexion vers des serveurs externes.
|
|
|
|
|
Some Java ORB products offer proprietary
solutions to this problem. For example, some implement what is called HTTP
Tunneling, while others have their special firewall features.
|
|
Certains produits proposant des ORBs Java offrent des solutions
propriétaires à ce problème. Par exemple, certains implémentent ce qui s'appelle un HTTP Tunneling,
alors que d'autres ont des fonctionnalités firewall spécifiques.
|
|
|
|
|
This is too complex a topic to be covered
in an appendix, but it is definitely something you should be aware
of.
|
|
C'est un point trop complexe pour être exposé dans une annexe, mais c'est
quelque chose que vous devriez approfondir.
|
|
|
|
CORBA vs. RMI
|
|
CORBA face à RMI
|
|
|
|
|
You saw that one of the main CORBA
features is RPC support, which allows your local objects to call methods in
remote objects. Of course, there already is a native Java feature that does
exactly the same thing: RMI (see Chapter 15). While RMI makes RPC possible
between Java objects, CORBA makes RPC possible between objects implemented in
any language. It’s a big difference.
|
|
Vous avez vu que la principale fonctionnalité de CORBA est le support de
RPC, qui permet à vos objets locaux d'appeler des méthodes d'objets distants. Bien sûr, il y a déjà
une fonctionnalité native à Java qui réalise exactement la même chose : RMI (voir Chapitre 15). Là
où RMI rend possible RPC entre des objets Java, CORBA rend possible RPC entre des objets
implémentés dans n'importe quel langage.
|
|
|
|
|
However, RMI can
be used to call services on remote, non-Java code. All you need is some kind of
wrapper Java object around the non-Java code on the server side. The wrapper
object connects externally to Java clients via RMI, and internally connects to
the non-Java code using one of the techniques shown above, such as JNI or
J/Direct.
|
|
Toutefois, RMI peut être utilisé pour appeler des services auprès de code
distant non-Java. Tout ce dont vous avez besoin est d'une sorte d'objet Java adaptateur autour du
code non-Java sur la partie serveur. L'objet adapteur est connecté à l'extérieur aux objets clients
par RMI, et en interne il se connecte au code non-Java en utilisant l'une des techniques vues
précédemment, comme JNI ou J/Direct.
|
|
|
|
|
This approach requires you to write a
kind of integration layer, which is exactly what CORBA does for you, but then
you don’t need a third-party
ORB.
|
|
Cette approche nécessite que vous écriviez une sorte de couche
d'intégration, exactement ce que CORBA fait pour vous, mais vous n'avez pas besoin ici d'un ORB
venu de l'extérieur.
|
|
|
|
Enterprise JavaBeans
|
|
Enterprise Java Beans
|
|
|
|
|
Suppose[77]
you need to develop a multi-tiered application to view and update records in a
database through a Web interface. You can write a database application using
JDBC, a Web interface using JSP/servlets, and a distributed system using
CORBA/RMI. But what extra considerations must you make when developing a
distributed object system rather than just knowing API’s? Here are the
issues:
|
|
[70]A partir de maintenant, vous avez été
présenté à CORBA et à RMI. Mais pourriez-vous imaginer de tenter le développement d'une application
à grande échelle en utilisant CORBA et/ou RMI ? Votre patron vous a demandé de développer une
application multi-tiers pour consulter et mettre à jour des enregistrements dans une base de
données, le tout à travers une interface Web. Vous vous assoyez et pensez à ce que cela veut
vraiment dire. Sûr, vous pouvez écrire une application qui utilise JDBC, une interface Web qui
utilise JSP et des Servlets, et un système distribué qui utilise CORBA/RMI. Mais quelles autres
considérations devez-vous prendre en compte lorsque vous développez un système basé sur des objets
distribués plutôt qu'avec des APIs classiques ? Voici les problèmes :
|
|
|
|
|
Performance: The
distributed objects you create must perform well, as they could potentially
service many clients at a time. You’ll need to use optimization techniques
such as caching as well as pooling resources like database connections.
You’ll also have to manage the lifecycle of your distributed
objects.
|
|
Performance : Les nouveaux objets distribués que
vous avez créé devront être performants puisque ils devront potentiellement répondre à plusieurs
clients en même temps. Donc vous allez vouloir mettre en place des techniques d'optimisation comme
l'utilisation de cache, la mise en commun des ressources (comme les connexions à des bases de
données par JDBC). Vous devrez aussi gérer le cycle de vie de votre objet distribué.
|
|
|
|
|
Scalability: The
distributed objects must also be scalable. Scalability in a distributed
application means that the number of instances of your distributed objects can
be increased and moved onto additional machines without modifying any
code.
|
|
Adaptation à la charge : Les objets distribués
doivent aussi s'adapter à l'augmentation de la charge. La scalabilité dans une application
distribuée signifie que le nombre d'instances de votre objet distribué peut augmenter et passer sur
une autre machine sans la modification du moindre code. Prenez par exemple un système que vous
développez en interne comme une petite recherche de clients dans votre organisation depuis une base
de données. L'application fonctionne bien quand vous l'utilisez, mais votre patron l'a vue et a dit
: "Robert, c'est un excellent système, mettez ça sur notre site Web public maintenant !!!". Est-ce
que mon objet distribué est capable de supporter la charge d'une demande potentiellement
illimitée.
|
|
|
|
|
Security: A distributed
object must often manage the authorization of the clients that access it.
Ideally, you can add new users and roles to it without
recompilation.
|
|
Sécurité : Mon objet distribué contrôle-t-il
l'accès des clients ? Puis-je ajouter de nouveaux utilisateurs et des rôles sans tout recompiler
?
|
|
|
|
|
Distributed Transactions: A
distributed object should be able to reference distributed transactions
transparently. For example, if you are working with two separated databases, you
should be able to update them simultaneously within the same transaction and
roll them both back if a certain criteria is not met.
|
|
Transactions distribuées : Mon objet distribué
peut-il utiliser de manière transparente des transactions distribuées ? Puis-je mettre à jour ma
base de données Oracle et Sybase simultanément au sein de la même transaction et les annuler
ensemble si un certain critère n'est pas respecté ?
|
|
|
|
|
Reusability: The ideal
distributed object can be effortlessly moved onto another vendors’
application server. It would be nice if you could resell a distributed object
component without making special modifications, or buy someone else’s
component and use it without having to recompile or rewrite it.
|
|
Réutilisation : Ai-je créé mon objet distribué de
telle sorte que je puisse le passer d'une application serveur d'un fournisseur à une autre ?
Puis-je revendre mon objet distribué (composant) à quelqu'un d'autre ? Puis-je acheter un composant
de quelqu'un d'autre et l'utiliser sans avoir à recompiler et à tailler dans son code ?
|
|
|
|
|
Availability: If one of the
machines in the system goes down, clients should automatically fail-over to
backup copies of the objects running on other machines.
|
|
Disponibilité : Si l'une des machines de mon
système tombe en panne, mes clients sont-ils capables de basculer des copies de sauvegarde de mes
objets fonctionnant sur d'autres machines ?
|
|
|
|
|
|
|
Comme vous avez pu le voir ci-dessus, les considérations qu'un développeur
doit prendre en compte lorsqu'il développe un système distribué sont complexes, et nous n'avons
même pas parlé de la solution du problème qui nous essayons de résoudre à l'origine !
|
|
|
|
|
These considerations, in addition the
business problem that you set out to solve, can make for a daunting development
project. However, all the issues except for your business problem are
redundant—solutions must be reinvented for every distributed business
application.
|
|
Donc maintenant vous avez une liste de problèmes supplémentaires que vous
devez résoudre. Alors comme allez-vous vous y prendre ? Quelqu'un l'a certainement déjà fait ? Ne
pourrais-je pas utiliser des modèles de conception bien connus pour m'aider à résoudre ces
problèmes ? Soudain, une idée vous vient à l'esprit... « Je pourrais créer un framework qui
prend en charge toutes ces contraintes et écrire mes composants en m'appuyant sur ce framework
! »... C'est là que les Entreprise JavaBeans rentrent en jeu.
|
|
|
|
|
Sun, along with other leading distributed
object vendors, realized that sooner or later every development team would be
reinventing these particular solutions, so they created the Enterprise JavaBeans
specification (EJB). EJB describes a server-side component model that tackles
all of the considerations mentioned above using a standard approach that allows
developers to create business components called EJBs that are isolated from
low-level “plumbing” code and that focus solely on providing
business logic. Because EJB’s are defined in a standard way, they can
vendor
independent.
|
|
Sun, avec d'autres fournisseurs d'objets distribués a compris que tôt ou
tard toute équipe de développement serait en train de réinventer la roue. Ils ont donc créé la
spécification des Entreprise JavaBeans (EJB). Les EJB sont une spécification d'un modèle de
composant côté serveur qui prend en compte toutes les considérations mentionnées plus haut
utilisant une approche standard et définie qui permet aux développeurs de créer des composants (qui
sont appelés des Entreprise JavaBeans), qui sont isolés du code de la 'machinerie' bas-niveau et
focalisés seulement sur la mise en place de la logique métier. Et puisque les EJBs sont définis sur
un standard, ils peuvent être utilisés sans être dépendant d'un fournisseur.
|
|
|
|
JavaBeans vs. EJBs
|
|
JavaBeans contre EJBs
|
|
|
|
|
Because of the similarity in names, there
is much confusion about the relationship between the JavaBeans component model
and the Enterprise JavaBeans specification. While both the JavaBeans and
Enterprise JavaBeans specifications share the same objectives in promoting reuse
and portability of Java code between development and deployment tools with the
use of standard design patterns, the motives behind each specification are
geared to solve different problems.
|
|
La similitude entre les deux noms amène souvent une confusion entre le
modèle de composants JavaBeans et la spécification des Enterprise JavaBeans. Bien que les
spécifications des JavaBeans et des Enterprise JavaBeans partagent toutes deux les même objectifs
(comme la mise en avant de la réutilisation et la portabilité du code Java entre développements,
comme aussi des outils de déploiement qui utilise des modèles de conception standards), les
motivations derrière chaque spécification ont pour but de résoudre des problèmes
différents.
|
|
|
|
|
The standards defined in the JavaBeans
component model are designed for creating reusable components that are typically
used in IDE development tools and are commonly, although not exclusively, visual
components.
|
|
Les standards définis dans le modèle de composants JavaBeans sont conçus
pour créer des composants réutilisables qui sont typiquement utilisés dans des outils de
développement IDE et sont communément, mais pas exclusivement, des composants visuels.
|
|
|
|
|
The Enterprise JavaBeans specification
defines a component model for developing server side java code. Because EJBs can
potentially run on many different server-side platforms—including
mainframes that do not have visual displays—An EJB cannot make use of
graphical libraries such as AWT or
Swing.
|
|
La spécification des Enterprise JavaBeans définit un modèle de composants
pour développer du code Java côté serveur. Comme les EJBs peuvent potentiellement fonctionner sur
différentes plate-formes serveurs (incluant des systèmes qui n'ont pas d'affichage visuel), un EJB
ne peut pas utiliser de librairies graphiques tels que AWT ou Swing.
|
|
|
|
The EJB specification
|
|
Que définit la spécification des EJBs ?
|
|
|
|
|
The Enterprise JavaBeans specification
describes a server-side component model. It defines six roles that are used to
perform the tasks in development and deployment as well as defining the
components of the system. These roles are used in the development, deployment
and running of a distributed system. Vendors, administrators and developers play
the various roles, to allow the partitioning of technical and domain knowledge.
The vendor provides a technically sound framework and the developers create
domain-specific components; for example, an “accounting” component.
The same party can perform one or many roles. The roles defined in the EJB
specification are summarized in the following table:
|
|
La spécification des EJBs, actuellement la version 1.1 (public release 2)
définit un modèle de composant côté serveur. Elle définit six rôles qui sont utilisés pour réaliser
les tâches de développement et de déploiement ainsi que la définition des composants du
système.
|
|
|
|
|
|
|
Les rôles
|
|
|
|
|
|
|
La spécification des EJBs définit des rôles qui sont utilisés durant le
développement, le déploiement et le fonctionnement d'un système distribué. Les fabricants, les
administrateurs et les développeurs jouent des rôles variés. Ils permettent la séparation du
savoir-faire technique, de celui propre au domaine. Ceci permet au fabricant de proposer un
framework technique et aux développeurs de créer des composants spécifiques au domaine comme par
exemple un composant de compte bancaire. Un même intervenant peut jouer un ou plusieurs rôles. Les
rôles définis dans la spécification des EJBs sont résumés dans la table suivante :
|
|
|
|
|
Role
|
Responsibility
|
|
Enterprise Bean Provider
|
The developer responsible for creating
reusable EJB components. These components are packaged into a special jar file
(ejb-jar file).
|
|
Application Assembler
|
Creates and assembles applications from a
collection of ejb-jar files. This includes writing applications that utilize the
collection of EJBs (e.g., servlets, JSP, Swing etc. etc.).
|
|
Deployer
|
Takes the collection of ejb-jar files
from the Assembler and/or Bean Provider and deploys them into a run-time
environment: one or more EJB Containers.
|
|
EJB Container/Server Provider
|
Provides a run-time environment and tools
that are used to deploy, administer, and run EJB components.
|
|
System Administrator
|
Manages the different components and
services so that they are configured and they interact correctly, as well as
ensuring that the system is up and running.
|
|
|
|
Rôle
|
Responsabilité
|
|
Fournisseur d'Enterprise Bean
|
Le développeur qui est responsable de la création des composants EJB
réutilisables. Ces composants sont regroupés dans un fichier jar spécial (fichier
ejb-jar).
|
|
Assembleur d'Application
|
Crée et assemble des applications à partir d'une collection de fichiers
ejb-jar. Ceci inclut la réalisation d'applications mettant en oeuvre la collection d'EJB (comme des
Servlets, JSP, Swing, etc.).
|
|
Déployeur
|
Le rôle du déployeur est de prendre la collection de fichiers ejb-jar de
l'Assembleur et/ou du Fournisseur d'EJB et de déployer ceux-ci dans un environnement d'exécution
(un ou plusieurs Conteneurs d'EJBs).
|
|
Fournisseur de Conteneurs/Serveurs d'EJB
|
Fournit un environnement d'exécution et les outils qui sont utilisés pour
déployer, administrer et faire fonctionner les composants EJB.
|
|
Administrateur Système
|
Par dessus tout, le rôle le plus important de l'ensemble du système :
mettre en place et faire fonctionner. La gestion d'une application distribuée consiste à ce que les
composants et les services soient tous configurés et interagissent ensemble
correctement.
|
|
|
|
|
EJB components
|
|
Composants EJB
|
|
|
|
|
EJB components are elements of reusable
business logic that adhere to strict standards and design patterns as defined in
the EJB specification. This allows the components to be portable. It also allows
other services—such as security, caching and distributed
transactions—to be performed on behalf of the components. An Enterprise
Bean Provider is responsible for developing EJB components.
|
|
Les composants EJB sont de la logique métier réutilisable. Les composants
EJB suivent strictement les standards et les modèles de conception définis dans la spécification
des EJBs. Cela permet à ces composants d'être portables et aussi à tous les autres services tels
que la sécurité, la mise en cache et les transactions distribuées, d'être mis en oeuvre sur ces
composants eux-mêmes. Un fournisseur d'Entreprise Bean est responsable du développement des
composants EJB. Les entrailles d'un composant EJB sont traités dans Qu'est-ce qui compose un
composant EJB ?
|
|
|
|
EJB Container & Server
|
|
Conteneur d'EJB
|
|
|
|
|
The EJB Container is a run-time
environment that contains and runs EJB components and provides a set of standard
services to those components. The EJB Container’s responsibilities are
tightly defined by the specification to allow for vendor neutrality. The EJB
container provides the low-level “plumbing” of EJB, including
distributed transactions, security, lifecycle management of beans, caching,
threading and session management. The EJB Container Provider is responsible for
providing an EJB Container.
|
|
Le conteneur d'EJB est un environnement d'exécution qui contient et fait
fonctionner les composants EJB tout en leur fournissant un ensemble de services. Les
responsabilités des conteneurs d'EJB sont définies précisément par la spécification pour permettre
une neutralité vis-à-vis du fournisseur. Les conteneurs d'EJB fournissent la machinerie bas-niveau
des EJBs, incluant les transactions distribuées, la sécurité, la gestion du cycle de vie des beans,
la mise en cache, la gestion de la concurrence et des sessions. Le fournisseur de conteneur d'EJB
est responsable de la mise à disposition d'un conteneur d'EJB.
|
|
|
|
|
|
|
Serveur EJB
|
|
|
|
|
An EJB Server is defined as an
Application Server that contains and runs one or more EJB Containers. The EJB
Server Provider is responsible for providing an EJB Server. You can generally
assume that the EJB Container and EJB Server are the same.
|
|
Un serveur d'EJB est défini comme un Serveur d'Applications et comporte un
ou plusieurs conteneurs d'EJBs. Le fournisseur de serveur EJB est responsable de la mise à
disposition d'un serveur EJB. Vous pouvez généralement considérer que le conteneur d'EJB et le
serveur EJB sont une seule et même chose.
|
|
|
|
Java Naming and Directory Interface (JNDI)
|
|
Java Naming and Directory Interface (JNDI)
|
|
|
|
|
Java Naming and Directory Interface
(JNDI) is used in Enterprise JavaBeans as the naming service for EJB Components
on the network and other container services such as transactions. JNDI maps very
closely to other naming and directory standards such as CORBA CosNaming and can
actually be implemeted as a wrapper on top of it.
|
|
Java Naming and Directory Interface (JNDI) est utilisé dans les Entreprise
JavaBeans comme le service de nommage pour les composants EJB sur le réseau et pour les autres
services du conteneur comme les transactions. JNDI ressemble fort aux autres standards de nommage
et de répertoires tels que CORBA CosNaming et peut être implémenté comme un adaptateur de
celui-ci.
|
|
|
|
Java Transaction API/Java Transaction Service (JTA/JTS)
|
|
Java Transaction API / Java Transaction Service (JTA/JTS)
|
|
|
|
|
JTA/JTS is used in Enterprise JavaBeans
as the transactional API. An Enterprise Bean Provider can use the JTS to create
transaction code, although the EJB Container commonly implements transactions in
EJB on the EJB components’ behalf. The deployer can define the
transactional attributes of an EJB component at deployment time. The EJB
Container is responsible for handling the transaction whether it is local or
distributed. The JTS specification is the Java mapping to the CORBA OTS (Object
Transaction Service)
|
|
JTA/JTS est utilisé dans les Enterprise JavaBeans comme API
transactionnelle. Un fournisseur d'Entreprise Bean peut utiliser le JTS pour créer un code
transactionnel bien que le conteneur d'EJB implémente généralement les transactions dans les EJBs
sur les composants EJBs eux-mêmes. Le déployeur peut définir les attributs transactionnels d'un
composant EJB au moment du déploiement. Le conteneur d'EJB est responsable de la prise en charge de
la transaction qu'elle soit locale ou distribuée. La spécification du JTS est la version Java de
CORBA OTS (Object Transaction Service).
|
|
|
|
CORBA and RMI/IIOP
|
|
CORBA et RMI/IIOP
|
|
|
|
|
The EJB specification defines
interoperability with CORBA through compatibility with CORBA protocols. This is
achieved by mapping EJB services such as JTS and JNDI to corresponding CORBA
services and the implementation of RMI on top of the CORBA protocol IIOP.
|
|
La spécification des EJBs définit l'interopérabilité avec CORBA. La spécification 1.1 précise que L'architecture
des Entreprise JavaBeans sera compatible avec les protocoles CORBA. L'interopérabilité avec CORBA passe par l'adaptation des services EJB comme JTS et
JNDI aux services CORBA et l'implémentation de RMI à travers le protocole CORBA IIOP.
|
|
|
|
|
Use of CORBA and RMI/IIOP in Enterprise
JavaBeans is implemented in the EJB Container and is the responsibility of the
EJB Container provider. Use of CORBA and RMI/IIOP in the EJB Container is hidden
from the EJB Component itself. This means that the Enterprise Bean Provider can
write their EJB Component and deploy it into any EJB Container without any
regard of which communication protocol is being
used.
|
|
L'utilisation de CORBA et de RMI/IIOP dans les Entreprise JavaBeans est
implémentée dans le conteneur EJB et est sous la responsabilité du fournisseur du conteneur d'EJB.
L'utilisation de CORBA et de RMI/IIOP dans le conteneur EJB est invisible pour le composant EJB
lui-même. Cela signifie que le fournisseur d'Entreprise Bean peut écrire ses composants EJBs et les
déployer dans un conteneur EJB sans s'inquiéter du protocole de communication qui est
utilisé.
|
|
|
|
The pieces of an EJB component
|
|
Qu'est-ce qui compose un composant EJB ?
|
|
|
|
|
An EJB consists of a number of pieces,
including the Bean itself, the implementation of some interfaces, and an
information file. Everything is packaged together into a special jar
file.
|
|
Un EJB se décompose en un ensemble de pièce, dont le
Bean lui-même, l'implémentation d'interfaces et un fichier d'informations. Le tout est rassemblé
dans un fichier jar spécial.
|
|
|
|
Enterprise Bean
|
|
Enterprise Bean
|
|
|
|
|
The Enterprise Bean is a Java class that
the Enterprise Bean Provider develops. It implements an Enterprise Bean
interface and provides the implementation of the business methods that the
component is to perform. The class does not implement any authorization,
authentication, multithreading, or transactional
code.
|
|
L'Enterprise Bean est une classe Java que le fournisseur d'Enterprise Bean
développe. Elle implémente une interface EnterpriseBean (pour plus de détails, voir la section qui
suit) et fournit l'implémentation des méthodes métier que le composant supporte. La classe
n'implémente aucun mécanisme d'autorisation ou d'authentification, de concurrence ou
transactionnel.
|
|
|
|
Home interface
|
|
Interface Home
|
|
|
|
|
Every Enterprise Bean that is created
must have an associated Home interface. The Home interface is used as a factory
for your EJB. Clients use the Home interface to find an instance of your EJB or
create a new instance of your EJB.
|
|
Chaque Enterprise Bean créé doit être associé à une interface Home.
L'interface Home est utilisée comme une Factory de votre EJB. Les clients utilisent l'interface
Home pour trouver une instance de votre EJB ou pour créer une nouvelle instance de votre
EJB.
|
|
|
|
Remote interface
|
|
Interface Remote
|
|
|
|
|
The Remote interface is a Java Interface
that reflects the methods of your Enterprise Bean that you wish to expose to the
outside world. The Remote interface plays a similar role to a CORBA IDL
interface.
|
|
L'interface Remote est l'interface Java qui reflète les méthodes de
l'Enterprise Bean que l'on souhaite rendre disponible au monde extérieur. L'interface Remote joue
un rôle similaire à celui de l'interface IDL de CORBA.
|
|
|
|
Deployment descriptor
|
|
Descripteur de Déploiement
|
|
|
|
The deployment descriptor is an XML file
that contains information about your EJB. Using XML allows the deployer to
easily change attributes about your EJB. The configurable attributes defined in
the deployment descriptor include:
- The Home and Remote
interface names that are required by your
EJB
- The name to
publish into JNDI for your EJBs Home
interface
- Transactional
attributes for each method of your
EJB
- Access Control
Lists for
authentication
|
|
Le descripteur de Déploiement est un fichier XML qui contient les
informations relatives à l'EJB. L'utilisation d'XML permet au Déployeur de facilement changer les
attributs propres à l'EJB. Les attributs configurables définis dans le descripteur de déploiement
incluent :
- Les noms des interfaces Home et Remote que nécessite l'EJB ;
- Le nom avec lequel sera publiée dans JNDI l'interface Home de l'EJB
;
- Les attributs transactionnels pour chaque méthode de l'EJB ;
- Les listes de contrôle d'accès (Access Control Lists) pour
l'authentification.
|
|
|
|
EJB-Jar file
|
|
Fichier EJB-Jar
|
|
|
|
|
The EJB-Jar file is a normal java jar
file that contains your EJB, Home and Remote interfaces, as well as the
deployment
descriptor.
|
|
Le fichier EJB-Jar est un fichier jar Java normal qui contient un EJB, les
interface Home et Remote ainsi que le descripteur de déploiement.
|
|
|
|
EJB operation
|
|
Comment travaille un EJB ?
|
|
|
|
|
Once you have an EJB-Jar file containing
the Bean, the Home and Remote interfaces, and the deployment descriptor, you can
fit all of the pieces together and in the process understand why the Home and
Remote interfaces are needed and how the EJB Container uses
them.
|
|
Maintenant que l'on a un fichier EJB-Jar contenant un Bean, les interfaces
Home et Remote, et un descripteur de déploiement, voyons un peu comment toutes ces pièces vont
ensemble, pourquoi les interfaces Home et Remote sont nécessaires et comment le conteneur d'EJB les
utilise.
|
|
|
|
|
The EJB Container implements the Home and
Remote interfaces that are in the EJB-Jar file. As mentioned earlier, the Home
interface provides methods to create and find your EJB. This means that the EJB
Container is responsible for the lifecycle management of your EJB. This level of
indirection allows for optimizations to occur. For example, 5 clients might
simultaneously request the creation of an EJB through a Home Interface, and the
EJB Container would respond by creating only one EJB and sharing it between all
5 clients. This is achieved through the Remote Interface, which is also
implemented by the EJB Container. The implemented Remote object plays the role
of a proxy object to the EJB.
|
|
Le conteneur d'EJB implémente les interfaces Home et Remote qui sont dans
le fichier EJB-Jar. Comme mentionné précédemment, l'interface Home met à disposition les méthodes
pour créer et trouver votre EJB. Cela signifie que le conteneur d'EJB est responsable de la gestion
du cycle de vie de votre EJB. Ce niveau d'abstraction permet aux optimisations d'intervenir. Par
exemple, cinq clients peuvent demander simultanément la création d'un EJB à travers l'interface
Home, le conteneur d'EJB pourrait n'en créer qu'un seule et partager cet EJB entre les cinq
clients. Ceci est réalisé à travers l'interface Remote, qui est aussi implémentée par le conteneur
d'EJB. L'objet implémentant Remote joue le rôle d'objet proxy vers l'EJB.
|
|
|
|
|
All calls to the EJB are
‘proxied’ through the EJB Container via the Home and Remote
interfaces. This indirection is the reason why the EJB container can control
security and transactional
behavior.
|
|
Tous les appels de l'EJB sont redirigés à travers le conteneur d'EJB grâce
aux interfaces Home et Remote. Cette abstraction explique aussi pourquoi le conteneur d'EJB peut
contrôler la sécurité et le comportement transactionnel.
|
|
|
|
Types of EJBs
|
|
Types d'EJBs
|
|
|
|
|
The Enterprise JavaBeans specification
defines different types of EJBs that have different characteristics and
behaviors. Two categories of EJBs have been defined in the specification:
Session Beans and Entity Beans, and each categoriy has
variations.
|
|
Il doit y avoir une question dans votre tête depuis le dernier paragraphe :
partager le même EJB entre les clients peut certainement augmenter les performances, mais qu'en
est-il lorsque je souhaite conserver l'état sur le serveur ?
|
|
|
|
|
|
|
La spécification des Enterprise JavaBeans définissent différents types
d'EJBs qui peuvent avoir différentes caractéristiques et adopter un comportement différent. Deux
catégories d'EJBs ont été définies dans cette spécification : les Session Beans et les Entity
Beans, et chacune de ces catégories a des variantes.
|
|
|
|
Session Beans
|
|
Session Beans
|
|
|
|
|
Session Beans are used to represent
Use-Cases or Workflow on behalf of a client. They represent operations on
persistent data, but not the persistent data itself. There are two types of
Session Beans, Stateless and Stateful. All Session Beans must
implement the javax.ejb.SessionBean interface. The EJB Container governs
the life of a Session Bean. |
|
Les Session Beans sont utilisés pour représenter les cas d'utilisations ou
des traitements spécifiques du client. Ils représentent les opérations sur les données
persistantes, mais non les données persistantes elles-mêmes. Il y a deux types de Session Beans :
non-persistant (Stateless) and persistant (Stateful). Tous les Session Beans doivent implémenter
l'interface javax.ejb.SessionBean. Le conteneur d'EJB contrôle la vie d'un Session Bean.
|
|
|
|
|
|
|
Les Session Beans non-persistants
|
|
|
|
|
Stateless Session Beans are the
simplest type of EJB component to implement. They do not maintain any
conversational state with clients between method invocations so they are easily
reusable on the server side and because they can be cached, they scale well on
demand. When using Stateless Session Beans, all state must be stored outside of
the EJB. |
|
Les Session Beans non-persistants sont le type d'EJB le plus simple à
implémenter. Ils ne conservent aucun état de leur conversation avec les clients entre les
invocations de méthodes donc ils sont facilement réutilisables dans la partie serveur et puisqu'ils
peuvent être mis en cache, ils supportent bien les variations de la demande. Lors de l'utilisation
de Session Beans non-persistants, tous les états doivent être stockés à l'extérieur de
l'EJB.
|
|
|
|
|
|
|
Les Session Beans persistants
|
|
|
|
|
Stateful Session Beans maintain
state between invocations. They have a one-to-one logical mapping to a client
and can maintain state within themselves. The EJB Container is responsible for
pooling and caching of Stateful Session Beans, which is achieved through
Passivation and Activation. If the EJB Container crashes, data for
all Stateful Session Beans could be lost. Some high-end EJB Containers provide
recovery for Stateful Session
Beans.
|
|
Les Session Beans persistants conservent un état entre l'invocation de
leurs méthodes (comme vous l'aviez probablement compris). Ils ont une association 1-1 avec un
client et sont capables de conserver leurs états eux-mêmes. Le conteneur d'EJBs a en charge le
partage et la mise en cache des Session Beans persistants, ceux-ci passe par la Passivation et
l'Activation.
|
|
|
|
Entity Beans
|
|
Entity Beans
|
|
|
|
|
Entity Beans are components that
represent persistent data and behavior of this data. Entity Beans can be shared
among multiple clients, the same way that data in a database can be shared. The
EJB Container is responsible for caching Entity Beans and for maintaining the
integrity of the Entity Beans. The life of an Entity Bean outlives the EJB
Container, so if an EJB Container crashes, the Entity Bean is still expected to
be available when the EJB Container again becomes available.
|
|
Les Entity Beans sont des composants qui représentent une donnée
persistante et le comportement de cette donnée. Les Entity Beans peuvent être partagés par
plusieurs clients, comme une donnée d'une base. Le conteneur d'EJBs a en charge de mettre en cache
les Entity Beans et de maintenir leur intégrité. La vie d'un Entity Bean est supérieur à celle du
conteneur d'EJBs, donc si un conteneur tombe en panne, l'Entity Bean est censé être encore
disponible lors que le conteneur le devient à nouveau.
|
|
|
|
|
There are two types of Entity Beans:
those with Container Managed persistence and those with Bean-Managed
persistence.
|
|
Il y a deux types d'Entity Beans, ceux dont la persistence est assurée par
le Bean lui-même et ceux dont la persistance est assurée par le conteneur.
|
|
|
|
|
|
|
|
|
|
|
|
|
