ソフトウェアサービスは完全にスタンドアロンであるべきですか、それとももっと大きなコンポーネントに含めるべきですか？

Question

私は、1つのサービス（Webサービスではなく、必ずしもそうでない可能性もあります）に同じことをする4つの異なるソフトウェアコンポーネントをリファクタリングする過程にあります。 3はC++で書かれていますが、最も重要なものはJavaで書かれています。残りのシステムはJavaで書かれているため、C++コードをリファクタリングすることはなく、特にC++で書かれているコンポーネントは近い将来、のJavaコンポーネントに置き換えられる予定であるため、JNIを使​​用します。

現在Javaで実装されているコンポーネントは、実際は大きなコンポーネントのサブコンポーネントです。したがって、より大きい/ラッピングコンポーネントがサブコンポーネント（サービスにリファクタリングされている）を使用する場合、単にプロセス内Javaメソッドを呼び出します。そのサブコンポーネントを別のサービスにリファクタリングすると、元のラッピングコンポーネントは、現在プロセスメソッドの呼び出しで持っている利点を失います。

サービスゲートウェイとして機能するように元の/ラッピングコンポーネントにスレッドを追加する必要がありますか、コードをスタンドアロンサービスに完全にリファクタリングする必要があります。

私は十分に明らかにされていることを願っています...一般的には

Answer 1

は、「サービス」の単一のインスタンスがあるわけではありませんし、インスタンスがリモートで呼び出される必要がありません。パフォーマンスや可用性の理由からの同時展開の戦略はかなり妥当です。あなたは、ロジックの単一の実装を持つだけで、多くの利益を得ています。

ただし、既にサービスプロバイダが特定の方法で管理されている場合は、サービスインフラストラクチャを既に使用している場合は、一貫性があることが望ましいと思われます。

この場合、分離の影響を理解する必要があります。この場合、インプロセス呼び出しの利点は重要ですか？また、インプロセス・サービスを他のクライアントのために遠隔呼び出し可能なサービスとして実行することが、既存のシステムのパフォーマンスに悪影響を与えるかどうかを検討する必要もあります。

ローカルとリモートの両方の呼び出しが可能なコンポーネント（シンプルなステートレスセッションEJBを使用して実行可能）でコードをプルし、2回展開します。一度元のシステムと一緒に配置されます。一度サービスとして。最小の摂動のために絶対一貫性を犠牲にする。