des enterprise beans - DÃ©partement Informatique

Guide du développeur 

Enterprise JavaBeans 

VERSION 5 

Borland ® 

JBuilder

Consultez le fichier DEPLOY.TXT situé dans le répertoire redist de JBuilder pour avoir la liste complète des fichiers 

que vous pouvez distribuer en accord avec votre contrat de licence JBuilder. 

Les applications mentionnées dans ce manuel sont brevetées par Borland Software Corporation ou en attente de 

brevet. Ce document ne donne aucun droit sur ces brevets. 

COPYRIGHT © 1997, 2001 Borland Software Corporation. Tous droits réservés. Tous les produits Borland sont des 

marques commerciales ou des marques déposées de Borland Software Corporation aux Etats-Unis et dans les 

autres pays. Les autres noms de produits sont des marques commerciales ou des marques déposées de leurs 

fabricants respectifs. 

Pour connaître les conditions et limites des fournisseurs tiers, lisez les Remarques version sur votre CD JBuilder. 

JBE0050WW21002entjb 2E1R0401 

0102030405-9 8 7 6 54321 

PDF

Table des matières 

Chapitre 1 

Introduction 

au développement des EJB 1-1 

Pourquoi avons-nous besoin 

des Enterprise JavaBeans . . . . . . . . . . . 1-2 

Rôles dans le développement 

d’une application EJB . . . . . . . . . . . . . . 1-3 

Rôles application . . . . . . . . . . . . . . . . 1-3 

Rôles infrastructure . . . . . . . . . . . . . . 1-3 

Rôles déploiement et opérations . . . . . . . 1-4 

Architecture EJB . . . . . . . . . . . . . . . . . . 1-5 

Le serveur EJB . . . . . . . . . . . . . . . . . 1-5 

Le conteneur EJB . . . . . . . . . . . . . . . . 1-6 

Comment fonctionne un enterprise bean . 1-6 

Types d’enterprise beans . . . . . . . . . . . . . 1-7 

Beans session . . . . . . . . . . . . . . . . . . 1-7 

Beans entité . . . . . . . . . . . . . . . . . . . 1-7 

Développement des enterprise beans . . . . . . 1-8 

Comment contacter le support développeur 

de Borland . . . . . . . . . . . . . . . . . . . . 1-9 

Ressources en ligne. . . . . . . . . . . . . . . 1-9 

World Wide Web . . . . . . . . . . . . . . 1-9 

Groupes de discussion Borland . . . . . .1-10 

Groupes de discussion Usenet . . . . . .1-10 

Rapports de bogues. . . . . . . . . . . . .1-10 

Conventions de la documentation . . . . . . . . 1-11 

Chapitre 2 

Configuration du serveur 

d’applications cible 2-1 

Ajout des fichiers du serveur d’applications 

à votre projet . . . . . . . . . . . . . . . . . . . 2-2 

Rendre ORB accessible à JBuilder . . . . . . . . 2-3 

Sélection d’un serveur d’applications . . . . . . 2-4 

Chapitre 3 

Création des enterprise beans 

avec JBuilder 3-1 

Création d’un groupe EJB. . . . . . . . . . . . . 3-2 

Création d’un groupe EJB vide . . . . . . . . 3-2 

Création d’un groupe EJB 

à partir d’enterprise beans existant . . . . . 3-3 

Création d’un enterprise bean . . . . . . . . . . 3-4 

Création d’un bean session . . . . . . . . . . 3-6 

Création d’un bean entité . . . . . . . . . . . 3-7 

Ajout de la logique métier à votre bean. . . . 3-9 

Exposition des méthodes métier 

via l’interface distante. . . . . . . . . . . . 3-11 

Génération de la classe du bean à partir 

d’une interface distante. . . . . . . . . . . . . 3-12 

Création des interfaces locale et distante 

d’un bean existant. . . . . . . . . . . . . . . . 3-15 

Compilation du bean . . . . . . . . . . . . . . . 3-17 

Modification des descripteurs de déploiement 3-20 

Chapitre 4 

Création des beans entité 

à partir d’une table existante 

dans une base de données 4-1 


avec le Modeleur Bean entité EJB . . . . . . . . 4-1 

Chapitre 5 

Test d’un enterprise bean 5-1 

Création d’un client de test . . . . . . . . . . . . 5-1 

Utilisation de l’application client de test . . . . . 5-3 

Test de votre enterprise bean . . . . . . . . . . . 5-5 

Chapitre 6 

Déploiement des enterprise beans 6-1 

Création d’un fichier descripteur 

de déploiement . . . . . . . . . . . . . . . . . . 6-2 

Le rôle du descripteur de déploiement . . . . . . 6-2 

Les types d’informations 

du descripteur de déploiement . . . . . . . 6-3 

Informations structurelles. . . . . . . . . . 6-4 

Informations sur l’assemblage 

de l’application . . . . . . . . . . . . . . . 6-4 

Sécurité . . . . . . . . . . . . . . . . . . . . 6-5 

Rôles de sécurité . . . . . . . . . . . . . . . 6-5 

Permissions de méthodes . . . . . . . . . . 6-5 

Liaison aux références 

des rôles de sécurité . . . . . . . . . . . . 6-5 

Déploiement sur un serveur d’applications . . . 6-6 

Déploiement d’un 

ou de plusieurs fichiers JAR . . . . . . . . . 6-6 

Déploiement sur les serveurs WebLogic 

ou WebSphere . . . . . . . . . . . . . . . . . 6-9 

Définition des options de déploiement 

avec la boîte de dialogue Propriétés . . . . 6-10 

i

Déploiement dynamique 

sur un serveur d’applications . . . . . . . . 6-11 

Chapitre 7 

Utilisation de l’éditeur 

de descripteur de déploiement 7-1 

Affichage de l’éditeur de descripteur 

de déploiement . . . . . . . . . . . . . . . . . . 7-2 

Visualisation du descripteur de déploiement 

d’un enterprise bean . . . . . . . . . . . . . . . 7-2 

Ajout des informations 

d’un nouvel enterprise bean . . . . . . . . . . 7-4 

Modification des informations 

concernant le bean . . . . . . . . . . . . . . . . 7-5 

Informations sur les enterprise beans . . . . . . 7-5 

Panneau Main . . . . . . . . . . . . . . . . . 7-5 

Panneau Environment . . . . . . . . . . . . . 7-7 

Panneau EJB references . . . . . . . . . . . . 7-8 

Panneau Security role references . . . . . . . 7-9 

Panneau Resource references . . . . . . . . .7-10 

Panneau Persistence . . . . . . . . . . . . . .7-12 

Panneau Finders . . . . . . . . . . . . . . . .7-14 

Panneau Properties. . . . . . . . . . . . . . .7-15 

Transactions conteneur . . . . . . . . . . . . . .7-20 

Ajout d’une transaction gérée 

par le conteneur. . . . . . . . . . . . . . . .7-20 

Travail sur les sources de données . . . . . . . .7-21 

Définition des niveaux d’isolation . . . . . .7-23 

Définition des propriétés 

des sources de données . . . . . . . . . . .7-23 

Ajout des rôles de sécurité 

et des méthodes autorisées . . . . . . . . . . .7-25 

Création d’un rôle de sécurité. . . . . . . . .7-25 

Assignation des méthodes autorisées . . . .7-26 

Visualisation et modification des propriétés 

WebLogic et WebSphere . . . . . . . . . . . . .7-27 

Vérification des informations du descripteur. .7-28 

Chapitre 8 

Utilisation de DataExpress 

pour les composants EJB 8-1 

Les composants DataExpress EJB . . . . . . . . 8-2 

Composants pour le serveur . . . . . . . . . 8-2 

Composants pour le client. . . . . . . . . . . 8-2 

Création des beans entité . . . . . . . . . . . . . 8-2 

Création du bean session côté serveur. . . . . . 8-3 

Ajout des composants fournisseur 

et résolveur au bean session. . . . . . . . . 8-3 

Ecriture de la méthode setSessionContext() . 8-4 

Ajout d’une référence EJB 

au descripteur de déploiement . . . . . . 8-5 

Ajout des méthodes de fourniture 

et de résolution . . . . . . . . . . . . . . . . 8-5 

Appel de la méthode find . . . . . . . . . . . 8-6 

Construction du côté client . . . . . . . . . . . . 8-7 

Gestion des relations . . . . . . . . . . . . . . . . 8-9 

Projet exemple. . . . . . . . . . . . . . . . . . . . 8-9 

Chapitre 9 

Développement des beans session 9-1 

Types de beans session . . . . . . . . . . . . . . . 9-1 

Beans session stateful . . . . . . . . . . . . . . 9-1 

Beans session stateless . . . . . . . . . . . . . 9-2 

Ecriture de la classe du bean session . . . . . . . 9-2 

Implémentation de l’interface SessionBean. . 9-2 

Ecriture des méthodes métier . . . . . . . . . 9-3 

Ajout d’une ou de plusieurs méthodes 

ejbCreate() . . . . . . . . . . . . . . . . . . . 9-3 

Comment JBuilder peut vous aider 

à créer un bean session . . . . . . . . . . . . 9-4 

La vie d’un bean session . . . . . . . . . . . . . . 9-5 

Beans stateless . . . . . . . . . . . . . . . . . . 9-5 

Beans stateful . . . . . . . . . . . . . . . . . . 9-6 

Etat prêt pour la méthode et état prêt 

pour la transaction . . . . . . . . . . . . . 9-7 

Un bean session pour faire vos courses. . . . . . 9-9 

Fichiers de l’exemple du chariot virtuel . . 9-10 

Le bean session Cart . . . . . . . . . . . . . 9-10 

Ajout des méthodes nécessaires . . . . . 9-11 

Ajout des méthodes métier . . . . . . . . 9-13 

Classe Item . . . . . . . . . . . . . . . . . . . 9-15 

Exceptions . . . . . . . . . . . . . . . . . . . 9-15 

Interfaces exigées . . . . . . . . . . . . . . . 9-16 

L’interface locale . . . . . . . . . . . . . . 9-16 

L’interface distante. . . . . . . . . . . . . 9-17 

Le descripteur de déploiement de Cart . 9-18 

Chapitre 10 

Développement des beans entité 10-1 

Persistance et beans entité . . . . . . . . . . . . 10-1 

Persistance gérée par le bean. . . . . . . . . 10-2 

Persistance gérée par le conteneur. . . . . . 10-2 

Clés primaires des beans entité . . . . . . . . . 10-3 

Ecriture de la classe du bean entité . . . . . . . 10-3 

Implémentation de l’interface EntityBean . 10-4 

Déclaration et implémentation 

des méthodes des beans entité . . . . . . . 10-5 

ii

Création des méthodes Create. . . . . . .10-5 

Création des méthodes Find. . . . . . . .10-7 

Ecriture des méthodes métier . . . . . . .10-8 

Utilisation des experts de JBuilder 

pour créer un bean entité . . . . . . . . . .10-8 

La vie d’un bean entité . . . . . . . . . . . . . .10-8 

L’état de non existence . . . . . . . . . . . . .10-9 

L’état en pool . . . . . . . . . . . . . . . . . .10-9 

L’état prêt . . . . . . . . . . . . . . . . . . . 10-10 

Retour à l’état en pool . . . . . . . . . . . . 10-10 

Exemple du bean entité bank . . . . . . . . . . 10-11 

L’interface locale d’un bean entité . . . . . 10-11 

L’interface distante d’un bean entité . . . . 10-12 

Un bean entité dont la persistance 

est gérée par le conteneur . . . . . . . . . 10-12 

Un bean entité dont la persistance 

est gérée par le bean . . . . . . . . . . . . 10-14 

La classe clé primaire . . . . . . . . . . . . 10-19 

Le descripteur de déploiement . . . . . . . 10-19 

Descripteur de déploiement 

d’un bean entité dont la persistance 

est auto-gérée . . . . . . . . . . . . . . 10-21 

Descripteur de déploiement 

d’un bean entité dont la persistance 

est gérée par le conteneur . . . . . . . 10-22 

Chapitre 11 

Création des interfaces 

locales et distantes 11-1 

Création de l’interface locale . . . . . . . . . . . 11-1 

La classe de base EJBHome . . . . . . . . . . 11-2 

Création d’une interface locale 

pour un bean session . . . . . . . . . . . . . 11-2 

Méthodes create() des beans session . . . 11-3 

Création d’une interface locale 

pour un bean entité. . . . . . . . . . . . . . 11-4 

Méthodes create() des beans entité . . . . 11-4 

Méthodes find des beans entité . . . . . . 11-5 

Création de l’interface distante . . . . . . . . . . 11-6 

L’interface EJBObject . . . . . . . . . . . . . . 11-7 

Chapitre 12 

Développement des clients 

des enterprise beans 12-1 

Localisation de l’interface locale . . . . . . . . 12-2 

Obtenir l’interface distante. . . . . . . . . . . . 12-2 

Beans session. . . . . . . . . . . . . . . . . . 12-2 

Beans entité . . . . . . . . . . . . . . . . . . 12-3 

Les méthodes find et la classe 

de la clé primaire . . . . . . . . . . . . . 12-4 

Méthodes create et remove . . . . . . . . 12-4 

Appel des méthodes . . . . . . . . . . . . . . . 12-5 

Suppression des instances de beans . . . . . . 12-6 

Référencement d’un bean avec son handle. . . 12-6 

Gestion des transactions . . . . . . . . . . . . . 12-7 

Découvrir les informations sur le bean . . . . . 12-8 

Création d’un client avec JBuilder . . . . . . . 12-9 

Chapitre 13 

Gestion des transactions 13-1 

Caractéristiques des transactions . . . . . . . . 13-1 

Support des transactions dans le conteneur . . 13-2 

Enterprise beans et transactions. . . . . . . . . 13-3 

Comparaison entre 

les transactions gérées par le bean 

et celles gérées par le conteneur . . . . . . 13-3 

Attributs des transactions . . . . . . . . . . 13-4 

Transactions locales et globales . . . . . . . 13-5 

Utilisation de l’API de transaction . . . . . . . 13-6 

Gestion des exceptions dans les transactions . 13-8 

Exceptions au niveau du système . . . . . . 13-8 

Exceptions au niveau de l’application . . . 13-8 

Gestion des exceptions au niveau 

de l’application . . . . . . . . . . . . . . . 13-9 

Annulation de la transaction . . . . . . . 13-9 

Options pour continuer une transaction 13-10 

Index I-1 

iii

Chapitre 

1 

Chapitre1Introduction 

au développement des EJB 

“Enterprise JavaBeans (EJB) specification” (http://java.sun.com/ 

products/ejb/docs.html) définit de manière formelle un modèle de 

composant Java côté serveur et une interface de programmation pour les 

serveurs d’applications. Les développeurs construisent des composants, 

appelés enterprise beans, pour contenir la logique métier de l’entreprise. 

Les enterprise beans s’exécutent sur un serveur EJB qui fournit aux beans 

des services comme la gestion des transactions et la sécurité. Les 

développeurs n’ont pas à se préoccuper de la programmation de ces 

services de bas niveau et complexes ; ils peuvent se concentrer sur 

l’encapsulation des règles métier de leur organisation à l’intérieur des 

beans, tout en sachant que les services sont accessibles aux beans lorsque 

c’est nécessaire. 

Outre son rôle d’ultime arbitre pour le cadre de travail EJB, la spécification 

Enterprise JavaBeans sert essentiellement aux fournisseurs, comme 

Borland, qui construisent les serveurs EJB et les conteneurs dans lesquels 

s’exécutent les beans. Ce manuel aidera le développeur JBuilder à savoir 

ce qu’il veut savoir sur le développement des enterprise beans et sur la 

création des applications qui les utilisent. 

Si vous êtes déjà familier du développement des EJB et souhaitez 

apprendre à créer des enterprise beans avec JBuilder, commencez par le 

Chapitre 3, “Création des enterprise beans avec JBuilder”. 

Introduction au dé veloppement des EJB 1-1

Pourquoi avons-nous besoin des Enterprise JavaBeans 

Pourquoi avons-nous besoin des Enterprise JavaBeans 

Le modèle client-serveur de développement des applications a eu une 

popularité considérable. L’application client réside sur une machine locale 

et accède aux données d’un ensemble de données tel qu’un système de 

gestion de bases de données relationnelles (SGBR). Ce modèle fonctionne 

bien tant que le système n’a qu’un petit nombre d’utilisateurs. Lorsque de 

plus en plus d’utilisateurs veulent accéder aux données, ces applications 

n’évoluent pas suffisamment bien pour suivre la demande. Comme la 

logique se trouve sur le client, il doit être installé sur chaque machine. La 

gestion devient donc de plus en plus difficile. 

Petit à petit, est apparue la nécessité de diviser les applications en un 

nombre de niveaux supérieur aux deux niveaux du modèle client-serveur. 

Dans une application multiniveau, seule l’interface utilisateur réside sur la 

machine locale alors que la logique de l’application s’exécute dans un 

niveau intermédiaire sur un serveur. Le niveau final est toujours constitué 

par les données stockées. Lorsqu’il convient de mettre à jour la logique 

d’une application, les modifications sont apportées au logiciel du niveau 

intermédiaire sur le serveur, ce qui simplifie considérablement la gestion 

des mises à jour. 

Pourtant, la création d’applications distribuées fiables, sécurisées et faciles 

à gérer est notoirement difficile. Par exemple, la gestion des transactions 

dans un système distribué est une lourde tâche. Heureusement, 

l’utilisation de composants respectant la spécification EJB pour construire 

des systèmes distribués permet de : 

• Diviser le développement d’un système distribué en plusieurs tâches 

spécifiques assignées à des spécialistes. 

Par exemple, si l’application est un système comptable, le développeur 

d’enterprise beans doit connaître la comptabilité. L’administrateur 

système doit savoir comment surveiller une application déployée en 

cours d’exécution. Chaque spécialiste assume un rôle particulier. 

• Rendre les services du serveur et du conteneur EJB accessibles à 

l’enterprise bean et aux développeurs d’applications. 

Le fournisseur de serveur EJB et le fournisseur de conteneur EJB (c’est 

souvent le même) prennent en charge beaucoup des tâches les plus 

difficiles, si bien que le développeur n’a pas à le faire. Par exemple, le 

conteneur dans lequel un enterprise bean s’exécute peut fournir au 

bean les services de transaction et de sécurité automatiquement. 

• Rendre portables les enterprise beans. 

Le bean une fois écrit peut être déployé sur n’importe quel serveur EJB 

qui respecte le standard Enterprise JavaBeans. Cependant, chaque bean 

est à même d’inclure des éléments spécifiques au fournisseur. 

1-2 Guide du dé veloppeur Enterprise JavaBeans

R ô les dans le dé veloppement d’ une application EJB 

Rôles dans le développement d’une application EJB 

Le travail de développement d’une application distribuée EJB se divise en 

six parties ou rôles distincts. Chaque rôle est pris en charge par un 

spécialiste du domaine. Le travail ainsi divisé, la création et la gestion 

d’un système distribué deviennent beaucoup plus faciles. 

Rôles application 

Ceux qui assurent les rôles concernant les applications écrivent le code des 

enterprise beans et des applications qui les utilisent. Ce deux domaines 

exigent une compréhension du métier lui-même mais à des niveaux 

différents. Voici les deux rôles application : 

• Fournisseur de beans 

Les fournisseurs de beans (également appelés développeurs de beans) 

créent les enterprise beans et écrivent la logique des méthodes métier 

qu’ils intègrent. Ils définissent également les interfaces distante et 

locale des beans et ils créent les descripteurs de déploiement des beans. 

Les fournisseurs de beans n’ont pas obligatoirement besoin de savoir 

comment leurs beans seront assemblés et déployés. 

• Assembleur d’applications 

Les assembleurs d’applications écrivent les applications qui utilisent les 

enterprise beans. Ces applications comprennent habituellement 

d’autres composants, comme les clients GUI, les applets, les JSP 

(JavaServer Pages) et les servlets. Ces composants sont assemblés en 

une application distribuée. Les assembleurs ajoutent des instructions 

d’assemblage aux descripteurs de déploiement des beans. Bien que les 

assembleurs d’applications aient besoin de connaître les méthodes 

contenues dans les enterprise beans pour les appeler, ils n’ont pas 

besoin de savoir comment elles sont implémentées. 

Les utilisateurs de JBuilder concernés par Enterprise JavaBeans sont 

généralement des fournisseurs de beans et des assembleurs 

d’applications. Ce manuel leur est donc dédié. JBuilder possède des 

experts, des concepteurs et d’autres outils qui simplifient le 

développement des enterprise beans et des applications qui les utilisent. 

Rôles infrastructure 

Sans le support d’une infrastructure, les enterprise beans et les 

applications qui les utilisent ne peuvent pas s’exécuter. Bien que les deux 

rôles concernant l’infrastructure soient distincts, ils sont presque toujours 

assurés par le même fournisseur. Ils apportent aux enterprise beans les 


R ô les dans le dé veloppement d’ une application EJB 

services du niveau système ainsi que l’environnement dans lequel ils 

s’exécutent. Voici les deux rôles infrastructure : 

• Fournisseur de serveurs EJB 

Les fournisseurs de serveurs EJB sont des spécialistes de la gestion 

distribuée des transactions, des objets distribués et d’autres services de 

bas niveau. Ils fournissent le cadre de travail applicatif dans lequel 

s’exécutent les conteneurs EJB. Au minimum, les fournisseurs de 

serveurs EJB doivent fournir aux beans un service d’annuaire et un 

service de transaction. 

• Fournisseur de conteneurs EJB 

Les fournisseurs de conteneurs EJB fournissent les outils nécessaires au 

déploiement des enterprise beans et le support des beans à l’exécution. 

Un conteneur procure des services de gestion à un ou à plusieurs beans. 

Il communique avec le serveur EJB afin d’accéder aux services dont le 

bean a besoin. 

Dans la majorité des cas, le fournisseur de serveurs EJB et le fournisseur 

de conteneurs EJB sont confondus. Borland AppServer fournit à la fois le 

serveur et le conteneur. 

Rôles déploiement et opérations 

Les dernières étapes du développement d’une application distribuée EJB 

sont le déploiement de l’application et la surveillance, pendant qu’elle 

s’exécute, de l’informatique de l’entreprise et de l’infrastructure de son 

réseau. Voici les rôles déploiement et opérations : 

• Déployeur 

Les déployeurs connaissent l’environnement opératoire des 

applications distribuées. Ils adaptent l’application EJB à 

l’environnement opératoire cible en modifiant les propriétés des 

enterprise beans au moyen des outils fournis par le fournisseur de 

conteneurs. Par exemple, les déployeurs déterminent les politiques de 

transaction et de sécurité en définissant les propriétés correspondantes 

dans le descripteur de déploiement. Ils intègrent d’autre part, 

l’application aux logiciels de gestion existant dans l’entreprise. 

• Administrateur système 

L’application une fois déployée, l’administrateur système la surveille 

pendant son exécution et prend les décisions appropriées si elle se 

comporte anormalement. Les administrateurs système sont chargés de 

configurer et d’administrer l’informatique et l’infrastructure réseau de 

l’entreprise, ce qui comprend le serveur EJB et le conteneur EJB. 


Architecture EJB 


Les applications distribuées multiniveaux sont souvent composées d’un 

client s’exécutant sur une machine locale, d’un niveau intermédiaire 

s’exécutant sur un serveur qui contient la logique métier et d’un niveau 

final constitué d’un système d’information d’entreprise (SIE). Un SIE peut 

être un système de bases de données relationnelles, un système ERP, une 

application standard, ou tout ensemble contenant les données qu’il faut 

accéder. Cette figure montre un système distribué EJB typique comportant 

trois niveaux : le client; le serveur, le conteneur et les beans déployés sur 

eux; ainsi que le système d’information de l’entreprise. 

Figure 1.1 

Diagramme de l’architecture EJB 

Notre sujet étant le développement des enterprise beans, nous nous 

concentrerons sur le niveau intermédiaire. 

Le serveur EJB 

Le serveur EJB fournit aux enterprise beans des services système et gère 

les conteneurs dans lesquels s’exécutent les beans. Il doit offrir un service 

d’annuaire accessible via JNDI et un service de transaction. Très souvent, 

le serveur EJB fait bénéficier de fonctions supplémentaires qui le 



distinguent de ses concurrents. Borland AppServer est un exemple de 

serveur EJB. 

Le conteneur EJB 

Un conteneur est un système d’exécution pour un ou plusieurs enterprise 

beans. Il fournit la communication entre les beans et le serveur EJB. Il 

fournit la gestion des transactions, de la sécurité et de la distribution sur le 

réseau. Un conteneur est à la fois du code et un outil qui génère le code 

spécifique à chaque enterprise bean. Un conteneur fournit également les 

outils du déploiement de l’enterprise bean ; c’est aussi un moyen pour le 

conteneur de surveiller et de gérer l’application. 

Le serveur EJB et le conteneur EJB fournissent ensemble l’environnement 

où le bean s’exécute. Le conteneur fournit des services de gestion à un ou à 

plusieurs beans. Le serveur fournit les services au bean, mais le conteneur 

agit pour le compte des beans pour obtenir ces services. 

Bien qu’il s’agisse d’une partie vitale de l’architecture Enterprise 

JavaBeans, les développeurs d’enterprise bean et les assembleurs 

d’applications n’ont pas à se préoccuper du conteneur. C’est un acteur “en 

coulisse” des systèmes distribués EJB. Nous n’en dirons donc pas plus sur 

les conteneurs et leur fonctionnement. Pour avoir des informations, 

reportez-vous à la “Enterprise JavaBeans 1.1 Specification” elle-même 

(http://java.sun.com/products/ejb/docs.html). Pour des informations 

spécifiques au conteneur EJB de Borland, voyez le Enterprise JavaBeans 

Programmer’s Guide de Borland AppServer. 

Comment fonctionne un enterprise bean 

Le développeur de beans doit créer les interfaces et les classes suivantes : 

• L’interface locale du bean 

L’interface locale définit les méthodes utilisées par le client pour créer, 

localiser et détruire les instances d’un enterprise bean. 

• L’interface distante du bean 

L’interface distante définit les méthodes métier implémentées dans le 

bean. Un client accède à ces méthodes via l’interface distante. 

• La classe de l’enterprise bean 

La classe de l’enterprise bean implémente la logique métier pour le 

bean. Le client accède à ces méthodes via l’interface distante du bean. 

Le bean une fois déployé dans le conteneur EJB, le client appelle la 

méthode create() définie dans l’interface locale pour instancier le bean. 

L’interface locale n’est pas implémentée dans le bean lui-même, mais par 


Types d’enterprise beans 

Types d’ enterprise beans 

le conteneur. D’autres méthodes, déclarées dans l’interface locale, 

permettent au client de localiser une instance d’un bean et de supprimer 

l’instance d’un bean lorsqu’elle n’est plus nécessaire. 

Lorsque l’enterprise bean est instancié, le client peut appeler les méthodes 

métier qu’il contient. Toutefois, le client n’appelle jamais de méthode 

directement dans l’instance du bean. Les méthodes accessibles au client 

sont définies dans l’interface distante du bean, et celle-ci est implémentée 

par le conteneur. Lorsque le client appelle une méthode, le conteneur 

reçoit la demande et la délègue à l’instance du bean. 

Un enterprise bean peut être un bean session ou un bean entité. 

Beans session 

Un enterprise bean session s’exécute au bénéfice d’un client unique. D’une 

certaine façon, le bean session représente le client pour le serveur EJB. 

Les beans session peuvent maintenir l’état du client, ce qui signifie qu’ils 

peuvent conserver des informations pour le client. L’exemple classique où 

un bean session peut être utilisé est celui du chariot que “remplit” un 

acheteur dans un magasin en ligne du web. Au fur et à mesure que 

l’acheteur sélectionne un élément à mettre dans son chariot, le bean 

session conserve la liste des éléments sélectionnés. 

Les beans session peuvent avoir une courte durée de vie. Généralement, le 

bean est supprimé par le client lorsque celui-ci termine la session. 

Les beans session peuvent être stateful ou stateless. Les beans Stateless ne 

maintiennent pas d’état pour un client particulier. Puisqu’ils ne 

maintiennent pas d’état conversationnel, les beans stateless peuvent être 

utilisés pour supporter plusieurs clients. 

Beans entité 

Un bean entité fournit un objet vue des données d’une base. 

Habituellement, le bean représente une ligne dans un ensemble de tables 

d’une base de données relationnelles. Un bean entité sert généralement 

plusieurs clients. 

Au contraire des beans session, les beans entité sont supposés avoir une 

longue durée de vie. Ils maintiennent un état persistant, vivant aussi 

longtemps que les données restent dans la base, et non aussi (peu) 

longtemps qu’un client particulier a besoin d’eux. 


D é veloppement des enterprise beans 

Le conteneur peut gérer la persistance du bean, ou le bean peut la gérer 

lui-même. Si la persistance est gérée par le bean, le développeur du bean 

doit écrire le code incluant les appels à la base de données. 

Développement des enterprise beans 

Les chapitres suivants expliquent comment utiliser les experts, les 

concepteurs et les outils de JBuilder qui faciliteront et accéléreront la 

création de vos enterprise beans. Il part de l’hypothèse que vous savez ce 

que sont les Enterprise JavaBeans, comment ils fonctionnent et quelles 

sont leurs exigences. 

Si votre connaissance d’EJB est insuffisante ou si vous voulez avoir plus 

d’informations sur le développement EJB avant de commencer à utiliser 

les experts et les outils EJB de JBuilder, lisez le Chapitre 9, 

“Développement des beans session” et les chapitres qui suivent avant de 

continuer. 

Le développement des Enterprise JavaBeans avec JBuilder se divise en 

plusieurs étapes : 

1 Configuration du serveur d’applications cible (voir Chapitre 2) 

2 Création d’un groupe EJB (voir page 3-2) 

3 Création d’un enterprise bean et de ses interfaces locale et distante (voir 

page 3-4) 

4 Compilation du bean (voir page 3-17) 

5 Modification du descripteur de déploiement (voir page 3-20) 

6 Création d’une application client de test (voir page 5-1) 

7 Test de votre enterprise bean (voir page 5-5) 

8 Déploiement sur un serveur d’applications (voir page 6-6) 

Vous pouvez aussi utiliser JBuilder pour créer des enterprise beans de 

type entité, basés sur les tables de n’importe quelle base de données 

accessible via JDBC. Voir “Création des beans entité avec le Modeleur 

Bean entité EJB”, page 4-1. 

Si vous préférez créer d’abord l’interface distante d’un enterprise bean, 

vous pouvez ensuite utiliser le Créateur de bean EJB pour créer le 

squelette de la classe et l’interface locale en fonction de cette interface 

distante. Pour plus d’informations, voir “Génération de la classe du bean à 

partir d’une interface distante”, page 3-12. 


Comment contacter le support dé veloppeur de Borland 

Comment contacter le support développeur de Borland 

Borland offre aux développeurs diverses options de support. Elles 

comprennent des services gratuits sur Internet, où vous pouvez consulter 

notre importante base d’informations et entrer en contact avec d’autres 

utilisateurs de produits Borland. En outre, vous pouvez choisir parmi 

plusieurs catégories de support, allant de l’installation des produits 

Borland au support tarifé de niveau consultant, en passant par une 

assistance complète. 

Pour obtenir des informations sur les services Borland de support aux 

développeurs, veuillez consulter notre site Web, à l’adresse 

http://www.borland.fr/Support/. 

Quand vous contacterez le support, préparez des informations complètes 

sur votre environnement, la version du produit que vous utilisez et une 

description détaillée du problème. 

Pour avoir de l’aide sur les outils tiers, ou leur documentation, contactez 

votre fournisseur. 

Ressources en ligne 

Vous pouvez obtenir des informations depuis les sources ci-après: 

World Wide Web 

FTP 

Listserv 

http://www.borland.fr/ 

ftp.borland.com 

Documents techniques accessibles par anonymous 

ftp. 

Pour vous abonner aux bulletins électroniques, utilisez 

le formulaire en ligne : 

http://www.borland.com/contact/listserv.html 

ou, pour l’international, 

http://www.borland.com/contact/intlist.html 

World Wide Web 

Consultez régulièrement www.borland.fr/jbuilder. L’équipe produit de 

JBuilder y place notes techniques, analyses des produits concurrents, 

réponses aux questions fréquemment posées, exemples d’applications, 

mises à jour du logiciel et informations sur les produits existants ou 

nouveaux. 

Vous pouvez vous connecter en particulier aux URL suivantes : 

• http://www.borland.fr/Produits/jbuilder/ (mises à jour du logiciel et 

autres fichiers) 


Comment contacter le support dé veloppeur de Borland 

• http://community.borland.com/ (contient notre magazine 

d’informations web pour les développeurs) 

Groupes de discussion Borland 

Vous pouvez vous inscrire à JBuilder et participer à de nombreux groupes 

de discussion dédiés à JBuilder. 

Vous trouverez des groupes de discussion, animés par les utilisateurs, 

pour JBuilder et d’autres produits Borland, à l’adresse 

http://www.borland.fr/Newsgroups/ 

Remarque 

Groupes de discussion Usenet 

Les groupes Usenet suivants sont dédiées à Java et concernent la 

programmation : 

• news:comp.lang.java.advocacy 

• news:comp.lang.java.announce 

• news:comp.lang.java.beans 

• news:comp.lang.java.databases 

• news:comp.lang.java.gui 

• news:comp.lang.java.help 

• news:comp.lang.java.machine 

• news:comp.lang.java.programmer 

• news:comp.lang.java.security 

• news:comp.lang.java.softwaretools 

Ces groupes de discussion sont maintenus par les utilisateurs et ne sont 

pas des sites Borland officiels. 

Rapports de bogues 

Si vous pensez avoir trouvé un bogue dans le logiciel, merci de le signaler 

dans la page du support développeur de JBuilder, à l’adresse 

http://www.borland.fr/Support/jbuilder/. Sur ce site, vous pouvez 

également demander une fonctionnalité ou consulter la liste des bogues 

déjà signalés. 

Quand vous signalez un bogue, indiquez toutes les étapes nécessaires à la 

reproduction de ce bogue, ainsi que tout paramètre spécial de votre 

environnement et les autres programmes utilisés avec JBuilder. Précisez 

bien le comportement attendu et ce qui s’est réellement passé. 

Si vous avez des commentaires (compliments, suggestions ou questions) 

concernant la documentation de JBuilder, vous pouvez envoyer un e-mail 

à jpgpubs@borland.com. Uniquement pour la documentation. Les 

questions de support doivent être adressées au support développeur. 

JBuilder est fait par des développeurs pour des développeurs. Nous 

apprécions vraiment vos remarques, car elles nous aident à améliorer 

notre produit. 


Conventions de la documentation 


La documentation Borland sur JBuilder utilise les polices et les symboles 

décrits dans le tableau ci-dessous pour signaler du texte particulier. 

Tableau 1.1 Polices et symboles 

Police 

Police à 

espacement fixe 

Gras 

Italiques 

Signification 

La police à espacement fixe représente : 

• du texte tel qu’il apparaît à l’écran 

• du texte que vous devez taper, comme “Entrez Hello World 

dans le champ Titre de l’expert Application.” 

• des noms de fichiers 

• des noms de chemins 

• des noms de répertoires ou de dossiers 

• des commandes, comme SET PATH, CLASSPATH 

• du code Java 

• des types de données Java, comme boolean, int et long. 

• des identificateurs Java, comme des noms de variables, 

classes, interfaces, composants, propriétés, méthodes et 

événements 

• des noms de paquets 

• des noms d’argument 

• des noms de champs 

• des mots clés Java, comme void et static 

Le gras est utilisé pour désigner les outils java, bmj (Borland 

Make for Java), bcj (Borland Compiler for Java) et les options du 

compilateur. Par exemple : javac, bmj, -classpath. 

L’italique est utilisé pour les termes nouveaux, les titres des 

manuels et, parfois, pour la mise en valeur. 

Touches 

Cette police indique une touche de votre clavier. Par exemple, 

“Appuyez sur Echap pour quitter un menu.” 

[ ] Les crochets droits dans le texte ou dans la syntaxe entourent les 

éléments facultatifs. Ne tapez pas ces crochets. 

< > Les crochets angulaires dans le texte ou dans la syntaxe 

indiquent une chaîne variable ; entrez la chaîne appropriée à 

votre code. Ne tapez pas ces crochets. Les crochets angulaires 

sont également utilisés pour les balises HTML. 

... Dans les exemples de code, les points de suspension indiquent 

du code manquant. Sur un bouton, les points de suspension 

indiquent que ce bouton ouvre un dialogue de sélection. 



JBuilder est disponible sur plusieurs plates-formes. Reportez-vous au 

tableau ci-dessous pour une description des conventions et répertoires 

associés aux diverses plates-formes dans la documentation. 

Tableau 1.2 Conventions et répertoires associés aux plates-formes 

Elément 

Chemins 

Répertoire de base 

Répertoire 

.jbuilder5 

Répertoire jbproject 

Captures d’écran 

Signification 

Les chemins d’accès mentionnés dans la documentation sont 

indiqués par une barre oblique (/). 

Pour la plate-forme Windows, utilisez une barre oblique 

inverse (\). 

L’emplacement du répertoire de base dépend de la 

plate-forme. 

• Pour UNIX et Linux, le répertoire de base peut varier. Par 

exemple, ce peut être /user/[nomutilisateur] ou /home/ 

[nomutilisateur] 

• Pour Windows 95/98, le répertoire de base est C:\Windows 

• Pour Windows NT, le répertoire de base est C:\Winnt\ 

Profiles\[nomutilisateur] 

• Pour Windows 2000, le répertoire de base est C:\Documents 

and Settings\[nomutilisateur] 

Le répertoire .jbuilder5, où sont stockés les paramètres de 

fonctionnement de JBuilder, est placé dans le répertoire de 

base. 

Le répertoire jbproject, qui contient les fichiers projet, classe 

et source, est placé dans le répertoire de base. JBuilder 

enregistre les fichiers dans ce chemin par défaut. 

Les captures d’écran reflètent l’apparence Metal de JBuilder 

sur diverses plates-formes. 


Chapitre 

2 

Chapitre2Configuration du serveur 

d’applications cible 

Remarque 

Remarque 

Avant de commencer à créer des Enterprise JavaBeans, vous devez 

configurer le serveur d’applications sur lequel vous allez les déployer. 

Dans tous les cas, Borland AppServer (BAS) ou Inprise Application 

Server 4.1 (IAS) doit avoir été installé sur votre ordinateur. 

Pour configurer JBuilder afin qu’il cible un ou plusieurs serveurs 

d’applications, 

1 Choisissez Outils|Configuration Entreprise. 

2 Sélectionnez la page Serveur d’applications. 

Vous pouvez accomplir l’étape suivante quel que soit le serveur 

d’applications pour lequel vous développez vos enterprise beans. Si 

vous ne l’accomplissez pas, les experts EJB sera estompés dans la 

galerie d’objets. 

3 Sélectionnez la page BAS 4.5 ou la page IAS 4.1 et spécifiez le répertoire 

où est installé Borland AppServer 4.5 ou Inprise Application Server 4.1. 

Pour BAS 4.5, c’est habituellement /Borland/AppServer. Définir une des 

Configuration du serveur d’ applications cible 2-1

Ajout des fichiers du serveur d’ applications à votre projet 

pages des serveurs d’applications Borland vous empêche de définir 

l’autre. 

4 Si vous voulez cibler le serveur WebLogic ou WebSphere, sélectionnez 

la page WebLogic ou WebSphere pour la version souhaitée et spécifiez 

le répertoire où est installé le serveur d’applications WebLogic ou 

WebSphere. Pour WebSphere, vous devez également spécifier où est 

installé le JDK IBM livré avec WebSphere. Pour WebLogic 6.0, le 

répertoire local de BEA est exigé. 

5 Si vous voulez utiliser le serveur d’applications que vous être en train 

de définir comme cible du projet en cours, cochez la case Appliquer les 

paramètres pour le serveur d’application modifié au projet en cours. 

6 Choisissez OK. 

Lorsque vous fermez la boîte de dialogue, une bibliothèque BAS 4.5 est 

automatiquement créée et elle contient tous les fichiers BAS qui vous 

seront nécessaires pour le développement EJB. (Si votre cible est Inprise 

Application Server, le nom de la bibliothèque sera IAS 4.1.) 

Vous devez fermer puis redémarrer JBuilder pour activer les experts EJB. 

Si vous voulez rendre VisiBroker ORB accessible à JBuilder, vous pouvez 

attendre de terminer cette étape avant d’interrompre et de redémarrer 

JBuilder. 

Ajout des fichiers du serveur d’applications à votre projet 

Vous devez ajouter à votre projet une bibliothèque contenant les fichiers 

de votre serveur d’applications. Au début de chaque nouveau projet, vous 

devez accomplir cette étape. Si vous avez coché la case Appliquer les 


Rendre ORB accessible à JBuilder 

paramètres pour le serveur d’application modifié au projet en cours dans 

la boîte de dialogue Configuration Entreprise, vous pouvez, pour cette 

fois, sauter cette étape car JBuilder a déjà ajouté la bibliothèque appropriée 

au projet en cours. Mais, au prochain démarrage d’un nouveau projet, 

vous devrez respecter les étapes suivantes pour ajouter une bibliothèque 

au projet en cours : 

1 Choisissez Projet|Propriétés du projet et assurez-vous que l’onglet 

Chemins est sélectionné. 

2 Cliquez sur l’onglet Bibliothèques nécessaires. 

3 Cliquez sur le bouton Ajouter pour afficher la boîte de dialogue 

Sélection de bibliothèques. Les bibliothèques disponibles dépendent 

des serveurs d’applications installés et configurés avec Outils| 

Configuration Entreprise. 

4 Sélectionnez la bibliothèque appropriée. Par exemple, si vous ciblez 

Borland AppServer, sélectionnez la bibliothèque BAS 4.5 et cliquez 

deux fois sur OK pour fermer les boîtes de dialogue. 

Rendre ORB accessible à JBuilder 

Lorsque vous utilisez Outils|Configuration Entreprise pour définir 

Borland AppServer ou Inprise Application Server, vos paramètres 

CORBA sont automatiquement configurés en même temps. Vous pouvez 

voir les paramètres en cours sur la page CORBA de la boîte de dialogue 

Configuration Entreprise. Vous pouvez souhaiter utiliser cette page pour 

définir le port SmartAgent de VisiBroker par un numéro unique. De 

même, pour ajouter au menu Outils une commande démarrant le 

SmartAgent, cochez l’option Ajouter un nouvel élément Smart Agent 

VisiBroker au menu Outils. 

Configuration du serveur d’ applications cible 2-3

S é lection d’ un serveur d’ applications 

Il reste encore une étape à accomplir : démarrer le SmartAgent VisiBroker. 

Cela gère les problèmes d’amorçage initial comme la façon dont le client 

localise le service d’annuaire, ou autre. 

Pour démarrer le Smart Agent, choisissez Outils|Smart Agent VisiBroker. 

Sélection d’un serveur d’applications 

JBuilder peut cibler un des multiples serveurs d’applications. Après avoir 

sélectionné le serveur d’applications cible, terminez la configuration de 

JBuilder en modifiant les propriétés de votre projet : 

1 Choisissez Projet|Propriétés du projet. 

2 Cliquez sur l’onglet Serveurs. 

3 Cliquez sur le bouton à points de suspension pour afficher la boîte de 

dialogue Sélection du serveur d’applications. Les serveurs 

d’applications disponibles dans la boîte de dialogue dépendent des 

serveurs d’applications supportés par JBuilder, du fait qu’ils aient été 

ajoutés en utilisant l’API OpenTools de JBuilder ou le bouton Ajouter 

de cette boîte de dialogue. 

4 Sélectionnez le serveur d’applications sur lequel s’exécuteront les beans 

que vous construisez. Borland AppServer 4.5 est le serveur par défaut. 

L’option EJB 1.1 est générique. Sélectionnez-la si le serveur 

d’applications que vous utilisez n’est actuellement pas pris en charge 

par JBuilder. Vous pouvez modifier le descripteur de déploiement 

résultant à l’aide des outils fournis avec ce serveur d’applications, pour 

définir les paramètres exactement comme vous le souhaitez. Vous 

pouvez également choisir cette option si vous ne ciblez aucun serveur 

d’applications particulier. 

5 Choisissez OK pour fermer la boîte de dialogue. 


Chapitre 

3 

Chapitre3Création des 

enterprise beans 

avec JBuilder 

Chaque enterprise bean que vous créez doit appartenir à un groupe EJB 

de JBuilder. Un groupe EJB est un groupement logique d’un ou de 

plusieurs beans qui seront déployés dans un même fichier JAR. Il contient 

les informations utilisées pour produire le ou les descripteurs de 

déploiement pour ce fichier JAR. Vous pouvez modifier le contenu d’un 

groupe EJB avec l’éditeur de descripteur de déploiement. 

Lorsque vous disposez d’un groupe EJB et que vous l’avez modifié pour 

votre liaison avec l’éditeur de descripteur de déploiement, vous pouvez 

Construire ou Reconstruire le groupe EJB pour produire le JAR. JBuilder 

utilise le descripteur de déploiement pour vous aider à identifier les 

fichiers classe à empaqueter. 

Selon l’extension de son nom de fichier, un groupe EJB peut appartenir à 

l’un ou à l’autre des deux types suivants : 

.ejbgrp 

.ejbgrpx 

Un fichier binaire. 

Un fichier XML. L’information est la même que dans un 

fichier .ejbgrp mais, comme c’est un fichier texte, il est plus 

facile de travailler avec lorsque vous utilisez un système de 

contrôle de version. 

Vous pouvez avoir plusieurs groupes EJB dans un projet. Tous les 

groupes EJB d’un même projet utilisent le même chemin de classes du 

projet et le même JDK, ils sont aussi configurés pour le même serveur 

d’applications cible. 

Si ce n’est déjà fait, suivez les instructions décrites au Chapitre 2, 

“Configuration du serveur d’applications cible”. Vous devez suivre les 

Cré ation des enterprise beans avec JBuilder 3-1

Cré ation d’ un groupe EJB 

Création d’un groupe EJB 

étapes permettant d’ajouter la bibliothèque contenant les fichiers de votre 

serveur d’applications à chaque projet EJB que vous entreprenez. 

Il y a deux façons de créer un groupe EJB : 

• Utiliser l’expert Groupe EJB vide pour créer un groupe EJB vide lorsque 

vous n’avez pas encore créé vos enterprise beans. 

• Utiliser l’expert Groupe EJB depuis descripteurs pour créer un EJB à 

partir des descripteurs de déploiement des enterprise beans dont vous 

disposez. 

Si vous n’avez pas ouvert de projet avant de lancer l’expert de groupe EJB, 

JBuilder affiche d’abord l’expert projet. L’expert EJB apparaît après la 

création d’un nouveau projet. 

Création d’un groupe EJB vide 

Remarque 

Si vous n’avez pas encore créé vos enterprise beans, commencez par créer 

un groupe EJB vide. Pour créer un groupe EJB vide, 

1 Choisissez Fichier|Nouveau et cliquez sur l’onglet Entreprise. 

Si les experts EJB de la page Entreprise sont estompés, vous n’avez pas 

encore configuré votre serveur d’applications. Pour plus 

d’informations sur la façon de le faire, voir Chapitre 2, “Configuration 

du serveur d’applications cible”. 

2 Double-cliquez sur l’icône de l’expert Groupe EJB vide pour faire 

apparaître l’expert : 


3 Spécifiez le nom du groupe EJB. 

Cré ation d’ un groupe EJB 

4 Spécifiez le type du nouveau groupe. 

Les choix sont ejbgrp, qui stocke en interne les descripteurs de 

déploiement au format .zip et était utilisé avant JBuilder 5, et ejbgrpx, 

qui stocke les descripteurs de déploiement au format XML. Le format 

XML permet aux utilisateurs de fusionner les modifications s’ils les 

vérifient à l’aide d’un système de contrôle des sources. Nous 

recommandons ejbgrpx sauf si vous partagez le fichier avec une 

version antérieure de JBuilder. 

5 Spécifiez le nom du fichier JAR où vous mettrez votre ou vos enterprise 

beans. 

JBuilder propose une valeur par défaut correspondant au nom de votre 

groupe EJB. Vous pouvez accepter ce nom ou en saisir un autre. 

JBuilder propose également un chemin d’accès basé sur le chemin de 

votre projet. Vous pouvez modifier ou accepter le chemin par défaut. 

6 Cliquez sur OK pour créer le groupe EJB. 

Création d’un groupe EJB à partir d’enterprise beans 

existant 

Si vous disposez déjà d’enterprise beans BAS, ajoutez-les au groupe EJB 

en suivant les étapes ci-dessous : 


2 Double-cliquez sur l’icône de l’expert Groupe EJB depuis descripteurs 

pour faire apparaître l’expert. 

3 Spécifiez le nom de votre nouveau groupe EJB. 


Cré ation d’ un enterprise bean 

4 Spécifiez le type du nouveau groupe. 

Les choix sont ejbgrp, qui stocke en interne les descripteurs de 

déploiement au format .zip et était utilisé avant JBuilder 5, et ejbgrpx, 

qui stocke les descripteurs de déploiement au format XML. Le format 

XML permet aux utilisateurs de fusionner les modifications s’ils les 

vérifient à l’aide d’un système de contrôle des sources. Nous 

recommandons ejbgrpx sauf si vous partagez le fichier avec une 

version antérieure de JBuilder. 

5 Spécifiez le nom et le chemin du fichier JAR où sera votre enterprise 

bean. 

JBuilder propose une valeur par défaut correspondant au nom de votre 

groupe EJB. Vous pouvez accepter ce nom ou en saisir un autre. 

6 Cliquez sur Suivant et spécifiez le répertoire contenant le ou les 

descripteurs de déploiement que vous voulez ajouter au groupe. 

L’expert vous montre alors les descripteurs de déploiement présents 

dans le répertoire spécifié dans le champ Descripteurs utilisables 

trouvés. 

Création d’un enterprise bean 

7 Cliquez sur Terminer pour créer le groupe EJB contenant les 

descripteurs de déploiement des beans existants. 

La galerie d’objets de JBuilder contient deux experts permettant de créer 

des enterprise beans : l’expert Enterprise JavaBean et le Modeleur Bean 

entité EJB. Le menu Experts en contient un autre : l’expert Créateur de 

bean EJB. Cette section explique comment créer un enterprise bean avec 

l’expert Enterprise JavaBean. 



L’expert Enterprise JavaBean et l’expert Modeleur Bean entité EJB utilisent 

un modèle dans lequel la classe et les interfaces locale et distante de votre 

enterprise bean sont créées en même temps. Si vous préférez commencer 

le développement de votre enterprise bean en créant en premier votre 

interface distante, voyez “Génération de la classe du bean à partir d’une 

interface distante”, page 3-12, pour savoir comment utiliser l’expert 

Créateur de bean EJB afin de générer la classe de votre bean à partir de 

l’interface distante que vous avez créée. 

Pour commencer à créer un enterprise bean avec l’expert Enterprise 

JavaBean, 


2 Double-cliquez sur l’icône de l’expert Enterprise JavaBean. 

L’expert apparaît. 

3 Dans la liste déroulante, sélectionnez le groupe EJB auquel vous voulez 

faire appartenir votre enterprise bean. Cliquez sur Suivant pour passer 

à l’étape 2 de l’expert. 

Si vous n’avez pas défini de groupe EJB avant de lancer l’expert 

Enterprise JavaBeans ou si vous voulez en créer un nouveau, cliquez 

sur le bouton Nouveau pour lancer l’expert Groupe EJB vide. Vous 

devez avoir défini au moins un groupe EJB dans votre projet avant de 

pouvoir créer un enterprise bean. Lorsque le groupe EJB a été créé avec 



l’expert Groupe EJB vide, sélectionnez le nouveau groupe et choisissez 

Suivant pour reprendre les étapes de l’expert Enterprise JavaBean. 

4 Spécifiez le nom de classe de votre bean, la paquet qui le contiendra et 

sa classe de base. 

Ensuite, vous devez décider si vous créez un bean session ou un bean 

entité. 

Création d’un bean session 

Si vous créez un bean session, 

1 Cliquez sur Bean session stateless ou sur Bean session stateful. 

Pour plus d’ informations sur les types de beans session, voir “Types de 

beans session”, page 9-1. 

2 Si vous sélectionnez un Bean session stateful, vous pouvez aussi choisir 

d’implémenter l’interface SessionSynchronization en cochant la case 

Synchronisation de session. 

Pour plus d’informations sur l’interface SessionSynchronization, voir 

“L’interface SessionSynchronization”, page 9-8. 


3 Cliquez sur Suivant pour aller à l’étape 3. 


4 Spécifiez des noms pour les Classe de l’interface locale, Classe de 

l’interface distante et Nom du bean local ; JBuilder propose des noms 

par défaut en se servant du nom de classe de votre bean. 

5 Cliquez sur Terminer. 

Création d’un bean entité 

Si vous créez un bean entité, 

1 Choisissez entre les options Bean entité à persistance gérée par Bean et 

Bean entité EJB 1.1 à persistance gérée par conteneur. (Si WebSphere 3.5 

est votre serveur d’applications cible, la seconde option est Bean entité 

EJB 1.0 à persistance gérée par conteneur.) 

Pour plus d’informations sur la persistance gérée par le bean ou par le 

conteneur, voir “Persistance et beans entité”, page 10-1. 

2 Spécifiez une Classe clé primaire. 




4 Spécifiez des noms pour les Classe de l’interface locale, Classe de 

l’interface distante et Nom du bean local ; JBuilder propose des noms 

par défaut en se servant du nom de classe de votre bean. 

5 Cliquez sur Terminer. 

Lorsque vous avez cliqué sur le bouton Terminer, JBuilder crée la classe 

du bean et ses interfaces locale et distante. Vous les verrez apparaître dans 

le volet projet. Examinez le code source de la classe du bean et vous verrez 

que la classe implémente l’interface SessionBean s’il s’agit d’un bean 

session et qu’elle implémente l’interface EntityBean s’il s’agit d’un bean 

entité. JBuilder a ajouté des méthodes dont le corps vide : ce sont les 

méthodes que tous les enterprise beans doivent implémenter. Vous 

pouvez ajouter au corps de ces méthodes le code qui fournit la logique 

nécessaire à votre bean lorsque qu’elles sont appelées. 

L’interface locale étend l’interface EJBHome et contient la méthode create() 

qui crée le bean. L’interface distante étend l’interface EJBObject mais elle 

est vide car vous n’avez déclaré aucune méthode de logique métier pour 

votre bean. 

Bien que vous puissiez commencer votre bean entité en utilisant l’expert 

Enterprise JavaBeans, le meilleur moyen de créer des beans entité est 

d’utiliser le Modeleur Bean entité EJB. Les beans entité que vous créez 

avec l’expert Enterprise JavaBean ne supporteront pas la vérification de 

l’éditeur de descripteur de déploiement si vous ne complétez pas le bean 

plus avant. 


Ajout de la logique métier à votre bean 


Dans le code source de la classe de votre bean, définissez et écrivez les 

méthodes qui implémentent la logique nécessaire à votre enterprise bean. 

Si vous devez lui ajouter des propriétés, vous pouvez soit les ajouter 

directement dans le code source, soit utiliser la page Propriétés du 

concepteur de bean. 

Pour utiliser le concepteur de bean afin de mettre en œuvre les propriétés, 

1 Double-cliquez sur la classe du bean dans le volet projet. 

2 Cliquez sur l’onglet Bean pour afficher le concepteur de bean. 

3 Cliquez sur l’onglet Propriétés pour afficher la page Propriétés. 



Pour ajouter une nouvelle propriété, 

1 Cliquez sur le bouton Ajouter une propriété pour afficher la boîte de 

dialogue Nouvelle propriété. 

2 Spécifiez le Nom de propriété et le Type. 

3 Spécifiez vos méthodes d’accès en définissant les options Getter et 

Setter. 

Si vous voulez que votre propriété possède une méthode getter, vous 

devez choisir si elle doit apparaître dans la classe et/ou dans l’interface 

distante du bean. Si vous voulez que votre propriété possède une 

méthode setter, vous devez choisir si elle doit apparaître dans la classe 

et/ou dans l’interface distante du bean. 

4 Choisissez Appliquer pour ajouter immédiatement la nouvelle 

propriété au code source de votre bean. Les méthodes d’accès que vous 

spécifiez sont ajoutées à la classe et/ou à l’interface distante du bean, 

selon les options choisies. 

5 Vous pouvez continuer d’ajouter de nouvelles propriétés dans la boîte 

de dialogue. Cliquez sur OK une fois terminé. 

Si vous utilisez l’expert Enterprise JavaBean pour initialiser un bean entité 

dont la persistance est gérée par le conteneur, vous ajouterez des 

propriétés à votre bean. N’oubliez pas qu’une des propriétés doit être la 

clé primaire et que vous devez spécifier le ou les champs qui la constituent 

dans le panneau Persistence de l’éditeur de descripteur de déploiement. Si 

vous ne le faites pas, l’éditeur de descripteur de déploiement ne pourra 

pas vérifier la validité du descripteur de déploiement. 

Vous pouvez aussi utiliser le page Propriétés pour modifier une propriété. 

Par exemple, si vous ne spécifiez pas de setter pour une propriété lorsque 

vous la déclarez et si vous décidez ensuite que votre bean en a besoin, 

vous n’avez qu’à cocher la case Setter de cette propriété dans la page 

Propriétés : JBuilder ajoutera la méthode setter à votre code source. Ou 

encore, vous pouvez supprimer une méthode getter ou setter en 

supprimant la coche de la case correspondante. 



Pour enlever une propriété à un bean en utilisant le page Propriétés, 

1 Sélectionnez la propriété listée dans la table des propriétés. 

2 Cliquez sur le bouton Remove. 

JBuilder vous demande si vous voulez supprimer la propriété et le code 

qui lui est associé. 

3 Choisissez Oui. 

Vous pouvez aussi utiliser la page Propriétés pour modifier le nom de la 

propriété et son type. Le concepteur de bean est un outil bidirectionnel, les 

modifications effectuées dans la page Propriétés se retrouvent dans le 

code et les modifications apportées au code se retrouvent dans la page 

Propriétés. 

Exposition des méthodes métier via l’interface distante 

Une fois les méthodes de logique métier déclarées dans le code source de 

votre bean, vous devez spécifier quelles sont celles que vous voulez 

ajouter à l’interface distante. Le client ne peut appeler que les méthodes 

exposées via l’interface distante du bean. 

Pour ajouter des méthodes à l’interface distante, 

1 Double-cliquez sur l’enterprise bean dans le volet projet. 

2 Cliquez sur l’onglet Bean pour afficher le concepteur de bean. 

3 Cliquez sur l’onglet Méthodes. 

4 Dans la boîte Méthodes, cochez les cases situées à côté des méthodes 

que vous voulez exposer dans l’interface distante. 


G é n é ration de la classe du bean à partir d’ une interface distante 

Au fur et à mesure que vous cochez des méthodes dans la boîte Méthodes, 

elles sont ajoutées à l’interface distante. 

Pour supprimer une méthode de l’interface distante, supprimez la coche 

de la case de la méthode dans la boîte Méthodes. 

Pour modifier une des méthodes, cliquez dessus avec le bouton droit pour 

afficher le menu contextuel et choisissez Modifier la sélection. Le fichier 

s’ouvre dans l’éditeur de code, votre curseur est positionné sur la 

méthode, et vous pouvez la modifier immédiatement. 

Le menu contextuel offre d’autres commandes intéressantes. Vous pouvez 

choisir Retirer ce qui est sélectionné pour supprimer une méthode de la 

classe du bean. Choisir Tout cocher coche toutes les méthodes et les ajoute 

toutes à l’interface distante ; choisir Tout décocher supprime la sélection 

de toutes les méthodes de sorte qu’aucune méthode n’est ajoutée à 

l’interface distante. 

Vous pouvez utiliser la page Méthodes pour vérifier que les méthodes 

déclarées dans la classe de votre bean ont la même signature que dans 

l’interface locale et l’interface distante. Par exemple, imaginons que vous 

avez ajouté un paramètre à la méthode ejbCreate() dans la classe de votre 

bean, mais négligé de le faire pour la méthode create() de l’interface 

locale. La boîte Méthodes affichera la méthode ejbCreate() et la méthode 

create() en caractères de couleur rouge. Si vous cliquez sur une méthode 

affichée en rouge, une boîte Description du problème apparaîtra et décrira 

la nature du problème. Vous pourrez alors ajouter le paramètre à la 

méthode create() pour unifier les signatures des méthodes et régler le 

problème. Ou, si vous supprimez des méthodes dans la classe de votre 

bean mais oubliez de le faire dans l’interface distante, la boîte Méthodes 

affichera ces méthodes en rouge pour vous rappeler de les supprimer 

aussi dans l’interface distante. 

Génération de la classe du bean à partir d’une interface distante 

Certains développeurs préfèrent commencer le développement d’un 

enterprise bean en concevant l’interface distante. Si cette approche vous 

convient, vous pouvez utiliser le Créateur de bean EJB pour générer le 

squelette de la classe du bean à partir de votre interface distante existante. 

Pour générer la classe du bean à partir d’une interface distante, 

1 Affichez l’interface distante dans l’éditeur. 



2 Choisissez Experts|EJB|Créateur de bean EJB pour afficher l’expert 

Créateur de bean EJB. 

3 Sélectionnez le groupe EJB auquel appartient le bean et cliquez sur 

Suivant. 

4 Sélectionnez le type d’EJB que vous voulez générer et cliquez sur 

Suivant. 



Si vous avez sélectionné une des options des beans session, cette page 

apparaît: 

• Spécifiez les Options de bean EJB : Classe Bean, Nom de bean, 

interface locale et Nom JNDI. 

Si vous avez sélectionné une des options des beans entité CMP, cet 

écran apparaît: 

• Spécifiez les Options de bean EJB : Classe Bean, Nom de bean, 

interface locale et Nom JNDI, Classe clé primaire, et les champs que 

voulez rendre persistants. 

5 Choisissez Terminer. 

Le Créateur de bean EJB crée le squelette de la classe du bean spécifié 

en incluant les méthodes trouvées dans l’interface distante. Dans la 


Cré ation des interfaces locale et distante d’ un bean existant 

classe générée, ces méthodes contiennent un commentaire vous 

rappelant de compléter leurs implémentations. Vous devez ajouter 

votre propre code aux méthodes pour les implémenter à votre 

convenance. 

Le Créateur de Bean EJB crée aussi une interface locale s’il en existe pas. 

S’il existe déjà une interface locale, le Créateur de Bean EJB vous 

demande si vous voulez remplacer l’interface locale et agit en fonction 

de la réponse. 

Création des interfaces locale et distante d’un bean existant 

Si vous avez déjà la classe d’un bean, mais pas les interfaces locale et 

distante requises, vous pouvez utiliser l’expert Créateur d’interface EJB 

pour les générer. Vous pouvez aussi utiliser l’expert si vous avez fait des 

modifications significatives dans le code source de votre bean et si vous 

voulez que ces modifications se retrouvent dans les interfaces. En utilisant 

le Créateur d’interface EJB, vous régénérez de nouvelles interfaces basées 

sur le nouveau code source de la classe du bean. 

Pour utiliser l’expert Créateur d’interface EJB, 

1 Ouvrez le code source de la classe de votre bean dans l’éditeur de code. 

2 Choisissez Experts|EJB|Créateur d’interface EJB. 

3 Sélectionnez le groupe EJB auquel appartient le bean et cliquez sur 

Suivant. 


Cré ation des interfaces locale et distante d’ un bean existant 

Cette page apparaît pour un bean session : 

Cette page apparaît pour un bean entité : 

4 Acceptez les noms par défaut ou entrez-en d’autres. 

5 Si l’enterprise bean est un bean session, sélectionnez l’option Stateless 

ou l’option Stateful. Si l’enterprise bean est un bean entité, sélectionnez 

l’option Persistance gérée par bean ou l’option Persistance gérée par 

conteneur. 


Compilation du bean 

6 Cliquez sur Suivant pour passer à l’étape 3, qui affiche les méthodes du 

bean : 


7 Laissez sélectionnées les méthodes que vous voulez exposer dans 

l’interface distante et supprimez la coche de celles que vous ne voulez 

pas faire apparaître dans cette interface. 


Lorsque vous avez écrit et enregistré votre enterprise bean, ses interfaces 

et toutes les classes de support éventuelles, vous êtes presque prêt à 

compiler. Auparavant et uniquement si votre cible est Borland AppServer 

ou Inprise Application Server 4.1 et si vous voulez tester votre bean en 

local, générez et ajoutez les stubs client à votre chemin d’accès aux classes. 

Pour cela, modifiez les propriétés de construction de votre interface locale 

et compilez. 

Pour modifier les propriétés de construction d’un groupe EJB afin de 

générer et d’ajouter les stubs client à votre chemin d’accès aux classes 

pour chacun des beans du groupe (cette étape est facultative), 

1 Cliquez avec le bouton droit sur le groupe EJB dans le volet projet et 

choisissez Propriétés. 

2 Sélectionnez l’onglet Construction. 



3 Sélectionnez l’onglet EJB. 

4 Modifiez les propriétés de construction à votre convenance. 

Vous pouvez changer le nom du fichier JAR de destination et 

l’emplacement où il est généré. 

Si, pour modifier les descripteurs de déploiement, vous voulez utiliser 

un autre outil que l’éditeur de descripteur de déploiement de JBuilder, 

modifiez les descripteurs de déploiement avec l’outil de votre choix. 

Vous pouvez également insérer des descripteurs de déploiement dans 

un groupe EJB et copier des descripteurs de déploiement n’importe où 

ailleurs. Vous pouvez aussi supprimer un descripteur de déploiement. 

Si vous voulez que soient ajoutés au fichier JAR des fichiers 

supplémentaires, cliquez sur le bouton Ajouter et spécifiez 

l’emplacement de ces fichiers. Cela vous sera utile si, par exemple, vous 

avez ajouté une nouvelle classe à votre projet et si vous voulez qu’elle 

fasse partie du fichier JAR. Ou, si vous avez des descripteurs de 

déploiement que vous avez modifiés hors de JBuilder, vous pouvez les 

ajouter ici en ne sélectionnant pas Inclure les descripteurs de 

déploiement dans le fichier JAR destination. Les descripteurs de 

déploiement montrés dans la liste Descripteurs de déploiement dans le 

groupe ne seront pas ajoutés au fichier JAR, mais ceux spécifiées dans 

la liste Fichiers supplémentaires pour le répertoire META-INF dans 

JAR le seront. 

Si vous ciblez plusieurs serveurs d’applications différents, vous pouvez 

utiliser l’option Retirer les fichiers stubs lors des modifications du 



serveur d’applications pour supprimer les stubs client utilisés par 

l’ancien serveur d’applications lorsque vous en choisissez un nouveau. 

L’option Toujours créer un JAR lors de la construction du projet est 

activée par défaut. En ne sélectionnant pas cette option, vous pouvez 

différer la construction du fichier JAR jusqu’à ce que vous soyez prêt à 

commencer les tests. 

5 Cliquez sur l’onglet du serveur d’applications que vous ciblez. Par 

exemple, cette image illustre la sélection de l’onglet BAS 4.5 : 

6 Sélectionnez les options de construction que vous souhaitez. Si vous 

avez besoin d’informations sur les options disponibles, cliquez sur le 

bouton Aide. 

Vous pouvez également modifier les propriétés de construction de chaque 

bean plutôt que de l’ensemble du groupe EJB : 

1 Cliquez avec le bouton droit sur l’interface locale du bean et choisissez 

Propriétés. 

2 Cliquez sur l’onglet Construction. 

3 Cliquez sur l’onglet VisiBroker. 

4 Cochez la case Créer IIOP et sélectionnez toute autre option Java2IIOP 

nécessaire. 

5 Cliquez sur OK. 

Pour compiler toutes les classes du projet, cliquez avec le bouton droit sur 

le fichier projet (.jpx) et choisissez Construire, ou choisissez 

directement Projet|Construire le projet. 


Modification des descripteurs de dé ploiement 

Au cours du processus de compilation, JBuilder peut détecter l’existence 

d’un problème dans un descripteur de déploiement qui le rend invalide. 

Si cela se produit, vous verrez apparaître dans le volet message un 

message vous demandant de vérifier le bean dans l’éditeur de descripteur 

de déploiement. Pour plus d’informations sur la vérification d’un 

descripteur de déploiement, voir “Vérification des informations du 

descripteur”, page 7-28. 

Remarque destinée aux utilisateurs de WebLogic. Si votre cible est le 

serveur WebLogic, vous provoquerez une erreur pendant le processus de 

construction si le répertoire temporaire ou le chemin d’accès aux classes 

porte un nom contenant des espaces, comme dans C:/Documents and 

Settings/jbprojects. 

Si vous avez choisi de générer les stubs client, plusieurs fichiers s’affichent 

désormais sous le nœud de l’interface locale dans le volet projet lorsque 

vous cliquez sur son icône pour le développer. Ces fichiers générés sont les 

stubs client et les classes Helper nécessaires au fonctionnement des EJB. 

Modification des descripteurs de déploiement 

Chaque enterprise bean conforme aux spécifications EJB 1.1 requiert une 

entrée descripteur de déploiement au format XML. Comme vous avez 

utilisé les experts de JBuilder pour créer un ou plusieurs enterprise beans, 

vous avez également créé un ou plusieurs descripteurs de déploiement. 

Lorsque vous compilez votre projet, JBuilder crée un fichier JAR, en 

fonction du nom configuré, et l’affiche en tant que nœud sous le groupe 

dans le volet projet. 

Vous pouvez également créer le fichier JAR sans compiler tout le projet. 

Cliquez avec le bouton droit sur le nœud du groupe EJB dans le volet 

projet et sélectionnez Construire pour compiler le nœud du groupe EJB. Si 

vous voulez modifier les propriétés de construction avant d’exécuter la 

commande Construire, sélectionnez Propriétés dans le même menu et 

faites toutes les modifications souhaitées dans la boîte de dialogue 

Construction. Choisissez ensuite Construire pour générer le fichier JAR. 

Le fichier JAR contient tous les descripteurs de déploiement. Chaque 

descripteur de déploiement est un fichier XML, sauf pour WebSphere qui 

utilise un fichier .ser pour chacun des beans. Chaque fichier JAR peut 

contenir un ou plusieurs descripteurs de déploiement. 

JBuilder ciblera un des multiples serveurs d’applications. Le serveur 

d’applications ciblé détermine le nombre de descripteurs de déploiement 

présents dans le fichier JAR généré. Chaque fichier JAR aura un 

ejb-jar.xml (sauf ceux ciblant WebSphere 3.5) décrivant les attributs de 

déploiement des beans du groupe communs à tous les serveurs 

d’applications. ejb-jar.xml est le descripteur de déploiement conforme à 

EJB 1.1. Si vous avez sélectionné EJB 1.1 comme serveur d’applications 



cible, ce sera le seul descripteur de déploiement que le fichier JAR 

contiendra. 

Toutes les informations spécifiques au fournisseur sont stockées dans le 

fichier ejb-inprise.xml, même lorsque le fournisseur n’est pas Borland. 

Lorsque vous compilez, les fichiers XML spécifiques au fournisseur sont 

générés à partir de cette information. Ils sont également générés lorsque 

vous cliquez sur l’onglet Source de l’éditeur de descripteur de 

déploiement. 

Si votre cible est Borland AppServer, il n’y aura qu’un fichier XML 

spécifique du serveur d’applications supplémentaire, ejb-inprise.xml. Si 

votre cible est WebLogic Server, le fichier JAR généré inclut un fichier 

weblogic-ejb-jar.xml et un fichier XML supplémentaire pour chaque bean 

entité dont la persistance est gérée par le conteneur. Si votre cible est 

WebSphere, le fichier JAR généré contiendra un fichier .ser pour chacun 

des beans. 

L’éditeur de descripteur de déploiement de JBuilder permet de modifier 

les descripteurs de déploiement existants. 

Pour afficher l’éditeur de descripteur de déploiement, double-cliquez sur 

le groupe EJB dans le volet projet. L’éditeur de descripteur de 

déploiement apparaît. Remarquez l’arborescence du groupe EJB qui 

apparaît dans le volet structure. 

Pour voir les informations concernant un enterprise bean dans l’éditeur de 

descripteur de déploiement, cliquez sur le bean dans le volet structure. 

Ou, si vous sélectionnez le nœud Descripteur de déploiement EJB dans le 

volet structure, vous pouvez cliquer sur l’onglet Contents pour afficher le 



contenu du groupe EJB et double-cliquer ensuite sur l’icône du bean que 

vous voulez voir. Lorsqu’un bean est sélectionné dans l’éditeur, plusieurs 

onglets apparaissent dans l’éditeur de descripteur de déploiement. 

Utilisez ces onglets pour aller dans les panneaux où vous pouvez modifier 

les informations de déploiement. 

Notez que l’onglet Propriétés EJB n’apparaît pas si le serveur 

d’applications cible est Borland AppServer ou Inprise Application Server. 

La page Propriétés EJB vous permet de modifier les valeurs s’appliquant 

aux serveurs d’applications WebLogic ou WebSphere. 

Pour des informations détaillées sur l’utilisation de l’éditeur de 

descripteur de déploiement, voir Chapitre 7, “Utilisation de l’éditeur 

de descripteur de déploiement”. 

Après avoir modifié le descripteur, vous pouvez vérifier le fichier pour 

vous assurer que les informations du descripteur sont exactes, que les 

fichiers classe des beans sont présents, etc. 

Pour vérifier les informations du descripteur, cliquez sur le bouton 

Vérifier dans la barre d’outils de l’éditeur de descripteur de déploiement. 

La vérification effectue ce qui suit : 

• S’assure que le descripteur respecte la spécification EJB 1.1. 

• S’assure que les classes référencées par les descripteurs de déploiement 

respectent la spécification EJB 1.1. 

Si la vérification échoue, un ou plusieurs messages apparaissent dans un 

panneau d’historique décrivant les échecs. 


Chapitre 

4 

beans entité 

à partir d’une table existante 

dans une base de données 


Souvent les données que vous souhaitez modeler dans un bean entité 

existent déjà dans une base de données. Vous pouvez utiliser le Modeleur 

Bean entité de JBuilder pour créer de tels beans entité. 

Création des beans entité avec le Modeleur Bean entité EJB 

L’expert Modeleur Bean entité EJB crée des beans entité en fonction de 

tables existant dans toute base de données accessible via JDBC. Vous 

pouvez utiliser cet expert pour créer plusieurs beans entité en même 

temps et spécifier n’importe quelle relation entre ces beans. 

Lorsque vous avez utilisé le Modeleur Bean entité EJB pour générer le 

code fournissant les beans entité, leurs clés primaires, leurs interfaces 

locale et distante et les entrées appropriées dans le descripteur de 

déploiement, vous pouvez ensuite modifier les résultats avec les autres 

outils de JBuilder, comme le concepteur de bean, l’éditeur de descripteur 

de déploiement ou l’éditeur de code. 

Pour afficher le modeleur de bean entité EJB, choisissez Fichier|Nouveau, 

cliquez sur l’onglet Entreprise et choisissez Modeleur Bean entité EJB. Si 

vous avez défini au moins un groupe EJB dans votre projet, le Modeleur 

Bean entité EJB apparaît. 

Cré ation des beans entité à partir d’ une table existante dans une base de donné es 4-1

Cré ation des beans entité avec le Modeleur Bean entité EJB 

Tous les enterprise beans développés avec JBuilder doivent appartenir à 

un groupe EJB. Si vous n’avez pas au moins un groupe EJB dans votre 

projet, cliquez sur le bouton Nouveau pour lancer l’expert Groupe EJB 

vide. Lorsque vous avez créé un groupe EJB avec l’expert Groupe EJB 

vide, le Modeleur Bean entité EJB apparaît. 

Pour créer un ou plusieurs beans à partir de tables de base de données 

existantes, suivez ces étapes : 

1 Sélectionnez un groupe EJB pour y placer votre bean et choisissez 

Suivant pour aller à l’étape 2. 

Le groupe EJB sélectionné sert à déterminer où seront écrites les 

informations de déploiement. 



2 Spécifiez une source de données JDBC. 

Entrez les informations nécessaires à la connexion à la source de 

données JDBC. 

Pour utiliser une connexion existante, cliquez sur le bouton Choisir une 

connexion existante et sélectionnez une connexion. Les autres 

informations de cette page sont ensuite entrées automatiquement à 

l’exception du mot de passe, que vous devez saisir vous-même si la 

connexion en utilise un. 

S’il n’y a pas de connexion existante ou si vous voulez en créer une, 

sélectionnez un pilote dans la liste déroulante Pilote et spécifiez une 

URL. 

Spécifiez le Nom d’utilisateur pour la source de données et le Mot de 

passe, si nécessaire. Sélectionnez toutes les propriétés avancées dont 

vous avez besoin. Enfin, spécifiez un nom JNDI pour la source de 

données. 

3 Spécifiez les options Types de schémas et table souhaitées. 

Si vous cochez l’option Tous les schémas, le Modeleur Bean entité EJB 

chargera tous les schémas aux quels l’utilisateur a le droit de se 

connecter. Si vous conservez non cochée l’option Tous les schémas, il 

chargera les seuls schémas qui portent le nom de l’utilisateur, ce qui 

devrait réduire le temps nécessaire à l’établissement de la connexion et 

au chargement des données. 

Cochez l’option Vues si vous voulez que des vues soient chargées dans 

le Modeleur Bean entité EJB. Si vous ne voulez pas charger de vue, 

conservez l’option Vues non cochée. 



Le Modeleur Bean entité EJB essaie de se connecter à la source de 

données spécifiée. La page suivante apparaît uniquement si la 

connexion réussit. 

4 Sélectionnez les tables que vous voulez associer aux beans entité. 

Pour chaque table sélectionnée, un bean entité sera créé. Dans la liste 

Disponibles, sélectionnez les tables voulues et faites-les passer dans la 

liste Sélectionnées à l’aide des boutons > et >>. Lorsque vous avez 

sélectionné toutes vos tables, choisissez Suivant. 



5 Sélectionnez les colonnes de chaque table que vous voulez associer aux 

champs des beans entité et spécifiez toutes les relations que vous 

voulez établir entre les tables. 

Dans la section Tables et liaisons, vous verrez toutes les tables 

sélectionnées à l’étape précédente. Sélectionnez tour à tour chaque table 

en cliquant dessus et utilisez ensuite la section Colonnes de la table 

sélectionnée pour placer chaque colonne de la table dans la liste 

Disponibles ou dans la liste Sélectionnées. Par défaut, toutes les 

colonnes de toutes les tables sont sélectionnées. 

Vous pouvez établir des relations entre les tables en faisant glisser le 

pointeur de la souris d’une table à l’autre dans la section Tables et 

liaisons, à gauche. Vous pouvez également utiliser le bouton Ajouter un 

lien. Lorsque vous avez choisi une de ces deux méthodes, une boîte de 

dialogue apparaît et vous propose une relation établie entre les deux 

tables, en fonction de leurs clés étrangères et primaires, de leurs index 

uniques, des noms et des types de leurs champs. Vous pouvez accepter 

cette relation ou la modifier pour en créer une autre. Pour supprimer 

un lien entre des tables, choisissez Retirer le lien. 

Voici un exemple de trois tables liées entre elles : 



Lorsque vous avez sélectionné dans chaque table toutes les colonnes 

que vous voulez associer aux champs des beans entité que vous êtes en 

train de créer, choisissez Suivant. 

6 Spécifiez les noms et les types de données des champs des beans entité 

à faire correspondre aux colonnes des tables. 

Cliquez sur l’onglet approprié pour sélectionner la table par laquelle 

vous voulez commencer le processus. Pour chaque colonne de cette 

table, un Nom de champ et un Type de champ vous sont proposés. 

Vous pouvez accepter ces propositions ou modifier les noms et types 

suggérés pour qu’ils soient comme vous le voulez. 

Pour modifier le type de données de plusieurs champs en même temps, 

sélectionnez les champs souhaités et choisissez Mettre à jour le type de 

champ. Une boîte de dialogue apparaît dans laquelle vous pouvez 

taper le nouveau type de champ. Lorsque vous choisissez appliquer ou 

OK, le type de chaque champ sélectionné est modifié. 

Si la table a déjà une clé primaire, le champ ou l’ensemble de champs 

correspondant est sélectionné lorsque la page Affectation des colonnes 

apparaît la première fois. S’il n’y a pas de clé primaire, vous devez 

sélectionner un ou plusieurs champs pour en créer une en cochant la 

case de ces champs dans la colonne Clé primaire. Lorsque vous avez 



fini d’associer les colonnes sélectionnées aux noms et types de champs 

de votre bean entité pour chaque table, choisissez Suivant. 

7 Spécifiez le paquet, les classes et interfaces, le nom JNDI pour chaque 

bean que vous créez. 

Pour chaque table, JBuilder suggère le nom du bean entité, le nom 

utilisé par JNDI, le nom des interfaces locale et distante, le nom de la 

classe du bean, et le type de la classe clé primaire. Vous pouvez 

spécifier un paquet différent pour chacun d’entre eux ; par défaut, le 

paquet du projet est utilisé. Vous pouvez accepter ces valeurs telles 

quelles ou les modifier à votre convenance. Lorsque vous avez fini de 

spécifier les informations pour toutes les tables, choisissez Suivant. 

8 Choisissez si la persistance des beans entité sera gérée par le conteneur 

ou par le bean. 



Si vous voulez que le code généré utilise le style EJB 2.0, sélectionnez 

l’option Style de code EJB 2.0. Pour plus d’informations sur ces options, 

choisissez le bouton Aide dans le Modeleur Bean entité EJB. 

Par défaut, la classe de base de votre bean est java.lang.Object. Si vous 

voulez utiliser une autre classe comme base de vos beans entité, utilisez 

le champ Classe de base pour le bean entité pour spécifier cette autre 

classe. 

Si vous voulez que vos beans entité soient capables de renvoyer toutes 

les lignes d’un ensemble de données, cochez l’option Générer la 

méthode findAll() des interfaces locales. Le Modeleur Bean entité EJB 

place une méthode findAll() dans l’interface locale de vos beans. Vous 

pouvez aussi choisir que les commentaires d’en-tête apparaissent dans 

les fichiers résultant. 

Les options disponibles sur cet écran dépendent de votre serveur 

d’applications cible. Par exemple, il n’apparaît pas d’option de gestion 

de la persistance par le conteneur lorsque WebSphere 3.5 est la cible car 

WebSphere 3.5 ne prend pas en charge la gestion de la persistance par 

le conteneur. 

Si votre serveur d’applications cible est WebLogic Server et si vous 

créez un bean entité dont la persistance est gérée par le conteneur, cette 

page inclut un champ Nom de pool où vous devez entrer le nom du 

pool de vos beans CMP WebLogic : 


Pour chaque table, JBuilder crée un bean entité et toutes les interfaces des 

classes de support. Vous pouvez maintenant ajouter aux beans la logique 

métier que vous voulez, définir les méthodes que le client pourra appeler 

dans l’interface distante, compiler les beans et modifier les descripteurs de 

déploiement des beans. 


Chapitre 

5 

Chapitre5Test d’un 

enterprise bean 

Création d’un client de test 

Lorsque vous avez créé un enterprise bean, JBuilder peut vous aider à 

créer une application client qui teste son fonctionnement. 

Pour créer une application client de test, 

1 Ouvrez le projet contenant le groupe EJB de votre enterprise bean. 

2 Choisissez Fichier|Nouveau, cliquez sur l’onglet Entreprise et 

double-cliquez sur Client test EJB. 

Test d’ un enterprise bean 5-1

Cré ation d’ un client de test 

3 Sélectionnez le bean pour lequel vous voulez créer un client en utilisant 

une des options de sélection et en spécifiant le bean : 

• Sélectionnez A partir du projet si votre bean appartient au projet en 

cours et spécifiez le bean concerné en le sélectionnant dans la liste 

déroulante. 

• Sélectionnez A partir du JAR ou du répertoire si votre bean n’est pas 

dans le projet en cours, mais ailleurs dans un fichier JAR ou un 

répertoire. Utilisez le bouton ... pour naviguer jusqu’à 

l’emplacement du fichier JAR et sélectionnez-le, puis utilisez la liste 

déroulante pour sélectionner le bean souhaité. 

4 Sélectionnez le nom du paquet dans la liste des paquets. Le paquet 

courant est la valeur par défaut. 

5 Entrez un nom pour la classe client de test ou acceptez le nom par 

défaut. 

6 Sélectionnez les options souhaitées : 

• Créer une méthode pour tester les appels d’interface distante avec 

les arguments par défaut 

Ajoute une méthode testRemoteCallsWithDefaultArguments() qui teste 

les appels d’interface distante avec les arguments par défaut. Par 

exemple, l’argument par défaut d’une String est “”, l’argument par 

défaut d’un int est 0, etc. 

• Générer les messages historiques 

Ajoute le code qui affiche les messages vous informant de l’état du 

bean lorsque le client s’exécute. Par exemple, un message est affiché 

lorsque l’initialisation du bean démarre et un autre lorsqu’elle se 

termine. Cette option génère également les enveloppes pour toutes 

les méthodes déclarées dans les interfaces locale et distante et les 

fonctions d’initialisation. Enfin, les messages signalent le temps 

nécessaire à l’accomplissement de chaque appel de méthode. 

• Générer la fonction principale 

Ajoute au client une fonction main. 

• Générer les commentaires d’en-tête 

Ajoute au client des commentaires d’en-tête JavaDoc que vous 

pouvez remplir d’informations sur le titre, l’auteur, etc. 

7 Choisissez OK. 

L’expert Client Test EJB génère un client de test créant une référence à 

l’enterprise bean. 

Si l’option Générer les messages historiques est sélectionnée, pour chaque 

méthode déclarée dans l’interface distante du bean, l’expert déclare et 


Utilisation de l’ application client de test 

implémente une méthode qui appelle la méthode distante. Chacune de ces 

méthodes signale le succès de l’invocation de la méthode distante et le 

temps nécessaire à son exécution. 

Il y a plusieurs façons d’utiliser l’application client de test générée. Si vous 

avez ajouté une fonction main() à l’application client de test, vous pouvez 

écrire le code qui invoque les appels aux méthodes de l’enterprise bean 

dans la fonction main(). Pour cela, appelez d’abord une méthode create ou 

find et, si une référence distante est renvoyée, utilisez cette référence pour 

appeler les méthodes métier du bean. Ou, car l’expert a déclaré un objet 

client dans la fonction main(), vous pouvez utiliser cet objet client pour 

simplement appeler les méthodes déclarées dans l’application client de 

test qui appellent les méthodes distantes du bean. 

Si vous avez sélectionné l’option Créer une méthode pour tester les appels 

d’interface distante avec les arguments par défaut, votre classe client 

contient désormais une méthode testRemoteCallsWithDefaultArguments(). Si 

vous avez sélectionné l’option historique, cette méthode appelle les 

enveloppes des méthodes distantes qui ont été générées à partir de cette 

option. Pour tester chaque méthode distante, vous pouvez ensuite appeler 

simplement testRemoteCallsWithDefaultArguments() après avoir créé une 

référence à l’interface distante soit dans la méthode create() de la classe 

du client, soit dans une de ses méthodes findByXXX(). 

Si vous n’avez pas sélectionné l’option historique, la méthode 

testRemoteCallsWithDeafultArguments() nécessite la transmission d’une 

interface distante en tant que paramètre. Vous devez créer une référence à 

l’interface distante soit dans la méthode create() de la référence à 

l’interface locale ou dans une de ses méthodes findByXXX(). Ajoutez ensuite 

le code à la classe client pour appeler la méthode 

testRemoteCallsWithDefaultArguments(), en lui passant la référence à 

l’interface distante comme argument. 

Si vous préférez écrire la logique appelant chacune des méthodes métier à 

partir d’une autre classe, vous pouvez choisir de créer et d’utiliser une 

instance de l’application client de test. Voir “Utilisation de l’application 

client de test”, page 5-3. 

Compilez votre application client de test. 

Utilisation de l’application client de test 

Vous pouvez ajouter rapidement la déclaration d’une classe client de test 

à n’importe quelle classe. 

1 Affichez dans l’éditeur la classe dans laquelle vous voulez insérer la 

déclaration. 


Utilisation de l’ application client de test 

2 Choisissez Experts|EJB|Utiliser client Test EJB. 

3 Si le client de test existe déjà, cochez l’option La classe client test EJB 

existe déjà. 

Si cette option n’est pas cochée, lorsque vous cliquez sur Suivant, 

l’expert Client Test EJB démarre. Lorsque vous êtes prêt, l’expert 

Utilisation d’un client Test EJB reprend son déroulement. 


5 Pour le champ Classe, naviguez jusqu’à la classe client de test que vous 

voulez utiliser. 

6 Dans le champ Champ, spécifiez un nom pour la variable qui 

contiendra l’instance de la classe client de test, ou acceptez la valeur par 

défaut proposée par l’expert. 



Test de votre enterprise bean 


L’expert ajoute à la classe une déclaration de l’application client de test 

spécifiée, par exemple : 

EmployeeTestClient1 employeeTestClient1 = new EmployeeTestClient1(); 

Vous voilà prêt à appeler les méthodes déclarées dans l’application client 

de test. 

Lorsque vous avez créé l’application client de test, vous êtes prêt à 

démarrer le conteneur et à exécuter l’application client. Créez deux 

configurations d’exécution : Serveur et Client. 

Pour créer une configuration Serveur, 

1 Choisissez Exécuter|Configurations. 



2 Cliquez sur le bouton Nouveau, puis sur l’onglet EJB. 

3 Entrez Serveur dans le champ Nom de configuration. 

4 Remplissez les Paramètres du Serveur d’applications et le Nom 

d’instance du Serveur d’applications nécessaires pour exécuter le 

serveur. Si vous avez sélectionné un serveur d’applications cible, 

comme décrit dans “Sélection d’un serveur d’applications”, page 2-4, 

des valeurs par défaut remplissent déjà Paramètres du Serveur 

d’applications et Nom d’instance du Serveur d’applications. Si vous 

n’avez pas sélectionné de serveur d’applications cible, le serveur 

d’applications sélectionné par défaut sera BAS 4.5. 

5 Sélectionnez dans la liste des JAR EJB le fichier JAR contenant les beans 

que vous voulez tester. S’il n’en existe qu’un, il est déjà sélectionné. Les 

fichiers JAR de cette liste ont été extraits des groupes EJB du projet. 

La liste des JAR EJB est désactivée pour WebSphere 3.5 car ce serveur 

d’applications ne prend pas en charge le déploiement sur un serveur en 

train de s’exécuter. 

Pour WebLogic Server 6.0, le ou les fichiers JAR sont copiés dans le 

répertoire \config\\applications. 

6 Cliquez sur OK. 

Pour créer une configuration Client, 

1 Choisissez Exécuter|Configurations. 

2 Cliquez sur le bouton Nouveau, puis sur l’onglet Application. 


3 Entrez Client dans le champ Nom de configuration. 


4 Cliquez sur le bouton ... situé à côté du champ Classe principale et 

naviguez jusqu’à l’application client de test que vous avez créée, ou 

jusqu’à l’application contenant la fonction main() appelant les méthodes 

du client de test. 

5 Cliquez deux fois sur OK. 

Vous voilà prêt à démarrer le conteneur. Sélectionnez la configuration 

d’exécution Serveur dans la liste déroulante du bouton Exécuter de la 

barre d’outils de JBuilder : 

Le conteneur démarre. Soyez patient car le processus de démarrage est 

relativement long. Vous pouvez suivre sa progression dans la fenêtre 

message. Toute erreur qui se produit apparaît également ici. 

Sélectionnez ensuite la configuration d’exécution Client pour exécuter 

votre application client. Les messages apparaissant dans le volet des 

messages signalent le succès ou l’échec de l’exécution de l’application 

client. 

Une autre façon de tester votre bean consiste simplement à cliquer avec le 

bouton droit sur son groupe EJB dans le volet projet et à choisir Exécuter. 

Vous pouvez déboguer avec JBuilder vos enterprise beans ou le client 

exactement comme vous le feriez pour tout autre code Java. Pour plus 

d’informations sur le débogage, voir “Débogage des programmes Java” 

dans Construction d’applications avec JBuilder. 



Chapitre 

6 

Chapitre6Déploiement 

des enterprise beans 

Le déploiement d’un enterprise bean sur un serveur d’applications se 

compose généralement des étapes suivantes : 

1 Création d’un fichier descripteur de déploiement basé sur XML et 

conforme à la spécification EJB 1.1 de Sun. (WebSphere 3.5 fait 

exception. Il est conforme aux spécifications EJB 1.0 et il ne prend pas 

en charge les descripteurs de déploiement basés sur XML.) 

Quand vous utilisez les experts EJB de JBuilder pour créer vos beans, 

les descripteurs de déploiement sont créés pour vous en même temps. 

2 Modification des descripteurs de déploiement, si nécessaire. 

Vous pouvez modifier les descripteurs de déploiement créés par 

JBuilder en utilisant l’éditeur de descripteur de déploiement de 

JBuilder. 

3 Création d’un fichier JAR EJB contenant le descripteur de déploiement 

et toutes les classes requises pour que l’EJB fonctionne (classe bean, 

interface distante, interface locale, stubs et squelettes, classe clé 

primaire si l’EJB est un bean entité et toute autre classe associée). 

Quand vous compilez votre groupe EJB en utilisant l’environnement de 

développement de JBuilder, le fichier JAR correspondant est créé pour 

vous. 

4 Déploiement de votre EJB dans un conteneur EJB. 

JBuilder offre un expert Déploiement EJB qui simplifie le processus de 

déploiement des enterprise beans de Borland. Si votre serveur 

d’applications cible est WebLogic ou WebSphere, choisir Outils| 

Déploiement EJB affiche une boîte de dialogue de paramètres de 

D é ploiement des enterprise beans 6-1

Cré ation d’ un fichier descripteur de dé ploiement 

déploiement spécifiques à votre serveur. Lorsque vous avez rempli les 

paramètres pour répondre à vos besoins et choisi OK pour fermer la 

boîte de dialogue, l’EJB est déployé comme vous l’avez spécifié. 

Création d’un fichier descripteur de déploiement 

Au fur et à mesure que vous créez vos enterprise beans en utilisant les 

outils EJB de JBuilder, ce dernier crée en même temps les descripteurs de 

déploiement. Vous pouvez ensuite utiliser l’éditeur de descripteur de 

déploiement pour ajouter des informations supplémentaires et modifier 

les attributs des descripteurs de déploiement. 

Chaque descripteur de déploiement conforme à la spécification EJB 1.1 

(cela exclut ceux qui sont utilisés par WebSphere 3.5) : 

• Doit être basé sur XML et conforme aux règles XML. 

• Doit respecter la norme DTD de la spécification EJB 1.1. 

• Se conformer aux règles sémantiques spécifiées dans la DTD. 

• Se référer à la DTD à l’aide de l’instruction suivante : 

 

Quand vous utilisez les outils EJB de JBuilder pour créer et modifier vos 

descripteurs de déploiement, vous n’avez pas à vous préoccuper 

d’apprendre XML ou de vous conformer aux règles sémantiques 

spécifiées dans la DTD de Sun. L’éditeur de descripteur de déploiement 

impose ces règles aux données que vous entrez et modifiez. Au fur et à 

mesure que vous remplissez les informations dans l’éditeur de 

descripteur de déploiement, il vous permet de savoir quelles données sont 

requises. Les outils de JBuilder configurent automatiquement les 

extensions spécifiques à Borland dans un fichier ejb-inprise.xml. Pour plus 

d’informations sur l’éditeur de descripteur de déploiement, voir 

Chapitre 7, “Utilisation de l’éditeur de descripteur de déploiement”. 

Le rôle du descripteur de déploiement 

Le rôle du descripteur de déploiement est de fournir des informations sur 

chaque EJB à rassembler et à déployer dans un fichier JAR particulier. Il 

est destiné à être utilisé par l’utilisateur du fichier JAR de l’EJB. C’est à 

vous, développeur du bean, de créer le descripteur de déploiement. Vous 

pouvez aussi modifier le descripteur de déploiement une fois que 

l’enterprise bean a été déployé. 

Les informations contenues dans le descripteur de déploiement sont 

utilisées pour définir les attributs des enterprise beans. Ces attributs 


Le rô le du descripteur de dé ploiement 

déterminent comment va fonctionner l’enterprise bean dans un 

environnement particulier. Par exemple, quand vous définissez les 

attributs transactionnels d’un bean, ils déterminent le comportement du 

bean lorsqu’il est impliqué dans une transaction. Le descripteur de 

déploiement mémorise les informations suivantes : 

• Des informations sur les types, qui définissent les types, ou noms, des 

classes des interfaces locales et distantes et de la classe du bean. 

• Des noms JNDI, qui définissent le nom sous lequel l’interface locale de 

l’enterprise bean sera enregistrée. 

• Des champs pour permettre la persistance gérée par le conteneur. 

• Des règles transactionnelles qui gouvernent le comportement 

transactionnel d’un bean. 

• Des attributs de sécurité qui gouvernent l’accès à un enterprise bean. 

• Des informations spécifiques à Borland, comme les informations sur les 

sources de données utilisées pour les connexions aux bases de données. 

Les types d’informations du descripteur de déploiement 

Les informations contenues dans le descripteur de déploiement peuvent 

être divisées en deux types de base : 

• Des informations structurelles sur les enterprise beans. 

Les informations structurelles décrivent la structure d’un enterprise 

bean et déclarent les dépendances externes de l’enterprise bean. Ces 

informations sont obligatoires. Les informations structurelles ne 

doivent généralement pas être modifiées car cela risque de détruire la 

fonctionnalité du bean. 

• Des informations sur l’assemblage de l’application. 

Les informations sur l’assemblage de l’application décrivent comment 

le ou les enterprise beans inclus dans le fichier ejb-jar.xml sont 

composés dans l’unité de déploiement d’une application plus grande. 

Cette information est facultative. Les informations au niveau de 

l’assemblage peuvent être modifiées sans risque de détruire la 

fonctionnalité du bean, bien que cela puisse altérer le comportement de 

l’application assemblée. 



Informations structurelles 

Le développeur du bean doit fournir les informations structurelles 

suivantes pour chaque bean du jar EJB : 

Tous les enterprise beans 

• Nom de l’enterprise bean, mnémonique utilisé pour faire référence au 

bean dans le descripteur de déploiement. 

• Classe de l’enterprise bean 

• Interface locale de l’enterprise bean 

• Interface distante de l’enterprise bean 

• Type de l’enterprise bean, bean session ou bean entité 

• Entrées d’environnement, si le bean a des paramètres de configuration 

• Références à la factory des ressources 

• Références aux EJB, si un enterprise bean fait référence à d’autres 

enterprise beans 

• Références aux rôles de sécurité, si un enterprise bean a besoin 

d’accéder à des rôles spécifiques 

Beans session 

• Type de gestion de l’état du bean session, stateful ou stateless 

• Type de transaction du bean session pour les beans stateful ayant des 

callbacks de synchronisation 

Beans entité 

• Type de gestion de la persistance du bean entité 

• Classe de la clé primaire du bean entité 

• Champs gérés par le conteneur pour les beans gérés par le conteneur 

Informations sur l’assemblage de l’application 

Vous pouvez spécifier n’importe lesquelles des informations suivantes sur 

l’assemblage de l’application. Pendant l’assemblage de l’application, ces 

informations sont facultatives. Ces mêmes informations ne sont pas 

facultatives pour le rôle du déployeur. 

• Liaison des références aux enterprise beans 

• Rôles de sécurité 

• Permissions de méthodes 

• Liaison aux références des rôles de sécurité 

• Attributs des transactions 



Durant le processus d’assemblage ou de déploiement d’une application, 

vous pouvez modifier les informations structurelles suivantes : 

• Les valeurs des entrées d’environnement. L’assembleur de l’application 

peut changer des propriétés existantes et/ou définir des propriétés 

environnementales. 

• Champs de description. L’assembleur de l’application peut changer des 

descriptions existantes ou en définir de nouvelles. 

Vous ne devez modifier aucun autre type d’informations structurelles. 

Cependant, vous pouvez modifier n’importe quelles informations sur 

l’assemblage de l’application au moment du déploiement. 

Sécurité 

L’assembleur de l’application spécifie généralement les informations 

suivantes dans le descripteur de déploiement : 

• Rôles de sécurité 

• Permissions de méthodes 

• Liens entre les références aux rôles de sécurité et les rôles de sécurité 

Rôles de sécurité 

En utilisant les éléments de rôles de sécurité dans le descripteur de 

déploiement, le développeur peut définir un ou plusieurs rôles de 

sécurité. Ils définissent les rôles de sécurité requis pour les clients des 

enterprise beans. 

Permissions de méthodes 

En utilisant les éléments de permissions de méthodes dans le descripteur 

de déploiement, le développeur peut définir une ou plusieurs permissions 

de méthodes. Les permissions de méthodes sont des relations à deux entre 

les rôles de sécurité et les méthodes des interfaces locale et distante de 


Liaison aux références des rôles de sécurité 

Si des rôles de sécurité ont été définis, le développeur doit les lier aux 

références aux rôles de sécurité en utilisant l’élément rôle-lien dans le 

descripteur de déploiement. 

Si votre serveur d’applications cible est Borland AppServer, vous aurez un 

descripteur de déploiement supplémentaire pour votre enterprise bean, 

ejb-inprise.xml. Pour connaître les informations spécifiques à Borland sur 

les descripteurs de déploiement, voir le chapitre “Déploiement des 

Enterprise JavaBeans” dans le Enterprise JavaBeans Programmer’s Guide de 

Borland AppServer. 


D é ploiement sur un serveur d’ applications 

Déploiement sur un serveur d’applications 

Lorsque votre bean fonctionne à votre convenance et si vous avez choisi 

Borland AppServer comme serveur d’applications pour le projet en cours, 

vous pouvez déployer votre bean sur Borland AppServer en utilisant 

l’expert Déploiement EJB de JBuilder. Si votre serveur d’applications cible 

est WebLogic Server ou WebSphere Application Server, choisir Outils| 

Déploiement EJB affiche une boîte de dialogue sur les paramètres 

permettant le déploiement sur ces serveurs. 

Les étapes décrites ci-dessous supposent que vous déployez pour le 

conteneur Borland. Démarrez le serveur d’applications et utilisez l’expert 

Déploiement EJB. 

Déploiement d’un ou de plusieurs fichiers JAR 

Pour déployer un ou plusieurs fichiers JAR sur Borland Application 

Server, 

1 Choisissez Outils|Déploiement EJB pour afficher l’expert Déploiement 

EJB. 

Les fichiers JAR du projet en cours apparaissent. 

2 Spécifiez le ou les fichiers JAR contenant les beans que vous voulez 

déployer. 

Si vous voulez déployer des fichiers JAR supplémentaires, cliquez sur 

le bouton Add et spécifiez les fichiers JAR que vous voulez ajouter. 

Pour retirer un fichier JAR de la liste, sélectionnez-le et cliquez sur 

Remove. Au cours de cette étape, vous avez également accès à l’outil 

d’archive de BAS 4.5 et à l’éditeur de descripteur de déploiement. 


3 Cliquez sur Next pour aller à l’étape suivante. 


4 Spécifiez le chemin des classes des bibliothèques dont dépendent vos 

enterprise beans, les options de génération des stubs et les options de 

vérification. Cliquez sur Next. 

L’expert analyse le ou les fichiers JAR et rend compte du résultat. 



5 Cliquez sur Next s’il n’y a pas d’erreur signalée ; sinon, corrigez-les et 

recommencez. 

6 Utilisez cette page pour sélectionner le conteneur dans lequel vous 

voulez déployer votre EJB. 

Dans cet exemple, l’utilisateur a cliqué sur le bouton Add EJB 

Container pour sélectionner un conteneur : 



Cliquez sur Next lorsque vous avez spécifié un conteneur. 

L’expert tente de déployer l’EJB et rend compte du résultat. 

7 Cliquez sur Finish pour fermer l’expert. 

Déploiement sur les serveurs WebLogic ou WebSphere 

Les développeurs pour WebLogic et WebSphere peuvent aussi déployer 

leurs EJB avec la commande Outils|Déploiement EJB. Si WebLogic ou 

WebSphere est le serveur d’applications sélectionné pour le projet en 

cours, cette commande affiche une boîte de dialogue de paramètres de 

déploiement spécifiques à ce serveur. Par exemple, voici la boîte de 

dialogue de paramètres de déploiement pour WebSphere : 

Remplissez les champs dont vous avez besoin et choisissez OK. Pour plus 

d’informations, cliquez sur le bouton Help dans la boîte de dialogue des 

paramètres de déploiement. 



Définition des options de déploiement avec la boîte de 

dialogue Propriétés 

Bien que vous puissiez utiliser Outils|Déploiement EJB pour définir les 

options de déploiement sur le serveur d’applications en cours pour le 

projet, vous pouvez aussi utiliser la boîte de dialogue Propriétés. Ces 

propriétés sont enregistrées pour le nœud particulier pour lequel elles ont 

été définies. 

Pour définir les options de déploiement en utilisant la boîte de dialogue 

Propriétés, 

1 Cliquez avec le bouton droit sur le nœud du groupe EJB, ou sur un JAR 

enfant de ce nœud, pour afficher le menu contextuel. 

2 Choisissez Propriétés pour afficher la boîte de dialogue Propriétés. Si 

vous avez cliqué avec le bouton droit sur le nœud du groupe EJB, vous 

devez alors cliquer sur l’onglet Déploiement de la boîte de dialogue 

Propriétés et ensuite sur la page spécifique à votre serveur 

d’applications (par exemple, BAS 4.5). 

3 Définissez vos options. Pour BAS 4.5, vous ne définirez que les 

paramètres de la VM. Pour IAS 4.1, vous pouvez définir un nom d’hôte 

et des paramètres VM. Les utilisateurs de WebLogic peuvent définir un 

nom d’unité, des options de déploiement, un mot de passe et les 

paramètres de la VM. Les utilisateurs de WebSphere peuvent définir le 

nom du nœud primaire, le nom du serveur d’applications, le nom du 

conteneur, les paramètres VM et une option pour générer XML. Si 

plusieurs nœuds sont sélectionnés, chacun ayant des options de 

déploiement différentes, les valeurs par défaut sont utilisées. 

4 Si votre serveur d’applications cible est WebSphere et si vous voulez 

qu’un fichier XML soit généré comme entrée de l’utilitaire XMLConfig 

WebSphere, cochez la case Générer XML. Si cette option n’est pas 

cochée, le fichier ne sera pas créé. Si vous apportez vos propres 

modifications au fichier XML généré (nommé 

deploy_.xml et apparaissant sous le nœud projet), 

désélectionnez cette option pour être certain de ne pas perdre vos 

modifications. 



Déploiement dynamique sur un serveur d’applications 

Pendant le cycle du développement, il vous sera probablement nécessaire 

de déployer, redéployer et dé-déployer rapidement vos enterprise beans 

sur un conteneur déjà en train de s’exécuter. Dans le volet projet, cliquez 

avec le bouton droit sur le nœud du groupe EJB, ou sur un de ses nœuds 

enfant, pour voir la liste des options de déploiement : 

• Déployer – Déploie un JAR sur le conteneur en train de s’exécuter sur le 

serveur d’applications du projet. 

• Redéployer – Redéploie un JAR sur le conteneur en train de s’exécuter. 

• Annuler le déploiement – Annule le déploiement d’un JAR déjà 

déployé sur le conteneur en train de s’exécuter. 

• Lister les déploiements – Liste tous les JAR déployés sur le conteneur 

en train de s’exécuter. 

• Arrêter le conteneur – Arrête le conteneur. Cette option n’apparaît que 

pour WebSphere. Lorsqu’un EJB déployé change, le conteneur doit être 

arrêté puis redémarré pour que les modifications soient enregistrées. 

• Démarrer le conteneur – Démarre le conteneur. Cette option n’apparaît 

que pour WebSphere. 



Chapitre 

7 

Chapitre7Utilisation de l’éditeur 

de descripteur de déploiement 

JBuilder comprend un éditeur de descripteur de déploiement vous 

permettant de modifier les informations de déploiement Borland (comme 

les politiques de transactions ou les éléments de sécurité) dans un fichier 

descripteur de déploiement d’un EJB. Vous pouvez également modifier la 

façon d’assurer la persistance d’un enterprise bean. 

L’éditeur de descripteur de déploiement de JBuilder permet de modifier 

les descripteurs de déploiement Borland existants. Pour plus 

d’informations sur les descripteurs de déploiement, voir Chapitre 6, 

“Déploiement des enterprise beans”. 

Vous pouvez aussi voir et modifier certaines des propriétés spécifiques 

aux serveurs WebLogic et WebSphere. Pour plus d’informations, voir 

“Visualisation et modification des propriétés WebLogic et WebSphere”, 

page 7-27. 

Utilisation de l’éditeur de descripteur de dé ploiement 7-1

Affichage de l’éditeur de descripteur de dé ploiement 

Affichage de l’éditeur de descripteur de déploiement 

Pour afficher l’éditeur de descripteur de déploiement, double-cliquez sur 

le groupe EJB dans le volet projet. L’éditeur de descripteur de 

déploiement apparaît. 

Remarquez l’arborescence du groupe EJB qui apparaît dans le volet 

structure. 

Visualisation du descripteur de déploiement d’un enterprise bean 

Pour voir les informations concernant un enterprise bean dans l’éditeur de 

descripteur de déploiement, cliquez sur le bean dans le volet structure. Ou 

cliquez sur l’onglet Contents pour afficher le contenu du groupe EJB, et 

double-cliquez ensuite sur l’icône du bean que vous voulez voir. Si vous 


Visualisation du descripteur de dé ploiement d’ un enterprise bean 

faites cela, plusieurs onglets supplémentaires apparaissent dans l’éditeur 

de descripteur de déploiement : 

Vous pouvez cliquer sur ces onglets en bas de l’éditeur de descripteur de 

déploiement pour voir les autres pages. Utilisez l’éditeur pour apporter 

toutes les modifications souhaitées aux informations de déploiement du 

bean. 

Vous pouvez voir des informations supplémentaires sur un descripteur 

de déploiement en utilisant le volet structure : 

Développez le nœud de l’enterprise bean concerné dans le volet structure. 

Vous verrez certains des nœuds supplémentaires suivants (ou tous) : 

Home Interface, Remote Interface, Method Permissions et Container 

Transactions. Sélectionner un de ces nœuds affiche des informations 

supplémentaires sur le bean. Par exemple, sélectionner Home Interface 

affiche dans le volet contenu les icônes et les noms des méthodes de 

l’interface locale, sélectionner Remote Interface affiche les icônes et les 

noms des méthodes de l’interface distante. Vous pouvez aussi utiliser les 

nœuds Security Roles et Data Sources du volet structure pour afficher des 

informations sur les rôles de sécurité et les sources de données, et pour les 

modifier. 


Ajout des informations d’ un nouvel enterprise bean 

Pour voir le code source de chaque descripteur, cliquez sur l’onglet Source 

DD EJB. Pour chaque descripteur de déploiement du groupe EJB, un 

onglet apparaît portant le même nom que le fichier. Sélectionnez l’onglet 

du fichier que vous voulez voir. Pendant que vous visualisez le code 

source d’un descripteur de déploiement, vous pouvez cliquer sur les 

éléments du volet structure pour placer une barre de surbrillance sur 

l’élément correspondant dans le code source. Vous pouvez modifier le 

code source directement. 

Ajout des informations d’un nouvel enterprise bean 

Pour ajouter un enterprise bean au descripteur de déploiement en 

utilisant l’éditeur de descripteur de déploiement, 

1 Sélectionnez le nœud EJB Deployment Descriptor dans le volet 

structure. 

2 Sélectionnez le type de bean que vous voulez ajouter. 

• Pour ajouter un bean session, cliquez sur l’icône dans la barre 

d’outils de l’éditeur de descripteur de déploiement. 

• Pour ajouter un bean entité, cliquez sur l’icône dans la barre 

d’outils de l’éditeur de descripteur de déploiement. 

Une boîte de dialogue apparaît. 

3 Dans la boîte de dialogue, entrez le nom de l’enterprise bean à ajouter 

et choisissez OK. 

Le nouveau bean apparaît dans le volet structure. 


Modification des informations concernant le bean 

4 Sélectionnez le bean dans le volet structure. 

Une série de panneaux apparaissent dans le volet contenu pour 

l’enterprise bean sélectionné. Utilisez les onglets du bas pour afficher le 

panneau voulu et saisir les informations sur le nouveau bean. 

Modification des informations concernant le bean 

Pour modifier les informations d’un bean, sélectionnez celui-ci dans le 

volet structure. Une série de panneaux apparaissent dans le volet contenu 

pour l’enterprise bean sélectionné. Utilisez les onglets du bas pour afficher 

le panneau voulu et modifier les informations existant sur le bean. 

Si vous êtes un habitué d’XML et du code source des descripteurs de 

déploiement, vous pouvez sélectionner l’onglet Source DD EJB et effectuer 

vos modifications directement dans le code source. 

Informations sur les enterprise beans 

Cette section décrit le type d’information que vous pouvez créer et stocker 

pour les enterprise beans dans un descripteur de déploiement. 

Panneau Main 

Utilisez le panneau Main pour entrer ou modifier les informations 

générales sur l’enterprise bean. 

Voici le panneau Main pour un bean session : 



Voici le panneau Main pour un bean entité : 

Le panneau Main comprend les informations suivantes : 

• Description : Un résumé des objectifs et des fonctions du bean. Cette 

information est facultative. 

• Bean Name : Un nom logique assigné à l’enterprise bean par le 

fournisseur du bean. Chaque enterprise bean possède un nom logique. 

Il n’y a pas de relation structurelle entre le nom logique du bean et le 

nom JNDI qui lui est assigné. Le déployeur du bean peut changer le 

nom logique du bean. 

• Home Interface : Le nom complet de l’interface locale de l’enterprise 

bean. Cette information est obligatoire. 

• Remote Interface : Le nom complet de l’interface distante de 

l’enterprise bean. Cette information est obligatoire. 

• Bean Class : Le nom complet de la classe Java qui implémente les 

méthodes métier du bean. Cette information est obligatoire. 

• JNDI Name : Le nom JNDI de l’interface locale de l’enterprise bean. 

• Small icon : Le nom du fichier de l’icône 16 x 16 pixels utilisée pour 

représenter le bean. 

• Large icon : Le nom du fichier de l’icône 32 x 32 pixels utilisée pour 

représenter le bean. 

Pour les beans session, le panneau Main inclut en outre ce qui suit : 

• Session Type : Spécifie si l’enterprise bean est Stateless ou Stateful. 



• Transaction Type : Spécifie si les modes transactionnels sont définis 

par le bean ou par le conteneur. 

Pour les beans entité, le panneau Main inclut en outre ce qui suit : 

• Primary Key Class : Le nom complet de la classe de la clé primaire du 

bean entité. La classe de la clé primaire est obligatoire. 

• Reentrant : Indique si le bean est réentrant. Borland vous recommande 

d’éviter de rendre un bean réentrant. 

Panneau Environment 

Le panneau Environment est une liste des entrées d’environnement de 

l’enterprise bean. Les entrées d’environnement vous permettent de 

personnaliser la logique métier du bean lorsque le bean est assemblé ou 

déployé. L’environnement vous permet de personnaliser le bean sans 

accéder au code source du bean, ni le modifier. 

Chaque enterprise bean définit son propre jeu d’entrées d’environnement. 

Toutes les instances d’un enterprise bean partagent les mêmes entrées 

d’environnement. Les instances d’un enterprise bean ne peuvent pas 

modifier l’environnement du bean à l’exécution. 

Pour ajouter une entrée d’environnement, 

1 Cliquez sur Add pour créer une nouvelle entrée. 

Une nouvelle ligne vierge apparaît. 



2 Entrez une propriété dans la colonne Property et sa valeur dans la 

colonne Value. 

3 Choisissez le type de la propriété dans le menu Type. 

4 Ajoutez autant d’entrées que souhaité. 

Pour supprimer une ligne, 

1 Sélectionnez la ligne. 

2 Cliquez sur le bouton Remove. 

Pensez à ce qui suit lorsque vous travaillez sur les entrées 

d’environnement : 

• Le fournisseur du bean doit déclarer toutes les entrées 

d’environnement accédées dans le code de l’enterprise bean. 

• Si le fournisseur du bean a attribué une valeur à une entrée 

d’environnement, cette valeur peut être modifiée ensuite lors de 

l’assemblage ou du déploiement. 

• L’assembleur peut modifier les valeurs des entrées d’environnement 

définies par le fournisseur du bean. 

• Le déployeur doit s’assurer que les valeurs de toutes les entrées 

d’environnement sont pertinentes. 

Panneau EJB references 

Le panneau EJB References est une liste de toutes les références aux 

interfaces locales des autres enterprise beans que l’enterprise bean 

requiert. 



Chaque référence EJB décrit ce que l’enterprise bean référençant requiert 

comme interfaces pour le bean référencé. Vous pouvez définir des 

références entre des beans appartenant au même fichier JAR ou à partir 

d’un enterprise bean externe (se trouvant hors du fichier JAR), par 

exemple d’un bean session vers un bean entité. Chaque référence contient 

les champs suivants : 

• Description : Une brève description du bean référencé. Cette 


• Name : Le nom du bean référencé. 

• IsLink : Lorsque l’option IsLink est cochée, la référence porte sur un 

bean du fichier JAR, la valeur JNDI Name n’est donc pas appropriée. Si 

IsLink n’est pas cochée, le nom JNDI est utilisé pour trouver le bean. 

Lorsque vous cochez cette option, vous sélectionnez ensuite dans la 

liste déroulante Link le bean référencé. 

• Link : Lie la référence EJB à l’enterprise bean cible. La valeur Link est le 

nom du bean cible. Cette information est facultative. 

• Type : Le type attendu pour le bean référencé. 

• Home : Le type Java attendu pour l’interface locale du bean référencé. 

• Remote : Le type Java attendu pour l’interface distante du bean 

référencé. 

• JNDI Name : Le nom JNDI du bean référencé. 

Voici des points importants à considérer pour ce qui concerne les 

références EJB : 

• L’enterprise bean cible doit avoir un type compatible avec la référence 

EJB déclarée. 

• Toutes les références EJB déclarées doivent être liées aux interfaces 

locales des enterprise beans existant dans l’environnement 

d’exploitation. 

• Si une valeur Link est spécifiée, la référence à l’enterprise bean doit être 

liée à l’interface locale de l’enterprise bean cible. 

Panneau Security role references 

Le panneau Security role references est une liste de toutes les références 

de l’enterprise bean aux rôles de sécurité. Le panneau lie les références 

aux rôles de sécurité utilisées par le développeur du bean à des rôles de 



sécurité spécifiques définis par l’assembleur de l’application ou par le 

déployeur. 

Avant que vous ajoutiez une référence à un rôle de sécurité, un ou 

plusieurs rôles de sécurité doivent avoir été définis ; sinon, le bouton Add 

n’est pas accessible dans le panneau. Pour plus d’informations sur la 

création et l’assignation des rôles de sécurité pour le déploiement d’une 

application, voir “Ajout des rôles de sécurité et des méthodes autorisées”, 

page 7-25. 

Pour ajouter un rôle, cliquez sur le bouton Add et remplissez les trois 

champs suivants : 

• Description : C’est un champ facultatif décrivant le rôle de sécurité. 

• Role : C’est le nom du rôle de sécurité spécifié par le développeur du 

bean. 

• Link : C’est le nom du rôle de sécurité utilisé lorsque l’application est 

déployée. Habituellement, ce rôle est défini par l’assembleur de 

l’application ou par le déployeur pour que celle-ci fonctionne dans un 

environnement d’exploitation particulier. 

Panneau Resource references 

Le panneau Resource references est une liste de toutes les références aux 

factories de ressources des enterprise beans. Il permet à l’assembleur de 

l’application et/ou au déployeur du bean de localiser toutes les références 



utilisées par l’enterprise bean. Chaque bean entité dont la persistance est 

gérée par le conteneur doit faire référence à une ressource. 

Pour ajouter une référence à une ressource, cliquez sur le bouton Add et 

remplissez les champs suivants : 

• Description : Une description de la référence ressource. Cette 


• Name : Le nom de l’entrée d’environnement utilisé dans le code de 


• Type : Le type Java de la factory de la ressource attendu par le code de 

l’enterprise bean. (C’est le type Java de la factory de la ressource, et non 

celui de la ressource.) 

• Authentification : Une authentification Application indique que 

l’enterprise bean effectue par programme la connexion à la ressource. 

Une authentification Container indique que le conteneur se connecte à 

la ressource en fonction des informations de mappage fournies par le 

déployeur. 

• JNDI Name : Un nom JNDI pour la référence ressource. 

• CMP (container-managed persistence) : Si vous faites gérer la 

persistance du bean par le conteneur, vous devez avoir une (et une 

seule) référence ressource dont le champ CMP est coché. 



Panneau Persistence 

Le panneau Persistence apparaît uniquement pour les beans entité. Il 

indique comment est gérée la persistance de l’enterprise bean. Les 

informations affichées dans ce panneau varient selon que la persistance 

est gérée par le bean ou par le conteneur. 

Le panneau Persistence comprend les champs suivants : 

• Persistence Type : Indique si la persistance est gérée par le bean 

lui-même ou par le conteneur. 

• Primary Key Class : Le nom complet de la classe de la clé primaire du 

bean entité. Cette information est obligatoire. 

• Bouton Get Meta Data : Cliquer sur ce bouton lit les métadonnées pour 

la table et remplit la liste déroulante associée à chacune des cellules 

Column Name(s). Chaque élément de la liste déroulante est un couple 

nom de colonne/type de colonne. Faire une sélection dans la liste 

déroulante remplit à la fois la cellule du nom de colonne et la cellule du 

type de colonne. La liste déroulante ne contient que les noms de 

colonne ayant déjà été utilisés dans le panneau. 

Pour les beans dont la persistance est gérée par le conteneur, les 

informations supplémentaires suivantes sont incluses pour vous 

permettre d’établir la correspondance entre les champs du bean et les 

colonnes d’une table de base de données : 

• Table(s) : Le nom de la ou des tables de la base référencées par le bean. 



• CMP : Une marque de sélection indique que le champ est géré par le 

conteneur. 

• isPK : Une marque de sélection indique que le champ est la clé 

primaire. 

• Field Type : Le type de données du champ. 

• Field Name : Le nom du champ. La colonne Field Name présente la 

liste de tous les champs du bean entité. 

• Column Name : Vous pouvez faire correspondre des champs 

composés du bean (par exemple, adresse.rue) aux colonnes de la table 

de la base de données. Vous pouvez mapper soit le champ racine (par 

exemple, adresse), soit les sous-champs (par exemple, adresse.rue), 

mais pas les deux. 

• Column Type : Le type de données du champ. 

• EJB Reference : Si le type de champ est une classe EJB, un menu 

apparaît et présente la liste des références EJB à sélectionner. Ces 

références sont définies dans le panneau EJB references. 

Pour définir un bean entité dont la persistance est gérée par le conteneur, 

sélectionnez Container comme Persistence Type. Si vous avez utilisé le 

Modeleur Bean entité EJB pour générer le bean, Container est déjà 

sélectionné. Le panneau affiche le nom de la classe clé primaire qui n’est 

pas modifiable. Dans le champ CMP Description, vous pouvez entrer du 

texte décrivant le bean. 

Pour chaque champ de votre bean entité dont la persistance sera gérée par 

le conteneur, le champ CMP est coché. Pour chaque champ, entrez le nom 

de la colonne à laquelle il correspond. Si vous avez utilisé le Modeleur 

Bean entité EJB, JBuilder a établi ces correspondances à votre place. 

Modifiez Column Name et Column Type si vous le voulez. Vous pouvez 

entrer dans le champ Description un texte décrivant chaque champ, mais 

cela n’est pas obligatoire. 

L’éditeur de descripteur de déploiement utilise JDBC pour obtenir les 

métadonnées des tables existantes. Vous pouvez lier facilement les beans 

entité existants aux tables existantes. Par exemple, vous pourriez avoir 

acquis un enterprise bean tiers et souhaiter l’utiliser avec une table de 

votre base de données. Pour remplir les champs Column Name et Column 

Type, cliquez sur le bouton Get Meta Data, les métadonnées seront 

trouvées et affichées. 



Panneau Finders 

Le panneau Finders spécifie les clauses “where” utilisées pour un bean 

géré par le conteneur afin d’exécuter les méthodes find (de recherche) 

définies par ce bean. 

Vous trouverez les informations suivantes dans le panneau Finders : 

• Method : Le nom de la méthode find et la liste de tous ses paramètres. 

• Where Clause : Spécifie la clause SQL “where” utilisée par le conteneur 

pour extraire les enregistrement de la base de données. Notez que les 

instructions SQL ne peuvent pas toutes être converties dans la logique 

de requête WebLogic. 

• Load State : Lorsqu’il est sélectionné, cet attribut permet au conteneur 

de pré-charger tous les champs gérés par le conteneur chaque fois 

qu’une opération de recherche est effectuée. 

Pour spécifier une méthode find, 

1 Cliquez sur le bouton Add. 

Une boîte de dialogue Finder apparaît. 

2 Sélectionnez la signature pour la méthode find souhaitée dans la liste 

déroulante. 

3 Modifiez éventuellement les noms des arguments et spécifiez la clause 

Where de l’opération de recherche. 



Voici un exemple : 

Panneau Properties 

Le panneau Properties contient des informations qui varient en fonction 

du contexte. Lorsque vous sélectionnez un enterprise bean dans le volet 

structure, le panneau Properties suivant apparaît: 

Pour ajouter une propriété à l’enterprise bean sélectionné dans le volet 

structure, 

1 Cliquez sur le bouton Add pour ajouter une ligne au panneau. 

2 Dans la liste déroulante Name, sélectionnez la propriété à ajouter. 



3 Spécifiez une valeur dans le champ Value. 

Vous spécifierez certaines valeurs en les sélectionnant dans une liste 

déroulante, d’autres en saisissant la valeur appropriée, chaîne ou entier 

par exemple ; les valeurs booléennes seront représentées par une case à 

cocher — cocher la case indique que la valeur est true. Voici la liste des 

valeurs possibles et leur description : 

ejb.cmp.primaryKeyGenerator 

Spécifie une classe, écrite par l’utilisateur, qui implémente l’interface 

com.inprise.ejb.cmp.PrimaryKeyGenerator et génère les clés primaires. 

Pour plus d’informations sur la génération des clés primaires, voir 

l’exemple /Borland/AppServer/examples/ejb/pkgen. 

ejb.cmp.getPrimaryKeyBeforeInsertSql 

Spécifie le SQL exécuté par le moteur CMP pour générer une clé 

primaire lorsqu’a lieu le prochain INSERT. Le moteur CMP met à jour 

le bean entité avec la valeur de la clé primaire. Cette propriété est 

habituellement utilisée en conjonction avec les séquences Oracle. Pour 

plus d’informations sur la génération des clés primaires, voir l’exemple 

/Borland/AppServer/examples/ejb/pkgen. 

ejb.cmp.getPrimaryKeyAfterInsertSql 

Spécifie le SQL exécuté par le moteur CMP pour générer une clé 

primaire après le prochain INSERT. Le moteur CMP met à jour le bean 

entité avec la valeur de la clé primaire. Lorsque vous spécifiez cette 

propriété, vous devez également spécifier la propriété 

ejb.cmp.ignoreColumnsOnInsert. Pour plus d’informations sur la 

génération des clés primaires, voir l’exemple /Borland/AppServer/ 

examples/ejb/pkgen. 

ejb.cmp.ignoreColumnsOnInsert 

Spécifie le nom de la colonne que le CMP ne doit pas définir au cours 

de l’INSERT. Cette propriété est utilisée en conjonction avec la 

propriété ejb.cmp.getPrimaryKeyAfterInsertSql. Pour plus d’informations 

sur la génération des clés primaires, voir l’exemple /Borland/AppServer/ 

examples/ejb/pkgen. 

ejb.cmp.checkExistenceBeforeCreate 

Supprime la vérification d’existence qui a lieu avant la création d’un 

nouveau bean entité. La spécification EJB 1.1 exige que le conteneur 

vérifie d’abord l’existence d’un bean entité (c’est-à-dire, vérifie 

l’existence d’une ligne de la table) et déclenche une 

javax.ejb.DuplicateKeyException si une telle entité est trouvée. Pour 

améliorer les performances, vous pouvez souhaiter éliminer cet accès 



supplémentaire à la base de données et compter sur la base de données 

pour empêcher l’insertion des valeurs dupliquées. 

ejb.cmp.jdbcAccesserFactory 

Spécifie une factory pour une instance implémentée par l’utilisateur de 

l’interface com.inprise.ejb.cmp.JdbcAccessor. Cette interface vous donne 

la moyen d’écrire du code spécifique pour lire une valeur dans un 

java.sqlResultSet ou pour écrire une valeur dans un 

java.sql.PreparedStatement. La valeur par défaut est none. 

ejb.cmp.manager 

Spécifie le nom de la classe implémentant l’interface 

com.inprise.ejb.cmp.Manager. Une instance de cette classe est utilisée 

pour assurer la persistance gérée par le conteneur (CMP). 

ejb.maxBeansInPool 

Spécifie le nombre maximal de beans présents dans le pool des beans 

prêts. Si le pool des beans prêts dépasse cette limite, des entités seront 

supprimées du conteneur par l’appel de unsetEntityContext(). La valeur 

par défaut est 1000. 

ejb.maxBeansInCache 

Spécifie le nombre maximal de beans présents dans le cache Option A 

(voir ci-dessous ejb.transactionCommitMode). Si le cache dépasse cette 

limite, des entités seront déplacées dans le pool des beans prêts par 

l’appel de ejbPassivate(). La valeur par défaut est 1000. 

ejb.transactionCommitMode 

Indique la disposition d’un bean entité par rapport à une transaction. 

Les valeurs sont : 

• A ou Exclusif — Cette entité a un accès exclusif à une table 

particulière de la base de données. Ainsi, l’état du bean à la fin de la 

dernière transaction validée est supposé être l’état du bean au début 

de la prochaine transaction. Les beans sont mis en cache entre les 

transactions. 

• B ou Partagé — Cette entité partage l’accès à une table particulière 

de la base de données. Mais, pour des questions de performances, un 

bean particulier reste associé à une clé primaire particulière entre les 

transactions afin d’éviter les appels externes à ejbActivate() et à 

ejbPassivate() entre les transactions. Le bean reste dans le pool actif. 

Il s’agit du mode de fonctionnement par défaut. 

• C ou Aucun — Cette entité partage l’accès à une table particulière de 

la base de données. Un bean particulier ne reste pas associé à une clé 

primaire particulière entre les transactions, mais retourne au pool 



des beans prêts après chaque transaction. Ce n’est généralement pas 

utile. 

ejb.cmp.optimisticConcurrencyBehavior 

Vous pouvez spécifier l’une des options suivantes : 

• UpdateAllFields 

• UpdateModifiedFields 

• VerifyModifiedFields 

• VerifyAllFields 

• UpdateAllFields — Effectue la mise à jour de tous les champs, qu’ils 

aient été modifiés ou non. Soit un bean CMP (persistance gérée par le 

conteneur) comportant trois champs : “key”, “value1” et “value2” 

stockés dans une table appelée “MyTable”, la mise à jour ci-dessous 

sera effectuée à la fin de chaque transaction que le bean ait été 

modifié ou pas : 

UPDATE MyTable SET (value1 = , value2 = ) 

WHERE key = 

• UpdateModifiedFields — Il s’agit du mode de fonctionnement par 

défaut. Effectue uniquement la mise à jour des champs qui ont été 

modifiés, ou empêche la mise à jour si le bean n’a pas été modifié. 

Avec le bean précédent, si seule “value1” a été modifiée, la mise à 

jour suivante est effectuée: 

UPDATE MyTable SET (value1 = ) 

WHERE key = 

Cela peut entraîner une amélioration significative des performances 

pour les raisons suivantes : 

1 Très souvent, l’accès aux données s’effectue en lecture seulement. 

Dans ces cas-là, il est souhaitable de ne pas envoyer de mise à jour 

à la base de données. Borland a constaté une grande amélioration 

des performances à la suite de cette seule optimisation. 

2 De nombreuses bases de données écrivent des historiques en 

fonction du type des colonnes modifiées. Par exemple, SQL Server 

consignera la mise à jour si un champ TEXT ou IMAGE est mis à 

jour, que la valeur de la colonne ait réellement changé ou non. 

Notez que, souvent, la base de données ne sait (ou ne peut) pas 

distinguer la mise à jour d’une colonne par la valeur qu’elle 

contenait déjà (ce qui se produit avec “UpdateAllFields”) d’une 

véritable modification de la valeur de la colonne. Supprimer la 

mise à jour lorsque la valeur n’est pas vraiment modifiée, peut 

avoir un impact considérable sur les performances si vous utilisez 

un SGBD de ce type. 

3 Il y a moins de trafic vers la base de données sur le réseau et 

moins de travail pour le pilote JDBC. Les difficultés liées au 



réseau ne sont généralement pas significatives mais celles 

concernant le pilote JDBC le sont. Nos mesures de performance 

indiquent que 70 % du temps CPU est dévolu au pilote JDBC dans 

les applications EJB à grande échelle. Souvent, cela provient du 

fait que de nombreux pilotes JDBC du commerce ne sont pas 

suffisamment bien réglés vis à vis des performances. Et même 

pour les pilotes bien réglés, moins ils ont de travail, mieux c’est. 

• VerifyModifiedFields — Dans ce mode, le moteur CMP effectue une 

mise à jour adaptée en vérifiant que les champs qu’il met à jour sont 

cohérents par rapport aux valeurs qu’ils contenaient au préalable. 

Ainsi, dans l’exemple précédent où seule “value1” a été modifiée, la 

mise à jour suivante est effectuée: 


WHERE key = AND value1 = 

• VerifyAllFields — Ce mode est semblable à VerifyModifiedFields, 

mais tous les champs sont vérifiés. La mise à jour serait donc : 


WHERE key = AND value1 = AND value2 = 

Ces deux vérifications peuvent être utilisées pour répliquer le niveau 

d’isolation SERIALIZABLE dans le conteneur. Souvent vos 

applications exigeront l’isolation SERIALIZABLE. Mais, demander à la 

base de données d’implémenter cela pour vous risque de coûter trop 

cher en performance. Nos tests montrent qu’utiliser SERIALIZABLE 

avec Oracle, plutôt qu’un niveau d’isolation moins restrictif, peut 

ralentir une application de plus de 50 %. La raison principale de ce 

ralentissement est qu’Oracle assure un accès concurrentiel de type 

optimiste utilisant un modèle de verrouillage de niveau ligne. Avec les 

deux définitions précédentes, vous demandez pratiquement au moteur 

CMP d’implémenter un accès concurrentiel optimiste utilisant un 

verrouillage de niveau champ. Et, comme dans tout système de 

concurrence, l’accès simultané est d’autant meilleur que la granularité 

du verrouillage est plus fine. 

ejb.findByPrimaryKeyBehavior 

Indique le comportement souhaité pour la méthode 

findByPrimaryKey(). Les valeurs sont : 

• Verify — Le comportement standard pour findByPrimaryKey() est de 

vérifier que la clé primaire spécifiée existe dans la base de données. 

• Load — Ce comportement provoque la chargement de l’état du bean 

dans le conteneur lorsque findByPrimaryKey() est invoquée, si l’appel 

de la méthode find s’exécute au sein d’une transaction active. On 

part de l’hypothèse que les objets seront généralement trouvés, et il 

est optimal de charger l’état d’un objet au moment où on le trouve. Il 

s’agit du mode de fonctionnement par défaut. 


Transactions conteneur 

• None — Ce comportement indique que findByPrimaryKey() doit être 

sans effet. Cela entraîne que la vérification du bean sera différée 

jusqu’à ce que l’objet soit réellement utilisé. Comme un objet peut 

toujours être supprimé entre l’appel de la méthode find et son 

utilisation réelle, dans la majorité des programmes, cette 

optimisation ne changera rien à la logique client. 

Transactions conteneur 

Pour plus d’informations sur le panneau Properties dans d’autres 

contextes, voir “Définition des propriétés des sources de données”, 

page 7-23, et “Assignation des méthodes autorisées”, page 7-26. 

Le mode transactionnel des enterprise beans dont les transactions sont 

gérées par le conteneur doit être défini par le conteneur. L’éditeur de 

descripteur de déploiement vous permet de définir les modes 

transactionnels gérés par le conteneur et de les associer aux méthodes des 

interfaces locale et distante de l’enterprise bean. 

Ajout d’une transaction gérée par le conteneur 

Pour ajouter une transaction conteneur, 

1 Double-cliquez sur l’enterprise bean dans le volet structure pour 

développer son arborescence. 

2 Cliquez sur Container Transactions dans le volet structure. 


Travail sur les sources de donné es 

3 Cliquez sur le bouton Add pour ajouter une ligne à la grille. 

4 Dans cette ligne, choisissez l’interface qui expose la méthode : 

sélectionnez Home ou Remote, ou sélectionnez * pour inclure les deux 

interfaces. 

5 Dans la liste déroulante Methods, sélectionnez une méthode, ou 

sélectionnez * pour inclure toutes les méthodes possibles pour la 

transaction. 

6 Dans la liste déroulante Transaction Attribute, sélectionnez l’attribut 

souhaité pour la transaction. 

Pour une description des attributs des transactions, voir “Attributs des 

transactions”, page 13-4. 

7 Entrez une description de la transaction dans le champ Description. 

Cette information est facultative. 

Travail sur les sources de données 

Pour voir les informations sur une source de données dans votre 

descripteur de déploiement, développez le nœud Data Sources dans le 

volet structure et sélectionnez une des sources de données. L’éditeur de 

descripteur de déploiement affiche le panneau Data Source. Vous pouvez 

utiliser ce panneau pour modifier les informations de la source de 

données sélectionnée. Seuls les beans entité ont une source de données. 



L’éditeur de descripteur de déploiement vous permet de spécifier une 

nouvelle source de données pour les beans entité et de définir le niveau 

d’isolation des transactions. 

Pour ajouter une nouvelle source de données au descripteur de 

déploiement, 

1 Cliquez sur l’icône dans la barre d’outils de l’éditeur de 


Une boîte de dialogue New DataSource apparaît. 

2 Entrez le nom de la nouvelle source de données et choisissez OK. 

La nouvelle source de données est ajoutée à l’arborescence du volet 

structure. 

3 Sélectionnez la source de données dans l’arborescence. 

4 Entrez les informations pour la nouvelle source de données. 

La source de données est définie par un nom, un emplacement URL et, 

si nécessaire, un nom d’utilisateur et un mot de passe permettant d’y 

accéder. Le panneau inclut également le nom de classe du pilote JDBC 

et les propriétés JDBC. 

5 Lorsque vous avez spécifié la connexion à la source de données, vous 

pouvez cliquer sur le bouton Test Connection. 

L’éditeur de descripteur de déploiement essaie d’établir la connexion à 

la source de données spécifiée. Les résultats sont reportés dans 

l’historique des messages. 


Définition des niveaux d’isolation 


Le niveau d’isolation limite la façon dont des transactions multiples et 

entrelacées interfèrent les unes sur les autres dans une base de données 

multi-utilisateur. Voici les violations possibles : 

• Lecture brouillée: La transaction t1 modifie une ligne, la transaction t2 

lit ensuite cette ligne. Puis, t1 effectue une annulation (rollback). t2 a 

donc vu une ligne qui n’a jamais vraiment existé. 

• Lecture ne pouvant pas être répétée: La transaction t1 extrait une 

ligne. Ensuite, la transaction t2 met à jour cette ligne et t1 extrait à 

nouveau la même ligne. La transaction t1 a donc extrait la même ligne 

deux fois et a vu deux valeurs différentes. 

• Ligne fantôme : La transaction t1 lit un ensemble de lignes satisfaisant 

certaines conditions de recherche. Ensuite, la transaction t2 insère une 

ou plusieurs lignes satisfaisant les mêmes conditions de recherche. Si la 

transaction t1 répète la lecture, elle verra des lignes qui n’existaient pas 

au préalable. Ces lignes sont appelées lignes fantômes. 

Pour définir ou modifier le niveau d’isolation des transactions pour une 

source de données, choisissez un niveau d’isolation dans la liste 

déroulante Isolation Level : 

Attribut Syntaxe Description 

Uncommitted TRANSACTION_READ_UNCOMMITTED Autorise l’ensemble 

des trois violations 

Committed TRANSACTION_READ_COMMITTED Autorise les lectures 

ne pouvant pas être 

répétées et les lignes 

fantômes, n’autorise 

pas les lectures 

brouillées. 

Repeatable TRANSACTION_REPEATABLE_READ Autorise les lignes 

fantômes, mais pas 

les deux autres 

violations. 

Serializable TRANSACTION_SERIALIZABLE N’autorise aucune 

des trois violations. 

Définition des propriétés des sources de données 

Lorsqu’une source de données est sélectionnée dans l’éditeur de 

descripteur de déploiement, un onglet Properties apparaît en même temps 

que l’onglet Data Source. Le panneau Properties vous permet de définir 

des propriétés affectant le moteur Borland de persistance gérée par le 

conteneur (CMP). 



Pour modifier les propriétés d’une source de données, 

1 Sélectionnez la source de données dans le volet structure. 

2 Cliquez sur l’onglet Propriétés. 

3 Dans le panneau Properties, sélectionnez la propriété à définir dans la 

liste déroulante Name. 

La valeur Type est remplie automatiquement en fonction de votre 

sélection dans la liste Name. 

4 Sélectionnez la valeur de la propriété dans la colonne Value. 

5 Ajoutez des propriétés en cliquant sur le bouton Add pour ajouter une 

nouvelle ligne, puis en sélectionnant les entrées Name et Value de la 

nouvelle propriété. 

Voici les propriétés possibles : 

Propriété 

uniqueSequence 

batchUpdates 

Description 

Détermine si le moteur CMP doit déclarer une séquence 

unique pour les colonnes clé primaire. Habituellement, 

cela s’effectue en déclarant les colonnes appropriées 

comme clés primaires (voir primaryKeyDeclaration). 

Indique si le moteur CMP doit traiter par lot les mises à 

jour dans la base de données. Cela peut générer un gain 

significatif de performance lors de transactions mettant à 

jour un grand nombre d’entités, et doit être utilisé si le 

pilote le supporte. Malheureusement, la majorité d’entre 

eux ne supportent pas encore ces mises à jour par lot. La 

valeur par défaut est false. 


Ajout des rô les de sé curité et des mé thodes autorisé es 

Propriété 

reuseStatements 

notNullDeclaration 

dialect 

primaryKeyDeclaration 

Description 

Détermine si le moteur CMP doit réutiliser des 

instructions préparées, de transaction en transaction. La 

réutilisation d’instructions préparées a un effet positif sur 

les performances, elles doivent être utilisées sauf si les 

présentations du pilote JDBC sont réutilisées. La valeur 

par défaut est true. 

Détermine si les champs Java qui ne peuvent être nuls 

(comme int ou float) doivent être mappés sur des 

colonnes non nulles. La valeur par défaut est true. 

Détermine le type de la source de données, par exemple 

un JDataStore, Oracle, Informix ou une autre source de 

données. Sélectionnez un dialecte dans la liste déroulante 

de la colonne Value. Si vous ne définissez pas ce champ, le 

moteur CMP crée des tables uniquement pour JDataStore. 

La valeur par défaut est none. 

Détermine si le moteur CMP déclare les colonnes clé 

primaire de la table comme clés primaires. Certaines bases 

de données ne supportent pas les déclarations de clés 

primaires. La valeur par défaut est true. 

Ajout des rôles de sécurité et des méthodes autorisées 

L’éditeur de descripteur de déploiement vous permet de créer ou de 

modifier les rôles de sécurité dans le descripteur de déploiement. Après 

avoir créé des rôles de sécurité, vous pouvez leur associer des méthodes 

des interfaces locale et distante de l’enterprise bean, définissant ainsi la 

vue sécurité de l’application. 

Cette section décrit l’utilisation de l’éditeur de descripteur de déploiement 

pour créer les rôles de sécurité et leur assigner les méthodes de 

l’enterprise bean. La section “Panneau Security role references”, page 7-9 

décrit l’utilisation du panneau Roles pour assigner à ces rôles des groupes 

d’utilisateurs et/ou des comptes utilisateur. 

La définition des rôles de sécurité dans le descripteur de déploiement est 

facultative. 

Création d’un rôle de sécurité 

Pour créer un rôle de sécurité dans le descripteur de déploiement, 

1 Cliquez sur l’icône dans la barre d’outils de l’éditeur de 


2 Dans la boîte de dialogue qui apparaît, entrez le nom du nouveau rôle 

de sécurité et choisissez OK. 


Ajout des rô les de sé curité et des mé thodes autorisé es 

Le nouveau rôle apparaît sous le nœud Security Roles dans le volet 

structure. Si vous ne le voyez pas, vérifiez que vous avez bien développé 

le nœud Security Roles. Un panneau Properties dédié au rôle apparaît 

également : 

Vous pouvez entrer la description du nouveau rôle dans le panneau 

Properties. Cette information est facultative. 

Assignation des méthodes autorisées 

Lorsque vous avez défini un rôle de sécurité, vous pouvez spécifier les 

méthodes des interfaces locale et distante d’un enterprise bean que le rôle 

de sécurité est autorisé à appeler. 

Vous n’êtes pas obligé d’associer un rôle de sécurité aux méthodes d’une 

interface locale ou distante d’un enterprise bean. En ce cas, aucun des 

rôles de sécurité définis dans le descripteur de déploiement ne sera 

autorisé à appeler ces méthodes. 

Pour autoriser des méthodes, 

1 Développez le nœud du bean dans le volet structure pour faire 

apparaître son sous-nœud Method Permissions. 


Visualisation et modification des proprié t é s WebLogic et WebSphere 

2 Sélectionnez le nœud Method Permission pour afficher un panneau 

Properties. 

Chaque rôle de sécurité défini apparaît comme titre de colonne. 

3 Cliquez sur le bouton Add pour ajouter une ligne au panneau. 

4 Dans la nouvelle ligne, choisissez Home, Remote ou * (pour indiquer 

les deux) dans la liste déroulante du champ Interface. 

5 Dans la liste déroulante Method, sélectionnez la méthode que vous 

autorisez à appeler, ou sélectionnez * pour autoriser l’appel de toutes 

les méthodes. 

6 Cochez la case de chaque rôle de sécurité que vous voulez autoriser à 

appeler les méthodes spécifiées. 

7 Enfin, décrivez l’autorisation définie par cette ligne dans le champ 

Description, si vous le souhaitez. 

Visualisation et modification des propriétés WebLogic et 

WebSphere 

Vous pouvez utiliser l’éditeur de descripteur de déploiement pour 

visualiser et modifier certains éléments spécifiques au fournisseur et 

uniques à WebLogic et WebSphere. Si votre serveur d’applications cible 

est le serveur WebLogic ou le serveur WebSphere, l’éditeur de descripteur 

de déploiement affiche un onglet EJB Properties en bas du volet contenu. 


V é rification des informations du descripteur 

Pour voir les propriétés spécifiques à WebLogic ou WebSphere, 

1 Double-cliquez sur le nœud du groupe EJB dans le volet projet. 

2 Cliquez dans le volet structure sur l’enterprise bean avec lequel vous 

travaillez. 

3 Cliquez sur l’onglet EJB Properties. 

Le panneau EJB Properties affiche un tableau des propriétés spécifiques 

au serveur WebLogic ou au serveur WebSphere. Par exemple, voici le 

panneau EJB Properties qui apparaît lorsque WebLogic Server 6.0 est le 

serveur d’applications sélectionné : 

Vous pouvez utiliser ce tableau pour voir les valeurs des propriétés ou les 

modifier. Utilisez la colonne de droite pour saisir les valeurs des 

propriétés que vous voulez modifier. Les valeurs des propriétés sont 

stockées dans les descripteurs de déploiement spécifiques au serveur 

d’applications. 

Vérification des informations du descripteur 

Après avoir modifié le fichier descripteur, vous pouvez vérifier que les 

informations du descripteur sont au format correct, que les fichiers classe 

des beans nécessaires sont présents, etc. 

Pour vérifier les informations, cliquez sur l’icône de vérification ( ) 

dans la barre d’outils de l’éditeur de descripteur de déploiement. Avant 

de choisir l’icône de vérification, vous pouvez définir les options de 

vérification en cliquant sur l’icône . 


V é rification des informations du descripteur 

La vérification effectue ce qui suit : 

• S’assure que le descripteur respecte la spécification EJB 1.1. 

• S’assure que les classes référencées par les descripteurs de déploiement 

respectent la spécification EJB 1.1. 

Set Class Path est utilisé pour la réflexion du code binaire, non pour celle 

du code source. Pour activer la réflexion du code binaire, ajoutez cette 

instruction à la section Preferences du fichier Borland/AppServer/console/ 

plugins/iaspt.ini : 

UseSourceReflection=false 

Pour définir le chemin d’accès aux classes, cliquez sur l’icône et 

utilisez la boîte de dialogue qui apparaît pour indiquer le nouveau 

chemin. 



Chapitre 

8 

Chapitre8Utilisation de DataExpress 

pour les composants EJB 

JBuilder propose plusieurs composants permettant de récupérer les 

données des beans entité dans des ensembles de données DataExpress 

(fourniture) ou d’enregistrer les données des ensembles de données 

DataExpress dans les beans entité (résolution). Ces composants 

DataExpress pour EJB facilitent l’implémentation du modèle de 

conception où le bean session enveloppe le bean entité. En utilisant ce 

modèle de conception, les clients n’ont pas directement accès aux beans 

entité mais les accèdent en utilisant des beans session. Les beans session, 

qui sont co-localisés avec les beans entité, rassemblent tous les appels aux 

beans entité dans une même transaction et renvoient ensuite toutes les 

données en même temps. Les ensembles de données sont le moyen de 

transport des données entre le bean session et le client, et vice-versa. 

Comme les données sont expédiées sur la ligne une seule fois pour fournir 

les données au client, et une seule fois encore pour résoudre les 

modifications dans les beans entité sur le serveur, les performances 

s’améliorent. 

Ces composants rendent également plus faciles la construction des 

applications client utilisant des composants visuels orientés DataExpress 

comme dbSwing ou InternetBeans Express. Pour une description 

complète de DataExpress, voir “Les applications de bases de données de 

JBuilder” dans le Guide du développeur d’applications bases de données. 

Ce chapitre explique comment utiliser ces composants pour transférer des 

données depuis les beans entité déployés sur un serveur vers votre 

application client et vice-versa. Le code utilisé dans le chapitre provient 

du projet exemple /JBuilder5/samples/Ejb/ejbdx.jpx. L’exemple accède à 

des données stockées dans le DataStore Employee. L’exemple crée un bean 

entité pour contenir les données Employee. Il crée aussi un bean session 

Utilisation de DataExpress pour les composants EJB 8-1

Les composants DataExpress EJB 

Personnel qui lit les données de Employee et les envoie ensuite au client. Le 

client renvoie les données au bean Personnel, qui résout les données dans 

les instances du bean entité Employee. 

Les composants DataExpress EJB 


Quatre des composants DataExpress EJB appartiennent à la page EJB de la 

palette de composants. Vous pouvez travailler avec ces composants dans 

le concepteur d’interface utilisateur, en définissant des propriétés et des 

événements à l’aide de l’inspecteur. Il existe d’autres classes que votre 

code peut appeler mais que vous ne pouvez pas mettre en œuvre de 

manière visuelle. Pour plus d’informations sur les classes, voir la 

Référence API. 

Composants pour le serveur 

Les deux composants de la page EJB de la palette de composants utilisés 

par le bean session déployé sur le serveur sont EntityBeanProvider et 

EntityBeanResolver. EntityBeanProvider fournit des données depuis les beans 

session déployés sur le serveur et EntityBeanResolver résout les données 

dans ces beans entité. Vous ajoutez ces composants au bean session que 

vous créez pour rendre le bean session capable de fournir les données des 

beans entité et de les résoudre. 

Composants pour le client 

Deux des composants de la page EJB sont utilisés côté client : 

EjbClientDataSet et SessionBeanConnection. EjbClientDataSet fournit les 

données depuis le bean session et résout les modifications dans le bean 

session référencé dans SessionBeanConnection. Un SessionBeanConnection 

contient la référence à un bean session sur le serveur et les noms des 

méthodes servant à fournir les ensembles de données à partir de ce bean 

session et à résoudre les ensembles de données dans ce bean session. 

Commencez par utiliser le Modeleur Bean entité EJB pour créer les beans 

entité qui accèdent aux données qui vous intéressent. Le projet exemple 

crée les beans entité Employee et Department mais ce chapitre ne s’occupe que 

de Employee. 


Création du bean session côté serveur 

Cré ation du bean session cô t é serveur 

Créez le bean session qui résidera sur le serveur. Envisagez l’utilisation de 

l’expert Enterprise JavaBean pour créer un bean session stateless. Dans la 

prochaine section, vous ajouterez les classes EntityBeanProvider et 

EntityBeanResolver à ce bean. Comme ces classes ne sont pas sérialisables, il 

est plus facile de les placer dans un bean session stateless qui, pour 

Borland Application Server, n’est jamais désactivé. Si votre application 

exige un bean session stateful, il faut soit que le bean session stateful fasse 

référence au bean session stateless, soit que vous ré-instanciez 

EntityBeanProvider et EntityBeanResolver lorsque le bean session stateful est 

activé. 

Voici à quoi ressemble une classe bean résultante, nommée PersonnelBean : 

public class PersonnelBean implements SessionBean { 

private SessionContext sessionContext; 

public void ejbCreate() { 

} 

public void ejbRemove() throws RemoteException { 

} 

public void ejbActivate() throws RemoteException { 

} 

public void ejbPassivate() throws RemoteException { 

} 

public void setSessionContext(SessionContext sessionContext) throws 

RemoteException { 

this.sessionContext = sessionContext; 

} 

} 

Cliquez sur l’onglet Conception pour afficher le concepteur d’interface 

utilisateur. 

Ajout des composants fournisseur et résolveur au bean 

session 

Depuis la page EJB de la palette de composants, ajoutez un 

EntityBeanProvider et un EntityBeanResolver au bean session. Vous devez 

aussi ajouter un composant ensemble de données pour contenir les 

données récoltées dans les beans entité avant qu’elles ne soient envoyées 

au client, ainsi que les données renvoyées par le client. Depuis la page 

DataExpress de la palette de composants, ajoutez un composant 

TableDataSet et donnez à ce TableDataSet un nom plus évocateur. 

Voici à quoi doit ressembler la partie supérieure de PersonnelBean ; le 

TableDataSet a été renommé en employeeDataSet : 





EntityBeanProvider entityBeanProvider = new EntityBeanProvider(); 

EntityBeanResolver entityBeanResolver = new EntityBeanResolver(); 

TableDataSet employeeDataSet = new TableDataSet(); 

... 

En utilisant l’inspecteur, définissez les propriétés provider et resolver du 

TableDataSet par les composants EntityBeanProvider et EntityBeanResolver 

nouvellement ajoutés. Le résultat est l’ajout de deux nouvelles méthodes 

dans la méthode jbInit() : 

employeeDataSet.setProvider(entityBeanProvider); 

employeeDataSet.setResolver(entityBeanResolver); 

En revanche, le projet exemple contient ces méthodes dans la méthode 

setSessionContext(). Vous pouvez vous-même ajouter les appels de ces 

méthodes à setSessionContext() si vous préférer imiter exactement le projet 

exemple. Les deux approches conviennent parfaitement. 

Ajoutez aux membres de cette classe une référence à l’interface locale du 

bean entité contenant les données que vous voulez accéder. Pour cet 

exemple, la référence est faite à l’interface locale du bean entité Employee, 

comme montré ici en gras. 



EntityBeanProvider entityBeanProvider = new EntityBeanProvider(); 

EntityBeanResolver entityBeanResolver = new EntityBeanResolver(); 

TableDataSet employeeDataSet = new TableDataSet(); 

EmployeeHome employeeHome; 

... 

Ecriture de la méthode setSessionContext() 

Dans la méthode sessionContext() du bean session, ajoutez un bloc try. 

Modifiez la méthode pour qu’elle ressemble à ceci : 

public void setSessionContext(SessionContext sessionContext) 

throws RemoteException { 

this.sessionContext = sessionContext; 

try { 

Context context = new InitialContext(); 

Object object = context.lookup("java:comp/env/ejb/Employee"); 

employeeHome = (EmployeeHome) PortableRemoteObject.narrow(object, 

EmployeeHome.class); 

entityBeanProvider.setEjbHome(employeeHome); 

entityBeanResolver.setEjbHome(employeeHome); 

} 

catch (Exception ex) { 

throw new EJBException(ex); 

} 

} 



Notez que setSessionContext() définit la valeur des propriétés ejbHome des 

composants EntityBeanProvider et EntityBeanResolver par le nom de 

l’interface locale du bean entité Employee. 

Ajout d’une référence EJB au descripteur de déploiement 

Vous devez ajouter une référence EJB à Personnel dans le descripteur de 

déploiement pour que la recherche fonctionne. Vous pouvez utiliser 

l’éditeur de descripteur de déploiement : 

1 Dans le volet projet, double-cliquez sur le nœud de groupe EJB. Pour le 

projet exemple, il s’agit de personnel.ejbgrpx. 

L’éditeur de descripteur de déploiement apparaît. 

2 Cliquez sur le bean Personnel dans le volet structure. 

3 Cliquez sur l’onglet EJB References dans l’éditeur de descripteur de 

déploiement. 

4 Cliquez sur le bouton Add pour ajouter une référence au bean entité 

contenant les données qui vous intéressent. 

5 Entrez un nom de référence. Dans le projet exemple, le nom est ejb/ 

Employee. 

6 Cochez la case IsLink. 

7 Spécifiez le bean entité dans la liste déroulante Link. 

Le reste des données doit être rempli automatiquement. 

Ajout des méthodes de fourniture et de résolution 

Vous devez ajouter deux méthodes au bean session, un fournisseur et un 

résolveur. Les noms de ces méthodes utilisent la valeur que vous avez 

spécifiée comme valeur de la propriété methodName pour le composant 

EjbClientDataSet. Ainsi, le fournisseur de PersonnelBean devient 

provideEmployee() et le résolveur resolveEmployee(). 

Le fournisseur doit appeler la méthode d’une classe EntityBeanConnection 

qui fournit les données d’un bean entité à un ensemble de données 

pouvant être envoyé sur la ligne. Voici à quoi doit ressembler la méthode 

provideEmployee() générée : 

public DataSetData [] provideEmployee(RowData [] parameterArray, 

RowData [] masterArray) { 

return EntityBeanConnection.provideDataSets(new StorageDataSet [] 

{employeeDataSet}, parameterArray, masterArray); 

} 



Le résolveur doit appeler la méthode d’une classe EntityBeanConnection qui 

résout toutes les mises à jour dans les beans entité. Voici comment 

resolveEmployee() doit se présenter : 

public DataSetData [] resolveEmployee(DataSetData[] dataSetDataArray) { 

return EntityBeanConnection.saveChanges(dataSetDataArray, 

new DataSet [] {employeeDataSet}); 

} 

Ajoutez ensuite ces méthodes à l’interface distante. Le moyen le plus 

simple est d’utiliser Beans express. Le fichier source du bean étant ouvert 

dans l’éditeur, cliquez sur l’onglet Bean, cliquez sur l’onglet Méthodes et 

cochez les cases situées à côté des méthodes que vous venez d’ajouter. 

Vous pouvez maintenant tester l’interface distante de votre bean session 

afin de vérifier que les deux méthodes sont désormais définies : 

public interface Personnel extends EJBObject { 

public com.borland.dx.dataset.DataSetData[] 

providePersonnel(com.borland.dx.ejb.RowData[] parameterArray, 

com.borland.dx.ejb.RowData[] masterArray) throws RemoteException; 

public com.borland.dx.dataset.DataSetData[] 

resolvePersonnel(com.borland.dx.dataset.DataSetData[] dataSetDataArray) 

throws RemoteException; 

} 

Appel de la méthode find 

Vous devez indiquer au EntityBeanProvider les beans entité à fournir. Pour 

ce faire, ajoutez un événement au EntityBeanProvider : 

1 Alors que vous êtes dans le concepteur d’interface utilisateur, 

sélectionnez le EntityBeanProvider dans le volet structure. 

2 Cliquez sur l’onglet Evénements de l’inspecteur, puis double-cliquez 

dans la colonne vierge associé à l’événement findEntityBeans. Un nouvel 

événement est ajouté. 

Voici le code résultant pour cet événement, tel qu’il apparaît dans le 

projet ejbdx.jpx : 

entityBeanProvider1.addEntityBeanFindListener(new 

com.borland.dx.ejb.EntityBeanFindListener() { 

public void findEntityBeans(EntityBeanFindEvent e) { 

entityBeanProvider1_findEntityBeans(e); 

} 

}); 

... 

void entityBeanProvider_findEntityBeans(EntityBeanFindEvent e) { 

} 


Construction du côté client 

Construction du cô t é client 

3 Ajoutez au nouveau gestionnaire d’événement une méthode find pour 

renvoyer les beans entité souhaités. Le code ajouté apparaît ici en gras : 

void entityBeanProvider_findEntityBeans(EntityBeanFindEvent e) { 

try { 

e.setEntityBeanCollection(employeeHome.findAll()); 

} 


throw new EJBException(ex); 

} 

} 

Dans cet exemple, le gestionniare d’événement appelle une méthode 

findAll() pour renvoyer tous les beans entité. Vous pouvez appeler 

n’importe quelle méthode find. Vous pourriez utiliser la propriété 

parameterRow du EntityBeanProvider pour déterminer de manière 

dynamique quelle méthode find appeler et/ou quels paramètres lui 

transmettre. 

Pour la résolution, le EntityBeanResolver peut déterminer par défaut 

comment appliquer les mises à jour et les suppressions. Mais il ne peut 

pas déterminer automatiquement comment créer de nouveaux beans 

entité car il n’a aucun moyen de savoir quelle méthode create() appeler et 

quels paramètres lui transmettre. Aussi, lorsque vous voulez ajouter une 

ligne à la source de données, vous devez ajouter vous-même l’événement 

create et fournir la logique nécessaire. Vous pouvez utiliser l’inspecteur 

pour ajouter le code squelette de l’événement create à votre bean session. 

Vous trouverez un exemple d’événement create dans le projet exemple 

ejbdx.jpx. Vous pouvez aussi utiliser les autres événements disponibles 

dans EntityBeanResolver pour surcharger le comportement par défaut, si 

vous le voulez. 

Déployez les beans session et entité sur le serveur d’applications. Pour 

plus d’informations sur le déploiement des beans, voir “Déploiement sur 

un serveur d’applications”, page 6-6. 

Maintenant que vous avez créé les beans entité et le bean session qui les 

accède et que vous les avez déployés sur votre serveur d’applications 

cible, vous êtes prêt à construire le client. 

Suivez ces étapes : 

1 Créez un module de données. Choisissez Fichier|Nouveau|Module de 

données. 

2 Dans la palette, sélectionnez le composant EjbClientDataSet et ajoutez-le 

au module de données. 


Construction du cô t é client 

3 Dans la palette, sélectionnez le composant SessionConnectionBean et 

ajoutez-le au module de données. 

4 Dans l’inspecteur, définissez la propriété sessionBeanConnection du 

EjbClientDataSet par le nom du SessionBeanConnection. 

5 Dans l’inspecteur, spécifiez un nom pour la propriété methodName pour le 

composant EjbClientDataSet. 

La propriété methodName détermine comment sont nommées les 

méthodes qui fournissent et résolvent les données. Par exemple, si vous 

spécifiez la valeur Employee pour methodName, les méthodes qui 

fournissent et résolvent les données du bean session deviendront 

provideEmployee() et resolveEmployee(). Plus tard, vous devrez ajouter ces 

méthodes au bean session que vous créez. 

6 Dans l’inspecteur ou directement dans le code source, définissez la 

propriété jndiName du composant SessionBeanConnection. Ou bien, vous 

pouvez spécifier le nom de l’interface distante du bean session que 

vous allez créer comme valeur de la propriété sessionBeanRemote. 

Vous pouvez aussi utiliser l’inspecteur pour ajouter un événement 

creating à votre SessionBeanConnection. Le code que vous ajoutez au 

gestionnaire de l’événement peut contrôler la création du bean session 

après la recherche JNDI. Habituellement, vous devez ajouter un 

événement creating si vous voulez invoquer une méthode create() sur 

l’interface locale qui requiert des paramètres. 

Voici le code source résultant, tel qui se trouve dans le projet exemple / 

JBuilder5/samples/Ejb/ejbdx.jpx. 

import com.borland.dx.dataset.*; 

import com.borland.dx.ejb.*; 

public class PersonnelDataModule implements DataModule { 

private static PersonnelDataModule myDM; 

SessionBeanConnection sessionBeanConnection = new SessionBeanConnection(); 

EjbClientDataSet personnelDataSet = new EjbClientDataSet(); 

public PersonnelDataModule() { 

try { 

jbInit(); 

} 

catch(Exception e) { 

e.printStackTrace(); 

} 

} 

private void jbInit() throws Exception { 

try { 

sessionBeanConnection.setJndiName("Personnel"); 

sessionBeanConnection.addCreateSessionBeanListener(new 

com.borland.dx.ejb.CreateSessionBeanListener() { 

public void creating(CreateSessionBeanEvent e) { 

sessionBeanConnection_creating(e); 


Gestion des relations 

} 

}); 

personnelDataSet.setSessionBeanConnection(sessionBeanConnection); 

personnelDataSet.setMethodName("Personnel"); 

} 


} 

} 

public static PersonnelDataModule getDataModule() { 

if (myDM == null) { 

myDM = new PersonnelDataModule(); 

} 

return myDM; 

} 

public com.borland.dx.ejb.SessionBeanConnection getSessionBeanConnection() { 

return sessionBeanConnection; 

} 

public com.borland.dx.ejb.EjbClientDataSet getPersonnelDataSet() { 

return personnelDataSet; 

} 

} 

} 

Gestion des relations 

Projet exemple 

void sessionBeanConnection_creating(CreateSessionBeanEvent e) { 

Le EntityBeanProvider facilite automatiquement les relations. Par exemple, 

si vous avez un bean entité Employee possédant une méthode getDept() qui 

renvoie un Dept, où Dept est un bean entité distant, un DataSet est créé 

possédant tous les champs du bean entité Employee plus tous les champs du 

bean entité Dept (y compris les colonnes cachées contenant les clés 

primaires de chacun des beans entité). Sauf Dept.ejbPrimaryKey, les champs 

de Dept sont en lecture seule. 

Pour résoudre les modifications dans le cas d’une relation un-à-un, vous 

devez ajouter un auditeur d’événement au EntityBeanProvider car il ne lui 

est pas possible de déterminer de manière dynamique l’interface locale du 

bean entité concerné. Le projet exemple ejbdx.jpx ne gère pas de relation. 

Jusqu’à présent, nous avons vu comment transférer efficacement des 

données, dans un sens et dans l’autre, entre le client et le serveur. Le projet 

exemple /JBuilder5/samples/Ejb/ejbdx.jpx montre comment mettre en 

œuvre les techniques décrites avec un client Java utilisant des contrôles 


Projet exemple 

dbSwing et avec un client Web utilisant la technologie JSP combinée à 

InternetBeansExpress. Vous serez alors en mesure de travailler avec de 

véritables données. Consultez la page Ejb.html du projet pour les 

instructions complètes permettant d’exécuter le projet exemple. 


Chapitre 

9 

Chapitre9Développement 

des beans session 

Types de beans session 

Les outils EJB de JBuilder peuvent grandement simplifier la création des 

enterprise beans et de leurs interfaces de support. Toutefois, vous devez 

savoir ce qu’exigent ces classes et ces interfaces, afin de pouvoir modifier 

les fichiers produits par JBuilder et comprendre le travail que celui-ci fait 

pour vous. Les chapitres suivants vous y aideront. 

Un bean session existe habituellement pour la durée de vie d’une session 

client unique. Les méthodes d’un bean session accomplissent un ensemble 

de tâches ou de processus pour le compte du client qui utilise le bean. Les 

beans session sont persistants uniquement pour la durée de la connexion 

avec le client. D’une certaine façon, le bean session représente le client 

pour le serveur EJB. Il fournit généralement un service au client. A moins 

de travailler avec des données persistantes existant dans un ensemble de 

données, vous utiliserez habituellement des beans session. 

Voici les deux types de beans session : ceux qui peuvent maintenir des 

informations d’état entre les appels des méthodes, appelés beans stateful, 

et ceux qui ne le peuvent pas, appelés beans stateless. 

Beans session stateful 

Les beans session stateful sont des objets utilisés par un seul client et ils 

maintiennent un état pour le compte de ce client. Par exemple, supposons 

un bean session représentant un chariot de supermarché. Au fur et à 

D é veloppement des beans session 9-1

Ecriture de la classe du bean session 

mesure que l’acheteur d’un magasin en ligne sélectionne ses achats, 

ceux-ci sont ajoutés à son chariot par le stockage des éléments sélectionnés 

dans une liste à l’intérieur de l’objet bean session représentant le chariot. 

Lorsque l’acheteur a fini ses achats, la liste est utilisée pour calculer le 

montant total. 

Beans session stateless 

Les beans session stateless ne maintiennent d’état pour aucun client 

spécifique. De ce fait, ils peuvent être utilisés par de nombreux clients. Par 

exemple, imaginons un bean session de tri contenant une méthode 

sortList(). Le client invoque sortList() en lui passant une liste d’éléments 

non triée. sortList() passe en retour au client la liste triée. 


Pour créer la classe d’un bean session, 

• Créez une classe qui implémente l’interface javax.ejb.SessionBean. 

• Implémentez une ou plusieurs méthodes ejbCreate(). Si vous créez un 

bean session stateless, la classe implémente une seule méthode sans 

paramètre, ejbCreate(). Si vous avez déjà créé l’interface locale du bean, 

le bean doit avoir une méthode ejbCreate(), avec la même signature, 

pour chaque méthode create() de l’interface locale. 

• Définissez et implémentez les méthodes métier que votre bean doit 

avoir. Si vous avez déjà créé l’interface distante du bean, les méthodes 

doivent être définies exactement comme elles le sont dans l’interface 

distante. 

L’expert Enterprise JavaBean de JBuilder peut commencer ces tâches à 

votre place, y compris la création des interfaces locale et distante. Il crée 

une classe étendant l’interface SessionBean et écrit les implémentations 

vides des méthodes SessionBean. Vous remplissez ces implémentations si 

votre bean en a besoin. La section suivante explique quelles sont ces 

méthodes et comment elles sont utilisées. 

Implémentation de l’interface SessionBean 

L’interface SessionBean définit les méthodes que tous les beans session 

doivent implémenter. Elle étend l’interface EnterpriseBean. 

package javax.ejb; 

public interface SessionBean extends EnterpriseBean { 

void setSessionContext(SessionContext sessionContext) 

throws EJBException, RemoteException; 

void ejbRemove() throws EJBException, RemoteException; 


} 


void ejbActivate() throws EJBException, RemoteException; 

void ejbPassivate() throws EJBException, RemoteException; 

Les méthodes de l’interface SessionBean sont intimement associées au cycle 

de vie d’un bean session. Ce tableau explique leur fonction : 

Méthode 

setSessionContext() 

ejbRemove() 

ejbActivate() 

ejbPassivate() 

Description 

Définit le contexte d’une session. Le conteneur du bean 

appelle cette méthode pour associer l’instance d’un bean 

session à son contexte. L’interface contexte de session fournit 

les méthodes d’accès aux propriétés d’exécution du contexte 

dans lequel la session s’exécute. Habituellement, un bean 

session retient son contexte dans un champ de données. 

Signale à un objet session qu’il va être supprimé. Le 

conteneur appelle cette méthode chaque fois qu’il supprime 

un bean session stateful à la suite de l’appel par le client d’un 

méthode remove() de l’interface locale ou distante. 

Signale à un objet session stateful qu’il a été activé. 

Signale à un objet session stateful qu’il va être désactivé par 

le conteneur. 

Les méthodes ejbActivate() et ejbPassivate() permettent à un bean session 

stateful de gérer des ressources. Pour plus d’informations, voir “Beans 

stateful”, page 9-6. 

Ecriture des méthodes métier 

Dans la classe de votre enterprise bean, écrivez les implémentations 

complètes des méthodes métier dont a besoin votre bean en utilisant 

l’éditeur de code de JBuilder. Pour rendre ces méthodes accessibles à un 

client, vous devez les déclarer dans l’interface distante du bean, 

exactement comme elles sont déclarées dans la classe du bean. Le 

concepteur de bean de JBuilder peut effectuer cette tâche à votre place. 

Voir “Exposition des méthodes métier via l’interface distante”, page 3-11. 

Ajout d’une ou de plusieurs méthodes ejbCreate() 

Si vous utilisez l’expert Enterprise JavaBean pour commencer à créer votre 

enterprise bean, vous verrez que l’expert ajoute à la classe du bean une 

méthode ejbCreate() qui ne prend pas de paramètre. Vous pouvez ajouter 

des méthodes ejbCreate() supplémentaires qui incluent des paramètres. 

Alors que les beans session stateless ne nécessitent jamais plus d’une 

méthode ejbCreate() sans paramètre car ils ne conservent pas d’état, les 

beans session stateful exigent souvent une ou plusieurs méthodes 

ejbCreate() avec paramètres. 



Lorsque vous ajoutez des méthodes ejbCreate() avec paramètres, 

respectez les règles suivantes : 

• Chaque ejbCreate() doit être déclarée publique. 

• Chacune doit renvoyer void. 

• Les paramètres d’une méthode ejbCreate() doivent être en même 

nombre et avoir le même type que ceux de la méthode create() 

correspondante dans l’interface distante du bean. Pour les beans 

session stateless, il ne peut y avoir qu’une méthode ejbCreate() sans 

paramètre. 

Voici la signature de toutes les méthodes ejbCreate() d’un bean session : 

public void ejbCreate( ) { 

// implémentation 

} 

La méthode ejbCreate() n’a pas besoin de déclencher une exception, bien 

qu’elle puisse déclencher des exceptions spécifiques à l’application et 

d’autres exceptions comme javax.ejb.CreateException. L’expert Enterprise 

JavaBean génère une méthode ejbCreate() déclenchant 

javax.ejb.CreateException. 

Comment JBuilder peut vous aider à créer un bean session 

A l’aide de l’expert Enterprise JavaBean de JBuilder, vous pouvez 

commencer à créer un bean session en sélectionnant, sur la seconde page, 

l’option Bean session stateless ou Bean session stateful : 

Non seulement l’expert Enterprise JavaBean crée la classe de votre 

enterprise bean, mais il crée en même temps les interfaces locale et 

distante du bean. De cette façon, vous êtes sûr que la méthode create() de 


La vie d’un bean session 

La vie d’ un bean session 

l’interface locale renvoie l’interface distante tandis que la méthode 

ejbCreate() renvoie toujours void. 

Après avoir écrit les méthodes métier dans la classe de votre bean, vous 

pouvez utiliser le concepteur de bean pour spécifier celles que vous 

voulez définir dans l’interface distante du bean. Une application client 

accède uniquement aux méthodes définies dans l’interface distante. 

Lorsque vous avez spécifié les méthodes qu’un client pourra appeler, le 

concepteur de bean définit ces méthodes dans l’interface distante à votre 

place. 

Si vous avez déjà la classe complète d’un enterprise bean, mais pas les 

interfaces locale et distante requises, vous pouvez les faire créer par 

l’expert Interfaces EJB de JBuilder. Les signatures des méthodes dans les 

interfaces locale et distante seront conformes aux spécifications EJB 1.1 

sans que vous ayez à vous en occuper. 

Pour plus d’informations sur l’utilisation des outils EJB de JBuilder pour 

créer des beans session, voir Chapitre 3, “Création des enterprise beans 

avec JBuilder”. 

Les bean session stateful et stateless ont des cycles de vie différents. Il 

serait bon que vous sachiez ce qui se passe dans la vie de chacun. 

Beans stateless 

La vie d’un bean session stateless commence lorsque le client appelle la 

méthode create() de l’interface locale du bean session. Le conteneur crée 

une nouvelle instance du bean session et renvoie au client la référence vers 

un objet. 

Lors du processus de création, le conteneur invoque la méthode 

setSessionContext() de l’interface SessionBean et appelle la méthode 



ejbCreate() de l’implémentation du bean session. Le nouvel objet bean 

rejoint le pool des objets bean stateless prêts à être utilisés par les clients. 

Comme les objets bean session stateless ne maintiennent pas d’état 

spécifique au client, le conteneur peut assigner n’importe quel objet bean 

pour traiter l’appel de la méthode à venir. Lorsque le conteneur supprime 

un objet du pool des objets bean session, il appelle la ejbRemove() de l’objet 

bean. 

Notez que l’appel de la méthode create() ou de la méthode remove() des 

interfaces locale/distante n’ajoute pas ou ne supprime pas d’objet bean 

session stateless dans le pool des beans session stateless. Le conteneur 

contrôle le cycle de vie des beans stateless. 

Beans stateful 

La vie d’un bean session stateful commence lorsque le client appelle la 

méthode create() de l’interface locale du bean session. Le conteneur crée 

une nouvelle instance du bean session, l’initialise et renvoie au client la 

référence vers un objet. 

Lors du processus de création, le conteneur invoque la méthode 

setSessionContext() de l’interface SessionBean et appelle la méthode 

ejbCreate() de l’implémentation du bean session. En tant que fournisseur 

du bean, vous pouvez utiliser ces méthodes pour initialiser le bean 

session. 

L’état du bean session est désormais prêt pour la méthode, c’est-à-dire 

qu’il peut effectuer des opérations non transactionnelles ou être inclus 

dans une transaction pour des opérations transactionnelles. Le bean reste 

dans cet état jusqu’à ce qu’un des trois faits suivants se produise : 

• Le bean entre dans une transaction. 

• Le bean est supprimé. 

• Le bean est désactivé. 

Lorsqu’un client appelle la méthode remove() de l’interface locale ou 

distante, le conteneur invoque la méthode ejbRemove() correspondante sur 

l’objet bean session. En tant que fournisseur du bean, vous placerez dans 

cette méthode le code de nettoyage spécifique à l’application. Après 

l’exécution de ejbRemove(), l’objet bean n’est plus utilisable. Si le client 



tente d’appeler une méthode de l’objet bean, le conteneur déclenche 

java.rmi.NoSuchObjectException. 

Le conteneur peut désactiver l’instance du bean session. Cela se produit 

habituellement pour des raisons de gestion des ressources, par exemple 

lorsqu’un objet session est provisoirement inactif ou si le conteneur 

demande plus de mémoire. Le conteneur désactive le bean en appelant la 

méthode ejbPassivate() du bean. Lorsque l’instance d’un bean est 

désactivée, ce que nous appellerons la désactivation, le conteneur stocke 

sur disque les informations de références et l’état de l’objet session, et 

libère la mémoire allouée au bean. Vous pouvez ajouter du code à 

ejbPassivate() si vous voulez accomplir certaines tâches juste avant que la 

désactivation se produise. 

Le conteneur active à nouveau l’objet bean en appelant la méthode 

ejbActivate(). Cela se produit lorsque le client appelle une méthode sur le 

bean session qui est désactivé. Pendant l’activation, le conteneur recrée 

l’objet session en mémoire et restaure son état. Si vous voulez que quelque 

chose se produise immédiatement après que le bean soit à nouveau actif, 

ajoutez votre code à la méthode ejbActivate(). 

Etat prêt pour la méthode et état prêt pour la transaction 

Lorsqu’un client appelle une méthode sur un objet bean session dans un 

contexte transactionnel, le conteneur démarre une nouvelle transaction ou 

inclut l’objet bean dans une transaction existante. Le bean passe de l’état 

prêt pour la méthode à l’état prêt pour la transaction. Il existe dans le cycle 

de vie d’une transaction des points, appelés points de synchronisation de 

la transaction, où un objet bean session peut être averti des événements 

transactionnels à venir, et cet objet peut accomplir auparavant une action 

si nécessaire. 



L’interface SessionSynchronization 

Un bean session peut implémenter l’interface SessionSynchronization s’il 

veut être averti de l’état de toute transaction dans lequel il est impliqué. 

Seuls les beans session stateful utilisant des transactions gérées par le 

conteneur peuvent implémenter SessionSynchronization ; son utilisation est 

facultative. Les méthodes de SessionSynchronization sont des callbacks 

effectués dans le bean par le conteneur, et elles marquent des points dans 

le cours de la transaction. Voici l’interface SessionSynchronization : 

public interface javax.ejb.SessionSynchronization 

{ 

public abstract void afterBegin() throws RemoteException; 

public abstract void beforeCompletion() throws RemoteException; 

public abstract void afterCompletion(boolean completionStatus) throws 

RemoteException; 

} 

L’expert Enterprise JavaBean peut ajouter ces méthodes à la classe de 

votre bean. Dans l’expert, cochez la case Synchronisation de session : 

l’expert déclarera les trois méthodes dans la classe de votre bean, en 

laissant vide le corps de ces méthodes : 


Un bean session pour faire vos courses 

Le tableau suivant décrit chacune de ces méthodes : 

Méthode 

afterBegin() 

beforeCompletion() 

afterCompletion() 

Description 

Signale à l’instance du bean qu’elle va être utilisée dans 

une transaction. Tout code écrit dans afterBegin() 

s’exécute dans la portée de la transaction. 

Signale à l’instance du bean que la transaction va être 

validée. Si le bean a des valeurs en cache, utilisez 

beforeCompletion() pour les écrire dans la base de 

données. Si nécessaire, un bean session peut utiliser la 

méthode beforeCompletion() pour forcer la transaction à 

effectuer un rollback en appelant la méthode 

setRollbackOnly() de l’interface SessionContext. 

Signale à l’instance du bean que la transaction est finie. Si 

la transaction a été validée (commit), le paramètre 

completionStatus est défini par true. Si la transaction a été 

annulée (rollback), ce paramètre est défini par false. 

Voici comment sont utilisées les méthodes SessionSynchronization : Le 

client appelle une méthode métier transactionnelle définie dans l’interface 

distante, ce qui place l’objet bean dans l’état prêt pour la transaction. Le 

conteneur appelle la méthode afterBegin() dans l’objet bean. Plus tard, si 

la transaction est validée (commit), le conteneur appelle la méthode 

beforeCompletion() puis, si la validation réussit, la méthode 

afterCompletion(true). Si la transaction a été annulée (rollback) ou si sa 

validation a échoué, le conteneur appelle afterCompletion(false). L’objet 

bean session est désormais à nouveau dans l’état prêt pour la méthode. 

Pour plus d’informations sur l’utilisation des beans session dans les 

transactions, voir Chapitre 13, “Gestion des transactions”. 


Cette exemple démontre l’utilisation d’un enterprise bean de type session 

et stateful, Cart, qui se transforme en chariot virtuel de magasin en ligne. 

Les acheteurs sélectionnent des éléments et les placent dans un chariot 

virtuel. Ils peuvent quitter quelque temps le site, revenir et ajouter 

d’autres achats à leur chariot. A tout moment, les acheteurs peuvent voir 

les éléments contenus dans leur chariot. Lorsqu’ils ont fini, ils paient les 

éléments contenus dans leur chariot. 

Vous trouverez le code complet de l’exemple cart dans le répertoire / 

Borland/AppServer/examples/ejb/cart. 



Fichiers de l’exemple du chariot virtuel 

L’exemple du chariot est composé de plusieurs fichiers différents. Cette 

section décrit les fichiers que vous auriez pu écrire vous-même et ceux qui 

illustrent un aspect particulièrement intéressant des beans session. 

Certains des fichiers du répertoire cart sont des fichiers générés (stubs, 

squelettes, et autre code CORBA) dont nous ne parlerons pas ici. 

Voici les principaux fichiers : 

• CartHome.java, le fichier définissant l’interface locale du bean session 

Cart. 

• Cart.java, le fichier définissant l’interface distante du bean session Cart. 

• CartBean.java, la classe du bean session. 

• Item.java, un fichier élément utilisé par CartBean. Il fournit les méthodes 

donnant le prix et l’intitulé des éléments placés dans le chariot virtuel. 

• Cart.xml, le fichier descripteur de déploiement. Pour EJB 1.1, c’est un 

fichier XML qui contient le descripteur de déploiement d’un enterprise 

bean. 

• Des fichiers Exception. Ces fichiers définissent les exceptions 

spécifiques de l’application déclenchées par CartBean. Il y a trois 

exceptions et chacune est définie dans un fichier séparé : 

• ItemNotFoundException 

• PurchaseProblemException 

• CardExpiredException 

• CartClient.java, l’application client. 

Le bean session Cart 

Cette section explique en détail comment vous pouvez implémenter un 

bean session comme Cart. Commencez par utiliser l’expert Enterprise 

JavaBean. Sur la seconde page de l’expert, tapez le nom de la classe, 

CartBean, sélectionnez l’option Bean session stateful et cliquez sur Suivant. 

Acceptez les propositions pour le nom de l’interface locale, le nom de 

l’interface distante, le nom local du bean et choisissez Terminer. L’expert 

crée pour vous le squelette de la classe du bean : 

package shoppingcart; 

import java.rmi.*; 

import javax.ejb.*; 

public class CartBean implements SessionBean { 



public void ejbCreate() throws CreateException { 

} 

public void ejbRemove() throws RemoteException { 

} 

public void ejbActivate() throws RemoteException { 

} 

public void ejbPassivate() throws RemoteException { 

} 


public void setSessionContext(SessionContext context) throws RemoteException 

{ 

sessionContext = context; 

} 

} 

Une classe de bean session doit être définie publique. Elle ne peut être 

définie finale ni abstraite. La classe du bean doit implémenter l’interface 

SessionBean. 

Les beans session sont des objets Java, ils peuvent donc avoir des variables 

d’instance. CartBean a quatre variables d’instance que vous ajoutez à la 

classe. Les quatre variables sont déclarées privées : 

private Vector _items = new Vector(); 

private String _cardHolderName; 

private String _creditCardNumber; 

private Date _expirationDate; 

Placez ces déclarations après la variable sessionContext qui a été ajoutée à 

la classe par l’expert Enterprise JavaBean. 

La variable _items contient les éléments appartenant à l’objet chariot. C’est 

un vecteur, une collection d’éléments. Les trois autres variables d’instance 

stockent les informations sur la carte de crédit de l’acheteur en ligne. 

Ajout des méthodes nécessaires 

Un bean session doit implémenter les quatre méthodes qui sont définies 

par l’interface SessionBean. Le conteneur EJB invoque ces méthodes sur 

l’instance du bean à des points précis du cycle de vie d’un bean session. Le 

fournisseur du bean doit, au minimum, implémenter ces méthodes avec 

un corps vide. Le fournisseur du bean peut ajouter, si nécessaire, du code 

supplémentaire à ces méthodes. Notre bean session CartBean ne leur ajoute 

pas de code. Voici les quatre méthodes : 

public void ejbRemove() {} 

public void ejbActivate() {} 

public void ejbPassivate() {} 

public void setSessionContext(SessionContext context) {} 



L’expert Enterprise JavaBean ajoute les quatre méthodes suivantes. Dans 

la méthode setSessionContext(), l’expert assigne la valeur du paramètre 

contexte à la variable d’instance sessionContext. 

Le conteneur du bean appelle la méthode setSessionContext() pour 

associer l’instance du bean à son contexte de session. Le bean peut choisir 

de retenir la référence au contexte de session comme partie de son état 

conversationnel, mais il n’est pas obligé de le faire. Si vous avez utilisé 

l’expert Enterprise JavaBean, la référence au contexte de session est 

retenue. Le bean session peut utiliser le contexte de session pour obtenir 

des informations sur lui-même, comme ses variables d’environnement ou 

son interface locale. 

Le conteneur appelle la méthode ejbPassivate() sur l’instance du bean 

lorsqu’il a besoin de placer l’instance du bean dans un état passif. 

Lorsqu’il désactive le bean, le conteneur écrit l’état en cours de celui-ci 

dans une zone de stockage secondaire. Il restaure cet état lorsqu’il réactive 

le bean ultérieurement. Comme le conteneur appelle la méthode 

ejbPassivate() juste avant de désactiver l’instance du bean, en tant que 

fournisseur du bean, vous pouvez ajouter du code à cette méthode pour 

mettre en cache n’importe quelle variable spéciale. De même, le conteneur 

appelle la méthode ejbActivate() sur l’instance du bean juste avant de la 

faire passer de l’état passif à l’état actif. Lorsqu’il réactive le bean, il 

restaure toutes les valeurs d’état préservées. Vous pouvez choisir 

d’ajouter du code à la méthode ejbActivate(). CartBean laisse vides ces 

implémentations. 

Alors qu’un bean session n’est pas obligé d’implémenter un constructeur, 

il doit implémenter au moins une méthode ejbCreate(). Cette méthode sert 

de constructeur pour créer une nouvelle instance du bean. Une session 

stateful peut implémenter plus d’une méthode ejbCreate(). Chaque 

méthode ejbCreate() ne se distingue que par ses paramètres. 

L’exemple CartBean déclare une méthode ejbCreate() qui prend trois 

paramètres : 

public void ejbCreate(String cardHolderName, String creditCardNumber, 

Date expirationDate) throws CreateException { 

_cardHolderName = cardHolderName; 

_creditCardNumber = creditCardNumber; 

} 

Le conteneur appelle la méthode ejbRemove() juste avant de supprimer 

l’instance du bean. Vous pouvez ajouter du code spécifique à l’application 

qui s’exécuterait avant la suppression du bean, mais ce n’est pas 

obligatoire. L’exemple CartBean laisse vide le corps de la méthode 

ejbRemove(). 



Ajout des méthodes métier 

Voici quelques règles que doivent respecter vos méthodes métier : 

• Les noms de méthodes ne doivent pas utiliser le préfixe ejb afin 

d’éviter les conflits avec les noms réservés à l’architecture EJB. 

• Chaque méthode doit être déclarée publique. 

• Aucune méthode ne peut être déclarée finale ou statique. 

• Les types des paramètres et des valeurs renvoyées doivent être valides 

pour RMI-IIOP. 

• La clause throws peut inclure l’exception javax.ejb.EJBException et 

définir d’autres exceptions spécifiques à l’application. 

Dans l’exemple Cart, cinq méthodes métier sont implémentées. Les 

signatures (nom de la méthode, nombre des paramètres, types des 

paramètres et type de la valeur de retour) des méthodes de la classe du 

bean session doivent correspondre à celles de l’interface distante. Pour 

être sûr qu’il en soit ainsi, vous pouvez utiliser le concepteur de bean pour 

placer les méthodes que vous ajoutez à la classe du bean dans l’interface 

distante de celui-ci. 

Afin de vous aider à suivre le programme, chaque méthode métier 

comprend une ligne de code affichant le nom de la méthode et ce qu’elle 

fait. 

La méthode addItem() ajoute un élément au vecteur qui contient la liste des 

éléments se trouvant dans le chariot : 

public void addItem(Item item) { 

System.out.println("\taddItem(" + item.getTitle() + "): " + this); 

_items.addElement(item); 

} 

La méthode removeItem() est plus compliquée. La méthode parcourt dans 

une boucle la liste des éléments et recherche si la classe et l’intitulé de 

l’élément à supprimer correspond à la classe et l’intitulé d’un élément de 

la liste. Cette méthode vérifie que vous supprimez bien l’élément souhaité. 

Si aucune correspondance n’est trouvée, la méthode déclenche une 

ItemNotFoundException. 

public void removeItem(Item item) throws ItemNotFoundException { 

System.out.println("\tremoveItem(" + item.getTitle() + "): " + this); 

Enumeration elements = _items.elements(); 

while(elements.hasMoreElements()) { 

Item current = (Item) elements.nextElement(); 

// les éléments sont égaux s’ils ont la même classe et le même intitulé 

if(item.getClass().equals(current.getClass()) && 

item.getTitle().equals(current.getTitle())) { 

_items.removeElement(current); 

return; 

} 

} 



La méthode getTotalPrice() initialise le prix total à zéro, puis parcourt 

dans une boucle la liste des éléments, en ajoutant le prix de chaque 

élément au prix total. Elle renvoie le prix total arrondi au centime le plus 

proche. 

public float getTotalPrice() { 

System.out.println("\tgetTotalPrice(): " + this); 

float totalPrice = 0f; 

Enumeration elements = _items.elements(); 


Item current = (Item) elements.nextElement(); 

totalPrice += current.getPrice(); 

} 

// arrondit au centime le plus bas 

return (long) (totalPrice * 100) / 100f; 

} 

Toutes les types de données passées entre un client et un serveur doivent 

être sérialisables. C’est à dire qu’ils doivent implémenter l’interface 

java.io.Serializable. Dans l’exemple Cart, le bean renvoie une liste 

d’éléments au client. S’il n’y avait pas de restriction de sérialisation, vous 

pourriez utiliser _items.elements() pour renvoyer le contenu du vecteur 

d’éléments. Mais, _items.elements() renvoie un objet Java Enumeration qui 

n’est pas sérialisable. Pour éviter ce problème, le programme implémente 

une classe, appelée com.inprise.ejb.util.VectorEnumeration(_items). Cette 

classe prend un vecteur et renvoie une véritable énumération, qui est 

sérialisable, pour le contenu du vecteur. L’objet CartBean passe ce vecteur 

sérialisable au client, et reçoit du côté client un vecteur sérialisable. La 

méthode getContents() effectue la conversion entre l’objet Java Enumeration 

et l’objet VectorEnumeration sérialisable. 

public java.util.Enumeration getContents() { 

System.out.println("\tgetContents(): " + this); 

return new com.inprise.ejb.util.VectorEnumeration(_items); 

} 

La méthode purchase() doit accomplir ce qui suit : 

1 Obtenir la date du jour. 

2 Comparer la date d’expiration de la carte de crédit et la date du jour. Si 

la date d’expiration précède la date du jour, la méthode déclenche 

l’exception application CardExpiredException. 

3 Terminer le processus d’achat, y compris la mise à jour du stock, la 

transmission du montant des dépenses à la société de crédit et le 

lancement de la procédure de livraison. (Aucune de ces fonctions n’est 

implémentée dans notre exemple Cart.) Si une erreur se produit à ce 

stade, le processus d’achat n’est pas complet et la méthode déclenche 

une exception PurchaseProblemException. 

public void purchase() throws PurchaseProblemException { 

System.out.println("\tpurchase(): " + this); 

// vérifie que la carte de crédit n’est pas expirée 



Date today = Calendar.getInstance().getTime(); 

if(_expirationDate.before(today)) { 

throw new CardExpiredException("Date d’expiration : " + 

_expirationDate); 

} 

// termine le processus d’achat 

// déclenche PurchaseProblemException si une erreur se produit 

} 

CartBean inclut une méthode toString() pour imprimer le CartBean et le nom 

du propriétaire de la carte. 

// méthode imprimant le CartBean et nom du propriétaire de la carte 

public String toString() { 

return "CartBean[name=" + _cardHolderName + "]"; 

} 

Classe Item 

L’exemple CartBean utilise une classe Item. Item est publique et étend 

java.io.Serializable ; des données sérialisées peuvent être transmises sur 

le câble : 

package shoppingcart; 

public class Item implements java.io.Serializable { 

private String _title; 

private float _price; 

public Item(String title, float price) { 

_title = title; 

_price = price; 

} 

public String getTitle() { 

return _title; 

} 

public float getPrice() { 

return _price; 

} 

} 

Exceptions 

Il y a trois classes exception dans l’exemple Cart. Toutes sont des 

extensions de la classe Java Exception : 

public class ItemNotFoundException extends Exception { 

public ItemNotFoundException(String message) { 

super(message); 

} 

} 

public class PurchaseProblemException extends Exception { 

public PurchaseProblemException(String message) { 


} 



} 

public class CardExpiredException extends Exception { 

public CardExpiredException(String message) { 


} 

} 

Interfaces exigées 

Les enterprise beans ont toujours deux interfaces : une interface locale et 

une interface distante. Dans cet exemple le bean session Cart a une 

interface distante EJB publique appelée Cart et une interface locale appelée 

CartHome. 

Lorsque vous utilisez l’expert Enterprise JavaBean, les interfaces locale et 

distante sont créées en même temps que la classe du bean. Si vous avez 

déjà un bean session, mais pas les interfaces, utilisez l’expert Interfaces 

EJB. Pour utiliser l’expert, affichez le code source de votre enterprise bean 

dans l’éditeur de code et choisissez Experts|Interfaces EJB. Répondez aux 

demandes de l’expert et il créera l’interface locale et l’interface distante de 

votre enterprise bean. 

Pour plus d’informations sur l’utilisation des experts Enterprise JavaBean 

et Interfaces EJB, voir Chapitre 3, “Création des enterprise beans avec 

JBuilder”. 

L’interface locale 

Comme toute interface locale, CartHome étend l’interface EJBHome. Alors que 

l’interface locale a deux fonctions : créer des instances du bean et trouver 

des instances du bean, les beans session n’ont qu’à créer l’instance d’un 

bean. Les beans session cessent d’exister lorsque la session d’un client se 

termine. De ce fait, il n’y a pas à trouver d’instance de CartBean, par 

exemple lorsqu’un acheteur entre dans le magasin en ligne, car il n’existe 

pas d’instance de CartBean. Seules les interfaces locales des beans entité 

incluent des opérations find, car les beans entité sont utilisés par plusieurs 

clients et vivent aussi longtemps que les entités de données. Voici 

l’interface CartHome : 

// CartHome.java 

public interface CartHome extends javax.ejb.EJBHome { 

Cart create(String cardHolderName, String creditCardNumber, 

java.util.Date expirationDate) 

throws java.rmi.RemoteException,javax.ejb.CreateException; 

} 

L’interface CartHome est très simple, elle définit une seule méthode create(). 

Comme il s’agit d’un bean session stateful, il pourrait y avoir plusieurs 

méthodes create(). Dans cet exemple, la méthode create() de l’interface 

CartHome accepte trois paramètres : cardHolderName, creditCardNumber et 

expirationDate. 



Le client invoque la méthode create() pour demander un chariot et le 

conteneur en crée un particulier pour cet utilisateur. Le client peut utiliser 

son chariot de manière intermittente, mais le bean session reste actif pour 

ce client-là jusqu’à ce que l’utilisateur s’en aille et que l’instance du bean 

soit supprimée. 

Un bean session stateful maintient l’état entre les appels de méthodes, que 

ces méthodes soient ou non incluses dans le contexte d’une transaction. 

L’état, ce sont les données transportées par un objet bean. Les données 

restent associées à l’objet bean pour la durée de vie de l’objet. Lorsque la 

session est terminée, le conteneur efface l’état du bean session de la 

mémoire. 

La méthode create() suit les règles définies par les spécifications EJB : elle 

déclenche une exception remote RMI, java.rmi.RemoteException, et une 

exception create EJB, javax.ejb.CreateException. La signature de la 

méthode create() doit correspondre à celle de la méthode ejbCreate() de la 

classe du bean session quant au nombre et aux types des arguments. La 

valeur renvoyée par create() est une interface distante Cart. C’est que 

l’interface CartHome fonctionne comme une factory pour CartBean. (La 

valeur renvoyée par la méthode ejbCreate() correspondante dans la classe 

CartBean est void.) 

L’interface distante 

Le bean session Cart a une interface distante Cart qui étend l’interface 

EJBObject. EJBObject est l’interface de base de toutes les interfaces distantes. 

Elle définit les méthodes vous permettant ce qui suit : 

• Obtenir les informations sur le bean session. 

Vous pouvez tester si l’objet bean est identique à un autre objet 

enterprise bean. (Vous pouvez aussi obtenir la clé primaire d’un bean 

entité, mais cela ne s’applique pas à un bean session.) 

• Obtenir une référence ou un handle sur le bean session. 

Vous pouvez obtenir une référence à l’interface locale du bean d’un 

handle de sérialisation sur l’instance du bean. Vous pouvez stocker le 

handle et le retrouver ultérieurement afin de l’utiliser pour retrouver 

votre référence à l’instance du bean. 

• Supprimer l’instance du bean. 

L’interface EJBObject définit la méthode remove() pour supprimer 

l’instance du bean. 

L’interface distante Cart définit des méthodes métier, en plus d’hériter des 

méthodes de EJBObject. Ces méthodes métier sont les méthodes 

implémentées dans la classe du bean session CartBean. L’interface distante 

Cart ne fait qu’exposer ces méthodes aux clients. Un client ne peut appeler 



que les méthodes qui sont exposées par l’interface distante de l’enterprise 

bean. Voici les méthodes métier exposées : 

• addItem(), qui ajoute un élément au chariot. 

• removeItem(), qui supprime un élément du chariot. 

• getTotalPrice(), qui ajoute les prix de tous les éléments et renvoie le 

montant total. 

• getContents(), qui rassemble les éléments du chariot et les renvoie dans 

une liste pouvant être visualisée et imprimée. 

• purchaseItems(), qui tente d’acheter les éléments. 

Le descripteur de déploiement de Cart 

Selon la spécification EJB 1.1, le descripteur de déploiement doit être un 

fichier XML. Le fichier XML respecte la DTD (Document Type Definition) 

approuvée par Sun Microsystems. Un descripteur de déploiement 

contient un ensemble de propriétés qui décrivent comment le conteneur 

déploiera l’enterprise bean ou l’application. 

Pendant que vous utilisez l’expert Enterprise JavaBean pour créer un bean 

session, JBuilder crée également pour vous un descripteur de 

déploiement. Vous pouvez ensuite utiliser l’éditeur de descripteur de 

déploiement pour adapter ce dernier à vos besoins. 

Le descripteur de déploiement inclut un jeu de balises et d’attributs dont 

les valeurs indiquent les propriétés du bean. Par exemple, voici certaines 

des balises de l’exemple Cart : 

• La balise spécifie que l’enterprise bean est un bean session. 

Outre la balise , il existe d’autres balises : 

• – Le nom de la classe du bean session qui implémente le 

bean. 

• – Le nom de l’interface locale. 

• – Le nom de l’interface locale. 

• – Indique si le bean session est stateful ou stateless. 

• – Indique si la persistance est gérée par le 

conteneur ou par le bean. 

• – L’attribut de transaction de chaque méthode. 

• – Le délai d’attente pour le bean session. 

Voici le fichier descripteur de déploiement pour le bean session cart : 

 

 

 

 



Descripteur de déploiement XML du bean session cart 

 

cart 

CartHome 

Cart 

CartBean 

Stateful 

Container 

 

 

 

 

 

cart 

* 

 

NotSupported 

 

 

 

cart 

purchase 

 

Required 

 

 

 

Le programme CartClient est l’application client qui utilise l’enterprise 

bean Cart. Sa routine main() inclut tous les éléments que toutes les 

applications client d’enterprise bean doivent implémenter. Elle démontre 

comment 

• Utiliser JNDI pour localiser l’interface locale du bean. 

• Utiliser la méthode create() de l’interface locale pour créer un nouvel 

objet Cart distant. 

• Invoquer la méthode déclarée dans l’objet Cart. 

public static void main(String] args) throws Exception { 

// obtient un contexte JNDI en utilisant le service d’annuaire 

javax.naming.Context context = new javax.naming.InitialContext(); 

Object objref = context.lookup("cart"); 

CartHome home = (CartHome)javax.rmi.PortableRemoteObject.narrow(objref, 

CartHome.class); 

Cart cart; 

{ 

String cardHolderName = "Jack B. Quick"; 

String creditCardNumber = "1234-5678-9012-3456"; 

Date expirationDate = new GregorianCalendar(2001, 

Calendar.JULY,1).getTime(); 

cart = home home.create(cardHolderName, creditCardNumber, expirationDate); 

} 



Book knuthBook = new Book("The Art of Computer Programming", 49.95f); 

cart.addItem(knuthBook); 

... // crée CompactDisc et l’ajoute au chariot, 

// puis liste le contenu du chariot 

summarize(cart) 

cart.removeItem(knuthBook); 

... // ajoute un autre livre et récapitule le contenu du chariot 

try { 

cart.purchase(); 

} 

catch(PurchaseProblemException e) { 

System.out.println("Impossible d’acheter les items:\n\t" + e); 

} 

cart.remove(); 

} 

La routine main() commence par un contexte JNDI de recherche d’objets. 

Elle construit un contexte initial (un contexte d’annuaire Java). C’est le 

code JNDI standard. 

main() recherche l’objet de CartHome appelé cart. Recherche un nom avec 

JNDI en invoquant un appel du client au service CosNaming pour 

chercher le nom dans CosNaming. Le service CosNaming renvoie au 

client une référence sur un objet. Dans cet exemple, il renvoie une 

référence sur un objet CORBA. Le programme doit effectuer une 

opération PortableRemoteObject.narrow() sur la référence à l’objet, 

transtyper l’objet renvoyé en type CartHome, et l’assigner à la variable 

locale. Cet appel est typique des applications distribuées. L’appel utilise 

CORBA et IIOP pour accomplir ce qui suit : 

• Parler à un serveur. 

• Effectuer une recherche CosNaming. 

• Obtenir une référence sur un objet CORBA. 

• Renvoyer au client la référence à l’objet. 

Le programme déclare une référence sur l’objet cart distant, initialise les 

trois variables paramètres de create() et crée un nouvel objet cart distant. 

Le programme crée deux éléments du chariot de supermarché, un livre et 

un disque compact, et les ajoute au contenu du chariot en utilisant la 

méthode addItem() de cart. 

La routine fait ensuite la liste des éléments du chariot en appelant la 

fonction summarize(). summarize() extrait les éléments du chariot avec la 

méthode getContents() de cart, qui renvoie une Enumeration Java. Elle utilise 

ensuite les méthodes de l’interface Java Enumeration pour lire chaque 

élément de Enumeration, en récupérant l’intitulé et le prix de chacun. Voici 

le code de la fonction summarize() : 

static void summarize(Cart cart) throws Exception { 

System.out.println("======== Récapitulatif du chariot =========")’ 

Enumeration elements = cart.getContents(); 



} 


Item current = (Item) elements.nextElement(): 

System.out.println("Prix : $" + current.getPrice() + "\t" + 

current.getClass().getName() + " titre : " + current.getTitle()); 

} 

System.out.println("Total : $" + cart.getTotalPrice()); 

System.out.println("==============================="); 

Le programme appelle ensuite la méthode removeItem() de cart pour retirer 

un élément du chariot. Il ajoute un élément différent et récapitule à 

nouveau le contenu du chariot. 

Finalement, le programme essaie d’acheter les éléments. L’opération 

d’achat échoue car elle n’est pas implémentée sur le serveur et déclenche 

une exception PurchaseProblemException. 

L’utilisateur ayant terminé sa session de shopping, le programme 

supprime le chariot. Il n’est pas nécessaire de supprimer le chariot, bien 

que la bonne pratique de la programmation nous y incite. Un bean session 

existe pour le client qui l’a créé. Lorsque le client termine la session, le 

conteneur supprime automatiquement l’objet bean session. Le conteneur 

supprime également l’objet bean session lorsqu’il dépasse son délai, bien 

que cela ne se produise pas immédiatement. 

CartClient inclut du code qui étend la classe générique Item avec deux 

types d’éléments : un livre et un disque compact. Book et CompactDisc sont 

les classes utilisées dans cet exemple. 



10 

Chapitre 

Chapitre10Développement 

desbeansentité 

Persistance et beans entité 

Un bean entité représente directement les données enregistrées dans un 

système de stockage permanent comme une base de données. Il 

correspond à une ou à plusieurs lignes d’une table dans une base de 

données relationnelles, ou à un objet entité dans une base de données 

orientée objet. Il peut aussi correspondre à une ou à plusieurs lignes de 

plusieurs tables. Dans une base de données, une clé primaire identifie de 

façon unique une ligne dans une table. De même, une clé primaire 

identifie l’instance d’un bean entité particulier. Chaque colonne d’une 

table dans une base de données relationnelles correspond à une variable 

d’instance dans le bean entité. 

Comme un bean entité représente habituellement des données stockées 

dans une base de données, il vit aussi longtemps que les données 

elles-mêmes. Quelle que soit la durée pendant laquelle un bean entité 

reste inactif, le conteneur ne le supprime pas du stockage persistant. 

La seule façon de supprimer un bean entité est de le supprimer 

explicitement. Un bean entité est supprimé par l’appel de sa méthode 

remove(), qui supprime les données sous-jacentes dans la base de données. 

Une autre application de l’entreprise peut également supprimer les 

données de la base. 

Tous les enterprise beans entité sont persistants ; c’est-à-dire que leur état 

est stocké entre les sessions et les clients. En tant que fournisseur du bean, 

vous pouvez choisir comment sera implémentée la persistance de votre 

bean entité. 

D é veloppement des beans entité 10-1

Persistance et beans entité 

Vous pouvez implémenter la persistance du bean directement dans la 

classe du bean entité, en chargeant le bean de maintenir sa propre 

persistance. C’est ce que nous appellerons la persistance gérée par le bean. 

Ou alors, vous pouvez déléguer la gestion de la persistance de votre bean 

entité au conteneur EJB. C’est ce que nous appellerons la persistance gérée 

par le conteneur. 

Persistance gérée par le bean 

Un bean entité dont la persistance est gérée par le bean contient le code 

permettant d’accéder à une base de données et de la mettre à jour. C’est à 

vous, en tant que fournisseur du bean, d’écrire les appels accédant à la 

base directement dans le bean entité ou ses classes associées. 

Habituellement, vous écrirez ces appels en utilisant JDBC. 

Les appels accédant à la base de données peuvent se trouver dans les 

méthodes métier du bean entité, ou dans une des méthodes de l’interface 

du bean entité. (Bientôt, nous vous en dirons plus sur l’interface d’un bean 

entité.) 

Habituellement, un bean qui gère sa persistance est plus difficile à écrire 

car vous devez écrire en plus le code d’accès aux données. Et, comme vous 

pouvez choisir d’intégrer le code d’accès aux données dans les méthodes 

du bean, il peut s’avérer difficile d’adapter le bean entité à plusieurs bases 

de données ou à différents schémas. 

Persistance gérée par le conteneur 

Avec les beans entités dont la persistance est gérée par le conteneur, vous 

n’avez pas à écrire le code qui accède aux bases de données et les met à 

jour. En revanche, le bean se repose sur le conteneur pour l’accès et la mise 

à jour de la base. 

La gestion de la persistance par le conteneur a de nombreux avantages 

comparée à la gestion par le bean : 

• De tels beans sont plus faciles à coder. 

• Les détails de la gestion de la persistance peuvent être modifiés sans 

changer ni recompiler le bean entité. En effet, le déployeur ou 

l’assembleur d’application peut modifier le descripteur de 

déploiement. 

• La complexité du code diminue, ainsi que le risque d’erreurs. 

• En tant que fournisseur du bean, vous pouvez vous concentrer sur la 

logique métier du bean et non sur les systèmes sous-jacents. 


Clé s primaires des beans entité 

La persistance géré par le conteneur a toutefois quelques limites. Par 

exemple, le conteneur peut charger l’état global de l’objet entité dans les 

champs de l’instance du bean avant d’appeler la méthode ejbLoad(). Cela 

peut créer des problèmes de performance si le bean a beaucoup de 

champs. 

Clés primaires des beans entité 

Chaque instance d’un bean entité doit avoir une clé primaire. Une clé 

primaire est une valeur (ou une combinaison de valeurs) identifiant 

l’instance de manière unique. Par exemple, une table de base de données 

contenant des enregistrements sur des employés peut utiliser leur numéro 

de sécurité sociale comme clé primaire. Le bean entité créé sur cette table 

des employés peut aussi utiliser le numéro de sécurité sociale comme clé 

primaire. 

Pour les enterprise beans, la clé primaire est représentée par un type 

String ou Integer, ou une classe Java contenant les données uniques. La 

classe de la clé primaire peut être n’importe quelle classe pour autant que 

le type de la classe soit valide pour RMI_IIOP. Cela signifie que la classe 

doit étendre l’interface java.io.Serializable et implémenter les méthodes 

Object.equals(Other other) et Object.hashCode(), dont héritent toutes les 

classes Java. 

La classe de la clé primaire peut être spécifique à une classe de bean entité 

particulière. Chaque bean entité peut donc définir sa propre classe clé 

primaire. Ou, plusieurs beans entité peuvent partager la même classe clé 

primaire. 

Ecriture de la classe du bean entité 

Pour créer la classe d’un bean entité, 

• Créez une classe qui implémente l’interface javax.ejb.EntityBean. 

• Implémentez une ou plusieurs méthodes ejbCreate(). Si vous avez déjà 

créé l’interface locale du bean, le bean doit avoir une méthode 

ejbCreate(), avec la même signature, pour chaque méthode create() de 

l’interface locale. 

• Définissez et implémentez les méthodes métier que votre bean doit 

avoir. Si vous avez déjà créé l’interface distante du bean, les méthodes 

doivent être définies exactement comme elles le sont dans l’interface 

distante. 

• Pour les beans entité dont la persistance est auto-gérée, implémentez 

des méthodes find. 



L’expert Enterprise JavaBean de JBuilder peut commencer ces tâches à 

votre place. Il crée une classe étendant l’interface EntityBean et écrit des 

implémentations vides des méthodes EntityBean. Vous remplissez ces 

implémentations si votre bean en a besoin. La section suivante explique 

quelles sont ces méthodes et comment elles sont utilisées. 

Si vous voulez construire des beans entité à partir de tables de bases de 

données existantes, utilisez le Modeleur Bean entité EJB de JBuilder. Pour 

plus d’informations, voir “Création des beans entité avec le Modeleur 

Bean entité EJB”, page 4-1. 

Implémentation de l’interface EntityBean 

L’interface EntityBean définit les méthodes que tous les beans entité 

doivent implémenter. Elle étend l’interface EnterpriseBean. 

public void EntityBean extends EnterpriseBean { 

public void setEntityContext(EntityContext ctx) throws EJBException, 

RemoteException; 

public void unsetEntitycontext() throws EJBException, RemoteException; 

void ejbRemove() throws RemoveException, EJBException, RemoteException; 

void ejbActivate() throws EJBException, RemoteException; 

void ejbPassivate() throws EJBException, RemoteException; 

void ejbLoad() throws EJBException, RemoteException; 

public void ejbStore() throws EJBException, RemoteException; 

} 

Les méthodes de l’interface EntityBean sont intimement associées au cycle 

de vie d’un bean entité. Ce tableau explique leur fonction : 

Méthode 

setEntityContext() 

unsetEntityContext() 

ejbRemove() 

Description 

Définit le contexte d’une entité. Le conteneur utilise cette 

méthode pour passer à l’instance du bean une référence 

vers l’interface EntityContext. L’interface EntityContext 

fournit les méthodes d’accès aux propriétés du contexte 

d’exécution du bean entité. L’instance d’un bean entité 

qui utilise ce contexte doit le stocker dans une variable 

d’instance. 

Libère les ressources qui ont été allouées au cours de 

l’appel à la méthode setEntityContext(). Le conteneur 

appelle cette méthode avant d’interrompre la vie de 

l’instance en cours du bean entité. 

Supprime l’entrée ou les entrées de la base de données 

associées à ce bean entité particulier. Le conteneur 

appelle cette méthode lorsqu’un client invoque une 

méthode remove(). 



Méthode 

Description 

ejbActivate 

Signale au bean entité qu’il a été activé. Le conteneur 

invoque cette méthode sur l’instance sélectionnée dans le 

pool des instances disponibles et assignée à l’identité 

d’un objet entité spécifique. Lorsque l’instance du bean a 

été activée, elle a la possibilité d’acquérir les ressources 

supplémentaires dont elle a éventuellement besoin. 

ejbPassivate() Signale à un bean entité qu’il va être désactivé — 

c’est-à-dire que l’association de l’instance et de l’identité 

de l’objet entité va être rompue et que l’instance 

reviendra au pool des instances disponibles. L’instance 

peut alors libérer les ressources allouées avec la méthode 

ejbActivate() qu’elle ne souhaite plus gérer lorsqu’elle 

sera dans le pool. 

ejbLoad() 

Rafraîchit à partir de la base les données représentées par 

l’objet entité. Le conteneur appelle cette méthode sur 

l’instance du bean entité afin que l’instance synchronise 

l’état de l’entité mis en cache dans les variables 

d’instance avec l’état de l’entité dans la base de données. 

ejbStore() 

Stocke dans la base de données les données représentées 

par l’objet entité. Le conteneur appelle cette méthode sur 

l’instance du bean entité afin que l’instance synchronises 

l’état dans la base de données avec l’état de l’entité mis 

en cache dans les variables d’instance. 

Déclaration et implémentation des méthodes des beans 

entité 

Les beans entité peuvent avoir trois types de méthodes : 

• Méthodes Create 

• Méthodes Find 

• Méthodes métier 

Création des méthodes Create 

Si vous utilisez l’expert Enterprise JavaBean pour commencer à créer votre 

enterprise bean, vous verrez que l’expert ajoute à la classe du bean une 

méthode ejbCreate() et une méthode ejbPostCreate() qui ne prennent pas 

de paramètre. Vous pouvez écrire d’autres méthodes create si votre bean 

en a besoin. 

N’oubliez pas que les beans entité ne sont pas obligés d’avoir des 

méthodes create. Appeler une méthode create pour un bean entité insère 

de nouvelles données dans la base de données. Vous pouvez avoir des 

beans entité sans méthode create si les nouvelles instances des objets 

entité doivent être ajoutées à la base de données uniquement par les mises 

à jour du SGBDR ou par une application existante. 



Méthode ejbCreate() 

Si vous choisissez d’ajouter des méthodes ejbCreate() supplémentaires qui 

incluent des paramètres, respectez les règles suivantes : 

• Chaque ejbCreate() doit être déclarée publique. 

• Pour les beans entité gérés par le conteneur, une méthode ejbCreate() 

doit renvoyer null. 

Le conteneur a l’entière responsabilité de la création des beans entité 

qu’il gère. 

• Pour les beans entité auto-gérés, une méthode ejbCreate() doit renvoyer 

une instance de la classe clé primaire pour le nouvel objet entité. 

Le conteneur utilise cette clé primaire pour créer la référence à la 

véritable entité. 

• Les paramètres d’une méthode ejbCreate() doivent être en même 

nombre et avoir le même type que ceux de la méthode create() 

correspondante dans l’interface distante du bean. 

• Chaque méthode ejbCreate() doit avoir une méthode ejbPostCreate() 

correspondante avec le même nombre de paramètres. 

La signature de la méthode ejbCreate() est la même que la persistance du 

bean soit gérée par le conteneur ou par le bean. Voici la signature de 

toutes les méthodes ejbCreate() d’un bean entité : 

public ejbCreate( ) 


} 

Lorsque le client appelle la méthode create(), le conteneur exécute en 

réponse la méthode ejbCreate() et insère dans la base de données un 

enregistrement représentant l’objet entité. Habituellement, les méthodes 

ejbCreate() initialisent un certain état de l’entité. De ce fait, elles ont 

souvent un ou plusieurs paramètres et leurs implémentations incluent le 

code définissant l’état de l’entité à partir des valeurs des paramètres. 

L’exemple bank, traité plus loin dans ce chapitre, a un bean entité compte 

chèque dont la méthode ejbCreate() prend deux paramètres, une chaîne et 

un nombre flottant. La méthode initialise le nom du compte avec la valeur 

chaîne et le solde du compte avec la valeur Float : 

public AccountPK ejbCreate(String name, float balance) { 

this.name = name; 

this.balance = balance; 

return null; 

} 



Méthode ejbPostCreate() 

Lorsqu’une méthode ejbCreate() a fini de s’exécuter, le conteneur appelle 

la méthode ejbPostCreate() correspondante pour permettre à l’instance de 

terminer son initialisation. La méthode ejbPostCreate() ressemble à la 

méthode ejbCreate() pour ce qui est de ses paramètres, mais renvoie void : 

public void ejbPostCreate( ) 


} 

Respectez ces règles lorsque vous définissez une méthode ejbPostCreate() : 

• Elle doit être déclarée publique. 

• Elle ne peut être déclarée finale ni statique. 

• Le type renvoyé doit être void. 

• Sa liste de paramètres doit correspondre à celle de son homologue 

ejbCreate(). 

Utilisez ejbPostCreate() pour accomplir tout processus spécial que votre 

bean doit exécuter avant d’être accessible au client. Si votre bean n’a rien 

de spécial à faire, laissez vide le corps de la méthode mais n’oubliez 

d’inclure une méthode ejbPostCreate() par méthode ejbCreate() dans le cas 

d’un bean entité dont la persistance est gérée par le bean. 

Création des méthodes Find 

Chaque bean entité doit avoir une ou plusieurs méthodes find. Les 

méthodes find sont utilisées par les clients pour localiser les beans entité. 

Chaque bean entité auto-géré doit posséder une méthode 

ejbFindByPrimaryKey() ayant son homologue findByPrimaryKey() dans 

l’interface locale du bean. Voici la signature de la méthode 

ejbFindByPrimaryKey() : 

public ejbFindByPrimaryKey() { 


} 

Vous pouvez définir d’autres méthodes find pour votre bean. Par 

exemple, vous pouvez avoir une méthode ejbFindByLastName(). Chaque 

méthode find doit respecter les règles suivantes : 

• Elle doit être déclarée publique. 

• Son nom doit utiliser le préfixe ejbFind. 

• Elle ne peut être déclarée finale ni statique. 

• Elle doit renvoyer une clé primaire, une collection de clés primaires ou 

une Enumeration de clés primaires. 

• Les types des paramètres et de la valeur renvoyée doivent être valides 

pour RMI Java. 


La vie d’ un bean entité 

La vie d’un bean entité 

Pour les beans entité à persistance auto-gérée, chaque méthode find 

déclarée dans la classe du bean doit avoir une méthode find 

correspondante dans l’interface locale du bean, utilisant les mêmes 

paramètres mais renvoyant l’interface distante du bean entité. Le client 

localise le bean entité qu’il veut en appelant la méthode find de l’interface 

locale, le conteneur invoque ensuite la méthode find correspondante dans 

la classe du bean. Voir “Méthodes find des beans entité”, page 11-5. 

Ecriture des méthodes métier 

Dans la classe de votre enterprise bean, écrivez les implémentations 

complètes des méthodes métier dont a besoin votre bean. Pour rendre ces 

méthodes accessibles à un client, vous devez les déclarer dans l’interface 

distante du bean en utilisant exactement la même signature. 

Utilisation des experts de JBuilder pour créer un bean entité 

Vous pouvez utiliser l’expert Enterprise JavaBeans de JBuilder pour 

commencer rapidement la création de votre bean entité. Si vous avez des 

tables de base de données à partir desquelles vous voulez créer des 

enterprise beans, démarrez avec l’expert Modeleur Bean entité EJB de 

JBuilder. Si vous avez déjà un bean entité, mais pas ses interfaces locale et 

distante, faites-les créer par l’expert Interfaces EJB de JBuilder. Modifiez 

ensuite le code dans JBuilder avec l’éditeur de code et le concepteur de 

bean. Modifiez les descripteurs de déploiement avec l’éditeur de 

descripteur de déploiement de JBuilder. Créez une application client de 

test avec l’expert Client test EJB et testez vos nouveaux enterprise beans. 

Enfin, utilisez l’expert Déploiement EJB pour simplifier le processus de 

déploiement de vos enterprise beans. 

Pour plus d’informations sur l’utilisation des outils EJB de JBuilder pour 

créer des beans entité, voir Chapitre 3, “Création des enterprise beans 

avec JBuilder”, Chapitre 7, “Utilisation de l’éditeur de descripteur de 

déploiement”, et Chapitre 6, “Déploiement des enterprise beans”. 

Le cycle de vie d’un enterprise bean entité est composé de trois états 

distincts : 

• Inexistant 

• En pool 

• Prêt 



Le diagramme suivant décrit le cycle de vie de l’instance d’un bean entité : 

L’état de non existence 

Au départ, l’instance du bean entité n’existe pas. Le conteneur EJB crée 

une instance d’un bean entité et appelle ensuite la méthode 

setEntityContext() sur le bean entité pour passer à l’instance une référence 

à son contexte ; c’est-à-dire une référence à l’interface EntityContext. 

L’interface EntityContext procure à l’instance un accès aux services fournis 

par le conteneur et lui permet d’obtenir des informations sur ses clients. 

Le bean entité est maintenant dans l’état en pool. 

L’état en pool 

Chaque type de bean entité a son propre pool. Aucune des instances du 

pool n’est associée à des données. Comme aucune de leurs variables 

d’instance n’est définie, les instances n’ont pas d’identité et sont toutes 

équivalentes. Le conteneur est libre d’assigner n’importe quelle instance 

au client qui demande un tel bean entité. 

Lorsqu’une application client appelle une des méthodes find du bean 

entité, le conteneur exécute la méthode ejbFind() correspondante sur une 

instance arbitraire du pool. L’instance reste dans l’état en pool pendant 

l’exécution de la méthode find. 



Lorsque le conteneur sélectionne une instance qui servira les demandes 

d’un client concernant un objet entité, cette instance passe de l’état en pool 

à l’état prêt. Il existe deux façons pour une instance entité de passer de 

l’état en pool à l’état prêt : 

• Via les méthodes ejbCreate() et ejbPostCreate(). 

• Via la méthode ejbActivate(). 

Le conteneur sélectionne l’instance qui gérera la demande create() d’un 

client sur l’interface locale du bean. En réponse à l’appel de create(), le 

conteneur crée un objet entité et appelle les méthodes ejbCreate() et 

ejbPostCreate() lorsque l’instance est assignée à l’objet entité. 

Le conteneur appelle la méthode ejbActivate() pour activer une instance 

de sorte qu’il puisse répondre à une invocation sur un objet entité existant. 

Habituellement, le conteneur appelle ejbActivate() lorsqu’il n’existe pas 

dans l’état prêt d’instance qui pourrait gérer les appels du client. 

L’état prêt 

Lorsque l’instance est dans l’état prêt, elle est associée à une clé primaire 

spécifique. Les clients peuvent appeler sur le bean entité les méthodes 

spécifiques à l’application. Le conteneur appelle les méthodes ejbLoad() et 

ejbStore() pour demander au bean de charger et d’enregistrer ses 

données. Elles permettent également à l’instance du bean de synchroniser 

son état et celui de l’entité de données sous-jacente. 

Retour à l’état en pool 

Lorsque l’instance d’un bean entité revient à l’état en pool, l’instance est 

découplée des données représentées par l’entité. Le conteneur peut 

désormais assigner l’instance de tout objet entité dans la même interface 

locale du bean entité. Il existe deux façons pour une instance entité de 

passer de l’état prêt à l’état en pool : 

• Le conteneur appelle la méthode ejbPassivate() pour dissocier 

l’instance de sa clé primaire sans supprimer l’objet entité sous-jacent. 

• Le conteneur appelle la méthode ejbRemove() pour supprimer l’objet 

entité. Il appelle ejbRemove() lorsque l’application client appelle la 

méthode remove() locale ou distante du bean. 

Pour supprimer du pool une instance non associée, le conteneur appelle la 

méthode unsetEntityContext() de l’instance. 


Exemple du bean entité bank 


L’exemple bank montre comment utiliser des beans entité. Il inclut deux 

implémentations de la même interface distante Account. L’une utilise la 

persistance gérée par le bean, l’autre par le conteneur. 

Le bean entité SavingsAccount, qui utilise la persistance gérée par le bean, 

représente des comptes d’épargne. Si vous examinez le code du bean 

entité, vous verrez qu’il comprend des appels directs à JDBC. 

Le bean entité CheckingAccount, qui utilise la persistance gérée par le 

conteneur, représente des comptes chèques. Il se repose sur le conteneur 

pour implémenter la persistance, mais pas vous, le développeur du bean. 

Un troisième enterprise bean appelé Teller transfère les fonds d’un 

compte à l’autre. C’est un bean session stateless qui montre comment les 

appels à plusieurs beans entité peuvent être regroupés dans la même 

transaction gérée par le conteneur. Même si l’opération de crédit se 

produit avant l’opération de débit au cours de l’opération de transfert, le 

conteneur annule (rollback) la transaction si le débit échoue, et ni le débit 

ni le crédit n’est effectif. 

Vous trouverez le code complet de l’exemple bank dans le répertoire / 

Borland/AppServer/examples/ejb/bank. 

L’interface locale d’un bean entité 

Plusieurs beans entité peuvent partager les mêmes interfaces locale et 

distante, même si un bean utilise la persistance gérée par le conteneur et 

les autres la persistance gérée par le bean. Les deux beans entité 

SavingsAccount et CheckingAccount utilisent la même interface locale, 

AccountHome. Ils utilisent également la même interface distante Account. 

L’interface locale d’un bean entité est très semblable à l’interface locale 

d’un bean session. Elles étendent la même interface javax.ejb.EJBHome. 

L’interface locale des beans entité doivent inclure au moins une méthode 

find. La méthode create() est facultative. 

Voici le code de l’interface AccountHome : 

public interface AccountHome extends javax.ejb.EJBHome { 

Account create(String name, float balance) 

throws java.rmi.RemoteException, javax.ejb.CreateException; 

Account findByPrimaryKey(AccountPK primaryKey) 

throws java.rmi.RemoteException, javax.ejb.FinderException; 

java.util.Enumeration findAccountsLargerThan(float balance) 

throws java.rmi.RemoteException, javax.ejb.FinderException: 

} 

L’interface locale AccountHome implémente trois méthodes. Alors que la 

méthode create() n’est pas obligatoire pour les beans entité, l’exemple 



bank en implémente une. La méthode create() insère un nouvel objet bean 

entité dans la base de données sous-jacente. Si vous aviez choisi de 

déléguer la création des nouveaux objets entité au SGBDR ou à une autre 

application, vous ne définiriez pas de méthode create(). 

La méthode create() nécessite deux paramètres, une chaîne pour le nom 

du compte et le montant du solde. L’implémentation de cette méthode 

dans la classe du bean entité utilise deux valeurs de paramètres pour 

initialiser l’état de l’objet entité — le nom du compte et le solde initial — 

lorsqu’elle crée un nouvel objet. La clause throws d’une méthode create() 

doit inclure java.rmi.RemoteException et java.ejb.CreateException. Elle doit 

également inclure les autres exceptions spécifiques à l’application. 

Les beans entité doivent posséder la méthode findByPrimaryKey(), 

l’interface AccountHome déclare donc cette méthode. Elle prend un 

paramètre, la classe clé primaire AccountPK, et renvoie une référence sur 

l’interface distante Account. Cette méthode trouve une entité compte 

particulière et renvoie une référence vers elle. 

Bien que cela ne soit pas obligatoire, l’interface locale déclare une seconde 

méthode find, findAccountsLargerThan(). Cette méthode renvoie un objet 

Java Enumeration contenant tous les comptes dont le solde est supérieur à 

un certain montant. 

L’interface distante d’un bean entité 

Plusieurs beans entité peuvent utiliser la même interface distante, même 

lorsqu’ils gèrent leur persistance différemment. Les deux beans entité de 

l’exemple bank utilisent la même interface distante Account. 

L’interface distante étend l’interface javax.ejb.EJBObject et expose les 

méthodes métier accessibles aux clients. Voici le code : 

public interface Account extends javax.ejb.EJBObject { 

public float getBalance() throws java.rmi.RemoteException; 

public void credit(float amount) throws java.rmi.RemoteException; 

public void debit(float amount) throws java.rmi.RemoteException; 

} 

Un bean entité dont la persistance est gérée par le 

conteneur 

L’exemple bank implémente un bean entité CheckingAccount qui illustre 

l’utilisation de la persistance gérée par le conteneur. Sur de nombreux 

points, cette implémentation ressemble à l’implémentation d’un bean 



session. Mais, il faut noter les éléments suivants sur l’implémentation 

d’un bean entité utilisant la persistance gérée par le conteneur : 

• Le bean entité n’a pas d’implémentation des méthodes find. C’est le 

conteneur EJB qui fournit les implémentations des méthodes find pour 

les beans entité dont la persistance est gérée par le conteneur. Plutôt 

que de fournir l’implémentation dans la classe du bean, le descripteur 

de déploiement contient des informations qui permettent au conteneur 

d’implémenter ces méthodes. 

• Le bean entité déclare publics tous les champs gérés par le conteneur à 

la place du bean. Le bean CheckingAccount déclare name et balance comme 

champs publics. 

• La classe du bean entité implémente ces méthodes, déclarées dans 

l’interface EntityBean : ejbActivate(), ejbPassivate(), ejbLoad(), 

ejbStore(), ejbRemove(), setEntityContext() et unsetEntityContext(). Le 

bean entité ne doit fournir que les implémentations squelette de ces 

méthodes, mais il est possible d’ajouter du code spécifique à 

l’application. Le bean CheckingAccount enregistre le contexte renvoyé par 

setEntityContext() et libère la référence dans unsetEntityContext(). 

Sinon, il n’ajoute aucun code aux méthodes de l’interface EntityBean. 

• CheckingAccount inclut une implémentation de la méthode ejbCreate(), 

car cet enterprise bean permet aux appelants de créer de nouveaux 

comptes chèques. L’implémentation initialise également les deux 

variables d’instance, name et balance, avec les valeurs des paramètres. 

ejbCreate() renvoie une valeur null car, avec la persistance gérée par le 

conteneur, le conteneur crée la référence à renvoyer au client. 

• CheckingAccount fournit l’implémentation minimale de la méthode 

ejbPostCreate() mais cette méthode pourrait effectuer un plus ample 

travail d’initialisation si cela était nécessaire. Pour les beans dont la 

persistance est gérée par le conteneur, vous n’avez besoin que d’une 

implémentation minimale de ejbPostCreate() car elle est utilisée comme 

callback de notification. 

import javax.ejb.* 

import java.rmi.RemoteException; 

public class CheckingAccount implements EntityBean { 

private javax.ejb.EntityContext _context; 

public String name; 

public float balance; 

public float getBalance() { 

return balance; 

} 

public void debit(float amount) { 

if(amount > balance) { 

// marque la transaction en cours pour le rollback ... 



_context.setRollbackOnly(); 

} 

else { 

balance = balance - amount; 

} 

} 

public void credit(float amount) { 

balance = balance + amount; 

} 

public AccountPK ejbCreate(String name, float balance) { 


this.balance = balance; 

return null; 

} 

public void ejbPostCreate(String name, float balance) {} 

public void ejbRemove() {} 

public void setEntityContext(EntityContext context) { 

_context = context; 

} 

public void unsetEntityContext() { 

context = null; 

} 

public void ejbActivate() {} 

public void ejbPassivate() {} 

public void ejbLoad() {} 

public void ejbStore() {} 


return"CheckingAccount[name=" + name + ",balance=" + balance +"]"; 

} 

} 

Un bean entité dont la persistance est gérée par le bean 

L’exemple bank implémente également un bean SavingsAccount, un bean 

entité dont la persistance est auto-gérée. Le bean SavingsAccount accède à 

une autre table de comptes que le bean CheckingAccount. Bien que les deux 

beans entité gèrent différemment leur persistance, ils peuvent utiliser les 

mêmes interfaces locale et distante. Cependant, les deux implémentations 

sont différentes. 

L’implémentation d’un bean entité dont la persistance est gérée par le 

bean accomplit ce qui suit : 

• Il peut déclarer ses variables d’instance comme privées plutôt que 

publiques. 

Le bean inclut le code nécessaire pour accéder aux variables d’instance, 

charger les valeurs issues de la base de données dans ces variables et 



stocker leurs modifications dans la base. Ainsi, le bean peut contrôler 

l’accès à ces variables comme il l’entend. C’est différent de la 

persistance gérée par le conteneur où le bean doit déclarer publiques 

toutes les variables gérées par le conteneur afin que celui-ci y accède. 

• La méthode ejbCreate() renvoie la classe clé primaire. 

Pour le bean SavingsAccount, cette classe est AccountPK. Le conteneur 

prend la classe clé primaire renvoyée et l’utilise pour construire une 

référence distante sur l’instance du bean entité. 

• Comme un bean dont la persistance est gérée par le conteneur, un bean 

dont la persistance est auto-gérée peut fournir plus qu’une 

implémentation vide de la méthode ejbCreate(). 

Le bean SavingsAccount n’a pas besoin d’inclure du code d’initialisation 

supplémentaire dans cette méthode. 

• Il a les implémentations des méthodes ejbLoad() et ejbStore(). 

Un bean à persistance gérée par le conteneur fournit généralement une 

simple implémentation vide de ces méthodes car c’est le conteneur qui 

gère la persistance. Un bean entité à persistance auto-gérée doit fournir 

son propre code pour lire les valeurs de la base de données dans ses 

variables d’instance avec la méthode ejbLoad() et écrire dans la base les 

valeurs modifiées avec la méthode ejbStore(). 

• Il a les implémentations pour toutes les méthodes find. 

Le bean entité SavingsAccount implémente deux méthodes find, la 

méthode ejbFindByPrimaryKey(), obligatoire, et la méthode 

ejbFindAccountsLargerThan(), facultative. 

• Un bean entité dont la persistance est auto-gérée doit implémenter la 

méthode ejbRemove(). 

Comme le bean gère l’objet entité de la base de données sous-jacente, il 

doit implémenter cette méthode pour pouvoir supprimer de la base de 

données l’objet entité. Un bean dont la persistance est gérée par le 

conteneur omettra l’implémentation de cette méthode car c’est le 

conteneur qui est responsable de la gestion de la base. 

• Chaque méthode qui accède à l’objet de la base de données sous-jacente 

doit inclure le bon code d’accès à cette base. 

Ces méthodes sont ejbCreate(), ejbRemove(), ejbLoad(), ejbStore, 

ejbFindByPrimaryKey(), toutes les autres méthodes find et les méthodes 

métier. Chaque méthode contient le code de connexion à la base de 

données, suivi du code de construction puis d’exécution des 

instructions SQL qui accomplissent la fonctionnalité de la méthode. 

Quand les instructions SQL sont terminées, la méthode ferme les 

instructions et la connexion à la base de données avant de revenir au 

programme. 



L’exemple de code suivant montre les parties intéressantes du code de la 

classe d’implémentation de SavingsAccount. L’exemple supprime le code 

qui contient simplement les implémentations vides des méthodes des 

interfaces EntityBean, comme ejbActivate(), ejbPassivate(), etc. 

Observez d’abord la méthode ejbLoad(), qui accède à l’objet entité de la 

base de données, pour voir comment un bean dont la persistance est 

auto-gérée implémente l’accès à la base. Notez que toutes les méthodes 

implémentées dans la classe SavingsAccount suivent la même approche que 

ejbLoad(). La méthode ejbLoad() commence par établir la connexion à la 

base de données. Elle appelle la méthode interne getConnection(), qui 

utilise un DataSource pour obtenir une connexion JDBC à la base de 

données à partir d’un pool de connexions JDBC. Une fois la connexion 

établie, ejbLoad() crée un objet PreparedStatement et construit son 

instruction SQL d’accès à la base de données. Comme ejbLoad() lit les 

valeurs de l’objet entité dans les variables d’instance du bean, elle 

construit l’instruction SQL SELECT d’une requête qui sélectionne la 

valeur du solde des comptes d’épargne dont les noms correspondent à un 

modèle. La méthode exécute ensuite la requête. Si la requête renvoie un 

résultat, c’est le montant du solde. La méthode ejbLoad() termine en 

fermant les objets PreparedStatement, puis la connexion à la base de 

données. Notez que la méthode ejbLoad() ne ferme pas réellement la 

connexion. A la place, elle renvoie simplement la connexion au pool de 

connexions. 

import.java.sql.*; 

import javax.ejb.*; 

import java.util.*; 

import java.rmi.RemoteException; 

public class SavingsAccount implements EntityBean { 

private entitycontext _constext; 

private String _name; 

private float _balance; 

public float getBalance() { 

return _balance; 

} 

public void debit(float amount) { 

if(amount > balance) { 

// marque la transaction en cours pour le rollback... 

_context.setRollbackOnly(); 

} else { 

_balance = _balance - amount; 

} 

} 

public void credit(float amount) { 

_balance = _balance + amount; 

} 



// setEntitycontext(), unsetEntityContext(), ejbActivate(), ejbPassivate(), 

// les implémentations squelette de ejbPostCreate() ne sont pas montrées ici 

... 

public AccountPK ejbCreate(String name, float balance) 

throws RemoteException, CreateException { 

_name = name; 

_balance = balance; 

try { 

Connection connection = getConnection(); 

PreparedStatement statement = connection.prepareStatement 

("INSERT INTO Savings_Accounts (name, balance) VALUES (,)*); 

statement.setString(1, _name); 

statement.setFloat(2, _balance); 

if(statement.executeUpdate() != 1) { 

throw new CreateException("Impossible de créer : " + name); 

} 

statement.close(); 

connection.close(); 

return new AccountPK(name); 

} catch(SQLException e) { 

throw new RemoteException("Impossible de créer : " + name, 3); 

} 

} 

... 

public void ejbRemote() throws RemoteException, RemoveException { 

try { 



("DELETE FROM Savings Account WHERE name = "); 


if(statement.executeUpdate() != 1) { 

throw new RemoteException("Impossible de supprimer : " + _name, e); 

} 




throw new RemoteException("Impossible de supprimer : " + _name, e); 

} 

} 

public AccountPK ejbFindByPrimaryKey(AccountPK key) throws RemoteException, 

FinderException { 

try { 



("SELECT name FROM Savings_Accounts WHERE name = "); 

statement.setString(1, key.name); 

ResultSet resultSet = statement.executeQuery(); 

if(!resultSet.next()) { 

throw new FinderException("Impossible de trouver : " + key 



return key; 




} 

} 

throw new RemoteException("Impossible de trouver : " + key, e); 

public java.util.Enumeration ejbFindAccountsLargerThan(float balance) 

throws RemoteException, FinderException { 

try { 



("SELECT name FROM Savings_Account WHERE balance > "); 

statement.setFloat(1, balance); 


Vector keys = new Vector(); 

while(resultSet.next()) { 

String name = resultSet.getString(1); 

keys.addElement(new AccountPK(name)); 

} 



return keys.elements(); 

} catch(SQLException 3) { 

throw new RemoteException("Impossible findAccountsLargerThan : " + 

balance, e); 

} 

} 

public void ejbLoad() throws RemoteException { 

// obtient le nom de la clé primaire 

_name = (AccountPK) _context.getPrimaryKey()).name; 

try { 



("SELECT balance FROM Savings_Account WHERE name = "); 



if(!resultSet.next()) { 

throw new RemoteException("Compte introuvable : " + _name); 

} 

_balance = resultSet.getFloat(1); 




throw new RemoteException("Impossible de charger : " + _name, e): 

} 

} 

public void ejbStore() throw RemoteException { 

try { 



("UPDATE Savings_Accounts SET balance = WHERE name = "); 

statement.setFloat(1, _balance); 


statement.executeUpdate(); 






throw new RemoteException("Impossible de stocker : " + _name, e); 

} 

} 

private connection getconnection() throws SQLException { 

Properties properties = _context.getEnvironment(); 

String url = properties.getProperty("db.url"); 

String username = properties.getProperty("db.username"); 

String password = properties.getProperty("db.password"); 

if(username != null) { 

return DriverManager.getConnection(url, username, password); 

} else { 

return DriverManager.getConnection(url); 

} 

} 


return "SavingsAccount[name=" + _name + ",balance=" + _balance +"]"; 

} 

} 

La classe clé primaire 

CheckingAccount et SavingsAccount utilisent tous deux le même champ pour 

identifier de manière unique un enregistrement de compte particulier. 

Dans ce cas, ils utilisent tous deux la même classe clé primaire, AccountPK, 

pour représenter l’identificateur unique de chaque type de compte : 

public class AccountPK implements java.io.Serializable { 

public String name; 

public AccountPK() {} 

public AccountPK(String name) { 


} 

} 

Le descripteur de déploiement 

Le descripteur de déploiement de l’exemple bancaire déploie trois sortes 

de beans : le bean session Teller, le bean entité CheckingAccount, dont la 

persistance est gérée par le conteneur, et le bean entité SavingsAccount, dont 

la persistance est auto-gérée. 

Vous utilisez les propriétés du descripteur de déploiement pour spécifier 

des informations sur les interfaces des beans entité, les attributs de 

transaction, etc., comme vous le feriez pour les beans session. Mais, vous 

ajoutez également des informations propres uniquement aux beans entité. 



L’exemple de code XML géré par un bean montre les balises de propriété 

d’un descripteur de déploiement typique pour un bean entité dont la 

persistance est auto-gérée. L’exemple de code XML géré par le conteneur 

montre les balises d’un descripteur de déploiement typique pour un bean 

entité dont la persistance est gérée par le conteneur. Quand vous 

comparez les balises de descripteur des deux types de beans entité, vous 

remarquez que le descripteur de déploiement d’un bean entité dont la 

persistance est gérée par le conteneur est plus complexe. 

Le type de descripteur de déploiement du bean est défini par . 

Remarquez que les premières balises de la section 

dans les deux exemples de code spécifient que le bean est un bean entité. 

Le descripteur de déploiement d’un bean entité spécifie le type 

d’informations suivant : 

• Les noms des interfaces associées (locale et distante) et la classe 

d’implémentation du bean. 

Chaque enterprise bean spécifie son interface locale en utilisant la 

balise , son interface distante en utilisant la balise et 

sa classe d’implémentation en utilisant la balise . 

• Les noms JNDI sous lesquels le bean entité est enregistré et grâce 

auxquels les clients localisent le bean. 

• Les attributs de transaction du bean et son niveau d’isolation. 

Cela apparaît généralement dans la section du 


• Le nom de la classe clé primaire du bean entité. 

Dans cet exemple, la classe clé primaire est AccountPK et apparaît dans la 

balise . 

• La persistance utilisée par le bean. 

Le bean CheckingAccount utilise la persistance gérée par le conteneur, et 

donc le descripteur de déploiement définit la balise 

par Container. 

• Si le bean est réentrant. 

Ni le bean SavingsAccount, ni le bean CheckingAccount ne sont réentrants, 

donc la balise est définie à False pour les deux. 

• Les champs gérés par le conteneur, si le bean utilise la persistance gérée 

par le conteneur. 

Un bean qui utilise la persistance auto-gérée ne spécifie aucun champ 

relatif à la gestion par le conteneur. Donc, le descripteur de 

déploiement du bean SavingsAccount ne spécifie aucun champ relatif à la 

gestion par le conteneur. Un bean entité utilisant la persistance gérée 

par le conteneur doit spécifier les noms des champs ou les variables 



d’instances que le conteneur doit gérer. Utilisez une combinaison des 

balises et pour cela. La première balise, 

, indique que le champ est géré par le conteneur. A 

l’intérieur de cette balise, la balise spécifie le nom du 

champ lui-même. Par exemple, le descripteur de déploiement du bean 

CheckingAccount indique que le champ du solde est géré par le conteneur 

comme ceci : 

balance 

Des informations sur les champs gérés par le conteneur, pour les beans 

gérés par le conteneur. Le conteneur utilise cette information pour générer 

les méthodes find pour ces champs. 

Descripteur de déploiement d’un bean entité dont la persistance est 

auto-gérée 

L’exemple de code suivant montre les parties principales du descripteur 

de déploiement d’un bean entité dont la persistance est auto-gérée. 

Comme c’est le bean, et non le conteneur, qui gère ses propres lectures des 

valeurs entité de la base de données et met à jour ces valeurs, le 

descripteur ne spécifie pas de champ à gérer par le conteneur. Il n’indique 

pas non plus au conteneur comment implémenter ses méthodes find, car 

c’est l’implémentation du bean qui les fournit. 

 

 

Ce bean entité est un exemple de persistance auto-gérée 

savings 

AccountHome 

Account 

SavingsAccount 

Bean 

AccountPK 

False 

 

... 

 

 

 

 

savings 

* 

 

Required 

 

 



Descripteur de déploiement d’un bean entité dont la persistance est 

gérée par le conteneur 

L’exemple de code suivant montre les parties principales du descripteur 

de déploiement d’un bean entité dont la persistance est gérée par le 

conteneur. Comme le bean laisse le conteneur gérer les chargements des 

valeurs entité de la base de données et les mises à jour de ces valeurs, le 

descripteur spécifie les champs que le conteneur doit gérer. 

 

 

Ce bean entité est un exemple de persistance gérée par le 

conteneur 

 

checking 

AccountHome> 

Account 

chkingAccount 

Container 

AccountPK>/prim-key-class> 

False 

 

name 

 

 

 

 

 

 

chekcing 

* 

 

 

 

 


11 

Chapitre 


interfaces locales 

et distantes 

Création de l’interface locale 

En tant que fournisseur d’enterprise bean, vous devez créer deux 

interfaces pour chaque bean : une interface locale et une interface distante. 

L’interface locale définit les méthodes qu’utilise une application client 

pour créer, localiser et détruire les instances d’un enterprise bean. 

L’interface distante définit les méthodes métier implémentées dans le 

bean. Un client accède à ces méthodes via l’interface distante. 

L’interface locale d’un enterprise bean contrôle le cycle de vie du bean. 

Elle contient la définition des méthodes permettant de créer, trouver et 

supprimer l’instance d’un enterprise bean. 

En tant que fournisseur de bean, vous devez définir l’interface locale, mais 

vous ne l’implémentez pas. Le conteneur EJB le fait, en générant un objet 

local qui renvoie une référence au bean. 

Il est coutumier de donner à l’interface locale le même nom que celui de la 

classe du bean suivi du suffixe Home. Par exemple, si l’enterprise bean se 

nomme Account, l’interface locale de Account sera AccountHome. Par défaut, 

une interface locale générée par les experts EJB de JBuilder suit cette 

convention, bien que vous ayez la possibilité de changer le nom de 

l’interface lorsque vous utilisez cet expert. 

Cré ation des interfaces locales et distantes 11-1

Cré ation de l’ interface locale 

La classe de base EJBHome 

Toutes les interfaces locales étendent l’interface javax.ejb.EJBHome. Voici la 

définition complète de EJBHome : 

package javax.ejb 

public interface EJBHome extends java.rmi.Remote { 

void remove(Handle handle) throws java.rmi.RemoteException, 

RemoveException; 

void remove(Object primaryKey) throws java.rmi.RemoteException, 

RemoveException; 

EJBMetaData getEJBMetaData() throws RemoteException; 

HomeHandle getHomeHandle() throws RemoteException; 

} 

EJBHome possède deux méthodes remove() pour supprimer les instances des 

enterprise beans. La première méthode remove() identifie l’instance par un 

handle ; la deuxième par une clé primaire. 

Un handle, identificateur d’objet bean sérialisable, a la même durée de vie 

que l’objet enterprise bean qu’il référence. Pour un bean session, le handle 

n’existe que le temps de la session. Pour un bean entité, le handle peut 

persister et un client peut utiliser un handle sérialisé pour rétablir une 

référence à l’objet entité qu’il identifie. 

Un client se servira de la deuxième méthode remove() pour supprimer 

l’instance d’un bean entité en utilisant sa clé primaire. 

getEJBMetaData() renvoie l’interface EJBMetaData de l’objet enterprise bean. 

Cette interface permet au client d’obtenir les informations de 

métadonnées relatives au bean. Son objectif est d’être utilisée par les outils 

de développement qui construisent des applications utilisant des 

enterprise beans déployés. 

Notez que l’interface EJBHome n’a pas de méthode pour créer ou localiser les 

instances d’un enterprise bean. A la place, vous devez ajouter ces 

méthodes aux interfaces locales que vous développez pour vos beans. 

Comme les beans session et les beans entité ont des cycles de vie 

différents, les méthodes définies dans leurs interfaces locales diffèrent. 

Création d’une interface locale pour un bean session 

Un bean session a presque toujours un seul client (sauf occasionnellement 

les beans session stateless). Quand un client crée un bean session, cette 

instance du bean session n’existe que pour l’utilisation de ce client. 

Pour créer une interface locale pour un bean session, 

• Déclarez une interface locale qui étend javax.ejb.EJBHome. 

• Ajoutez la signature d’une méthode create() pour chaque méthode 

ejbCreate() du bean, avec un nombre et des types d’arguments 

correspondant exactement. 



Quand vous utilisez l’expert Enterprise JavaBean de JBuilder, ce dernier 

crée une interface locale avec une méthode create() en même temps qu’il 

crée la classe de l’enterprise bean. Vous pouvez alors ajouter d’autres 

méthodes create() à l’interface locale si vous ajoutez d’autres méthodes 

ejbCreate() à votre bean. Ou, si vous avez déjà la classe d’un enterprise 

bean existant, utilisez l’expert Interfaces EJB de JBuilder pour créer une 

interface locale et une interface distante avec des signatures 

correspondant à celles de votre classe bean. Pour plus d’informations, voir 

Chapitre 3, “Création des enterprise beans avec JBuilder”. 

Si vous choisissez de commencer le développement de votre EJB en créant 

une interface distante, vous pouvez utiliser le Créateur de bean EJB pour 

générer le squelette de la classe du bean et l’interface locale. Pour plus 

d’informations sur le Créateur de bean EJB, voir “Génération de la classe 

du bean à partir d’une interface distante”, page 3-12. 

Méthodes create() des beans session 

L’interface locale d’un bean session fonctionne comme une factory de 

bean session, car elle doit définir une ou plusieurs méthodes create(). 

Quand le client appelle create(), une nouvelle instance du bean est créée. 

En accord avec la spécification EJB, chaque méthode create() définie dans 

l’interface locale doit 

• Renvoyer le type d’interface distante du bean session. 

• S’appeler create(). 

• Correspondre à une méthode ejbCreate() de la classe du bean session. 

Le nombre et les types d’arguments de chaque méthode create() doit 

concorder avec sa méthode ejbCreate() correspondante dans la classe 

du bean session. 

• Déclencher l’exception java.rmi.RemoteException. 

• Déclencher l’exception javax.ejb.CreateException. 

• Utiliser ses paramètres, s’il y en a, pour initialiser le nouvel objet bean 

session. 

Vous pouvez utiliser les experts EJB pour être sûr que ses règles seront 

suivies. 

L’exemple de code suivant montre deux méthodes create() possibles de 

l’interface locale d’un bean session. Les parties en gras sont obligatoires : 

public interface AtmHome extends javax.ejb.EJBHome { 

Atm create() 


Atm create(Profile preferredProfile) 


} 



Création d’une interface locale pour un bean entité 

Un bean entité est destiné à servir plusieurs clients. Quand un client crée 

une instance de bean entité, n’importe quel autre client peut également 

l’utiliser. 

Pour créer une interface locale pour un bean entité, 

• Déclarez une interface qui étend javax.ejb.EJBHome. 

• Ajoutez la signature d’une méthode create() pour chaque méthode 

ejbCreate() du bean, avec les signatures correspondant exactement. 

• Ajoutez la signature d’une méthode find pour chaque méthode find du 

bean, avec les signatures correspondant exactement. 

Quand vous utilisez l’expert Enterprise JavaBean ou le Modeleur Bean 

entité EJB de JBuilder, ce dernier crée une interface locale avec une 

méthode create() en même temps qu’il crée la classe de l’enterprise bean. 

Vous pouvez alors ajouter d’autres méthodes create() à l’interface locale si 

vous ajoutez d’autres méthodes ejbCreate() à votre bean. Ou, si vous avez 

déjà la classe d’un enterprise bean existant, utilisez l’expert Interfaces EJB 

de JBuilder pour créer une interface locale et une interface distante avec 

des signatures correspondant à celles de votre classe bean. Pour plus 

d’informations, voir Chapitre 3, “Création des enterprise beans avec 

JBuilder”. 

Si vous choisissez de commencer le développement de votre EJB en créant 

une interface distante, vous pouvez utiliser le Créateur de bean EJB pour 

générer le squelette de la classe du bean et l’interface locale. Pour plus 

d’informations sur le Créateur de bean EJB, voir “Génération de la classe 

du bean à partir d’une interface distante”, page 3-12. 

Méthodes create() des beans entité 

Comme l’interface locale d’un bean session, l’interface locale d’un bean 

entité fonctionne comme une factory de bean entité, car elle doit définir 

une ou plusieurs méthodes create(). En accord avec la spécification EJB, 

chaque méthode create() définie doit 

• Déclencher l’exception java.rmi.RemoteException. 

• Déclencher l’exception javax.ejb.CreateException. 

• Renvoyer le type d’interface distante du bean entité. 

• S’appeler create(). 

• Correspondre à une méthode ejbCreate() de la classe du bean session. 

Le nombre et les types d’arguments de chaque méthode create() doit 

concorder avec sa méthode ejbCreate() correspondante dans la classe 

du bean session. 



• Doit inclure dans les exceptions de la clause throws toutes les 

exceptions déclenchées par les méthodes ejbCreate() et ejbPostCreate() 

correspondantes de la classe du bean entité. En d’autres termes, 

l’ensemble des exceptions de la méthode create() doit être un 

sur-ensemble de la réunion des exceptions des deux méthodes 

ejbCreate() et ejbPostCreate(). Le type de renvoi de la méthode 

ejbCreate() est la classe clé primaire. 

• Utiliser ses paramètres, s’il y en a, pour initialiser le nouvel objet bean 

entité. 

Méthodes find des beans entité 

Comme les beans entité ont généralement une longue durée de vie et 

peuvent être utilisés par plusieurs clients, une instance du bean entité 

existe probablement déjà lorsqu’une application client en a besoin. Dans 

ce cas, le client n’a pas besoin de créer une instance du bean entité, mais il 

a besoin de localiser celle qui existe. C’est pourquoi l’interface locale d’un 

bean entité définit une ou plusieurs méthodes find. 

Les beans session n’ont pas besoin de méthode find puisqu’ils servent un 

seul client, l’application qui a créé le bean. Le client n’a pas besoin de 

trouver l’instance du bean session — il sait déjà où elle se trouve. 

L’interface locale d’un bean entité doit définir la méthode find par défaut, 

findByPrimaryKey(). Elle permet à un client de localiser un objet entité 

utilisant une clé primaire : 

findByPrimaryKey( key) 

throws java.rmi.RemoteException, FinderException; 

findByPrimaryKey() a un seul argument, la clé primaire. Son type de renvoi 

est l’interface distante du bean entité. Dans le descripteur de déploiement 

du bean, vous indiquez au conteneur le type de la clé primaire. 

findByPrimaryKey() renvoie toujours un seul objet entité. 

Vous pouvez définir d’autres méthodes find dans l’interface locale. 

Chaque méthode find doit avoir une implémentation correspondante 

dans la classe d’un bean entité dont la persistance est gérée par le bean. 

Pour la persistance gérée par le conteneur, c’est le conteneur qui 

implémente les méthodes find. Chaque méthode find doit respecter les 

conventions suivantes : 

• Le type de renvoi doit être le type de l’interface distante, ou, pour les 

méthodes find qui renvoient plus d’un objet entité, un type de 

collection dont le type de contenu est le type de l’interface distante. Les 

types corrects de collection Java sont java.util.Enumeration et 

java.util.Collection. 

• Le nom de la méthode find doit toujours commencer par le préfixe 

find. Le nom de la méthode find correspondante dans la classe du bean 

entité doit commencer par le préfixe ejbFind. 


Cré ation de l’ interface distante 

• La méthode doit déclencher l’exception java.rmi.RemoteException. 

• La méthode doit déclencher l’exception javax.ejb.FinderException. 

• La clause throws de la méthode find de l’interface locale doit 

correspondre à la clause throws de la méthode ejbFind 

correspondante dans la classe du bean entité. 

L’exemple d’interface locale suivant contient deux méthodes create() et 

deux méthodes find. Les parties en gras sont obligatoires : 

Création de l’interface distante 

public interface AccountHome extends javax.ejb.EJBHome { 

} 

Account create(String accountID) 


Account create(String accountID, float initialBalance) 


Account findByPrimaryKey(String key) 


Account findBySocialSecurity(String socialSecurityNumber) 


L’interface distante que vous créez pour votre enterprise bean décrit les 

méthodes métier qu’une application client peut appeler. Pendant que 

vous définissez les méthodes dans l’interface distante, vous implémentez 

ces mêmes méthodes dans la classe de l’enterprise bean. Les clients d’un 

enterprise bean n’ont jamais accès directement au bean. Ils accèdent à ses 

méthodes via l’interface distante. 

Pour créer une interface distante, 

• Déclarez une interface qui étend javax.ejb.EJBObject. 

• Déclarez dans l’interface distante chaque méthode métier qu’une 

application client pourra appeler dans l’enterprise bean, dont les 

signatures correspondent exactement à celles de la classe du bean. 

Lorsque vous utilisez les experts EJB de JBuilder, JBuilder crée pour vous 

une interface distante qui étend EJBObject. Vous pouvez utiliser le 

concepteur de bean pour spécifier quelles méthodes métier de votre bean 

apparaîtront dans l’interface distante. 

Chaque méthode définie dans l’interface distante doit suivre ces règles, 

qui sont les mêmes pour les beans session et pour les beans entité : 

• Elle doit être publique. 



• Elle doit déclencher l’exception java.rmi.RemoteException. 

• Sa valeur de renvoi et tous ses arguments doivent être des types valides 

pour RMI-IIOP. 

• Une méthode doit exister dans l’interface distante pour chaque 

méthode de la classe de l’enterprise bean que le client pourra appeler. 

Les méthodes de l’interface distante et du bean lui-même doivent 

porter le même nom, avoir le même nombre d’arguments de mêmes 

types, avoir le même type de valeur de renvoi, et elles doivent 

déclencher les mêmes exceptions ou un sous-ensemble des exceptions 

des méthodes de l’interface distante. 

L’exemple de code suivant montre l’interface distante appelée Atm d’un 

bean session ATM. L’interface distante Atm définit une méthode métier 

appelée transfer(). Les parties en gras sont obligatoires : 

public interface Atm extends javax.ejb.EJBObject{ 

} 

public void transfer(String source, String target, float amount) 

throws java.rmi.RemoteException, InsufficientFundsException; 

La méthode transfer() déclarée dans l’interface Atm déclenche deux 

exceptions : l’exception obligatoire java.rmi.RemoteException et 

InsufficientFundsException, qui est une exception spécifique à une 

application. 

L’interface EJBObject 

L’interface distante étend l’interface javax.ejb.EJBObject. Voici le code 

source de EJBObject : 


public interface EJBObject extends java.rmi.Remote ( 

public EJBHome getEJBHome() throws java.rmi.RemoteException; 

public Object getPrimaryKey() throws java.rmi.RemoteException; 

public void remove() throws java.rmi.RemoteException, 

java.rmi.RemoveException; 

public Handle getHandle() throws java.rmi.RemoteException; 

boolean isIdentical (EJBObject other) throws java.rmi.RemoteException; 

} 

La méthode getEJBHome() permet à une application d’obtenir l’interface 

locale du bean. Si le bean est un bean entité, la méthode getPrimaryKey() 

renvoie la clé primaire du bean. La méthode remove() supprime 

l’enterprise bean. getHandle() renvoie un handle persistant à l’instance du 

bean. Utilisez isIdentical() pour comparer deux enterprise beans. 

Le conteneur EJB crée une interface EJBObject pour l’enterprise bean. 

Comme l’interface distante étend l’interface EJBObject, l’interface EJBObject 

créée par le conteneur inclut les implémentations de toutes les méthodes 



de l’interface EJBObject ainsi que les méthodes métier que vous définissez 

dans l’interface distante. L’interface EJBObject instanciée est visible sur le 

réseau et agit comme un proxy pour le bean. Elle possède un stub et un 

squelette. Le bean lui-même n’est pas visible sur le réseau. 


12 

Chapitre 

Chapitre12Développement des clients 

des enterprise beans 

Le client d’un enterprise bean est une application — application 

autonome, servlet ou applet — ou un autre enterprise bean. Dans tous les 

cas, le client doit effectuer les opérations suivantes pour utiliser un 

enterprise bean : 

• Localiser l’interface locale du bean. La spécification EJB précise que le 

client doit utiliser l’API JNDI (Java Naming and Directory Interface) 

pour localiser les interfaces locales. 

• Obtenir la référence à l’interface distante d’un objet enterprise bean. 

Cela implique l’utilisation de méthodes définies dans l’interface locale 

du bean. Vous pouvez soit créer un bean session, soit créer ou trouver 

un bean entité. 

• Appeler une ou plusieurs méthodes définies par l’enterprise bean. Un 

client ne peut pas appeler directement les méthodes définies par 

l’enterprise bean. A la place, le client appelle les méthodes de l’interface 

distante de l’objet enterprise bean. Les méthodes définies dans 

l’interface distante sont celles que l’enterprise bean a exposées aux 

clients. 

Les sections suivantes décrivent l’application client SortClient.java, qui 

appelle le bean session exemple SortBean. SortBean est un bean session 

stateless qui implémente un algorithme de fusion et de tri. Voici le code de 

SortClient : 

// SortClient.java 

... 

public class SortClient { 

... 

D é veloppement des clients des enterprise beans 12-1

Localisation de l’ interface locale 

Localisation de l’interface locale 

Obtenir l’interface distante 

public static void main(String[] args) throws Exception { 

javax.naming.Context context; 

{ // obtient un contexte JNDI en utilisant le service d’annuaire 

context = new javax.naming.InitialContext(); 

} 

Object objref = context.lookup("sort"); 

SortHome home = (SortHome) javax.rmi.PortableRemoteObject.narrow(objref, 

SortHome.class); 

Sort sort = home.create(); 

... // effectue le travail de tri et de fusion 

sort.remove(); 

} 

} 

SortClient importe les classes JNDI requises et les interfaces locale et 

distante SortBean. Le client utilise l’API JNDI pour localiser l’interface 

locale d’un enterprise bean. D’abord, le client doit obtenir un contexte 

d’annuaire initial JNDI. Le code de SortClient instancie un nouvel objet 

javax.naming.Context, qui est appelé InitialContext. Le client utilise alors la 

méthode lookup() du contexte pour renvoyer ce nom à une interface locale. 

La méthode contextuelle lookup() renvoie un objet de type 

java.lang.Object. Votre code doit transtyper l’objet renvoyé dans le type 

attendu. Le code SortClient montre une partie du code client de l’exemple 

de tri. La routine main() commence par utiliser le service d’annuaire JNDI 

et la méthode lookup() de son contexte pour localiser l’interface locale. 

Vous passez le nom de l’interface distante, qui est dans ce cas sort, à la 

méthode context.lookup(). Notez que le programme transtype 

éventuellement les résultats de la méthode context.lookup() en SortHome, 

qui est le type de l’interface locale. 

Une fois que vous avez l’interface locale d’un enterprise bean, il vous faut 

une référence à l’interface distante du bean. Pour cela, utilisez les 

méthodes create ou find de l’interface locale. La méthode à utiliser dépend 

du type d’enterprise bean et des méthodes que le fournisseur du bean a 

défini dans l’interface locale. 

Beans session 

Si l’enterprise bean est un bean session, le client utilise une méthode create 

pour renvoyer l’interface distante. Les beans session n’ont pas de méthode 

find. Si le bean session est stateless, il aura juste une méthode create(), et il 


Obtenir l’ interface distante 

sera donc le seul que le client devra appeler pour obtenir l’interface 

distante. La méthode create() par défaut n’a pas de paramètre. Donc, pour 

l’exemple de code SortClient, l’appel pour obtenir l’interface distante 

ressemble à ceci : 

Sort sort = home.create(); 

L’exemple du chariot traité au Chapitre 9, “Développement 

des beans session”, d’autre part, utilise un bean session stateful et son 

interface locale, CartHome, implémente plusieurs méthodes create(). Une de 

ses méthodes create() prend trois paramètres, qui ensemble identifient 

l’acheteur du contenu du chariot, et renvoie une référence à l’interface 

distante Cart. CartClient définit les valeurs des trois paramètres — 

cardHolderName, creditCardNumber, et expirationDate — puis appelle la 

méthode create(). Voici le code : 

Cart cart; 

{ 

String cardHolderName = "Jack B. Quick"; 

String creditCardNumber = "1234-5678-9012-3456"; 

Date expirationDate = new GregorianCalendar(2001, Calendar.JULY, 

1).getTime(); 

cart = home.create(cardHolderName, creditCardNumber, expirationDate); 

} 

Beans entité 

S’il s’agit d’un bean entité, utilisez soit une méthode create, soit une 

méthode find pour obtenir l’interface distante. Comme un objet entité 

représente des données sous-jacentes stockées dans une base de données, 

et que ces données sont persistantes, les beans entité ont généralement une 

longue durée de vie. Donc, le client a la plupart du temps seulement 

besoin de trouver le bean entité qui représente les données plutôt que de 

créer un nouvel objet entité, qui voudrait créer et stocker de nouvelles 

données dans la base sous-jacente. 

Un client utilise une opération de recherche (find) pour localiser un objet 

entité existant, comme une ligne spécifique à l’intérieur d’une table dans 

une base de données relationnelle. C’est-à-dire que les opérations de 

recherche localisent les entités de données qui ont été préalablement 

insérées dans un stockage de données. Les données peuvent avoir été 

ajoutées au datastore par un bean entité ou avoir été ajoutées à l’extérieur 

du contexte EJB, par exemple directement depuis un SGBD (système de 

gestion de bases de données). Ou, dans le cas de systèmes existants, les 

données peuvent avoir existé avant l’installation du conteneur EJB. 

Un client utilise la méthode create() d’un objet bean entité pour créer une 

nouvelle entité des données qui sera stockée dans la base de données 

sous-jacente. La méthode create() d’un bean entité insère l’état entité dans 


Obtenir l’ interface distante 

la base de données, initialisant les variables de l’entité avec les valeurs des 

paramètres de la méthode create(). 

Chaque instance d’un bean entité doit avoir une clé primaire qui l’identifie 

de manière unique. L’instance d’un bean entité peut aussi avoir des clés 

secondaires qui peuvent être utilisées pour localiser un objet entité 

particulier. 

Les méthodes find et la classe de la clé primaire 

La méthode find par défaut d’un bean entité est findByPrimaryKey(), qui 

localise l’objet entité en utilisant la valeur de sa clé primaire. Voici sa 

signature : 

findByPrimaryKey( primaryKey) 

Chaque bean entité doit implémenter une méthode findByPrimaryKey(). Le 

paramètre primaryKey est la classe d’une clé primaire distincte qui est 

définie dans le descripteur de déploiement. <key type> est le type de 

la clé primaire et ce doit être un type valide pour RMI-IIOP. La classe de la 

clé primaire peut être n’importe quelle classe, comme une classe Java ou 

une classe que vous avez vous-même écrite. 

Par exemple, supposons que vous ayez un bean entité Account pour lequel 

vous avez défini la classe de clé primaire AccountPK. AccountPK, de type 

String, contient l’identificateur du bean Account. Pour obtenir une référence 

à une instance spécifique du bean entité Account, définissez AccountPK par 

l’identificateur de compte et appelez la méthode findByPrimaryKey() 

comme indiqué ici : 

AccountPK accountPK = new AccountPK("1234-56-789"); 

Account source = accountHome.findByPrimaryKey(accountPK); 

Les fournisseurs de beans peuvent définir d’autres méthodes find que les 

clients puissent utiliser. 

Méthodes create et remove 

Un client peut également créer des beans entité en utilisant des méthodes 

create définies dans l’interface locale. Quand un client invoque une 

méthode create pour un bean entité, la nouvelle instance de l’objet entité 

est enregistré dans le datastore. Le nouvel objet entité a toujours une 

valeur de clé primaire qui est son identificateur. Son état peut être 

initialisé par les valeurs transmises comme paramètres à la méthode 

create. 

N’oubliez pas qu’un bean entité existe aussi longtemps qu’il y a des 

données dans la base de données. La vie du bean entité ne se limite pas à 

la session du client. Le bean entité peut être supprimé par l’appel d’une 

des méthodes remove du bean. Ces méthodes suppriment le bean et la 

représentation sous-jacente des données entité de la base de données. Il est 

également possible de supprimer directement un objet entité, par exemple 


Appel des méthodes 

Appel des mé thodes 

en supprimant un enregistrement de la base de données par le biais du 

SGBD ou d’une application existante. 

Une fois que le client détient une référence à l’interface distante du bean, il 

peut invoquer les méthodes définies pour le bean dans l’interface distante. 

Le client est particulièrement intéressé par les méthodes incorporant la 

logique métier du bean. 

Par exemple, le code suivant est extrait d’un client qui accède au bean 

session de l’exemple du chariot (cart). Le code montré ici commence au 

point où il a créé une nouvelle instance du bean session pour un détenteur 

de chariot et récupéré une référence Cart à l’interface distante. Le client est 

prêt à invoquer les méthodes du bean : 

... 

Cart cart; 

{ 

... 

// obtient une référence à l’interface distante du bean 


} 

// crée un nouvel objet livre 

Book knuthBook = new Book("The Art of Computer Programming", 49.95f); 

// ajoute le nouvel article livre au chariot 

cart.addItem(knuthBook); 

... 

// liste les articles actuellement dans le chariot 

summarize(cart); 

cart.removeItem(knuthBook); 

... 

Le client crée d’abord un nouvel objet livre, en définissant ses paramètres 

title (titre) et price (prix). Ensuite, il invoque la méthode métier addItem() 

de l’enterprise bean pour ajouter l’objet livre à un chariot. Le bean session 

Cart définit la méthode addItem() et l’interface distante Cart la rend 

publique. Le client ajoute d’autres articles (qui ne figurent pas ici), puis 

appelle sa propre méthode summarize() pour faire la liste des articles se 

trouvant dans le chariot. Enfin, la méthode remove() supprime l’instance 

du bean. Notez qu’un client appelle les méthodes d’un enterprise bean de 

la même façon qu’il appelle n’importe quelle méthode, telle sa propre 

méthode summarize(). 


Suppression des instances de beans 

Suppression des instances de beans 

La méthode remove() opère différemment pour les beans session et pour 

les beans entité. Comme un objet session existe pour un seul client et n’est 

pas permanent, le client d’un bean session doit appeler la méthode 

remove() quand il en a terminé avec l’objet session. Deux méthodes 

remove() s’offrent à lui : le client peut supprimer l’objet session avec la 

méthode javax.ejb.EJBObject.remove() ou le handle de session avec la 

méthode javax.ejb.EJBHome.remove(Handle handle). Pour plus 

d’informations, voir “Référencement d’un bean avec son handle”, 

page 12-6. 

Bien qu’il ne soit pas obligatoire qu’un client supprime un objet session, 

c’est une bonne habitude à prendre. Si un client ne supprime pas un objet 

bean session stateful, le conteneur supprimera éventuellement l’objet 

après un certain temps, spécifié par un délai d’attente. La valeur du délai 

d’attente est une propriété du déploiement. Un client peut cependant 

garder un handle sur la session pour y faire référence plus tard. 

Les clients des beans entité n’ont pas ces problèmes parce que les beans 

entité ne leurs sont associés que pour la durée d’une transaction et que le 

conteneur prend en charge leur durée de vie, y compris leur activation et 

leur désactivation. Le client d’un bean entité n’appelle la méthode remove() 

du bean que si l’objet entité doit être supprimé de la base de données 

sous-jacente. 

Référencement d’un bean avec son handle 

Un handle est une autre façon de référencer un enterprise bean. Un handle 

est une référence sérialisable à un bean. Vous pouvez obtenir un handle 

depuis l’interface distante du bean. Une fois que vous avez le handle, vous 

pouvez l’écrire dans un fichier (ou dans tout autre stockage persistant). 

Plus tard, vous pourrez récupérer le handle depuis son stockage et 

l’utiliser pour établir à nouveau une référence à l’enterprise bean. 

Cependant, vous ne pouvez utiliser le handle de l’interface distante que 

pour recréer la référence au bean. Vous ne pouvez pas l’utiliser pour 

recréer le bean lui-même. Si un autre processus a supprimé le bean ou si le 

système a supprimé l’instance du bean, alors une exception est déclenchée 

au moment où le client tente de rétablir la référence à ce bean. 

Quand vous n’êtes pas sûr que l’instance du bean existera toujours, plutôt 

que d’utiliser un handle vers l’interface distante, vous pouvez stocker le 

handle local du bean et recréer l’objet bean plus tard en invoquant la 

méthode create ou la méthode find du bean. 

Une fois que le client a créé une instance du bean, il peut utiliser la 

méthode getHandle() pour obtenir un handle sur cette instance. Une fois 


Gestion des transactions 

Gestion des transactions 

qu’il a le handle, il peut l’écrire dans un fichier sérialisé. Plus tard, le 

programme client peut lire le fichier sérialisé et transtyper l’objet lu en 

type Handle. Ensuite, il appelle la méthode getEJBObject() sur le handle 

pour obtenir la référence au bean, en réduisant les résultats de 

getEJBObject() en un type valide pour le bean. 

Par exemple, le programme CartClient pourrait faire ceci pour utiliser un 

handle sur le bean session Cart : 

import java.io; 

import javax.ejb.Handle; 

... 

Cart cart; 

... 


// appelle getHandle() sur l’objet chariot pour obtenir son handle 

cartHandle = cart.getHandle(); 

// écrit le handle dans un fichier sérialisable 

FileOutputStream f = new FileOutputStream ("carthandle.ser"); 

ObjectOutputStream o = new ObjectOutputStream(f); 

o.writeObject(myHandle); 

o.flush(); 

o.close(); 

... 

// lit ultérieurement le handle dans le fichier 

FileInputStream fi = new FileInputStream ("carthandle.ser"); 

ObjectInputStream oi = new ObjectInputStream(fi); 

//lit l’objet dans le fichier et change son type en Handle 

cartHandle = (Handle)oi.readObject(); 

oi.close(); 

... 

// Utilise le handle pour faire référence à l’instance du bean 

Cart cart = (Cart) 

javax.rmi.PortableRemoteObject.narrow(cartHandle.getEJBObject(), 

Cart class); 

... 

Quand il en a terminé avec le handle du bean session, le client peut le 

supprimer en appelant la méthode javax.ejb.EJBHome.remove(Handle 

handle). 

Un programme client peut gérer ses propres transactions au lieu de laisser 

l’enterprise bean (ou son conteneur) le faire. Un client qui gère ses propres 

transactions le fait exactement de la même manière qu’un bean session. 


D é couvrir les informations sur le bean 

Quand un client gère ses propres transactions, il est responsable des 

limites de la transaction. C’est-à-dire qu’il doit explicitement démarrer la 

transaction et terminer (valider ou annuler) la transaction. 

Un client utilise l’interface javax.transaction.UserTransaction pour gérer ses 

propres transactions. Il doit d’abord obtenir un référence à l’interface 

UserTransaction, en utilisant JNDI pour cela. Une fois qu’il a le contexte 

UserTransaction, le client utilise la méthode UserTransaction.begin() pour 

démarrer la transaction, suivie plus tard de la méthode 

UserTransaction.commit() pour valider et terminer la transaction (ou de 

UserTransaction.rollback() pour annuler et terminer la transaction). Entre 

les deux, le client accède aux objets EJB, etc. 

Le code suivant montre comment un client pourrait gérer ses propres 

transactions ; le code spécifique à la gestion des transactions par le client 

est en gras : 

... 

import javax.naming.InitialContext; 

import javax.transaction.UserTransaction; 

... 

public class clientTransaction { 

public static void main (String[] argv) { 

InitialContext initContext = new InitialContext(); 

UserTransaction ut = null; 

ut = (UserTransaction)initContext.lookup("java:comp/UserTransaction"); 

// démarre une transaction 

ut.begin(); 

// fait un travail de transaction 

... 

// valide ou annule la transaction 

ut.commit(); // ou ut.rollback(); 

... 

} 

} 

Pour plus d’informations sur les transactions, voir Chapitre 13, “Gestion 

des transactions”. 

Découvrir les informations sur le bean 

Les informations sur un enterprise bean sont des métadonnées. Un client 

peut obtenir des métadonnées sur un bean en utilisant la méthode 

getMetaData() de l’interface locale de l’enterprise bean. 

La méthode getMetaData() est le plus souvent utilisée dans les 

environnements de développement et chez les constructeurs d’outils qui 

ont besoin de découvrir les informations sur un enterprise bean, par 


Cré ation d’ un client avec JBuilder 

exemple pour lier ensemble des beans qui ont déjà été installés. Les scripts 

des clients peuvent également vouloir obtenir les métadonnées relatives 

au bean. 

Une fois que le client a récupéré la référence à l’interface locale, il peut 

appeler sa méthode getEJBMetaData(). Ensuite, le client peut appeler les 

méthodes de l’interface EJBMetaData pour extraire des informations 

comme : 

• L’interface locale EJBHome du bean, en utilisant la méthode 

EJBMetaData.getEJBHome(). 

• L’objet classe de l’interface locale du bean, y compris ses interfaces, 

classes, champs et méthodes, en utilisant la méthode 

EJBMetaData.getHomeInterfaceClass(). 

• L’objet classe de l’interface distante du bean, y compris toutes les 

informations de classe, en utilisant la méthode 

EJBMetaData.getRemoteInterfaceClass(). 

• L’objet classe de la clé primaire du bean, en utilisant la méthode 

EJBMetaData.getPrimaryKeyClass(). 

• Si le bean est un bean session ou un bean entité, en utilisant la méthode 

EJBMetaData.isSession(). La méthode renvoie true s’il s’agit d’un bean 

session. 

• Si le bean session est stateless ou stateful, en utilisant la méthode 

EJBMetaData.isStatelessSession(). La méthode renvoie true si le bean est 

stateless. 

Voici l’interface EJBMetaData dans sa totalité : 


public interface EJBMetaData { 

EJBHome getEJBHome(); 

Class getHome InterfaceClass(); 

Class getRemoteInterfaceClass(); 

Class getPrimaryKeyClass(); 

boolean isSession(); 

boolean isStatelessSession(); 

} 

Création d’un client avec JBuilder 

Vous pouvez utiliser JBuilder pour commencer la création de votre client 

dans les meilleures conditions. JBuilder offre un expert Client Test EJB 

pour créer une application client simple permettant de tester votre 

enterprise bean. Vous pouvez également l’utiliser pour commencer à 

construire votre application client réelle. Indiquez à l’expert le nom de 

l’un de vos enterprise beans auquel le client doit accéder, et l’expert écrira 


Cré ation d’ un client avec JBuilder 

le code permettant d’obtenir un contexte d’annuaire, localisera l’interface 

locale du bean et donnera une référence sécurisée à son interface distante. 

Votre client est susceptible d’appeler plusieurs beans, c’est pourquoi vous 

devez effectuer ces étapes dans votre code client pour les autres beans 

qu’il devra accéder. Et vous ajouterez vous-même à votre code client les 

appels permettant d’accéder à la logique métier des enterprise beans. 

Pour plus d’informations sur l’utilisation de l’expert Client test EJB, voir 

“Création d’un client de test”, page 5-1. 


13 

Chapitre 

Chapitre13Gestion des 

transactions 

Vous pouvez bénéficier du développement d’applications sur des 

plates-formes comme Java 2 Enterprise Edition (J2EE) qui supportent les 

transactions. Un système basé sur les transactions facilite le 

développement des applications car il vous libère, vous le développeur, 

des questions complexes comme la récupération après panne et la 

programmation multi-utilisateur. Les transactions ne sont pas limitées à 

une seule base de données ni à un seul site. Les transactions distribuées 

peuvent mettre à jour simultanément plusieurs bases de données sur 

plusieurs sites. 

Un développeur divise habituellement la totalité du travail d’une 

application en une série d’unités. Chaque unité de travail est une 

transaction distincte. Au fil de la progression de l’application, le système 

sous-jacent garantit que chaque unité de travail, chaque transaction, se 

termine complètement sans l’interférence d’un autre processus. Si ce n’est 

pas le cas, le système annule la transaction et renverse totalement le travail 

qu’a effectué la transaction de sorte que l’application se retrouve dans 

l’état précédant cette transaction. 

Caractéristiques des transactions 

Habituellement, on appelle transactions les opérations d’accès à une base 

de données. Tous les accès à la base de données se produisent dans le 

contexte d’une transaction. Toutes les transactions partagent les 

caractéristiques suivantes, connues sous l’abréviation ACID : 

• Atomicité 

Généralement, une transaction est constituée de plusieurs opérations 

simples. L’atomicité exige que toutes les opérations d’une transaction 

réussissent pour que la transaction soit considérée comme terminée. Si 

Gestion des transactions 13-1

Support des transactions dans le conteneur 

toutes les opérations d’une transaction ne peuvent être effectuées, alors 

aucune d’entre elles ne pourra l’être. 

• Cohérence 

Il s’agit de la cohérence de la base de données. Une transaction doit 

faire passer la base de données d’un état cohérent à un autre et doit 

préserver l’intégrité sémantique et physique de la base. 

• Isolation 

L’isolation exige que chaque transaction apparaisse comme la seule 

opération manipulant à un certain moment les données de la base. Bien 

que d’autres transactions puissent être exécutées simultanément, une 

transaction ne doit pas voir ces manipulations tant qu’elles ne sont pas 

complètement terminées et que le travail n’est pas validé. En raison de 

l’interdépendance des mises à jour, une transaction pourrait avoir une 

vue incohérente des données et voir juste un sous-ensemble des mises à 

jour d’une autre transaction. L’isolation protège de ce type 

d’incohérence. 

L’isolation est liée à la simultanéité des transactions. Il existe trois 

niveaux d’isolation. Le plus haut niveau d’isolation limite l’étendue de 

la simultanéité. Le plus haut niveau d’isolation se produit lorsque 

toutes les transactions peuvent être sérialisées. C’est-à-dire, que le 

contenu de la base de données apparaît comme si chaque transaction 

s’exécutait seule jusqu’à la fin avant que ne commence la transaction 

suivante. Certaines applications, cependant, peuvent supporter un 

niveau d’isolation réduit afin d’autoriser un plus haut degré de 

simultanéité. Généralement, ces applications exécutent un grand 

nombre de transactions simultanées, même si ces transactions lisent des 

données qui peuvent être partiellement mises à jour et peut-être 

incohérentes. 

• Durabilité 

La durabilité signifie que les mises à jour effectuées par des transactions 

validées persistent même en cas de panne. La durabilité garantit que les 

mises à jour validées resteront dans la base de données malgré les 

pannes qui pourraient survenir après la validation, et que la base de 

données pourra être récupérée après une panne du système ou d’un 

support. 

Support des transactions dans le conteneur 

Un conteneur EJB supporte les transactions simples, mais pas les 

transactions imbriquées. Il propage également les transactions 

implicitement. Cela signifie que vous n’avez pas besoin de transmettre 

explicitement le contexte de la transaction par le biais d’un paramètre, car 

le conteneur s’en charge pour garantir la transparence au client. 


Enterprise beans et transactions 

N’oubliez pas que les JSP et les servlets, bien qu’ils puissent agir en tant 

que clients, sont conçus pour être des composants transactionnels. Utilisez 

des enterprise beans pour effectuer le travail transactionnel. Quand vous 

invoquez un enterprise bean pour effectuer le travail transactionnel, le 

bean et le conteneur configurent la transaction correctement. 


Les enterprise beans et le conteneur EJB simplifient considérablement la 

gestion des transactions. Grâce aux enterprise beans, une application peut 

mettre à jour des données dans plusieurs bases de données en une seule 

transaction, et ces bases de données peuvent résider sur plusieurs 

serveurs EJB. 

Traditionnellement, une application responsable de la gestion des 

transactions doit effectuer les tâches suivantes : 

• Créer l’objet transaction 

• Démarrer explicitement la transaction 

• Garder la trace du contexte de la transaction 

• Valider la transaction quand toutes les mises à jour sont faites 

Une telle application exigerait un développeur très doué et des erreurs 

pourraient s’y glisser facilement. 

Si vous utilisez des enterprise beans, le conteneur gère pour vous la 

plupart, sinon tous, des aspects de la transaction. Il commence et termine 

la transaction et maintient son contexte tout au long de la vie de l’objet 

transaction. Vos responsabilités sont considérablement réduites, en 

particulier pour les transactions dans des environnements distribués. 

Les attributs de transaction d’un enterprise bean sont déclarés au moment 

du déploiement. Ces attributs de transaction indiquent si le conteneur 

gère les transactions du bean ou si le bean gère ses propres transactions, et 

jusqu’où. 

Comparaison entre les transactions gérées par le bean et 

celles gérées par le conteneur 

Lorsqu’un enterprise bean effectue par programme sa propre démarcation 

des transactions au sein de ses méthodes métier, on parle de transactions 

gérées par le bean. (Démarquer une transaction signifie indiquer où une 

transaction commence et où elle se termine.) Lorsqu’un bean délègue 

toutes les démarcations de transactions à son conteneur EJB, le conteneur 

effectue la démarcation des transactions selon les instructions de 

déploiement de l’assembleur de l’application. On parle ici de transactions 

gérées par le conteneur. 



Les beans session stateful et stateless peuvent tous deux utiliser l’un ou 

l’autre type de transaction. Cependant, un bean ne peut pas utiliser les 

deux types de gestion des transactions en même temps. Le fournisseur du 

bean décide quel type le bean session utilisera. Un bean entité ne peut 

utiliser que les transactions gérées par le conteneur 

Vous pourriez souhaiter qu’un bean gère ses propres transactions si vous 

vouliez démarrer une transaction en tant que partie d’une opération et la 

terminer en tant que partie d’une autre opération. Cependant, vous 

rencontreriez des problèmes si une opération appelait la méthode qui 

démarre la transaction et qu’aucune opération n’appelait la méthode qui 

la termine. 

Chaque fois que c’est possible, écrivez des enterprise beans qui utilisent 

les transactions gérées par le conteneur. Ils exigent moins de travail de 

votre part et amènent moins d’erreurs. De plus, il est plus facile de 

personnaliser un bean utilisant les transactions gérées par le conteneur et 

de s’en servir pour composer d’autre beans. 

Attributs des transactions 

Les enterprise beans qui utilisent des transactions gérées par le conteneur 

ont des attributs de transaction associés à chaque méthode du bean ou au 

bean lui-même. La valeur d’un attribut indique au conteneur comment il 

doit gérer les transactions concernant le bean. Il existe six attributs de 

transaction différents que l’assembleur de l’application, ou celui qui la 

déploie, peut associer à chacune des méthodes du bean : 

• Required 

Garantit que le travail effectué par la méthode associée se trouve dans 

un contexte de transaction globale. Si l’appelant a déjà un contexte de 

transaction, le conteneur utilise le même contexte. Si l’appelant n’a pas 

de contexte de transaction, le conteneur commence automatiquement 

une nouvelle transaction. L’utilisation de cet attribut permet de 

composer plusieurs beans et de coordonner facilement le travail de tous 

ces beans en utilisant la même transaction globale. 

• RequiresNew 

Utilisé quand vous ne voulez pas la méthode associée à une transaction 

existante. Il garantit que le conteneur commence toujours une nouvelle 

transaction. 

• Supports 

Permet à la méthode d’éviter d’utiliser une transaction globale. 

N’utilisez cet attribut que lorsque la méthode d’un bean accède à une 

seule ressource de transaction, ou à aucune, et si la méthode n’invoque 

pas un autre enterprise bean. Comme cet attribut épargne le coût des 

transactions globales, son utilisation optimise votre bean. Si cet attribut 



est défini et qu’une transaction globale existe déjà, le conteneur 

invoque la méthode et joint la transaction globale existante. S’il n’existe 

aucune transaction globale, le conteneur démarre une transaction locale 

pour la méthode et la transaction se termine à la fin de la méthode. 

• NotSupported 

Permet également au bean d’éviter d’utiliser une transaction globale. Si 

un client appelle la méthode avec un contexte de transaction, le 

conteneur la suspend. A la fin de la méthode, la transaction globale 

reprend. 

• Mandatory 

Le client qui appelle une méthode avec cet attribut de transaction doit 

déjà être associé à une transaction. Sinon, le conteneur déclenche une 

javax.transaction.TransactionRequiredException. Cet attribut rend moins 

souple l’utilisation du bean puisqu’il part d’hypothèses sur la 

transaction de l’appelant. 

• Never 

Le client qui appelle une méthode avec cet attribut de transaction ne 

doit pas avoir de contexte de transaction. S’il en a un, le conteneur 

déclenche une exception. 

Transactions locales et globales 

Lorsqu’une seule connexion à une base de données existe, l’enterprise 

bean peut contrôler directement la transaction en appelant commit() ou 

rollback() sur la connexion. Ce type de transaction est une transaction 

locale. Dans le cas des transactions globales, toutes les connexions à la 

base de données sont enregistrées avec le service de transaction globale 

qui gère la transaction. Pour une transaction globale, l’enterprise bean ne 

fait jamais d’appels directs à la connexion à une base de données 

elle-même. 

Un bean pratiquant la démarcation des transactions gérées par le bean 

utilise l’interface javax.transaction.UserTransaction pour identifier les 

limites d’une transaction globale. Quand un bean utilise la démarcation 

gérée par le conteneur, ce dernier interrompt chaque appel de client pour 

contrôler la démarcation de la transaction, en utilisant l’attribut de 

transaction défini dans le descripteur de déploiement du bean par 

l’assembleur de l’application. L’attribut de transaction détermine 

également si la transaction est locale ou globale. 

Pour les transactions gérées par le conteneur, ce dernier suit certaines 

règles pour déterminer s’il doit faire une transaction locale ou globale. 

Généralement, un conteneur appelle la méthode dans une transaction 

locale après avoir vérifié qu’il n’existe pas déjà une transaction globale. Il 

vérifie également qu’on n’attend pas qu’il démarre une nouvelle 


Utilisation de l’ API de transaction 

transaction globale et que les attributs de transaction sont définis pour les 

transactions gérées par le conteneur. Le conteneur enveloppe 

automatiquement un appel de méthode à l’intérieur d’une transaction 

locale si une des conditions suivantes est vrai : 

• L’attribut de transaction est défini par NotSupported et le conteneur 

détecte que les ressources de bases de données ont été accédées. 

• L’attribut de transaction est défini par Supports et le conteneur détecte 

que la méthode n’a pas été invoquée depuis l’intérieur d’une 

transaction globale. 

• L’attribut de transaction est défini par Never et le conteneur détecte 

que les ressources de bases de données ont été accédées. 

Utilisation de l’API de transaction 

Toutes les transactions utilisent l’API JTA (Java Transaction API). Lorsque 

les transactions sont gérées par le conteneur, la plate-forme gère la 

démarcation des transactions et le conteneur utilise l’API JTA. Vous 

n’avez jamais besoin d’utiliser cette API dans le code de votre bean. 

Si votre bean gère lui-même ses transactions, il doit utiliser l’interface JTA 

javax.transaction.UserTransaction. Cette interface permet à un client ou à 

un composant de démarquer les limites des transactions. Les enterprise 

beans dont les transactions sont gérées par le bean utilisent la méthode 

EJBContext.getUserTransaction(). 

De plus, tous les clients transactionnels utilisent JNDI pour consulter 

l’interface UserTransaction. Vous faites cela en construisant un 

InitialContext JNDI à l’aide du service d’annuaire JNDI, comme indiqué 

ici : 

javax.naming.Context context = new javax.naming.InitialContext(); 

Une fois que le bean a obtenu l’objet InitialContext, il peut utiliser 

l’opération JNDI lookup() pour obtenir l’interface UserTransaction : 

javax.transaction.UserTransaction utx = (javax.transaction.UserTransaction) 

context.lookup("java:comp/UserTransaction") 

Notez qu’un enterprise bean peut obtenir une référence à l’interface 

UserTransaction depuis l’objet EJBContext. Le bean peut simplement utiliser 

la méthode EJBContext.getUserTransaction() au lieu de chercher à obtenir 

un objet InitialContext et d’utiliser ensuite la méthode JNDI lookup(). 

Mais, si le client transactionnel n’est pas un enterprise bean, il doit utiliser 

l’approche de recherche JNDI. 

Quand le bean ou le client détient la référence à l’interface UserTransaction, 

il peut alors initier et gérer ses propres transactions. C’est-à-dire que vous 

pouvez utiliser les méthodes de l’interface UserTransaction pour 

commencer et valider (ou annuler) des transactions. Vous utilisez la 


Utilisation de l’ API de transaction 

méthode begin() pour commencer la transaction, puis la méthode commit() 

pour renvoyer les modifications dans la base de données. Ou alors, vous 

utilisez la méthode rollback() pour annuler toutes les modifications 

effectuées dans la transaction et restaurer la base de données dans l’état 

qu’elle avait avant le début de la transaction. Entre les méthodes begin() et 

commit(), vous insérez le code qui effectue le travail de la transaction. Voici 

un exemple : 

public class NewSessionBean implements SessionBean { 

EJBContext ejbContext; 

public void doSomething(...) { 

javax.transaction.UserTransaction utx; 

javax.sql.DataSource dataSource1; 

javax.sql.DataSource dataSource2; 

java.sql.Connection firstConnection; 

java.sql.Connection secondConnection; 

java.sql.Statement firstStatement; 

java.sql Statement secondStatement; 

java.naming.Context context = new javax.naming.InitialContext(); 

dataSource1 = (javax.sql.DataSource) 

context.lookup("java:comp/env/jdbcDatabase1"); 

firstConnection = dataSource1.getConnection(); 

firstStatement = firstConnection.createStatement(); 

dataSource2 = (javax.sql.DataSource) 

context.lookup("java:comp/env/jdbcDatabase2"); 

secondConnection = dataSource2.getConnection(); 

secondStatement = secondConnection.createStatement(); 

utx = ejbContext.getUserTransaction(); 

utx.begin(); 

firstStatement.executeQuery(...); 

firstStatement.executeUpdate(...); 

secondStatement.executeQuery(...); 

secondStatement.executeUpdate(...); 

utx.commit(); 

firstStatement.close; 

secondStatement.close 

firstConnection.close(); 

secondConnection.close(); 

} 

... 


Gestion des exceptions dans les transactions 


Les enterprise beans peuvent déclencher des exceptions au niveau de 

l’application et/ou du système, s’ils rencontrent des erreurs pendant la 

gestion des transactions. Les exceptions au niveau de l’application sont 

dues à des erreurs dans la logique métier. L’application appelante doit les 

gérer. Les exceptions au niveau du système, comme les erreurs 

d’exécution, dépassent l’application elle-même et peuvent être gérées par 

l’application, l’enterprise bean ou le conteneur du bean. 

L’enterprise bean déclare les exceptions au niveau de l’application et 

celles au niveau du système dans les clauses throws de ses interfaces Home et 

Remote. Vous devez contrôler les exceptions “vérifiées” dans le bloc try/ 

catch de votre application client lorsque vous appelez les méthodes du 

bean. 

Exceptions au niveau du système 

Un enterprise bean déclenche une exception au niveau du système 

(généralement une java.ejb.EJBException, mais ce peut être une 

java.rmi.RemoteException) pour indiquer une panne inattendue du système. 

Par exemple, il déclenche une exception s’il ne peut pas ouvrir une 

connexion à une base de données. java.ejb.EJBException est une exception 

d’exécution et n’a pas besoin de figurer dans la clause throws des méthodes 

métier du bean. 

Les exceptions au niveau du système nécessitent généralement 

l’annulation de la transaction. Souvent, c’est le conteneur qui gère le bean 

qui effectue l’annulation. Parfois, le client doit annuler la transaction, en 

particulier quand les transactions sont gérées par le bean. 

Exceptions au niveau de l’application 

Le bean déclenche une exception au niveau de l’application pour indiquer 

des conditions d’erreurs spécifiques à l’application. Ce sont des erreurs de 

logique métier et non des problèmes du système. Les exceptions du 

niveau de l’application sont des exceptions autres que 

java.ejb.EJBException. Ce sont des exceptions “vérifiées”, ce qui signifie 

que vous devez les vérifier quand vous appelez une méthode qui a la 

possibilité de déclencher cette exception. 

Les méthodes métier du bean utilisent les exceptions au niveau de 

l’application pour rapporter des conditions anormales dans l’application, 

comme des valeurs saisies inacceptables ou des montants au-delà des 

limites valables. Par exemple, une méthode dans un bean qui débite un 

compte peut déclencher une exception au niveau de l’application pour 

signaler que le solde du compte est insuffisant pour permettre cette 



opération. Un client peut souvent réparer ces erreurs au niveau de 

l’application sans avoir besoin d’annuler la transaction toute entière. 

L’application ou le programme appelant obtient en retour la même 

exception que celle qui a été déclenchée, ce qui permet au programme 

appelant de connaître la nature précise du problème. Quand une 

exception survient au niveau de l’application, l’instance de l’enterprise 

bean n’annule pas automatiquement la transaction du client. Le client 

connaît maintenant le message d’erreur et a l’opportunité de l’évaluer, de 

prendre les décisions nécessaires pour corriger la situation et de réparer la 

transaction. Ou alors, il peut annuler la transaction. 

Gestion des exceptions au niveau de l’application 

Comme les exceptions au niveau de l’application signalent des erreurs 

dans la logique métier, c’est à votre client de les gérer. Bien que ces 

exceptions puissent nécessiter l’annulation de la transaction, elles ne 

marquent pas automatiquement la transaction pour annulation (rollback). 

Le client peut tenter à nouveau la transaction, bien que la plupart du 

temps il doive l’abandonner et l’annuler. 

En tant que fournisseur du bean, vous devez vous assurer que l’état du 

bean est tel que si le client continue la transaction, l’intégrité des données 

sera maintenue. Si vous ne pouvez pas le garantir, vous devrez marquer la 

transaction pour annulation (rollback). 

Annulation de la transaction 

Quand votre client obtient une exception au niveau de l’application, il faut 

vérifier d’abord si la transaction en cours a été marquée pour annulation 

(rollback) seulement. Par exemple, un client peut recevoir une 

javax.transaction.TransactionRolledbackException. Cette exception indique 

que l’enterprise bean helper a échoué et que la transaction a été 

abandonnée ou marquée pour annulation (rollback) seulement. 

Généralement le client ne connaît pas le contexte de la transaction dans 

laquelle l’enterprise bean a opéré. Le bean peut avoir opéré dans son 

propre contexte de transaction, distinct de celui du programme appelant, 

ou dans le contexte du programme appelant. 

Si l’enterprise bean a opéré dans le même contexte de transaction que le 

programme appelant, alors le bean lui-même (ou son conteneur) a déjà 

marqué la transaction pour annulation (rollback). Quand un conteneur 

EJB marque une transaction pour annulation (rollback), le client doit 

arrêter tout travail de la transaction. Habituellement, un client utilisant les 

transactions déclaratives obtient une exception appropriée, comme 

javax.transaction.TransactionRolledbackException. Notez que les 

transactions déclaratives sont celles où le conteneur gère les détails de la 

transaction. 



Un client qui est lui-même un enterprise bean doit appeler la méthode 

javax.ejbEJBContext.getRollbackOnly() pour déterminer si sa propre 

transaction a été marquée pour annulation (rollback). 

Pour les transactions gérées par le bean — transactions gérées 

explicitement par le client — le client doit annuler la transaction en 

appelant la méthode rollback() depuis l’interface 

java.transaction.userTransaction. 

Options pour continuer une transaction 

Quand une transaction n’est pas marquée pour annulation (rollback), le 

client dispose des options suivantes : 

• Annuler la transaction. 

Quand un client reçoit une exception vérifiée pour une transaction non 

marquée pour annulation, le plus sûr est d’annuler la transaction. Le 

client le fait soit en marquant la transaction pour annulation (rollback) 

seulement, soit, si le client a démarré la transaction, en appelant la 

méthode rollback() pour annuler réellement la transaction. 

• Transférer la responsabilité en déclenchant une exception vérifiée ou en 

déclenchant à nouveau l’exception initiale. 

Le client peut aussi déclencher sa propre exception vérifiée ou en 

déclencher à nouveau l’exception initiale. En déclenchant une 

exception, le client laisse les autres programmes impliqués dans la 

transaction décider d’annuler ou non la transaction. Mais, en général, il 

vaut mieux que ce soit le code ou le programme le plus près de 

l’occurrence du problème qui prenne la décision de poursuivre ou non 

la transaction. 

• Essayer à nouveau et continuer la transaction. Cela peut impliquer de 

réessayer des parties de la transaction. 

Le client peut continuer la transaction. Le client peut évaluer le 

message de l’exception et décider si appeler à nouveau la méthode avec 

d’autres paramètres a des chances de réussir. N’oubliez pas, cependant, 

que retenter une transaction est potentiellement dangereux. Votre code 

ne sait pas si l’enterprise bean a correctement nettoyé son état. 

Les clients qui appellent des beans session stateless peuvent cependant 

retenter la transaction s’ils sont capables de déterminer le problème à 

partir de l’exception déclenchée. Comme le bean appelé est stateless, il 

n’y a pas à se préoccuper de son état. 

Si vous utilisez Borland AppServer, lisez le chapitre “Transaction 

Management”, dans l’Enterprise JavaBeans Programmer’s Guide de 

Borland AppServer, pour avoir des informations complémentaires sur les 

transactions et sur le conteneur Borland. 


Index 

A 

activation 

beans entité 10-4 

beans session 9-7 

experts EJB 2-1 

Activer l’intégration, option 2-1 

administrateur système 

rôle EJB 1-4 

afterBegin() 9-9 

afterCompletion() 9-9 

ajout de méthodes métier aux EJB 3-9 

ajout de propriétés aux EJB 3-9 

annulation des transactions 13-9 

API JTA (Java Transaction API) 13-6 

application EJB, rôles 1-3 

applications client EJB exemple 

SortClient 12-1 

applications distribuées 

EJB 1-1 

applications multiniveaux 

pour systèmes distribués 1-2 

architecture 

Enterprise JavaBeans 1-5 

assembleur d’applications 

rôle EJB 1-3 

attributs 

transaction 13-3 

B 

bean, gestion de la persistance du bean 7-12, 10-1, 

10-2 

inconvénients 10-2 

bean, gestion des transactions 13-3, 13-6 


clés primaires 10-3, 12-4 

create() 11-4, 12-3 

définition 10-1 

écriture 10-3 

état d’inexistence 10-9 

état en pool 10-9 

état prêt 10-10 

états 10-8 

exemple 10-11, 10-12, 10-14 

fourniture des données 8-1 

interface distante 10-12 

interface locale 10-11, 11-4 

méthodes 10-5 

méthodes find 7-14, 11-5, 12-3 

partage des interfaces locale et distante 10-11 

persistance 10-1 

référencement 12-3 

résolution des données 8-1 

sources de données 7-21 

suppression 10-1 

beans session 1-7, 9-1 

create() 11-3 

création avec JBuilder 9-4 

cycle de vie 9-5 

écriture 9-2 

état prêt pour la méthode 9-6 

exemple 9-9 

exemple Cart 9-10 

implémentation des méthodes nécessaires 9-11 

interface locale 11-2 

interface SessionSynchronization 9-8 

méthodes create 12-2 

pool stateless 9-5 

référencement 12-2 

remove() 12-6 

stateful 9-1, 12-2 

stateless 9-2, 12-2 

types 9-1 

beans stateful 


beans stateless 


BeansExpress 

exposition des méthodes EJB 3-11 

beforeCompletion() 9-9 

bibliothèques 

fichiers du serveur d’applications 2-2 

Borland 

contacter 1-9 

serveur d’applications cible 2-1 

Borland Online 1-9 

C 

Cart, exemple de bean 9-10 

chariot de supermarché 

exemple de bean session 9-9 

checkExistenceBeforeCreate, propriété 7-15 

classe de clé primaire 10-3, 12-4 

exigences des beans entité 10-3 

classes des beans entité 

écriture 10-3 

exigences 10-3 

classes des beans session 

exigences 9-2 

clé primaire 

bean entité 12-4 

Index I-1

localisation des objets entité 11-5 

obtention 11-7 

clients 

création avec JBuilder 12-9 

enterprise bean 12-1 

gestion des transactions 12-7 

invocation de méthodes métier 12-5 

localisation de l’interface locale 12-2 

obtention de l’interface distante 12-2 

suppression des instances de beans 12-6 

clients de test 

création EJB 5-1 

déclaration d’une instance de 5-3 

exécution EJB 5-5 

utilisation EJB 5-3 

composants client EJB 8-2 

composants DataExpress pour EJB 8-1 

composants EJB 8-1 

composants serveur EJB 8-2 

concepteur de Bean 

page Méthodes 3-11 

page Propriétés 3-9 

Configuration Entreprise, commande 2-1 

configurations d’exécution 

Client et Serveur 5-5 

contacter Borland 1-9 

groupes de discussion 1-10 

World Wide Web 1-9 

conteneur EJB 

activation des beans session 9-7 

conteneur, gestion de la persistance du 

bean 10-2 

création de EJBObject 11-7 

cycle de vie des beans entité 10-8 

cycle de vie des beans stateful 9-6 

cycle de vie des beans stateless 9-5 


désactivation des beans session 9-7 

fournisseur 1-3 

implémentation de l’interface locale 11-1 

support des transactions 13-2 

conteneur, gestion de la persistance du bean 7-12, 

10-2, 10-22 

avantages 10-2 

limites 10-3 

sans classe clé primaire 10-6 

contexte d’annuaire 

obtention 12-2 

conventions de la documentation 1-11 

conventions des plates-formes 1-12 

create() 



exceptions 11-3, 11-4 

CreateException, exception 11-3, 11-4 

Créateur d’interface EJB, expert 3-15 

Créateur de Bean EJB, expert 3-12 

Créer IIOP, option 3-17 

D 

dé-déploiement d’un JAR EJB 6-11 

déploiement 

enterprise beans 6-1, 6-6 

enterprise beans sur WebLogic 6-1, 6-9 

enterprise beans sur WebSphere 6-1, 6-9 

JAR EJB 6-6 

JAR EJB sur un conteneur en exécution 6-11 

déploiement dynamique 

enterprise beans 6-11 

Déploiement EJB, expert 6-6 

déploiement, rôle EJB 1-4 

déployeur 

rôle EJB 1-4 

désactivation 

instances des beans session 9-7 

descripteurs de déploiement 

ajout d’informations au nouveau bean 7-4 

bean session 9-18 

création 6-2, 7-1 

édition 3-20 

exemple de bean entité 10-21, 10-22 

fichier XML 3-20 

informations contenues 6-3 

informations structurelles 6-4 

informations sur l’assemblage de 

l’application 6-4 

insertion dans un groupe EJB 3-17 

méthodes find 7-14 

modification 7-1 

modification des informations du bean 7-5 

niveaux d’isolation des transactions 7-23 

objectif 6-2 

permissions de méthodes 7-26 


politiques transactionnelles 7-20 

propriétés 7-15 

propriétés d’environnement 7-7 

propriétés des sources de données 7-23 

références des ressources 7-10 

références EJB 7-8 

rôles de sécurité 7-9, 7-25 


vérification 7-28 

visualisation 7-2 

développeur de beans 

rôle EJB 1-3 

tâches 1-6 

I-2 Guide du dé veloppeur Enterprise JavaBeans

E 

éditeur de descripteur de déploiement 7-1 

affichage 7-2 


panneau Data Source 7-21 

panneau EJB References 7-8 

panneau Environment 7-7 

panneau Finders 7-14 

panneau Main 7-5 

panneau Persistence 7-12 

panneau Properties 7-15 

panneau Resource References 7-10 

panneau Security Role References 7-9 

permissions de méthodes 7-26 

propriétés des sources de données 7-23 

rôles de sécurité 7-25 

vérification des descripteurs 7-28 

EJB 1-1 

Voir aussi Enterprise JavaBeans 

EJB 1.1, serveur d’applications 2-4 

EJB, conteneurs 1-6 

Voir aussi conteneur EJB 

EJB, rôles 1-3 

ejbActivate() 9-3, 10-4 

ejbCreate() 10-5 

appelée par le conteneur 10-6 

exemple 10-6 

exigences 9-3, 10-6 

ejbFindByPrimaryKey() 10-7 

EJBHome, classe de base 

étendue par l’interface locale 11-2 

ejb-jar.xml 3-20 

ejbLoad() 10-5 

EJBMetaData, interface 12-8 

EJBObject, interface 11-7 

étendue par l’interface distante 11-6 

ejbPassivate() 9-3, 10-5 

ejbPostCreate() 10-7 

ejbRemove() 9-3, 10-4 

ejbStore() 10-5 

élimination 

instances EJB 11-2 


client de test 5-1 

comparaison 11-7 

compilation 3-17 

création à l’aide d’experts 3-4 

déploiement 6-1, 6-6 

déploiement dynamique 6-11 

déploiement sur serveur WebLogic 6-9 

déploiement sur serveur WebSphere 6-9 

développement avec JBuilder 1-8 

entité 1-7 

exécution 5-5 

fonctionnement 1-6 

génération à partir d’une interface distante 3-12 

gestion des ressources 9-3 

méthodes métier 10-8 

obtenir des informations 12-8 

options de déploiement 6-10 

propriétés de construction 3-17 

session 1-7 

suppression d’instances 11-7 

test 5-5 

test des méthodes distantes 5-1 

transactions 13-3 

types 1-7 

Enterprise JavaBean, expert 3-4 

Enterprise JavaBeans 1-1 

1.1 specification 1-1 

activation des experts 2-1 

architecture 1-5 

développement 1-1 

rôles 1-3 

types 1-7 

usage 1-2 

EnterpriseBean, interface 

étendue par EntityBean 10-4 

étendue par SessionBean 9-2 

EntityBean, interface 

implémentation 10-4 

implémentations des beans entité 10-3 


état d’inexistence 


état en pool 


retour du beans entité 10-10 

état prêt 


état prêt pour la méthode 

dans une transaction 9-7 


état prêt pour la transaction 9-9 

exceptions 

au niveau de l’application 13-8, 13-9 

au niveau du système 13-8 

transaction 13-8 

exemple de bean entité 

CheckAccount 10-12 

SavingsAccount 10-14 

exemple de bean session 

Cart 9-9 

Expert Client Test EJB 5-1 

experts 

activation EJB 2-1 

Client test EJB 5-1 

Créateur d’interface EJB 3-15 

Créateur de Bean EJB 3-12 

Index I-3

Déploiement EJB 6-6 

Enterprise JavaBean 3-4 

Groupe EJB depuis descripteurs 3-3 

Groupe EJB vide 3-2 

Modeleur Bean entité EJB 4-1 

Utilisation d’un client Test 5-3 

experts EJB 

activation 2-1 

Client test 5-1 

Créateur d’interface EJB 3-15 

Créateur de Bean EJB 3-12 

Enterprise JavaBean 3-4 

Groupe EJB depuis descripteurs 3-3 

Groupe EJB vide 3-2 

Modeleur de Bean entité 4-1 

Utilisation d’un client Test 5-3 

F 

fichiers du serveur d’applications 

ajout à un projet 2-2 

findByPrimaryKey() 11-5, 12-4 

FinderException, exception 11-5 

fournisseur de beans 

rôle EJB 1-3 

tâches 1-6 

fournisseur de conteneurs 

rôle EJB 1-3 

fournisseur de serveurs 

EJB 1-3 

rôle EJB 1-3 

fourniture des données 


G 

getEJBHome() 

EJBObject 11-7 

getEJBMetaData() 11-2 

EJBHome 11-2 

getHandle() 


getHomeHandle() 

EJBHome 11-2 

getMetaData() 

enterprise bean 12-8 

getPrimaryKey() 


getPrimaryKeyAfterInsertSql, propriété 7-15 

getPrimaryKeyBeforeInsertSql, propriété 7-15 

getRollbackOnly() 13-9 

Groupe EJB depuis descripteurs, expert 3-3 

Groupe EJB vide, expert 3-2 

groupes de discussion 1-10 

Borland 1-10 

groupes EJB 

H 

copie des descripteurs de déploiement 3-17 

création 3-2 

définition 3-1, 3-2 

depuis descripteurs de déploiement 3-3 

extensions de fichiers 3-1 

insertion de descripteurs de déploiement 3-17 

propriétés de construction 3-17 

types 3-1 

vide 3-2 

handles 

EJB 11-2 

obtention d’enterprise beans 11-7 

I 

iaspt.ini, fichier 7-29 

ignoreColumnsOnInsert, propriété 7-15 

infrastructure EJB, rôles 1-3 

InitialContext 13-6 

interface distante 11-6 


création 11-6 

création pour un bean existant 3-15 




extension de EJBObject 11-7 

génération des EJB à partir de 3-12 


obtention d’une référence par le client 12-1 

référence 12-2 

référence à un bean entité. 12-3 

référence à un bean session 12-2 

interface locale 

beans entité 10-11, 11-4 


création 11-1, 11-2 

création pour un enterprise bean existant 3-15 


exemple de bean entité 11-6 


exigences des beans entité 11-4 

exigences des beans session 11-3 

extension de EJBHome 11-2 

localisation par le client 12-1, 12-2 

méthodes create 12-2, 12-4 

méthodes find 11-5, 12-2 

méthodes remove 12-4 

nom 11-1 

interface locale et distante 

partage par les beans entité 10-11 

interfaces 

distante 11-6 


locale 11-1 

isIdentical() 


J 

JAR EJB déployés 

liste 6-11 

jdbcAccesserFactory, propriété 7-15 

JNDI 

API 12-2 

service d’annuaire 12-2, 13-6 

L 

liste des JAR déployés 6-11 

localisation 

enterprise beans avec clé primaire 11-7 

lookup() 12-2 

M 

Mandatory, attribut des transactions 13-4 

métadonnées 


méthodes create 

bean entité 10-5, 12-3 

bean session 12-2 

méthodes distantes 

test 5-1 

méthodes find 7-14, 10-5, 11-5, 12-2, 12-3 



défaut 12-4 


préfixe 11-5 


ajout à un enterprise bean 3-9 


écriture 9-3 

exposition EJB 3-11 

interface distante 3-11, 11-6 

invoquées par le client 12-1, 12-5 

modèles de conception 

bean session enveloppe bean entité 8-1 

Modeleur Bean entité EJB, expert 4-1 

modification des descripteurs de déploiement 7-1 

N 

Never, attribut des transactions 13-4 

niveaux d’isolation 7-23 

NotSupported, attribut des transactions 13-4 

O 

opération, rôle EJB 1-4 

options de déploiement 

EJB 6-10 

options de déploiement EJB 

configuration 6-10 

P 

Paramètres de déploiement, boîte de dialogue 6-1 

partage des interfaces locale et distante 10-11 

passivité 9-7, 10-5 

permissions de méthodes 6-5, 7-26 


avantages de la gestion par le conteneur 10-2 

beans entité 7-12, 10-1 

gérée par le bean 7-12, 10-1, 10-2 

gérée par le conteneur 7-12, 10-2 

gérées par le conteneur 10-2 

gestion par le conteneur et gestion par le 

bean 10-2 

inconvénients de la gestion par le bean 10-2 

inconvénients de la gestion par le 

conteneur 10-3 

persistance gérée par le bean 10-21 

méthodes find 10-3 

polices 

conventions de la documentation 1-11 

ports 

SmartAgent VisiBroker 2-3 

primaryKeyGenerator, propriété 7-15 

propriétés 

descripteur de déploiement 7-15 

EJB 7-15 


propriétés d’environnement 

EJB 7-7 

propriétés de construction 

groupes EJB 3-17 

Propriétés de construction, boîte de dialogue 3-20 

R 

recherche d’objets entité 

clé primaire 11-7 

redéploiement 

JAR EJB 6-11 

référencement des enterprise beans 

méthodes create 12-2, 12-3 

méthodes find 12-2, 12-4 

utilisation de handles 12-6 

références 

EJB 7-8 

références des ressources 

EJB 7-10 

Index I-5

éférences des rôles de sécurité 6-5 

réflexion 

byte-code 7-29 

RemoteException, exception 11-3, 11-4, 11-5, 11-6 

remove() 

EJBHome 11-2 


Required, attribut des transactions 13-4 

RequiresNew, attribut des transactions 13-4 

résolution des données 


ressources en ligne 1-9 

Retirer les fichiers stubs lors des modifications du 

serveur d’applications, option 3-17 

rôles 

application EJB 1-3 

déploiement 1-4 

EJB 1-3 

infrastructure EJB 1-3 

opération 1-4 

rôles de sécurité 6-5 


EJB 7-9, 7-25 

rollback() 13-10 

S 

serveur d’applications 

cible Borland 2-1 

cible WebLogic 2-1 

cible WebSphere 2-1 

définition de la cible 2-1 

EJB 1.1 2-4 

sélection 2-4 


serveur EJB 


fournisseur 1-3 

serveurs 

EJB 1-5 

exécution EJB 5-5 

SessionBean, interface 

extension 9-2 


SessionContext, interface 9-9 

SessionSynchronization, interface 

beans session stateful 9-8 


setEntityContext() 10-4 

setRollbackOnly() 9-9 

setSessionContext() 9-3 

SmartAgent 2-3 

sources de données 

EJB 7-21 


propriétés 7-23 

stubs 

génération client 3-17 

stubs client 

génération 3-17 

support aux développeurs 1-9 

support technique 1-9 

Supports, attribut des transactions 13-4 

suppression 


instances de beans entité 12-4 

instances des beans session 12-6 

instances EJB 11-2 

JAR EJB déployé 6-11 

suppression des instances de beans 10-1 

T 

test des enterprise beans 5-5 

test des méthodes des enterprise beans 5-1 

Toujours créer un JAR lors de la construction du 

projet, option 3-17 

transaction 

attributs 13-4 

démarcation 13-3 

limites 12-7, 13-6 

politique 7-20 

transactions 

annulation 13-9 

attributs 13-3 

caractéristique atomicité 13-1 

caractéristique concurrence 13-1 

caractéristique durabilité 13-1 

caractéristique isolation 13-1 

caractéristiques 13-1 

cohérence 13-1 

démarcation 13-6 

et enterprise beans 13-3 

exceptions 13-8 

gérées par le bean 13-3 

gérées par le client 12-7 

gérées par le conteneur 7-20, 13-3, 13-5 

globales 13-5 

locales 13-5 

niveaux d’isolation 7-23 

transactions gérées par le conteneur 13-3 

ajout 7-20 

U 

unsetEntityContext() 10-4 

Usenet, groupes de discussion 1-10 

UserTransaction, interface 12-7, 13-5, 13-6 

Utilisation d’un client Test EJB, expert 5-3 


V 

vérification 

descripteurs de déploiement 7-28 

VisiBroker 

ORB, accessible à JBuilder 2-3 

SmartAgent 2-3 

W 

WebLogic 

boîte de dialogue Paramètres de 


descripteurs de déploiement 3-20 


WebLogic EJB, propriétés 

visualisation et modification 7-27 

WebLogic, serveur 

déploiement sur 6-9 

weblogic-ejb-jar.xml 3-20 

WebSphere 

boîte de dialogue Paramètres de 



WebSphere EJB, propriétés 

visualisation et modification 7-27 

WebSphere, serveur 

déploiement sur 6-9 

Index I-7

des enterprise beans - DÃ©partement Informatique

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?