Websphere共有ライブラリとJavaプロジェクトで定義されたライブラリの使用を理解していますか？

Question

Websphere共有ライブラリとJavaプロジェクトで定義されたライブラリの使用を理解する助けになる人はいますか？私はwebsphereには新しく、共有ライブラリのコンセプトを理解していないというだけでなく、作業しているプロジェクトのlibフォルダにライブラリクラスを置いているだけです。

Answer 1

共有ライブラリを使用することにはいくつかの利点があります。

1. は、メモリ消費量を削減します。多くのアプリケーションを使用する場合は、サーバーに関連する共有ライブラリまたは独立した共有ライブラリを使用することにより、JVMはアプリケーション内のライブラリの各コピーのクラスをロードするのではなく、クラスの単一のコピーをメモリにロードできます。
2. WARのサイズを小さくします。これにより、バックアップを維持すると、展開時間が短縮され、ネットワーク転送が削減され、ストレージサイズが縮小されます。
3. 環境の管理性を向上させます。多くのアプリケーションが展開されており、修正のためにライブラリの1つをアップグレードする必要がある場合は、中央ライブラリを更新するよりも多くのアプリケーションを再パッケージ化/再デプロイする方が多くなります。一度にすべてではなく「ゆっくり」アプリケーションを更新する必要がある場合は、依存バージョンの異なるバージョンに対して複数の共有ライブラリを宣言できます。このアプローチでは、サーバー関連のライブラリではなくアプリケーションに関連するライブラリを使用する必要があるため、ここに挙げたその他の利点を引き続き得るには、独立した共有ライブラリを使用する必要があります。
4. ネイティブライブラリのサポートが強化されました。アプリケーションでネイティブライブラリを使用するライブラリが必要で、アプリケーションでライブラリをパッケージ化する場合、ネイティブライブラリがアンロードされたりロードされたりするのを防ぐJVMの制限があるため、通常はサーバを再起動せずにアプリケーションを再起動することはできません。複数のアプリケーション。

通常、アプリケーションは使用しているライブラリのバージョンと緊密に結合しているため、ライブラリをアプリケーションから分離すると、アップグレードがより困難になる可能性があります。

Answer 2

ブレットが有効なポイントを持ち出しました。私は＃3の欠点についてもっと詳しく説明します。

＃3の場合は、修正のために例のような新しいバージョンにライブラリをアップグレードすることが有効です。しかし、私の経験では、同じJVMを本番環境で共有する複数のアプリケーションがあり、それらがすべてライブラリを使用すると、（a）新しいバージョンのライブラリ（b）をすべてのアプリケーションで適時にテストし、 ）すべての利害関係者が、異なる事業部門にある場合に特に配備される図書館の修正に同意するようにしてください。アプリケーションは、親ライブラリを親ラストに設定することによって親ライブラリをオーバーライドできますが、最新の修正を統合する必要のあるアプリケーションがEARファイル内で実行し、共有ライブラリをオーバーライドできることを意味します。しかし、それは共有ライブラリの利点を打ち破っています。これは、JVM環境がどのように「共有」されているか、同じJVM内のアプリケーションがタイムリーに新しいバージョンのライブラリを使用できるかどうか（つまり、テストを終了するかどうか）などです。