0

私は、ほぼ同じことを行う 4 つの異なるソフトウェア コンポーネントを 1 つのサービス (Web サービスではない - 必然的または可能性さえあります) にリファクタリングしている最中です。3 つは C++ で記述されていますが、最後で最も重要な部分は Java で記述されています。システムの残りの部分は Java で書かれているため、C++ コードをリファクタリングしたり、JNI を使用したりする予定はありません。特に、現在 C++ で書かれているコンポーネントは近い将来に Java コンポーネントに置き換えられる予定です。

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

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

私は十分に明確であることを願っています...

4

1 に答える 1

0

一般に、「サービス」のインスタンスは 1 つだけである必要はなく、インスタンスをリモートで呼び出す必要もありません。パフォーマンスまたは可用性の理由から共同展開する戦略は非常に合理的です。ロジックを 1 つ実装するだけで、多くの利益が得られます。

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

したがって、分離の影響を理解する必要があります。この場合、インプロセス呼び出しの利点は重要ですか? また、インプロセス サービスを他のクライアントのリモートで呼び出し可能なサービスとして公開することが、既存のシステムのパフォーマンスに悪影響を与えるかどうかも考慮する必要があります。

私の直感: ローカルとリモートの両方の呼び出しが可能なコンポーネントにコードを取り込み (私の世界では、単純なステートレス セッション EJB で実行できます)、それを 2 回デプロイします。元のシステムと同じ場所に配置されます。サービスとして一度。摂動を最小限に抑えるために、絶対的な一貫性を犠牲にします。

于 2009-07-14T07:04:33.137 に答える