In short: une façon (de plus) d'exposer des objets peu importe (en théorie) l'endroit ou il se trouve. Les nuances se font selon le type d'objet que tu veux exposer:
- si c'est un objet ne gérant aucune donnée, mais devant juste effectuer une opération.
- si c'est un objet ne gérant que des données "intermédiaire" devant effectuer une opération
- si l'objet gère en fait la donnée critique
- si l'objet est juste un message devant arriver quelque part
- etc...
C'est là que les concept de session bean (stateless et stateful), d'entity bean, de message driven bean, etc... apparaisse.
L'implémentation derrière est (comme dans pratiquement tout les cas) de montrer au client un objet qui a l'air "local", de marshaller l'appel (d'une façon ou d'une autre) afin de l'envoyer sur le réseau au serveur, qui va en déduire quel appel réel effectuer. Les nuances se situe généralement sur comment trouver l'objet distant et le fait que l'appel soit plus ou moins bloquant.
Si tu connais les web service (stateless session bean), COM+, Corba, RMI, ou même les RPC, tu as normalement une idée de ce que veulent faire les EJB.
Comme presque toujours dans le monde java, on y ajoute le mot "enterprise" parce que ça le fait, et on y ajoute une série de bullshit marketing style "scalability", "transparence", "performance", "reliablity",... etc...
Ce qui rend les EJB particulièrement lourd, c'est qu'à l'inverse de certain techno (genre COM, Corba ou Web Service), y'a pas vraiment une contrat first approach (tu ne définis pas avant dans un langage à part le contrat que ton objet expose), le contrat est en quelque sorte inclus dans le code. Et dans le cas des EJB<=3, ce code est particulièrement lourd (y'a bcp à taper) et complexe à maintenir (tu veux rajouter un param à une méthode, c'est vite long, et du coup, les développeurs fainéant que nous sommes préfère l'éviter, ce qui amène parfois à des design douteux). La version 3 ne change pas complètement cela, elle intègre la annotations java 5, donc c'est un peu moins lourd à écrire. Un autre désavantage des EJB, c'est qu'ils sont lourd et chiant à tester, ou même à utiliser, tu te retrouves vite à contraindre tes développeurs à avoir un serveur d'application surchargé sur chaque poste de dev. (pareil pour pas mal d'autre truc: unit tester un EJB est pas trivial, les perf sont parfois suprenante, etc...).
En très coutr pour répondre au journal: amha, si tu vises le court terme: Struts, Spring, Hibernate. Si tu trouves ça fun, regarde JSF, mais c'est pas encore top utilisé, et ça ne couvre pratiquement que la couche présentation.
[^] # Re: Mouais
Posté par tene . En réponse au journal Remise à niveau Java. Évalué à 7.
- si c'est un objet ne gérant aucune donnée, mais devant juste effectuer une opération.
- si c'est un objet ne gérant que des données "intermédiaire" devant effectuer une opération
- si l'objet gère en fait la donnée critique
- si l'objet est juste un message devant arriver quelque part
- etc...
C'est là que les concept de session bean (stateless et stateful), d'entity bean, de message driven bean, etc... apparaisse.
L'implémentation derrière est (comme dans pratiquement tout les cas) de montrer au client un objet qui a l'air "local", de marshaller l'appel (d'une façon ou d'une autre) afin de l'envoyer sur le réseau au serveur, qui va en déduire quel appel réel effectuer. Les nuances se situe généralement sur comment trouver l'objet distant et le fait que l'appel soit plus ou moins bloquant.
Si tu connais les web service (stateless session bean), COM+, Corba, RMI, ou même les RPC, tu as normalement une idée de ce que veulent faire les EJB.
Comme presque toujours dans le monde java, on y ajoute le mot "enterprise" parce que ça le fait, et on y ajoute une série de bullshit marketing style "scalability", "transparence", "performance", "reliablity",... etc...
Ce qui rend les EJB particulièrement lourd, c'est qu'à l'inverse de certain techno (genre COM, Corba ou Web Service), y'a pas vraiment une contrat first approach (tu ne définis pas avant dans un langage à part le contrat que ton objet expose), le contrat est en quelque sorte inclus dans le code. Et dans le cas des EJB<=3, ce code est particulièrement lourd (y'a bcp à taper) et complexe à maintenir (tu veux rajouter un param à une méthode, c'est vite long, et du coup, les développeurs fainéant que nous sommes préfère l'éviter, ce qui amène parfois à des design douteux). La version 3 ne change pas complètement cela, elle intègre la annotations java 5, donc c'est un peu moins lourd à écrire. Un autre désavantage des EJB, c'est qu'ils sont lourd et chiant à tester, ou même à utiliser, tu te retrouves vite à contraindre tes développeurs à avoir un serveur d'application surchargé sur chaque poste de dev. (pareil pour pas mal d'autre truc: unit tester un EJB est pas trivial, les perf sont parfois suprenante, etc...).
En très coutr pour répondre au journal: amha, si tu vises le court terme: Struts, Spring, Hibernate. Si tu trouves ça fun, regarde JSF, mais c'est pas encore top utilisé, et ça ne couvre pratiquement que la couche présentation.
ps: wikipedia en dit tous de même plus que moi: http://en.wikipedia.org/wiki/Enterprise_Java_Bean