Quelle architecture SOA est la plus appropriée pour une application Java?

Question

Je travaille actuellement sur une très grande application Java 6 où nous cherchons à diviser certaines de nos fonctionnalités en une architecture orientée services.

Il semble que le framework SOA principal pour l'espace d'application est OSGi et j'ai étudié Felix et Knopplerfish mais je voulais m'assurer que ce n'est pas ma seule option.

Est-il logique d'utiliser un protocole de service Web réel pour notre application comme SOAP, même si nous ne construisons pas d'application web? Est-ce que c'est même acceptable?

L'un de vous a-t-il utilisé une implémentation d'OSGi (Felix, etc.) avec votre application de bureau? Si oui, comment est-il allé? Connaissez-vous quelque chose de mieux?

Nous sommes tous nouveaux dans le domaine de la SOA, donc toute aide serait grandement appréciée.

Answer 1

Nous utilisons Eclipse RCP comme plate-forme d'application, basée sur OSGi (Equinox). Notre application utilise à la fois les plugins Eclipse et les bundles OSGi purs. Dans notre cas, nous avons des services qui sont à la fois locaux à l'application ainsi que distants (via Spring Remoting) aux serveurs Java EE.

Dans votre cas, OSGi peut être logique pour votre application, mais pas les protocoles de service distant.

De même, une application de bureau en elle-même n'est pas considérée SOA. Vous êtes simplement en train de chiffrer votre application, ce qui est une bonne chose.

Answer 2

Mon entreprise utilise largement OSGi, et cela fonctionne bien pour nous, car nous pouvons mettre à jour divers composants et avoir un meilleur contrôle sur ce qui est exposé de chaque composant.

Si vous envisagez de vouloir exécuter différents composants sur un matériel séparé, l'écriture à l'aide de services Web (REST/SOAP/etc) est logique. Mais il y a une pénalité de performance à la fois en envoyant des bits d'un processus ou d'un réseau à un autre, en sérialisant/en rassemblant ces données afin qu'elles puissent être envoyées, et en faisant le contraire de l'autre côté. Si vous ne pensez jamais que cela arrivera, n'utilisez pas les services Web.