[SOA] EJB3 / WS

Bonjour;
Je travail sur une application JEE qui permet de gérer un type de messages destinée à un domaine d’application bien précis, il s’agit d’une application web qui aura les même fonctionnalités comme Outlook ou n’importe quel autre client de messagerie mais qui concerne un type de messagerie.
Pour implémenter cette application je dois suivre une architecture SOA, donc du EJB3 ou les web services, mais je dois justifier mon choix (entre les architectures) via une matrice décisionnelle, mais puisque je n’ai pas une expérience en JEE (j’en suis encore très débutant), je vous demande de communiquer les +/- de chaqu’une des ces architectures ainsi que les serveurs qui les implémentes pour que je puisse décider de bosser avec quoi et également faire convaincre le chef de projet.
Merci

Bon pour commencer, EJB3 et WebServices ne jouent pas forcément dans la même catégorie. En effet tu peux très bien faire tourner des EJB3 utilisant des WebServices (SOAP & cie) en tant que couche de transport à la place de RMI.

cf http://www.theregister.co.uk/2007/01..._web_services/

Bref les EJB3 sont une couche supérieure aux WebServices ou à RMI (ou autre protocole, quel qu'il soit).

Donc grosso modo, comparer Web Services et EJB3 revient à comparer Mouton et Cochon, pas vraiment grand chose à voir.

Bonjour; Merci pour votre repense, en faite mon application doit suivre une architecture SOA, en jee (j'en suis débutant), j'ai trouver que je peux utiliser des EJB3, sinon des web services comme je peux faire des ejb3 & des web service à la fois. ce que je demande si je suis amené à utiliser que du ejb3 ou du web services séparément, quelle est la diff entre ces deux architectures pour que je puisse savoir quelles sont les avantages et les inconvenants de chaqu'une.
Merci

En fait, les EJB3, c'est une sorte de framework qui te permet d'ecrire des procedures metiers en beneficiant du tout le support que t'offre le serveur d'application (transactionnel, securité, ...).

Les webservices, ca se compare plutot à une couche de transport, tout comme RMI. Ca permet "d'exporter" ton objet metier (comme un EJB3 par exemple) pour le monde exterieur. Bref, RMI ca permet à un client Java de discuter avec ton objet exporté alors que les webservices sont plus fait pour maximiser l'interoperabilité, cad qu'un client .NET/PHP ou autre va pouvoir discuter avec ton objet exporté.

Finalement, comme le dit sinok, EJB3 et webservices sont 2 choses bien différentes, que tu peux, à l'occasion, utiliser ensemble. Tu peux, par exemple, coder un EJB3 et l'exporter en tant que webservices.

Complètement d'accord avec les messages précédents.

J'aimerais faire une remarque supplémentaire sur :

Citation:

---

mon application doit suivre une architecture SOA

---

Cette phrase fait partie de la collection des phrases types qu'on trouve dans plein de cahiers des charges et qui ne veulent pas dire grand chose. On peut faire du SOA avec plusieurs niveaux de complexité.

Si tu veux aller au bout de la démarche, il te faudra un ESB, du BPM et autres outils élaborés. En général, cette démarche est peu adaptée au développement d'un projet, mais est un projet à part entière qui tend à restructurer le Système d'Information. De plus, cette démarche doit être initiée dès l'expression des besoins, avec une logique de processus métier poussée.

Le plus souvent, une telle phrase est collée dans un cahier des charges pour demander que les développements restent compatible avec une future mise en place de tels outils. Dans ce cas, il faut surtout concevoir l'application en couches distinctes, avec une couche métier sur lesquels viendront se greffer ces outils.

En conclusion, cette phrase est trop vague et, si tu ne veux pas prendre de risque, demande plus de détail, et surtout l'objectif du SOA, ici.