Pourquoi et quand utiliser des services Web basés sur EJB?

Question

Pour transférer des données d'un système à un autre via l'interface de données, par les services Web, nous obtenons normalement un résultat par requête SQL et formatez-les en tant que point de terminaison de service Web.

Avec EJB 3.0, il semble que nous pouvons remplacer le jeu de résultats par le bean de session sans état. Y a-t-il donc des avantages par rapport aux services Web basés sur SQL? Et quand devrions-nous l'utiliser?

Answer 1

Ceci est une question très large sur le niveau de l'architecte système. Je vais essayer de répondre avec ma meilleure connaissance sans commencer une guerre de flamme (FYI, j'ai utilisé à la fois ejb et le printemps). Comme vous le savez, la construction d'une application logicielle stable/robuste nécessite de nombreux blocs de construction, tels que la journalisation, le pool de connexions, etc. Généralement, vous pouvez trouver des bibliothèques de ces blocs, mais elles n'ont pas toutes l'API commune. ils peuvent nécessiter une intégration. Dans le pire des cas, vous devrez peut-être verrouiller certains fournisseurs. L'idée principale de EJB 3 (ou Java EE) est de fournir un ensemble plus complet de blocs de construction (via API, annotation ou config), afin que les développeurs puissent commencer à travailler sur la logique métier immédiatement avec une API/spec/config sans formation sur les API propriétaires. De plus, vous pouvez changer de fournisseur sans changer vos codes puisque API/config sont vraiment la norme de l'industrie (bien, votre kilométrage peut varier beaucoup dans la vie réelle, espérons que le nouveau Java EE le corrigera).

Votre application peut déjà avoir certains des principaux éléments déjà fournis par EJB 3. Cependant, EJB 3 promet d'en fournir davantage comme le mappage ORM, l'équilibrage de charge, le basculement, les transactions, le redéploiement dynamique, la journalisation, la gestion du système, la gestion des threads, la mise en pool des ressources, la sécurité et la mise en cache.

Comme vous avez déjà une application qui fonctionne déjà, vous pouvez vraiment considérer s'il vaut la peine de migrer vos codes vers un système standard pour gagner en fonctionnalité et intégrer de nouvelles fonctionnalités individuellement. De plus, EJB 3.0 (ou Java EE) n'est pas vraiment le framework que vous pouvez choisir. Vous pouvez également regarder dans un autre cadre, tel que Spring.

Ma suggestion est de vraiment comprendre ce que votre système a besoin, puis de choisir les bonnes technologies au lieu de choisir les technologies les plus cool en premier.

Bonne chance