Beans enterprise
Un bean enterprise est un composant Java™ qui peut être combiné à d'autres ressources pour créer des applications Java. Il existe trois types de beans entreprise : les beans entity, les beans session et les beans gérés par message.
Tous les beans résident dans des conteneurs Enterprise JavaBeans (EJB) qui fournissent une interface entre les beans et le serveur d'application qui les héberge.
EJB 2.1 et les versions antérieures de la spécification définissent des beans entity comme moyen de stockage de données permanentes et requièrent donc une connexion vers une forme de stockage permanent. Ce stockage peut être une base de données, une application propriétaire existante, un fichier ou un autre type de stockage persistant.
La spécification EJB 3.0 rend obsolète les beans entity de niveau EJB 1.1. La spécification d'API de persistance Java (JPA) est destinée à remplacer les beans enterprise rendus obsolètes. Bien que la JPA les remplaçant soit dénommée classe d'entité, elle ne doit pas être confondue avec les beans enterprise de type entity. Une entité JPA n'est pas un bean enterprise et n'a pas à s'exécuter dans un conteneur d'EJB.
Les beans session contiennent généralement la logique métier de haut niveau et de niveau intermédiaire d'une application. Appliquée sur un bean session, chaque méthode effectue une opération de haut niveau particulière. Par exemple, la soumission d'une commande ou un transfert d'argent entre comptes. Les beans session appellent souvent des méthodes sur des beans entity lors de l'exécution de la logique métier.
Les beans session peuvent être des beans avec état, sans état ou singleton. Une instance de bean avec état est prévue pour être utilisée par un seul client au cours de son cycle de vie, pendant lequel le client lance une série d'appels de méthode liés entre eux au moment opportun pour ce client. Un exemple est le panier d'achats auquel le client ajoute des articles lors d'une session d'achat en ligne. Une instance de bean sans état est en revanche généralement utilisée par plusieurs clients au cours de son cycle de vie. Les beans sans état sont donc plus particulièrement adaptés aux opérations de logique métier qui peuvent s'effectuer dans le cadre d'un seul appel de méthode. Les beans avec état ne devraient être utilisés qu'en cas de nécessité absolue. L'utilisation de beans sans état améliore la capacité de débogage, de maintenance et de cadrage de l'application.
La spécification EJB 3.1 introduit les beans session singleton. Le conteneur d'EJB initialise une seule instance d'un bean session singleton et cette instance est partagée par tous les clients. Dans la mesure où une seule instance est partagée par tous les clients, les beans session singleton ont un cycle de vie spécial et une sémantique à accès concurrentiel. Les beans session singleton peuvent avoir des vues de type client de service Web, métier à distance ou métier local. Ils ne peuvent pas utiliser les vues client distant ou local EJB 2.1.
- Définir l'interface métier.
- Définir la classe qui l'implémente.
- Ajouter des métadonnées avec des annotations ou des descripteurs de déploiement XML.
package ejb3demo;
@Stateful
public class Cart3Bean implements ShoppingCart {
private ArrayList contents = new ArrayList();
public void addToCart (Object o) {
contents.add(o);
}
public Collection getContents() {
return contents;
}
}
Les composants EJB peuvent utiliser des annotations @EJB et d'autres références @Resource injectables s'il s'agit d'un module EJB 3.x. Les clients d'application Web et les clients d'application peuvent utiliser des références EJB définies dans le descripteur de déploiement. Si la référence se rapporte à un bean de session EJB 3.x sans interface 'home', elle doit être définie à l'aide d'un paramètre <home> ou <local-home> avec valeur NULL dans le descripteur de déploiement.
Les clients d'application Web et les clients d'application peuvent également utiliser des injections @EJB pour référence à des beans session EJB dans le même fichier d'archive d'entreprise (EAR), mais la liaison doit alors utiliser la prise en charge AutoLink dans le conteneur ou bien l'annotation doit utiliser le nom de la référence défini par le descripteur de déploiement et lié lors de l'installation de l'application. Pour plus d'informations sur AutoLink, voir la rubrique "Prise en charge des liaisons d'application EJB 3.x".
- Le conteneur d'EJB et le fournisseur JMS (Java Message Service) fonctionnent conjointement afin de traiter les messages. Lorsqu'un message arrive depuis un autre composant d'une application par le biais du fournisseur JMS, le conteneur d'EJB le transmet grâce à l'appel de la méthode onMessage à une instance de bean dépendant des messages qui traite alors le message. A d'autres égards, les beans dépendants des messages s'apparentent aux beans session sans état.
- Le conteneur d'EJB et un adaptateur de ressources JCA (Java Connector Architecture) fonctionnent conjointement afin de traiter les messages provenant d'un système EIS (Enterprise Information System). Lorsqu'un message arrive d'un système EIS, l'adaptateur de ressources reçoit le message et le transmet à un bean géré par message, qui traite alors le message. Le bean géré par message offre des services tels que la prise en charge des transactions par le conteneur d'EJB de la même manière que les autres beans enterprise fournissent un service.
Les beans qui nécessitent l'accès aux données utilisent des sources de données qui sont des ressources d'administration définissant des groupes de connexions dans des mécanismes de stockage persistant.