モジュラーJavaアプリケーション。 どうやって？

Javaがモジュール性をサポートしていないという事実は、すべての人に知られています。 問題は長い間存在しており、状況を修正するための多くの試みがありました。 Jigsawプロジェクトはこの目標に専念しています。 2011年には、2014年にJava 7でモジュール性のサポートを追加する予定でした-Java 8では、最終的に、変調の可能性があるJava 9が2017年7月末にリリースされることが発表されました。 しかし、この素晴らしい瞬間を見越して何をすべきか？

OSGiによる救助

Javaで真のモジュラーアーキテクチャを作成するには、OSGi（Open Services Gateway Initiative）-Javaアプリケーション用の動的モジュラーシステムおよびサービスプラットフォームの仕様（OSGi Allianceが開発）を使用できます。 コンポーネントがモジュラーアプリケーションの3つの主要な属性を持つソフトウェア開発モデルについて説明します。 カプセル化（各モジュールは実装を外部環境から隠します）、弱い接続（モジュールは以前に合意した契約とのみ相互作用します）、およびダイナミズム（コンポーネントはアプリケーション全体を停止せずにその場で交換できます）について話します。 OSGiコンセプトの基礎は、バンドルとサービスの2つのエンティティです。

バンドル

Javaでソフトウェアを開発する場合、原則として、サードパーティのライブラリが使用されます。 世界では、Javaライブラリーは、Javaクラス（.class拡張子を持つファイル）を含む通常のZIPアーカイブであるJAR拡張子（Java ARchive）を持つファイルにパッケージ化されています。 さらに、ライブラリの使用には特定の困難が伴う場合があります。



ライブラリの使用を開始すると、原則として、ライブラリ内のすべてのクラスが使用可能になります。 実際、ライブラリ開発者には、内部ロジックの実装に使用されるクラスを非表示にする機能がありません。 したがって、ライブラリの外部で使用することを意図していないコードを使用すると、ライブラリの新しいバージョンを使用するときに非互換性が発生したり、正しい機能が損なわれたりする可能性があります。



もう1つの問題は、いわゆるJAR地獄です。これについて、開発者は大量のコピーを破壊しました。 その本質は次のとおりです。同じライブラリの異なるバージョンを使用し始めるとすぐに（これは時間とともに進化する大規模なプロジェクトで発生します）、同じクラスがライブラリの異なるバージョンで異なるメソッドを持つという事実に遭遇する可能性があります。 Javaは、クラスローダーが検出したライブラリの最初のバージョンが使用されるように設計されています。 したがって、プログラムの実行中にコード内のクラスを参照すると、アクセスしているメソッドが存在しないというエラーが表示されます。 これは、実行時に、Javaが特定のケースで使用されるライブラリのバージョンについて何も知らないという事実によるものです。



OSGi開発者は、モジュール性を確保するためにJARファイルの構造を変更しませんでしたが、OSGi環境で使用される追加情報を単に追加しました。 さらに、この情報は、通常のJavaアプリケーションでのJARファイルの使用にはまったく影響しません。 したがって、JARファイルをOSGiセットにするために、Export-Package（このセットのパッケージは外部で使用可能）とImport-Package（このセットが機能するために必要な他のセットのパッケージ）を定義するデータが追加されます。 この場合、セットが他のセットに提供するAPIのバージョンと、そのセットが作業のために必要とするAPIのバージョンまたはバージョンの範囲の両方を指定することができます。 エクスポートされたセクションにないすべてのコレクションクラスは、コレクション（プライベート）の外部からアクセスできません。 このようにして、OSGiスイートは弱い接続要件を満たします。



今日、ほとんどのJavaライブラリはすでにOSGiに対応しています。 OSGiコンテナで実行できるようにするための情報が含まれています。 さらに、通常のJARファイルからOSGi用のモジュールを作成できる多くのツールとユーティリティがあります。



図 1。







OSGiでは、セットとこれらのセットによって提供されるインターフェイス間の依存関係に明確なバージョンがあるため、JAR Hellの状況を簡単に回避できます。 実行時に新しいセットを動的にロードおよびアンロードできます。 OSGiはセット間の依存関係を追跡し、それらを動的に解決します。

サービス

したがって、OSGi-kitの助けを借りて、インターフェース（API）を介して対話するモジュール式アプリケーションを開発できます。 しかし、必要なインターフェイスを実装するクラスはどこで入手できますか？ オプション「セットAPIに追加」は適合しません-モジュラーアーキテクチャの一部として、これらのセット外のセットの内部クラスを使用しないことに同意しました。 別の解決策は、インターフェイスを実装してファクトリAPIを適用し、コレクションAPIに追加することです。 しかし、あまり成功していません。なぜなら、 インターフェイスの実装を隠すには、毎回新しいクラスを開発する必要があります。



