Je me demandais pourquoi nous avons besoin d'interfaces locales et distantes distinctes pour les beans de session EJB 3.0. Je suppose que la plupart du temps, ils définissent tous deux le même contrat. Pourquoi ne puis-je pas avoir une interface commune et dans mon Bean, je devrais juste pouvoir dire que je veux que ce Bean soit accessible à distance et/ou localement.
Merci Vikas
C'est ce que dit la spécification EJB :
Le choix entre le modèle de programmation local et le modèle de programmation distant est une décision de conception que le Bean Provider prend lors du développement du bean d'entreprise.
Bien qu'il soit possible de fournir à la fois une vue client distante et une vue client locale pour un haricot d'entreprise, plus généralement l'un ou l'autre seulement sera fourni .
Ainsi, lorsque vous écrivez un bean, pensez à qui est le client. Il est très peu probable qu'un client local ait besoin des mêmes méthodes ou même du même bean qu'un client distant.
Je ne suis pas d'accord avec le fait qu'au moment de la conception, remote et local doivent être traités comme trivialement interchangeables.
Tout d'abord, l'invocation à distance entraîne des frais généraux. Ainsi, lorsque vous concevez des interfaces distantes, vous devez vous assurer que la granularité et la taille des paramètres sont correctes. Un rappel cela va être relativement cher est utile en tant que concepteur.
En outre, étant donné que les paramètres des interfaces distantes sont transmis par valeur et que les paramètres des interfaces locales sont transmis par référence, il existe des différences sémantiques fondamentales entre les deux cas, et vous pouvez donc choisir de concevoir les deux interfaces différemment.
La notion de "transparence de l'emplacement" est un anti-modèle dangereux. Votre conception doit absolument savoir s'il s'agit d'un appel local ou d'un appel distant, pour de nombreuses raisons (la gestion des erreurs et les performances étant les plus évidentes).
Les interfaces EJB distantes sont distinctes de leurs homologues locales parce que la signature des exceptions doit être différente pour tenir compte des erreurs liées au réseau qui ne peuvent se produire que lors d'un appel distant. Transférer le bagage de la gestion à distance à l'interface locale (comme c'était le cas dans EJB 1) rend le code horrible. EJB 2 a introduit des interfaces locales distinctes afin de simplifier la programmation des EJB qui étaient toujours locales.
Je pense que lorsque votre entreprise a besoin que toutes les méthodes de la section locale soient également exposées aux clients distants, alors
Cette approche pourrait être une solution de contournement pour obtenir @Local & @Remote sur la même interface. La même méthode peut être accédée localement si nécessaire et à distance si nécessaire, sans aucune surcharge de performance.
Voilà ce que je pense. Que quelqu'un me fasse part de son avis pour le valider.
Les clients accèdent à un bean de session ou d'entité par le biais des interfaces du bean. Le conteneur EJB génère les implémentations de l'interface pour appliquer et gérer ce comportement, agissant comme un conduit pour la communication entre le client et le bean. Dans les versions antérieures à la spécification EJB 2.0, tous les beans étaient définis et mis en œuvre en tant que composants distribués et distants. Par conséquent, les deux interfaces requises pour les beans étaient appelées l'interface d'origine (qui, en général, définit les méthodes du cycle de vie) et l'interface distante (qui, en général, définit les méthodes fonctionnelles de l'entreprise).
Internally, J2EE uses the Java Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) to enable remote, distributed method calls and applications. While this approach provides many benefits, it also generates a large amount of overhead, with a corresponding performance hit as stubs are referenced, parameters go through the marshaling process, and objects are tossed around the network.
Considerations of performance, practicality, and typical usage in the field resulted in the introduction of local interfaces in the EJB 2.0 specification. As noted, prior terminology referred to the home interface and the remote interface; at this point, depending on which approach is used, local interface and local home interface or remote interface and remote home interface are better terms. Either of the local home or remote home interfaces is referred to as the home interface; either of the local or remote interfaces is referred to as the component interface. This tutorial refers to the interfaces in these terms and uses these conventions for names.
When using J2EE technologies, it is normal to focus on distributed, or remote, beans, but you should keep the local option in mind, when applicable. It may be surprising to learn that a bean can have local interfaces, remote interfaces, or both. However, the client must write to a specific (that is, local or remote) interface. There are some issues to keep in mind when using local interfaces:Les beans doivent s'exécuter dans la même VM - ils sont, après tout, locaux. Les paramètres sont envoyés par référence plutôt que d'être copiés, comme c'est le cas pour les interfaces et les objets distants. Des effets secondaires inattendus peuvent se produire si vous ignorez cette distinction et ne codez pas en conséquence. Typiquement, la décision d'utiliser l'accès local ou distant est affectée par :
Le type de client - À moins que vous ne vous attendiez toujours à ce que le client soit un composant Web ou un autre bean, choisissez l'accès à distance.
Si les beans sont étroitement ou faiblement couplés - Si les beans dépendent les uns des autres et interagissent fréquemment, envisagez un accès local.
Évolutivité - L'accès à distance est intrinsèquement évolutif et doit être utilisé si l'évolutivité est un facteur important. Avec l'arrivée des interfaces locales dans la spécification EJB 2.0, la plupart des sources recommandent que les beans d'entité soient presque toujours basés sur un accès local. Avec les interfaces locales, la plupart des problèmes de performance concernant l'accès très fin aux données disparaissent. Si le client est distant, le modèle de conception standard prévoit que le client utilise une interface distante pour accéder à un bean de session, qui sert ensuite de liaison avec le bean d'entité. Le bean de session communique avec le bean d'entité par l'intermédiaire d'une interface locale (du point de vue des patrons, cette technique s'appelle une façade de session, et elle peut en fait être utilisée dans un contexte distant ou local).
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
