Enterprise Beans

Cedric Dumoulin
(C) The Java EE 7 Tutorial
http://docs.oracle.com/javaee/7/tutorial/doc/
Webographie
 The Java EE 7 Tutorial
 http://docs.oracle.com/javaee/7/tutorial/doc/
 Les slides de cette présentation sont des extraits de ce
tutorial
Qu’est-ce qu’un Enterprise Bean
(EJB)?
 C’est un composant coté serveur
 Il encapsule la logique métier d’une application
 Il est écrit en Java (c’est une classe POJO)
 Aussi appelé EJB (Enterprise Java Bean)
Avantages des EJB
 Simplifie le développement de grande application
distribuées.
 Le framework fournit les services de niveau systèmes
(sécurité, persistence, transaction, …)
 L’EJB contient la logique métier
 Le développeur se concentre sur la logique métier
 Prône la séparation de la logique métier et de la présentation
du client
 Les composants EJB sont portables
 Construction d’application par assemblage de composants
 Réutilisation
Dans quelle applications utiliser
des EJBs ?
 Si votre application a au moins un de ces besoins:
 Mise à l’echelle


l’application doit supporter un grand nombre de clients
L’application peut être distribuée sur plusieur machine
 L’intégrité des données doit être assuré par des
transactions

Les EJB supportent les transactions (de façon relativement
transparente)
 Plusieurs types de clients

La logique métier reste la même
Les différents types d’EJBs
 Il existe 2 types
 Les EJB session
 Les Messages Driven Bean (MDB)
Qu’est-ce qu’un EJB Session ?
 Un Bean Session encapsule la logique métier
 C’est une classe Java POJO
 Il peut être appelé programmatiquement par un client
(ie par un autre code)
 Localement au container
 A distance (remote)
 Le client invoque les méthodes de l’EJB
 L’EJB effectue la tâche demandé par le client
 Il effectue la logique métier dans le serveur
 Un EJB session n’est pas persistant.
3 types de Bean Session
 Stateful Session Bean
 L’état d’un objet est constitué des valeurs de ses variables
d’instance (ie ses attributs)
 Ce bean maintient l’état des variables d’instance entre 2
appels, et ce pour un client donné
 Stateless Session Bean
 Ne permet pas de maintenir des valeurs de variables
 Singleton Session Bean
 Instancié une et une seule fois pour une application
 Existe pout toute la durée de vie de l’application
StateFul Session Bean
 Maintient un état conversationnel avec le client
 N’a qu’un seul client
 Maintient son état entre les appels de ce client
 Se termine si le client se termine
  Le container maintient un Stateful par client
Stateless Session Bean
 Pas d’état conversationnel avec le client
 Le container maintient un pool de Stateless Session
Bean
 Le container alloue un de ces bean au client
 Un Stateless a un client à la fois.
  réutilisation des instances
  Peut avoir moins de stateless que de client
Quand utiliser un
Stateful Session Bean ?
 The bean's state represents the interaction between
the bean and a specific client.
 The bean needs to hold information about the client
across method invocations.
 The bean mediates between the client and the other
components of the application, presenting a simplified
view to the client.
Quand utiliser un
Stateless Session Bean ?
 Si vous voulez améliorer les performanes et que votre
bean à une des caractéristiques suivantes:
 The bean's state has no data for a specific client.
 In a single method invocation, the bean performs a
generic task for all clients.

For example, you might use a stateless session bean to send an
email that confirms an online order.
 The bean implements a web service.
Quand utiliser un
Singleton Session Bean ?
 State needs to be shared across the application.
 A single enterprise bean needs to be accessed by
multiple threads concurrently.
 The application needs an enterprise bean to perform
tasks upon application startup and shutdown.
 The bean implements a web service.
Atelier BeanSession
 Créer un bean session
 3.atelierBeanSession.pdf

tutoFirstBeanSession.pdf
 Créer un client lourd (avec un main() )
 Créer un client lourd (avec JUnit)
 Connecter 2 bean session (par Injection)
 Créer un second bean session avec une methode askMe() : String. Cette
méthode appelle firstBean.sayHello(), et retourne le résultat + la date.
 Créer un client avec JUnit
 Créer un client léger
Accéder au Session Bean
 Une session bean peut être accédé par
 Une vue sans interface

Cad les méthodes public du bean
 Une (ou plusieurs )interface de domaine
 Interface Java définissant les méthodes exposées par le bean
 L’implémentation interne du bean n’est pas accessible par
le client.
 L’interface et la vue sans-interface permettent de bien
séparer l’utilisation du bean (vue client) de son
implémentation
 Facilite la maintenance (peut changer l’implem)
  faire attention lors de la conception de l’interface
Utiliser un bean dans un client
 Un client peut obtenir une référence sur une instance
