Un service logiciel doit-il être complètement autonome ou peut-il/devrait-il faire partie d'un composant plus important?

Question

Je suis en train de refactoriser 4 composants logiciels disparates qui font à peu près la même chose dans un seul service (pas un service web - nécessairement ou même probable). 3 sont écrits en C++ tandis que le dernier et le plus important est écrit en Java. Le reste du système est écrit en Java et donc je ne vais pas refactoriser le code C++ et en utilisant JNI en particulier car les composants actuellement écrits en C++ sont programmés pour être remplacés par des composants Java dans un avenir prévisible.

Le composant implémenté actuellement dans Java est en fait un sous-composant d'un composant plus important. Par conséquent, lorsque le composant plus grand/emballage souhaite utiliser le sous-composant (refacturé dans un service), il appelle simplement les méthodes Java intra-processus. Si je refactorise ce sous-composant dans un service distinct, le composant d'emballage d'origine perdra le bénéfice qu'il a actuellement de l'appel de la méthode dans le processus. Puis-je ajouter un thread au composant original/wrapping pour qu'il serve de passerelle de service ou devrais-je complètement refactoriser le code dans un service autonome.

J'espère que je suis suffisamment claire ...

Answer 1

En général, il n'a pas besoin d'être une seule instance de « service » et les cas ne doivent pas être invoqué à distance. Une stratégie de co-déploiement pour des raisons de performance ou de disponibilité est tout à fait raisonnable. Vous avez beaucoup de gains simplement en ayant une seule implémentation de la logique.

Cependant, si vous avez déjà une infrastructure de service en place, où les fournisseurs de services sont peut-être gérés d'une manière particulière, il est probablement souhaitable d'être cohérent.

Vous devez donc comprendre l'impact de la séparation. Les avantages de l'invocation en cours de processus sont-ils importants dans ce cas? Vous devez également déterminer si le fait d'étendre le service in-process en tant que service appelable à distance pour d'autres clients aura un impact négatif sur les performances du système existant. Mon instinct: tirez le code dans un composant capable d'invocation locale et à distance (dans mon monde qui pourrait être fait avec un simple EJB Session sans état) et déployez-le deux fois. Une fois co-localisé avec le système original. Une fois en tant que service. Sacrifiez la cohérence absolue pour une perturbation minimale.