Jboss-fuse-quick-guide
JBoss Fuse-ESBの概要
この章では、Enterprise Service Busの基本から始めます。 以下に、ESBの詳細な説明と、その利点、欠点、および理解を容易にするためのいくつかの図を示します。
ESBとは何ですか?
ESBはEnterprise Service Busの略です。 最も単純な形のESBは、通信する複数のアプリケーションを支援する情報ハイウェイとして機能するミドルウェアです。
エンタープライズの世界では、多くのことに対するソリューションを開発しています。 これらのソリューションは、異なるテクノロジーと異なるデータ形式を使用する場合があります。 これらの技術では通信やデータ形式の互換性の違いにより、これらのソリューションを一緒に使用するのは面倒です。 したがって、これらの異なるソリューション間で*疎結合統合*を可能にする技術が必要です。
ESBは、すべてのアプリケーションの中央に位置し、それらの間のメッセージルーティングを容易にする「HUB」になることにより、この統合の問題を簡素化することを目指しています。 ESBはメディエーターとして機能し、情報ハイウェイとして機能し、データ変換ルーティングを処理し、コーダーまたは開発者は自分のアプリケーションロジックに集中することができます。
ESBを理解することは、ESBが特に設計された問題を理解すると非常に簡単になり、ソリューションが簡単になります。 さまざまな言語で記述され、さまざまなデータ形式を使用してさまざまなマシンで実行し、情報を共有し、統合されたビジネスプラットフォームを形成する多くの異種システムを有効にする方法を明確に理解する必要があります。
統合の問題
エンタープライズプラットフォームでは、複数のアプリケーションが連携してビジネス機能全体を提供するのが一般的ですが、これらのアプリケーションの統合は最も頻繁に発生する問題です。 アプリケーションが成長するにつれて、時間とともにさらに困難になります。
各アプリケーションは、独自の形式でデータを入出力できます。 このアプローチは、アプリケーションの数が少ない場合はうまく機能しますが、アプリケーションの数が増えるにつれて、統合ホイールもより良いアプローチでかき回す必要があります。 たとえば、ビジネスの特定のアプリケーションを変更する必要がある場合、そのマスターアプリケーションに依存するすべてのアプリケーションの出力または入力データ形式が影響を受けます。
このようなアプローチは、密結合アーキテクチャを期待する統合の最大のハードルとして機能します。 ESBが登場するのはここです。 各アプリケーションは、他のアプリケーションと直接通信する必要はありません。代わりに、すべてのアプリケーションがESBと通信し、ESBが情報のルーティングと内部データ形式の変換を処理します。
ESBを選ぶ理由
以下に、Enterprise Service Busが不可欠である理由を説明するいくつかのポイントを示します。
- ESBは、バリアント互換アプリケーションとの統合の問題を簡素化することを目的としています。
- これはミドルウェアとして機能し、すべてのアプリケーションのメディエーターとして機能し、アプリケーション間のメッセージルーティングを容易にします。
- すべてのアプリケーションが他のすべてのアプリケーションと直接インターフェースする代わりに、各アプリケーションはESBへのインターフェースを1つだけ持つようになりました。
- ESBは、メッセージを共通の形式に変換したり、共通の形式から変換したり、宛先にルーティングしたりします。
- 既存のアプリケーションのいずれかを置き換える必要がある場合、このアプローチの大きな節約は恩恵となります。 たくさんの新しいインターフェースを書く代わりに、(アプリケーションとESBの間で)気にするインターフェースが1つだけになりました。
SOA&ESB?
SOAとESBは一般的に交換可能に使用されますが、完全に異なります。
SOAは、アプリケーションが通信プロトコルを介してネットワーク上のサービスとしてその機能を公開できるようにする設計パターンです。一方、ESBは異種システム間の通信を容易にするモデルですが、ESBはSOAの実装中にバックボーンとして使用できます。
ヒューズとは
JBoss Fuseは、RedhatによるオープンソースESBソリューションです。 これは、コミュニティプロジェクトのApache Servicemixに基づくエンタープライズソリューションです。
ヒューズへの統合
JBoss Fuseは軽量で柔軟な統合プラットフォームであり、エンタープライズアプリケーションの迅速な統合を可能にします。
ヒューズは、当初Progressive Software Inc.によって開発されました。 2012年にRedhatに買収されました。 JBoss Fuse 6.1.0.redhat-379 GAはFuseの安定バージョンであり、公式Webサイトからダウンロードできます。
建築
ヒューズは、さまざまな技術を単一の製品として組み合わせています。
コンポーネント
Apache CXF
Apache CXFは、SOAP&Rest Webサービスの開発もサポートするオープンソースWebサービス開発フレームワークです。
アパッチキャメル
Apache Camelは、EIPベースの統合フレームワークです。 EIPまたはエンタープライズ統合パターンは、エンタープライズ統合で繰り返し発生する問題に対する特定されたソリューションです。 完全に統合されたソリューションは、これらの事前定義されたすぐに使用可能なパターンの組み合わせにより、気象的に実現できます。
Java、Spring DSL、Scalaなどのいくつかのドメイン固有言語でルーティングロジックを記述することができます。
Apache AMQ
Apache AMQは、JMS標準に従って信頼できるメッセージングシステムを提供するJMSです。 JMS仕様をサポートするだけでなく、JMS仕様に含まれていないエキサイティングで便利な機能も提供します。
アパッチ・カラフ
Apache Karafは、アーティファクトのランタイムとして機能する軽量のOSGiコンテナーです。 Apache Karafは、JVMと比較して本質的に動的です。 実行時にモジュールをインストールまたはアンインストールできます。 FuseのすべてのアーティファクトはKarafにデプロイされます。
ファブリック
Fabricは、大規模な分散環境での成果物の展開を管理する簡単な方法を提供します。 複数のヒューズインスタンスすべてを集中管理します。
Fuseのインストール
Fuseのインストールは非常に簡単です。 他のJBoss製品と同様に、Fuseは解凍可能なzipファイルとして提供され、いくつかの小さな設定変更の後、直接起動できます。
Fuseのインストールは、4ステップのプロセスです-
ダウンロード
次のリンクからFuse 6.1.0 GAをダウンロードします。 http://www.jboss.org/
解凍する
他のすべてのJBoss製品と同様に、Fuseもプラットフォームに依存しないzipです。
ダウンロードしたファイルを、Fuseインストールディレクトリにするディレクトリに解凍します。 このディレクトリは、Fuseインスタンスの存続期間中同じままにする必要があるため、賢明に選択してください。
注-Fuseは他のJBoss製品のように解凍して起動しますが、インストール完了後にFuseインストールをある場所から別の場所に移動することはお勧めしません。
設定する
Fuseを解凍すると、抽出されたディレクトリ内に次のディレクトリが見つかります-
- bin
- etc
- 展開する
- lib
- ライセンス
- エキストラ
- クイックスタート
このうち、 bin と etc の2つのディレクトリのみを使用します。
事実上、Fuseを抽出した後、fuseを直接起動できるはずですが、これにより、本番環境にはお勧めできないすべてのデフォルト構成でFuseが起動します。 Fuseを起動する前に、次の変更を行うことを強くお勧めします。
環境変数を設定する
- 以下の環境変数を設定します- JAVA_HOME
- 変数はJavaインストールディレクトリを指す必要があります- M2_HOME
- 変数はMavenインストールディレクトリを指す必要があります- PATH
- パス変数を設定して、JavaおよびMaven実行可能ファイルを含めます。
Windows
Windowsでは、以下の指示に従って設定を行うことができます-
スタート→マイコンピューター→右クリック→プロパティ→システムの詳細設定→環境変数。
UNIXおよびクローン
各ユーザーの* nix オペレーティングシステムにはbashプロファイルがあります。 このファイルを変更することにより、既存のシステム変数を追加または編集できます。
注-このファイルの変更は永続的です。 元のファイルを変更する前に、既存のファイルのバックアップを取ることを強くお勧めします。
基本設定
JBoss Fuseの基本設定について説明します。そのためには、次のコマンドで開始する必要があります Edit $ FUSE_INSTALLATION_DIR/etc/
- user.properties
- #admin = admin、admin
- これは、希望するユーザー名を持つ最初の管理者、パスワードを持つ2番目の管理者、3番目の管理者に応じて変更する必要があります。
- たとえば、FuseAdmin = FusePAss、admin
- System.properties
- karafName = root
- これは、Karafインスタンスに付ける名前を示します。
- Cont1のような任意の名前を付けることができます。
- 指定するこの名前が一意の名前であり、Fuseの別のインスタンスによって既に使用されていないことを確認してください。
- org.ops4j.pax.web.cfg
- Org.osgi.service.http.port = 8181
- このプロパティは、Fuseが提供するブラウザベースのインターフェースHAWTIOにアクセスするために使用されるポートを示します
- HAWTIOは、Fuseに組み込まれたブラウザインターフェースであり、6.0以降から利用可能です
- org.ops4j.pax.url.mvn.cfg
- org.ops4j.pax.url.mvn.localRepository = D:/repository
- このプロパティは、FuseがアーティファクトをインストールするMavenのlocalRepositoryへのパスを示します。
- org.ops4j.pax.url.mvn.settings = D:/Maven/conf/settings.xml *このプロパティは、Mavenからアーティファクトを取得するためにFuseが使用するsettings.xmlを示します。
Mavenの構成
MavenはFuseをインストールするための前提条件です。 mavenがわからない場合は、http://www.finddevguides.com/maven/を参照してください。
Mavenは、Fuseアーティファクトの構築に使用される構築ツールです。 Fuseは、アーティファクトをインストールするコマンドを発行すると、Mavenローカルリポジトリでアーティファクトを最初に検索します。 そのため、Mavenがインストールされている場所とMavenのローカルリポジトリのパスをFuseに知らせる必要があります。
$ FUSE_INSTALLATION_DIR/etc/* org.ops4j.paxurl.mvn.cfg *を編集します
次の2つのプロパティを更新します-
- org.ops4j.pax.url.mvn.settings = $ M2_HOME/conf/settings.xml
- org.ops4j.pax.url.mvn.localRepository = $ local_repo
注意- $ local_repo を、Mavens settings.xmlに記載されているローカルリポジトリの実際のパスに変更してください。
Run
基本的な設定変更を行った後、Fuseを開始できます。 Fuseで動作するすべてのバイナリファイルは、 $ FUSE_INSTALLATION_DIR にあります。
Fuseを起動するには2つの方法があります-
- *。/fuse *を使用する
- これにより、Fuseを起動した同じウィンドウですべての進行状況とログを確認できます。
- 以下に示すのと同じ端末でKarafコンソールを提供します。
注-これはコンソールモードでヒューズを起動します。つまり、ユーザーがセッションからログアウトしたり、ターミナルを閉じたりすると、ヒューズプロセスも停止します。これは、本番または開発シナリオでは望ましくありません。 このスクリプトは、Fuseのデバッグにのみ使用してください。
- *。/start *を使用する
- これにより、進行状況も含めて画面にログが表示されなくなりますが、これによりバックグラウンドでFuseが開始され、ユーザーがセッションを終了したり端末を閉じたりしてもFuseサービスは停止しません。
- 実際のアプリケーションでは、このタイプの動作が望まれます。 ターミナルを閉じても、ヒューズはバックグラウンドで実行されている必要があります。
- バックグラウンドで実行されているFuseに接続する場合は、同じフォルダーにある client スクリプトを使用できます。
- 次のスクリーンショットのように表示されるはずです。 *クライアントスクリプトを終了しても、Fuseサービスは停止しません。 Fuseコンソールを閉じるだけです。
HAWTIO
Fuseは、FMC(Fuse管理コンソール)を使用して完全なGUIアクセスも提供します。 GUIは、URL* http://localhost:8181 *にあります。
コマンドを実行して行ったことはすべて、このブラウザベースのGUIにアクセスすることでも実行できます。 複数のコンテナがあり、Fabric環境で実行している場合に非常に役立ちます。
JBoss Fuse-Apache Karaf
この章では、Apache Karafと、それが軽量OSGiコンテナと呼ばれる理由と、その利点およびその他の重要な機能について説明します。
JVMの問題
JVMまたはJava仮想マシンは、実際の仮想マシンとして機能しません。 内部で実行中のコンポーネントを即座に停止、開始、または再起動できるマシン。 クラスレベルでのホットデプロイが許可される場合がありますが、仮想マシンでアプリケーションのコンポーネントを再起動せずにデプロイまたはアンデプロイする方法はありません。
この問題を解決し、Javaアプリケーションのモジュール化を可能にするために、FuseはApache Karafと呼ばれるOSGiベースのランタイムを使用します。
OSGi
OSGiテクノロジーは、Javaの動的コンポーネントシステムを定義する一連の仕様です。 これらの仕様により、アプリケーションが(動的に)多くの異なる(再利用可能な)コンポーネントで構成される開発モデルが可能になります。
OSGiの利点
- 複雑さの軽減-アプリケーションは、実装の詳細を互いに隠し、複雑さを軽減するコラボレーションコンポーネントとして構築されます。
- 再利用性-多くのコンポーネントは、コンテナにデプロイされた同じコンポーネントを活用できます。
- 展開-OSGiは、コンテナを再起動せずに、ライフサイクル管理APIを使用して、コンポーネントのオンザフライでの起動、停止、更新をサポートします。
バンドルと機能
以下は、バンドルと機能の比較です。
バンドル
バンドルは、JVMに対するjarと同じOSGiと同等です。 バンドルは、OSGiコンテナーにデプロイ可能な成果物です。 バンドルは、一緒にまたは独立して動作してアプリケーションを形成するコンポーネントです。
これらのバンドルは、コンテナを再起動せずに、実行時にインストール、アンインストール、更新、開始、または停止できます。
特徴
機能は、複数のバンドルを一緒にデプロイする方法です。 バンドルをグループで展開する方が理にかなっている場合があります。 機能を使用すると、1つのコマンドでバンドルのグループを展開できます。
なぜ別のコンテナですか?
Apache KarafはOSGiベースのランタイムであり、アプリケーションバンドルが実行されます。 Fuseは、Apache Karafをランタイムとして使用し、バンドルが実行されて連携してビジネス機能を提供します。
Karafは、OSGiフレームワークであるFelixと分点の上に構築されています。
カラフアーキテクチャ
Apache Karafは、基本的なOSGiランタイムに次の追加機能を追加します。
ホット展開
Karafはホットデプロイメントをサポートしています。 これには、ホットデプロイディレクトリが含まれています。 このディレクトリに配置されたものはすべて、自動的にバンドルとしてKarafにデプロイおよびインストールされます。
ロギング
Karafは、 $ Fuse_home/data/log にあるすべてのバンドルのログを生成することにより、集中ログを提供します。 * $ Fuse_home/etcディレクトリ*の org.ops4j.pax.logging.cfg でロガー設定を編集できます。
管理コンソール
Karafは、実行中のfuseインスタンスと対話するための洗練された明快な管理コンソールを提供します。 また、実行時にコンポーネント(バンドル)を管理および監視するために使用できるコマンドのプリインストールセットも提供します。 このコンソールは拡張可能であるため、新しいバンドルをコンソールに追加することにより、新しいコマンドをコンソールに追加できます。
SSHアクセス
Karafでは、SSHを使用してこの管理コンソールにリモートアクセスできます。 有効な資格情報を持っている人は誰でもSSHターミナル経由でkaraf管理コンソールに接続できます。
JBoss Fuse-Apache Camel
この章では、Apache Camelとは何か、エンドポイント間でデータを効果的にルーティングする方法、およびいくつかの例を説明します。
Apache Camelとは何ですか?
Apache Camelは、2007年初頭に開始されたオープンソース統合フレームワークです。
これはEIP(エンタープライズ統合パターン)ベースのアプローチであり、エンタープライズ統合の問題を解決するために使用できる、すぐに使えるパターンの実装をいくつか提供します。 EIPは、エンタープライズ統合でよく文書化され、繰り返し発生する問題に対する実証済みのソリューションに他なりません。
Camelは、エンドポイント間でデータを効率的にルーティングするため、ルーティングおよびメディエーションエンジンとしても知られていますが、データ形式の変換、エンドポイントの接続性などの負荷がかかります。
基本的な例
Apache Camelを使用するための前提条件は次のとおりです-
- Java
- メーベン
- Redhat JBoss Fuse 6.1-GA-379
アプリケーションの基本的なスケルトンを作成する
これにより、次のディレクトリ構造が生成されます。
これは、生成されるCamelアプリケーションの基本的なスケルトンです。
camel-context.xmlを編集します
pom.xmlを編集します
<plugins> </plugins>内に次のコードを追加します
パッケージの種類を jar→bundle から変更します。
次のコマンドを使用してプロジェクトをビルドします-
Fuseにプロジェクトをインストールする
これはKarafおよびFuseコマンドにアクセスするためのCLIです。
プロジェクトが実行中かどうかをテストします
これで、アプリケーションがFuseにインストールされます。 camel-first-app 内のデータディレクトリをコピーし、 D:/src/ に配置すると、city = Londonのメッセージを D:/target/merssages/uk にコピーする必要があります。
入力ファイルを D:/src/data に配置します
入力
Message1.xml
Message2.xml
出力
D:/target/messages/uk
D:/target/messages/others
JBoss Fuse-キャメルの概念
この章では、さまざまなラクダの概念を理解します。 まず、基本的な例を取り上げて、基本的な概念を理解しましょう。
CamelContext
すべてのラクダアプリケーションには、少なくとも1つのCamelContextがあります。 これは、ラクダルートを追加する場所です。 Springの ApplicationContext に似ています。
キャメルコンテキストは、すべてをまとめて保持するコンテナと考えることができます。 1つのラクダコンテキストに複数のルートを含めることができます。
ルート
CamelContextには1つ以上のルートが含まれる場合があります。 ルートは、あるエンドポイントから別のエンドポイントにキャメルコンテキストでデータが流れる方法を定義する統合ロジックです。
終点
エンドポイントは、システムがメッセージを送受信できるチャネルの終わりです。 これは、通信言語で宛先または送信元と呼ばれるものです。
コンポーネント
コンポーネントはCamelの拡張ポイントです。 コンポーネントは、テクノロジー、データ形式、トランスフォーマーなどへのインターフェースになります。 また、エンドポイントのファクトリとして機能する場合もあります。
EIP
EIPは、Enterprise Integration Patternの略です。 これらは、繰り返し発生する問題に対する特定された既知のソリューションです。 Camelは、エンタープライズ統合パターンのほとんどをサポートしています。
コンテンツベースのルーター
CBRパターンを使用すると、入力ファイルのコンテンツに従ってデータをルーティングできます。
このパターンは、入力の本文の内容に応じて値をルーティングする必要がある場合に使用されます。
次の例は、 D:/data/input ディレクトリからデータを読み取ります。 読み取り後、データタグ内の値タグをチェックします。 値タグに value1 が含まれている場合、 D:/value1 に送信されます。 value2 が含まれている場合、 D:/value2 に送信され、これらの両方が存在しない場合は、他の人に送られました。
入力
D:/data/input/message1.xml
D:/data/input/message2.xml
出力
D:/value1/
D:/value2/
スプリッタ
スプリッターパターンは、入力データを小さなチャンクに分割するために使用されます。
このパターンはほとんどの場合、チャンクに分割する必要がある巨大なデータ入力で使用されるため、処理可能になります。 入力トークン文字列に基づいて、入力をより小さなフラグメントに分解します。
入力
D:/inbox/message.xml
出力
AMQをチェックすると、3つのメッセージが投稿されます。
受信者リスト
受信者リストパターンは、受信者のリストをメッセージ本文から取得する必要がある場合に使用されます。
次の例では、顧客タグにリストされているすべての受信者に、コンマ区切りの文字列のリストとしてメッセージが送信されます。
その他のEIP
キャメルは、特定されたほぼすべてのEIPをサポートします。 一般的に使用されるEIPの一部は以下のとおりです。
- Log -メッセージ全体またはその一部を記録する
- メッセージフィルター-メッセージの内容のフィルタリング
- Re-Sequencer -すべてのトークンを順番に取得する
- 盗聴-旅行中のメッセージを検査する
EIPとその使用法の完全なリストは、Camelの公式ドキュメントhttp://camel.apache.org/eiplにあります。
キャメルの例外処理
エラーハンドラの使用-これは、ラクダで例外を処理する最も簡単な方法です。
これを使用するには、エラーハンドラクラスBeanを設定し、 CamelContext errorHandlerRef 属性への参照として提供する必要があります。
Try Catch finallyの使用
Camelは、エラー処理のためにJavaスタイルの* Try Catch finallyブロック*もサポートしています。
Javaと同様に、次の3つのブロックがあります-
- doTry ブロックには、例外を生成する可能性のあるコードが含まれています。
- doCatch ブロックには、例外の場合に実行する必要があるコードが含まれています。
- doFinally ブロックには、例外に関係なく実行する必要があるコードがあります。 例外が発生したかどうかに関係なく、常に実行されます。
注-モックはコンポーネントをテストしているため、他の目的には推奨されません。 テスト駆動開発のjMOckコンポーネントと同様に、テストに使用されるラクダのコンポーネントです。
上記の例では、catchブロックで処理する必要がある例外のリストを指定できます。
Fuseでのバンドルの展開
start.batを使用してFuseを起動する場合、client.batを使用してFuseに接続します。 次のスクリーンショットに示すようにUIを取得する必要があります。
これはKarafおよびFuseコマンドにアクセスするためのCLIです。
JBoss Fuse-Apache CXF
この章では、Apache CXFの概要と、SOAPおよびRest Webサービスの開発でApache CXFがどのように役立つかについて説明します。
Apache CXFとは何ですか?
Apache CXFは、SOAPおよびRest Webサービスの開発に使用できるWebサービス開発フレームワークです。 CXFは、 JAX-RSおよびJAX-Ws 標準に完全に準拠しています。
現在、最も広く使用されているWebサービス開発フレームワークです。 CXFは、現在は徐々にCXFに置き換わっているAxis2を学習して改善しました。
CXFとAxis2
CXF | Axis2 | |
---|---|---|
Improvements |
CXF is most used framework as of now. Axis2よりも多くの_改善点_があります a |
Axis2は徐々にCXfに置き換えられています。 CXFと比較してより多くのコードが必要です |
Code required | CXF requires less code as compared to Axis2 | Axis2 requires more code comparatively |
Standard Compliance | CSF is fully compliant with JAX-RS and JAX-WS | Axis2 is not fully compliant with JAX-RS and JAX-WS |
Compatible with Spring | Yes | No |
Separation of front-ends | Clean separation of front-end from JAX-WS code | No clean separation is provided |
SOAP
SOAPはSimple Object Access Protocolの略です。 これは、2つのシステム間でWebサービスを介して構造化された情報を交換するためのプロトコルです。 データの構造化は主にXMLに依存し、メッセージのネゴシエーションと送信にはHTTPまたはSMTPを使用します。
SOAP Webサービスを開発するには、2つのアプローチがあります-
- コードファースト-このアプローチでは、WSDLはコードから生成されます。
- Contract First -Contract Firstでは、WSDLからコードが生成されます。
CXFを使用したSOAP開発
Mavenを構成する
次のプロファイルをMavenのsettings.xmlに追加します。
スケルトンを作成する
- Webサービスプロジェクトのビルド*。
次のコマンドを使用して、WebサービスをFuseにインストールします。
バンドルがSOQP Webサービスを登録しているかどうかを確認
URLを開く http://localhost:8181/cxf
Webサービスは次のようにリストされます。
- Webサービスのテスト*
JBoss Fuse-REST Webサービス
まず、RESTはRepresentational State Transferの略です。 これは、ほとんどの場合HTTPであるステートレスでキャッシュ可能なクライアント/サーバープロトコルに基づいてWebサービスを開発する方法です。
REST Webサービスは、HTTP要求を使用して、ネットワークからデータを送信、取得、削除します。
CXFを使用したREST開発
シンプルなMavenクイックスタートプロジェクトを作成する
依存関係を追加する
ビルド命令を追加
ヒューズプラグインリポジトリの追加
リポジトリを追加する
サービスクラスの作成
com/tuts/の下にクラスUserService.javaを作成します
Blueprint.xmlを作成する
/src/main/resources/OSGI-INF/blueprint blueprint.xmlの下にblueprint.xmlを作成します
FuseにRestサービスをインストールする
バンドルに登録済みWebサービスがあるかどうかを確認します
URLを開く http://localhost:8181/cxf
Webサービスのテスト
URLを開く http://localhost:8181/cxf/users12/UserService_1/get_data
JBoss Fuse-Apache AMQ
この章では、ActiveMQと、アプリケーションが相互に通信できるようにするためのメッセージブローカーとしての機能について説明します。
AMQとは何ですか?
ActiveMQは、Javaで書かれたオープンソースのメッセージブローカーです。 JMS 1.1標準に完全に準拠しています。
JMSは、メッセージベースのシステムの開発を可能にする仕様です。 ActiveMQは、アプリケーション間に存在するメッセージのブローカーとして機能し、非同期で信頼できる方法で通信できるようにします。
メッセージングの種類
理解を深めるために、以下に2種類のメッセージングオプションを説明します。
ポイントからポイントへ
このタイプの通信では、ブローカーは1つのコンシューマーのみにメッセージを送信しますが、他のコンシューマーはブローカーからメッセージを取得するまで待機します。 消費者は同じメッセージを受け取りません。
コンシューマーがない場合、ブローカーはコンシューマーを取得するまでメッセージを保持します。 このタイプの通信は、*キューベースの通信*とも呼ばれ、プロデューサはメッセージをキューに送信し、1つのコンシューマのみがキューから1つのメッセージを取得します。 複数の消費者がいる場合、次のメッセージを受け取ることがありますが、他の消費者と同じメッセージを受け取ることはありません。
公開/購読
このタイプの通信では、ブローカーはすべてのアクティブなコンシューマーに同じメッセージのコピーを送信します。 このタイプの通信は、*トピックベースの通信*とも呼ばれ、ブローカーは特定のトピックを購読しているすべてのアクティブな消費者に同じメッセージを送信します。 このモデルは、送信されたメッセージの検証が期待されない一方向通信をサポートします。
キューとトピックの作成
ヒューズはActiveMQにバンドルされています。 FMCコンソール(AMQで動作するブラウザーベースのインターフェイス)を使用してActiveMQにアクセスできます。
- [+作成]をクリックします
- キュー/トピック名を入力してください
- ラジオボタンからキュー/トピックを選択
- キューの作成/トピックの作成をクリックします
これで、ルート→キュー→の下に作成された TestQ が表示されるはずです。
作成されたトピックを確認するには、ルート→トピックに従ってください。
キューの内容の参照/削除
- localhost:8181 を使用してFMCにログインします
- ActiveMQタブを選択します
- ルート→キュー→TestQ <参照するキューを選択>→参照
- このメッセージの内容を確認するには、その特定のメッセージをクリックしてください。
- 特定のメッセージを削除するには、右上にある[削除]ボタンをクリックします
JBoss Fuse-キャメル付きAMQ
この章では、ActiveMQがCamelとどのように連携するかの基本を学びます。
ActiveMQコンポーネントへの構成
コードでActiveMQキューまたはトピックを使用する前に、ActiveMQComponentを構成する必要があります。 ActiveMQComponentの最小限の構成は、次のプログラムに示すように行うことができます-
- brokerURL -AMQブローカーのホストとポートを指定します。
- username -AMQ Brokerへの接続に使用するユーザー名を指定します。
- password -AMQ Brokerに接続するためのパスワードを指定します。
キューへの接続
ActiveMQComponentを構成したので、CamelContextでエンドポイントとして使用できます。
私たちは次の形式でAMQエンドポイントを使用します-
AMQへのメッセージの書き込み
このバンドルをFuseコンテナにデプロイすると、 D:/src/data にファイルとして配置されたAMQに投稿されたメッセージを確認できます。
入力
D:/src/data/input.txt
出力
AMQからの読み取り
入力
このバンドルをデプロイすると、D:/srcにファイルが生成され、メッセージが消費されます。 また、そのキューのコンシューマも表示される必要があります。
出力
D:/src
トピックへの書き込み
トピックから読む
入力
D:/src/file1.xml
出力
D:/src/
JBoss Fuse-ファブリック
ファブリックとは何ですか?
Fabricは、複数のFuseインスタンスに管理機能とオーケストレーション機能を提供します。 ファブリックを使用すると、接続されているすべてのFuseインスタンスを単一のポイントから制御できます。 通常のFuseコンテナは、Fabricとして機能するように変換できます。 ファブリックには、コンテナに関するすべての情報を含むデータストアとして機能するファブリックレジストリがあります。
なぜファブリックなのか
ファブリックには次の特別な機能があり、分散環境での使用に最適です。
- ファブリック内のすべてのコンテナの状態を監視します。
- リモートコンテナの起動と停止。
- 特定のアプリケーションを実行するためにリモートコンテナーをプロビジョニングします。
- ライブシステムでのアプリケーションのアップグレードとパッチのロールアウト。
- たとえば、システムの負荷の増加に対処するために、新しいコンテナですばやく起動およびプロビジョニングします。
ファブリックのセットアップ
ファブリックの作成
次のコマンドを使用して、通常のヒューズコンテナをファブリックに変換できます。
他のコンテナをファブリックに接続する-
注-<fabric_host>を、ファブリックが実行されている実際のホスト名に置き換えてください。
プロファイル
プロファイルには、次の情報が含まれています-
- インストールされるバンドル
- インストールする機能
- 適用される構成
プロファイルは、ファブリック環境で同じバンドル、機能、および構成のセットを複数のサーバーにインストールする方法を提供します。
同じプロファイルが複数のコンテナに適用され、コンテナからそのプロファイルに変更を加えると、同様の変更が適用される残りのコンテナに自動的に展開されます。
プロファイルを作成する
- FMCにログイン localhost:8181
- ランタイム→管理
- 左側の[プロファイル]メニューで[ + ]をクリックします
プロファイルに付ける名前を入力し、[作成]をクリックします。
この後、プロファイルを作成する必要があります。
コンテナへのプロファイルの適用
ランタイム→コンテナ→ルート(必要なコンテナを選択)
[追加]をクリックすると、ポップアップボックスが表示されます。 目的のプロファイルを検索し、[追加]をもう一度クリックします。
次のスクリーンショットに示すように、プロファイルがリストに表示されます。
バンドルの展開
バンドルを展開するには、次のパスを使用します-
ランタイム→コンテナ→ルート(必要なコンテナを選択)→First_profile(プロファイルを選択)
[バンドル]タブをクリックします。 バンドルパスを次の形式で設定し、[ + ]をクリックします。
- mvn:group.id/artifact.id/version*
例:* mvn:com.tutorialpoint.app/camel-firt-app/1.0-SNAPSHOT*
バンドルがプロファイルに追加され、プロファイルが割り当てられているすべてのコンテナーにデプロイされます。
バンドルの展開解除
バンドルを展開解除するには、次のパスを使用します-
ランタイム→コンテナ→ルート(必要なコンテナを選択)→First_profile(プロファイルを選択)
[バンドル]タブをクリックして、削除するバンドルを検索し、[ X ]をクリックします。 バンドルは、プロファイルが適用されるすべてのコンテナから削除されます。
JBoss Fuse-子コンテナ
子コンテナは、増加する負荷を管理する最も簡単な方法を提供します。 システムにトラフィックの急激な負荷がかかっており、単一のコンテナが負荷に対処できない場合、完全に新しいコンテナを作成するのではなく、子コンテナのセットを簡単に作成して負荷を分散できます。
子コンテナを作成する
今、パスに従ってください:ランタイム→コンテナ→+作成(右側のボタン)
子名、親コンテナのインスタンス数などの詳細を入力します。
[コンテナを作成して開始]をクリックします
子コンテナの管理
子コンテナは、通常のコンテナとしてのみ機能します。
子コンテナの停止
子コンテナを停止するには、次のパスに従ってください:ランタイム→コンテナ→Child1
[停止]をクリックして、子コンテナを停止します。
子コンテナの開始
子コンテナーを開始するには、次のパスに従ってください:ランタイム→コンテナー→Child1
[開始]をクリックして、子コンテナを開始します。
JBoss Fuse-問題と解決策
この章では、Fuseの使用中に発生する可能性のあるいくつかの既知の問題について説明します。 また、これらの問題を克服する方法についても説明します。
コードの変更は反映されません
クライアントスクリプトを使用してFuseインスタンスに接続します。 次のコマンドを使用して、問題に直面しているバンドルを検索します。
注-上記のコマンドの出力からのバンドルのバンドルID。以下のコマンドを使用します。
バンドルがダウンロードされていません
それは次の2つの理由のために発生する可能性があります-
- Mavenリポジトリが指定されていません *バンドルがリポジトリに存在しません
Mavenリポジトリが指定されていません
Mavenは、Fuseアーティファクトの構築に使用される構築ツールです。 Fuseは、アーティファクトをインストールするコマンドを発行すると、最初にMavenローカルリポジトリでアーティファクトを検索します。 そのため、Mavenがインストールされている場所とMavensローカルリポジトリのパスをFuseに知らせる必要があります。
$ FUSE_INSTALLATION_DIR/etc/* org.ops4j.paxurl.mvn.cfg *を編集します
次の2つのプロパティを更新します-
- org.ops4j.pax.url.mvn.settings = $ M2_HOME/conf/settings.xml
- org.ops4j.pax.url.mvn.localRepository = $ local_repo
注意-Mavens settings.xmlに記載されているローカルリポジトリの実際のパスで$ local_repoを変更してください
リポジトリに存在しないバンドル
Mavenの設定が整っているが、バンドルのダウンロード中に問題が発生する場合は、バンドル JAR がMavenリポジトリの正しい場所に存在することを確認してください。
たとえば、次のバンドルがダウンロード中にエラーをスローしている場合-
- mvn:com.tutorialpoint.app/camel-first-app/1.0-SNAPSHOT*
実際のJARが存在する場合は、$ M2_REPO/com/tutorialpoint/app/camel-first-app/1.0-SNAPSHOTをチェックインする必要があります。
注意-$ M2_REPOは、使用するようにFuseを構成したMavenリポジトリの実際のパスに置き換える必要があります。
FMC(ブラウザベースのGUI)にログインできない
ユーザーが作成されていません-次のUIを取得しているが、「ログインに失敗しました、禁止」というメッセージでログインできない場合。
ユーザーを追加するための正しい形式は-
HAWTIOポートは異なります
ブラウザのlocalhost:8181でUIを取得できない場合は、URLに正しいポートが記載されているかどうかを確認してください。
ファイル内の次のプロパティを編集して、アクセスするポートを使用します。
AMQブローカーが機能していません
61616ポートが開いていて、現在別のポートで使用されていないことを確認してください。 同じためにデフォルトの61616ポートを変更する場合は、 $ FUSE_INSTALLATION_HOME/etc/System.properties で編集できます。