サービス志向のアーキテクチャ効率でibatisをどのように使用しますか？

Question

いくつかのサービスがあり、それぞれが互いに独立して動作するのは理想的です。サービスの主な使用は、当社のWebAppをサポートすることです。これらのサービスでIbatisを使用する最良の方法を探しています。

私たちの最初のアプローチは、SQLSessionFactoryを使用して1つのプロジェクトを持ち、すべてのサービス実装にデータアクセスにそのプロジェクトを使用することでした。これは、プロジェクトがデータオブジェクトのすべてのサービス（サービスを分離し、サークル依存関係を排除するためにインプレクトする必要がある）に依存し、すべてのSQLマップが含まれていることを意味します。利点は、いつでもSQLSessionFactoryの1つのインスタンスと、管理する構成の1つです。ただし、1つのサービスがJunitsまたは他のユーティリティのように使用される場合、すべてのSQLマップは関係なくロードされ、すべてのサービスは依存関係です。

別のアプローチは、各サービスに独自のIBATIS構成とSQLSessionFactoryのインスタンスを持つことです。これにより、データアクセスプロジェクトへの依存のメッカの必要性が回避されますが、WebApp上のSQLFactoryのいくつかのインスタンスを意味します。

私は2番目のアプローチが好きですが、私は両方で良いことも悪いことも見えます。

あなたならどうしますか？あなたは私の議論から何を追加したり、奪ったりしますか？

助けてください！！！

Answer 1

あなたの最初の議論の強さは一般的にSOAの弱さを指し示していると思いますが、もしあなたがSOAをしているなら、それはすべてのサービスを互いに相互依存するという全体的な目的を打ち負かすと思います。

SOAを行っている場合、コンポーネントの分離と分離のために、より非効率的なリソース使用のトレードオフを受け入れています。

Answer 2

正直なところ、パフォーマンスのボトルネックを見つけるか、アプリケーションが大きすぎるまでシンプルにしてください。つまり、サービスが独自のスケジュールで独立して更新されると予想しない限り。

私が働いている場合、すべてのアプリケーションの間で共有される共通のコードがあります。それはすべて同じソースから来ていますが、各アプリケーションに独立して組み込まれています。これはおそらく最良のソリューションではありませんが、少なくとも、個別のアプリが展開されていることを心配することなく、一般的なコードを簡単に変更できます。また、より多くのアプリケーションが導入されるにつれて、一般的なコードが変更され、以前に展開されたアプリが発生することができます。

Answer 3

両方のソリューションが適用できる場合、おそらくすべてのサービスが同じJVMで実行されます。私の意見では、コンポーネントを別々のJVMで実行することを考える必要があります。真のサービスコンポーネントアーキテクチャとは、クラスター化された環境で実行され、ゆるく結合した人間で互いに話し合います（たとえばJMS、またはWebサービスやRMIなど）。各コンポーネントは独立しており、リモートサーバーで実行される場合があります。

この場合、もちろん2番目のアプローチを使用します。ただし、アプリケーションがこの分離を必要としない場合は、メモリ効率が高いため、最初のアプローチを使用する必要があります。

結局のところ、あなたのアプリケーションが本当に必要とするものの質問です。