Discussion :

[bouncebounce]

Bonjour,

Je suis novice dans la J2EE alors excusez moi pour la remarque, mais je souhaiterais connaître la différence entre un Web Sevice et un EJB, pas du point de vu de la programmation, mais savoir ce que chacun me permet de faire quoi exactement.
En effet, j'ai du mal à discerner les fonctionnalités de chacun. Je ne sais si je suis un cas isolé, mais quand je lis que c'est facile à comprendre et à programmer, excusez moi du peu, mais j'ai du mal.

Pourriez-vous m'aider, s'il vous plaît.

[alexismp]

Un EJB contient de la logique métier (éventuellement transactionnelle).
Un Web Service est un composant technique permettant d'exposer d'une logique métier. Un EJB peut donc être l'implémentation d'un Web Service.

[DrHelmut]

Je déboule bien tardivement, mais je ne m'intéresse que maintenant aux EJB, dans le cadre de la maintenace d'une vieille appli...

->alexismp, je comprends pas trop ta réponse : un EJB implémentant un webservice... à priori je dirais why not, mais c'est pas fait pour ça !
Y'a des outils java spécifiques pour la création de webservices, pas besoin de réinventer la roue...

->bouncebounce, pour répondre à ta question, la grande différence c'est qu'un webservice est indépendant de son implémentation, grâce au 'protocole' SOAP (plus une norme XML qu'un vrai protocole à mon sens)

Tu peux donc créer un webservice en php et l'intéroger avec un client Java ou inversement, ect... ça résoud donc pas mal de problème de conflit inter ou intra entreprises

Quand aux EJB, j'ai pas regardé la dernière version, mais de ce que je vois dans l'appli que je maintiens, je trouve que c'est l'usine à gaz comparé à une 'simple' architecture 3 tiers MVC jsp/servlet/Struts....

Le seul intêret que j'y vois, c'est de mutualiser du code métier entre plusieurs applis, et d'avoir un workflow indépendant de ces dernières.
Et c'est pas du tout comme ça que je le vois utilisé dans ma boite ou sur certains messages de ce forum... du coup je suis un peu perdu

[alexismp]

En Java, un Web Service est implémenté sous la forme d'une Servlet ou d'un EJB Session. Les outils facilitent la création de squelettes de code Java à partir de définition WSDL (ou inversement).

Pour les EJB, refais-toi une idée avec les EJB3.

[alexismp]

Quelques URL:
EJB3: http://www.netbeans.org/kb/55/ejb30.html
Web Services: http://www.netbeans.org/kb/55/websvc-jax-ws.html

[xv-mnt]

Quand aux EJB, j'ai pas regardé la dernière version, mais de ce que je vois dans l'appli que je maintiens, je trouve que c'est l'usine à gaz comparé à une 'simple' architecture 3 tiers MVC jsp/servlet/Struts....

jsp/servlet/struts sont des technologies liées au Web.
Les EJBs peuvent être utilisés hors web, par exemple dans l'architecture SOA, et s'utilisent pour traiter du code métier.
De plus, les conteneurs EJB adressent des problématiques différentes des conteneurs WEB, en particulier les transactions.

Enfin, l'architecture MVC peut se décliner sur plusieurs échelles :

• macroscopique : V = web, M = DB, C = EJB
• microscopique (par exemple): Dans un controleur WEB : V = jsp , C = servlet, M = DAO ou DTO.

[DrHelmut]

xv-mnt, j'ai bien précisé "dans l'appli que je maintiens" qui est une appli web en l'occurence.

Tu peux aussi faire du MVC en Swing... voire faire des archi n-tiers, où n >3... et avant les JSP, les servlets se chargeaient de la partie C et V (comme mes premières pages php )

Cela dit j'ai compris ta remarque, mais j'avais déja saisi cette particularité des EJB : ensemble métier/DAO/DTO dont les transactions sont gérés par leur container (d'ou leur indépendance, si chère à la POO, par rapport aux applis - mais également leur soucis de perfs - en tout cas toujours dans le cas particulier de cette appli de m.. que je dois maintenir - )

alexismp, merci pour tes liens : au premier abord EJB 3 c'est bien plus simple qu'avant, je regarderais ça en détail plus tard, n'ayant pas à faire évoluer l'appli mais juste à le maintenir en l'état (sniff)

Pour les WS, j'avais mal compris : j'ai cru que tu parlais de coder un EJB qui fonctionnerait comme un WebService;
Alors qu'en fait le truc, si j'ai bien compris, c'est juste que les outils JavaWS permettent d'écrire facilement un WS - sans autres connaissances que le J2SE ? - puis de le déployer sous forme d'EJB ou Servlet !

[Bba_M]

xv-mnt, j'ai bien précisé "dans l'appli que je maintiens" qui est une appli web en l'occurence.

Tu peux aussi faire du MVC en Swing... voire faire des archi n-tiers, où n >3... et avant les JSP, les servlets se chargeaient de la partie C et V (comme mes premières pages php )

Cela dit j'ai compris ta remarque, mais j'avais déja saisi cette particularité des EJB : ensemble métier/DAO/DTO dont les transactions sont gérés par leur container (d'ou leur indépendance, si chère à la POO, par rapport aux applis - mais également leur soucis de perfs - en tout cas toujours dans le cas particulier de cette appli de m.. que je dois maintenir - )

alexismp, merci pour tes liens : au premier abord EJB 3 c'est bien plus simple qu'avant, je regarderais ça en détail plus tard, n'ayant pas à faire évoluer l'appli mais juste à le maintenir en l'état (sniff)

Pour les WS, j'avais mal compris : j'ai cru que tu parlais de coder un EJB qui fonctionnerait comme un WebService;
Alors qu'en fait le truc, si j'ai bien compris, c'est juste que les outils JavaWS permettent d'écrire facilement un WS - sans autres connaissances que le J2SE ? - puis de le déployer sous forme d'EJB ou Servlet !

ce qu'il faut retenir:
-EJB et service web(SW) permet les deux d'invoquer une méthode à distance. mais l'avantage du SW c'est qui n'est pas lié à une plate-forme particuliere come EJB(Java). avec le SW il est possible pour une application dévelopé en java d'utiliser les méthodes d'une SW écrit en C++ ou autre et ce en utlisant les standard SOAP, WSDL .
-EJB normélement est utilisé dans un contexte orienté objet alors que le SW Objet ou non objet.
- utilisation des SW: quand une application a besoin des données d'une autre application(héterogene), il est temps d'utliser les SW.

- c'est mieux de comparer SW avec CORBA.