de bean
 Par injection (utilisation d’annotation Java)
 Par lookup JNDI
 Un client ne doit pas instancier directement un bean
 C’est le conteneur qui fait l’instanciation.
Qui supporte l’injection
 Tous les clients fonctionnant dans un server JEE
 JavaServer Faces web
 JAX-RS web services,
 other enterprise beans,
 or Java EE application clients
 Utiliser l’annotation javax.ejb.EJB
 Sinon, utiliser un lookup avec JNDI
Syntaxe JNDI portable
 Attention, certaines implementations JNDI ne supporte
pas cette syntaxe
 Namespaces:
 java:global, java:module, et java:app
 Remote
 java:global[/application name]/module name /enterprise bean
name[/interfacename ]
 Local, dans le même module (le même war, jar, rar)
 java:module/enterprise bean name/[interface name]
 Locale, dans la même application (le même EAR)
 java:app[/module name]/enterprise bean name [/interface
name]
Client local ou client remote?
 Tight or loose coupling of related beans
 Tight  local
 Loose  remote
 Type of client
 Application , sur une autre machine  remote
 Sur la même machine  local
 Component distribution  remote
 Besoin de mise à l’échelle  remote
 Performance  local
 Details:
 32.4.2 Deciding on Remote or Local Access
 Si incertain  remote
 Peu aussi être local ET remote !
Client local
 A local client has these characteristics.
 ■ It must run in the same application as the enterprise
bean it accesses.
 ■ It can be a web component or another enterprise bean.
 ■ To the local client, the location of the enterprise bean
it accesses is not transparent.
 La vue sans interface et une vue local
 Une interface @Local
@Local
public interface InterfaceName { ... }
@Local(InterfaceName.class)
public class BeanName implements InterfaceName { ... }
Accéder au Client Local
 Par la vue sans interface
 Utiliser la classe du bean
 Ou JNDI
@EJB ExampleBean exampleBean;
ExampleBean exampleBean = (ExampleBean)
InitialContext.lookup("java:module/ExampleBean");
 Par la vue domaine (interface locale)
 Utiliser le nom de l’interface locale
 Ou JNDI
@EJB Example example;
ExampleLocal example = (ExampleLocal)
InitialContext.lookup("java:module/ExampleLocal");
Client distant (remote)
 Un client distant a les caractéristiques suivantes:
 It can run on a different machine and a different JVM
from the EJB it accesses.

(It is not required to run on a different JVM.)
 It can be a web component, an application client, or
another enterprise bean.
 To a remote client, the location of the EJB is transparent.
 The enterprise bean must implement a business
interface.

remote clients may not access an enterprise bean through a
no-interface view.
Créer un client remote
 Soit décorer l’interface remote avec @Remote
@Remote
public interface InterfaceName { ... }
 Soit décorer le bean
@Remote(InterfaceName.class)
public class BeanName implements InterfaceName { ... }
Communication client remote bean
 Transparent pour le programmeur
 Mais RMI derrière
Obtenir le bean remote
 Par injection
 Utiliser l’interface remote
@EJB
Example example;
 Par lookup JNDI
 Utiliser l’interface remote
ExampleRemote example = (ExampleRemote)
InitialContext.lookup("java:global/myApp/ExampleRemote");
Constitution d’un EJB
 To develop an enterprise bean, you must provide the
following files:
 ■ Enterprise bean class: Implements the business methods of
the enterprise bean and any lifecycle callback methods.
 ■ Business interfaces: Define the business methods
implemented by the enterprise bean class. A business
interface is not required if the enterprise bean exposes a local,
no-interface view.
 ■ Helper classes: Other classes needed by the enterprise bean
class, such as exception and utility classes.
 Packager les fichiers
 Dans un EJB Jar
 Ou dans le WAR (WEBINF/classes)
Convention de nommage
des classes
Cycle de vie d’un Stateful Session
Bean
 Le système peut décider de « passiver » le bean
 Pour récupérer des ressources
 Peut utiliser des callback (par annotations)
Cycle de vie d’un Stateless Session
Bean
 Pas de passivation
 Car réutilisation par le conteneur
Cycle de vie d’un Singleton Session
Bean
Cycle de vie d’un
Message Driven Bean (MDB)
Voir chap 26 avaeetutorial7
More information on Enterprise
JavaBean
 The Java EE 7 Tutorial
 http://docs.oracle.com/javaee/7/tutorial/doc/
 Enterprise JavaBeans 3.2 specification:
 http://www.jcp.org/en/jsr/detail?id=345
 Enterprise JavaBeans web site:
 http://www.oracle.com/technetwork/java/ejb141389.html
 Enterprise JavaBeans 3.2 specification project:
 https://java.net/projects/ejb-spec/
Lectures
 The Java EE 7 Tutorial
 http://docs.oracle.com/javaee/7/tutorial/doc/
 chap 1 à 5
 chap 26 Enterprise Beans