OSGiでのインターフェースの実装の検索は、サービスレジストリを使用して実行されます。 このレジストリでは、コレクションは、それを記述するインターフェイスを使用して実装を登録できます。 別のセットのインターフェイスを使用するセットは、レジストリで目的のインターフェイスの必要な実装を見つけることができます。 通常、OSGiコンテナーで実行される場合、セットは登録サービスを設定します。 さらに、異なる実装と追加の識別データを備えた同じインターフェースをサービスレジストリに登録できます。 フィルタリングを使用すると、セットはレジストリで提示されたサービスの中で最も適切なものを選択できます。



図 2。

マイクロサービスJava仮想マシン

マイクロサービスアーキテクチャは、独立したモジュールのセット-個別のアプリケーションです。 それらの間の相互作用は、軽量プロトコル（REST、プロトコルバッファー、MQなど）を使用して明確に定義されたインターフェイスを介して発生します。 実際、各モジュールは1つの特定のタスクを実行するマイクロサービスであり、通常、最小限のコードが含まれています。 ソフトウェア開発に対するこのアプローチの利点：

• 軽さ（マイクロサービスの開発時には、プログラムの機能の一部のみが実装されます）。
• 交換の容易さ（サービスがそのタスクに対応していない場合、現在のソフトウェアを停止せずに書き換えて新しいバージョンに置き換えることができます）。
• 再利用（マイクロサービスは適切な場所で再利用できます）。

OSGiを使用したモジュラーアプリケーションの開発者は、これらすべての利点を長い間享受してきましたが、Java仮想マシン内でのみです。 レジストリにサービスを公開する各OSGiスイートは、Java仮想マシンJVM内のマイクロサービスです（OSGiの世界では、これらのマイクロサービスはµServicesと呼ばれます）。

Red Hat JBoss Fuse

Jetでは、通信事業者、保険、および処理会社向けのソフトウェアを開発する際に、OSGiのすべての利点を活用しています。 これを行うには、Red Hat JBoss Fuse（Fuse Fabric設定）を使用します。 このプラットフォームは、モジュラーアプリケーションを実行するための柔軟なOSGi環境を提供します。



アプリケーション操作の継続性、簡単な水平スケーリング、展開の容易さ、クラスターソフトウェアのクラスター管理ツールの可用性-これらの機能はすべて、Fuse Fabricで利用できます。 このテクノロジーにより、Red Hat JBoss Fuseの複数のインスタンスをデプロイし、それらをクラスターに結合することができます。また、結果の環境を管理するための集中ツールも提供します。



Fuse Fabricには次の抽象化があります。



機能 （機能）-任意の機能を実装するOSGiセットのセット。

プロファイル （プロファイル）-同じコンテナ内で実行する必要がある機能のセット、および機能に含まれるセットの構成設定。

コンテナーは、Red Hat JBoss Fuseコンテナーの制御下でFuse Fabricクラスターの特定のノードで実行される個々のJVMプロセスです。



図 3。







Fuse Fabricテクノロジに基づくソフトウェアは、機能にグループ化され、事前定義されたプロファイルに従って1つ以上のクラスターノードに個別のJVMプロセスの一部としてデプロイされるOSGiセットで構成されます。



Fuse Fabric環境には、生成されたクラスターを簡単に管理するための多くのツールが用意されています。 プロファイル（およびそれらに基づくコンテナー）の作成、クラスター内の任意のホストでのコンテナーの作成/削除/開始/停止、新しいクラスターノードの接続などができます。 そして、このすべてをオンラインで-クラスターの残りのノードの機能を中断することなく。 プロファイル、機能、OSGiセットの複数のバージョンを保存することができます。



分散OSGiテクノロジーのおかげで、結果として生じる環境では、OSGiキットは同じまたは異なるコンテナー内、さらには異なるホスト内で相互作用できます。 さらに（最小限の開発コストで）OSGiスイートを提供する各サービスは、外部システムから呼び出すことができるREST / Webサービスに変換できます。



したがって、Fuse Fabricを使用すると、構成と展開の容易さ、JVMプロセス内でのサービスの独立した実行（ガベージコレクターのさまざまな設定などの特定の設定）をサポートするマイクロサービスアーキテクチャを作成できます。軽量プロトコルを使用するネットワーク。



なぜなら Red Hat JBoss Fuseは、Apache ServiceMixテクノロジーのオープンソーススタックに基づいており、Apache ActiveMQ（JMS仕様の実装）、Apache Camel（エンタープライズアプリケーション統合パターンの実装）、Apache CXF（REST / Web開発用ライブラリ）などの強力なテクノロジーを自由に使用できますサービス）、ブループリント（依存性注入機能を提供）、Springなど。 これらのテクノロジーはRed Hat JBoss Fuseで互いにシームレスに統合されるため、これにより必要な機能の開発時間が大幅に短縮されます。



この資料は、Jet Infosystems Software Solutions Centerの専門家によって作成されました。