Les haricots d'entité traitent des données. Ils représentent typiquement des noms, tels qu'un compte, un client, ou un paiement de voyageur fréquent. Les vieux objets plats de Java héritent l'existence quand ils sont créés dans un programme. Quand le programme se termine, l'objet est perdu. Mais un haricot d'entité reste autour jusqu'à ce qu'il soit supprimé. Un programme peut créer un haricot d'entité et alors le programme peut être arrêté et remis en marche--mais l'haricot d'entité continuera à exister. Après avoir été remis en marche, le programme peut encore trouver l'haricot d'entité que cela fonctionnait avec et continuer de l'employer.

De vieux objets plats de Java sont employés seulement par un programme. Un haricot d'entité, d'une part, peut être employé par n'importe quel programme sur le réseau. Les programmes de client doivent juste trouver l'haricot d'entité par l'intermédiaire de JNDI afin de l'employer. Les haricots d'entité doivent avoir une clef primaire unique qui est employée pour trouver l'haricot spécifique d'entité qu'ils veulent manoeuvrer. Par exemple, un haricot d'entité des « employés » peut employer le nombre de la sécurité sociale des employés en tant que sa clef primaire. Les méthodes d'haricot d'entité fonctionnent sur une machine de « serveur ». Quand un programme de client appelle la méthode d'un haricot d'entité, le fil du programme de client cesse de s'exécuter et la commande passe au-dessus de au serveur. Quand la méthode retourne du serveur, le fil local reprend l'exécution.

La limite récipient-a contrôlé des moyens de persistance que le récipient d'EJB manipule tout l'accès aux bases de données exigé par l'haricot d'entité. Le code de l'haricot ne contient aucun appel de l'accès aux bases de données (SQL). En conséquence, le code de l'haricot n'est pas attaché à un mécanisme persistant spécifique de stockage (base de données). En raison de cette flexibilité, même si vous redéployez le même haricot d'entité sur les différents serveurs de J2EE qui emploient différentes bases de données, vous n'aurez pas besoin de modifier ou recompile le code de l'haricot. En bref, vos haricots d'entité sont plus portatifs.

Afin de produire des données accéder aux appels, le récipient a besoin d'informations que vous fournissez dans le schéma abstrait de l'haricot d'entité.

Une partie de descripteur du déploiement d'un haricot d'entité, le schéma abstrait définit les champs persistants et les rapports de l'haricot. L'abrégé sur limite distingue ce schéma du schéma physique du magasin fondamental de données. Dans une base de données relationnelle, par exemple, le schéma physique se compose des structures telles que des tables et des colonnes. Vous indiquez le nom d'un schéma abstrait dans le descripteur de déploiement. Ce nom est mis en référence par des questions écrites dans le langage d'interrogation de JavaBeans d'entreprise (« EJB QL »). Pour un haricot d'entité avec la persistance récipient-contrôlée, vous devez définir une question d'EJB QL pour chaque méthode de trouveur (excepté le findByPrimaryKey). La question d'EJB QL détermine la question qui est exécutée par le récipient d'EJB quand la méthode de trouveur est appelée. Vous le trouverez probablement utile d'esquisser le schéma abstrait avant d'écrire n'importe quel code. La figure représente un schéma abstrait simple qui décrit les rapports entre trois haricots d'entité. Ces rapports sont discutés plus loin dans les sections qui suivent.

Les champs persistants d'un haricot d'entité sont stockés dans le magasin fondamental de données. Collectivement, ces champs constituent l'état de l'haricot. Au temps d'exécution, le récipient d'EJB synchronise automatiquement cet état avec la base de données. Pendant le déploiement, le récipient trace typiquement l'haricot d'entité à une table de base de données et trace les champs persistants aux colonnes de la table.

Un haricot d'entité de CustomerEJB, par exemple, pourrait avoir les champs persistants tels que le firstName, le lastName, le téléphone, et l'email address. Dans la persistance récipient-contrôlée, ces champs sont virtuels. Vous les déclarez dans le schéma abstrait, mais vous ne les codez pas pendant que les variables d'exemple dans l'haricot d'entité classent. Au lieu de cela, les champs persistants sont identifiés dans le code par des méthodes d'accès (des acquéreurs et des poseurs).

Un champ de rapport est comme une clef étrangère dans une table de base de données--il identifie un haricot relatif. Comme un champ persistant, un champ de rapport est virtuel et est défini dans la classe d'haricot d'entreprise avec des méthodes d'accès. Mais à la différence d'un champ persistant, un champ de rapport ne représente pas l'état de l'haricot.