こんにちは!前回の説明では、Apache Camel と Quarkus の統合について詳しく説明し、Apache Camel を使用して現実世界のアプリケーションを作成する方法を示しました。シリーズを続ける中で、Apache Camel の重要なコンポーネントと本質的な詳細を深く掘り下げることを目指しています。
Apache Camel の核心は、Gregor Hohpe と Bobby Woolf による Enterprise Integration Patterns (EIP) の本で紹介された概念を中心に構成されています。この本では、エンタープライズ アプリケーション全体にわたる堅牢な統合ソリューションを設計および文書化するための標準化となった多数のパターンについて概説します
またはシステム。ここでは、Apache Camel 内で利用されるいくつかの重要なパターンの概要を示します:
アグリゲーター パターン (図 1) は、関連するメッセージを収集して単一のメッセージに統合し、包括的な処理を容易にするために不可欠です。これは特殊なフィルターとして機能し、データの完全なセットが受信されるまで相関メッセージを蓄積し、受信した時点で集約された出力を公開します
さらなる処理のために。
図 1 – アグリゲーター パターン (enterpriseintegrationpatterns.com)
このパターン (図 2) は、メッセージをその内容に基づいて適切な受信者に動的にルーティングします。ルーティングの決定は、フィールドの存在や特定のフィールド値などのさまざまなメッセージ属性に依存する可能性があります。
図 2 – コンテンツベースのルーター パターン (enterpriseintegrationpatterns.com)
動的ルーター (図 3) は、実行時のルーティング決定を容易にし、外部またはユーザー入力を通じて定義されたルールに基づいて動的に適応し、最新のサービス指向アーキテクチャをサポートします。
図 3 – 動的ルーター パターン (enterpriseintegrationpatterns.com)
メッセージ フィルター (図 4) は、メッセージを出力チャネルに送信するか、指定された基準に基づいて破棄し、特定の条件を満たすメッセージのみがさらに処理されるようにします。
図 4 – メッセージ フィルター パターン (enterpriseintegrationpatterns.com)
このパターン (図 5) は、ビジネス プロセスの一連のステップを調整し、実行順序と発生する例外の両方を処理します。逐次処理とエラー管理が重要な複雑なワークフローを支えます。
図 5 – プロセス マネージャー パターン (enterpriseintegrationpatterns.com)
ノーマライザー パターン (図 6) は、異なるシステム間のメッセージ形式の不一致という課題に対処する Apache Camel の重要なツールです。さまざまな形式の受信メッセージを受け取り、さらに処理する前に標準化された形式に変換し、データ処理パイプライン全体の一貫性を確保します。このパターンは、メッセージがさまざまな形式のさまざまなソースから発信される環境で特に有益です。
図 6 – ノーマライザー パターン (enterpriseintegrationpatterns.com)
複数のデータ項目で構成される複雑なメッセージの処理は、Splitter パターンによって合理化されます (図 7)。このパターンは、複合メッセージをその構成要素に効率的に分割し、各要素を独立して処理できるようにします。これは、メッセージのさまざまな部分を、それぞれの特性に基づいて異なる方法でルーティングまたは処理する必要があるシナリオで非常に役立ちます。
図 7 – スプリッター パターン (enterpriseintegrationpatterns.com)
これらは Apache Camel で使用されるパターンのほんの一部であることを言及しなければなりません。 Apache Camel では他にも多くのパターンが使用されています。しかし、私はこれらのパターンが最も重要だと考えています。
本質的に、Apache Camel フレームワークは強力なルーティング エンジン、より正確にはルーティング エンジン ビルダーを中心にしています。このエンジンを使用すると、開発者はオーダーメイドのルーティング ルールを考案し、メッセージを受け入れるソースを決定し、それらのメッセージをどのように処理してさまざまな宛先にディスパッチするかを定義できます。 Apache Camel は、複雑なビジネス プロセスで見られるものと同様の統合言語を通じて、複雑なルーティング ルールの定義をサポートします。
Camel の基本原則の 1 つは、データに依存しない性質です。この柔軟性により、開発者はデータを事前定義された標準形式に変換するという厳密な要件を必要とせずに、あらゆるタイプのシステムと対話できるため、非常に重要です。多様なデータ形式をシームレスに処理できる機能により、Camel はあらゆるシステム インテグレーターのツールキットに含まれる多用途ツールになります。
Apache Camel の領域では、メッセージはメッセージング チャネルを介したシステム間の通信を促進する基本的なエンティティです。これらのコンポーネントを (図 8) に示します。ルートの実行中に、メッセージはさまざまな変換を受ける可能性があります。メッセージは変更、複製、
される可能性があります。
プロセスの特定のニーズに応じて、完全に置き換えることもできます。メッセージは本質的に送信者から受信者へ一方向に流れ、いくつかのコンポーネントで構成されます。
本文 (ペイロード): メッセージのメインコンテンツ。
ヘッダー: キーとそのそれぞれの値を含めることができるメッセージに関連付けられたメタデータ。
添付ファイル: メッセージと一緒に送信できるオプションのファイル。
図 8 – Apache Camel メッセージ構造
Apache Camel のメッセージは、java.lang.String 型の識別子によって一意に識別されます。この識別子の固有性はメッセージ作成者によって強制され、使用されるプロトコルに依存しますが、形式自体は標準化されていません。独自のメッセージ識別スキームを持たないプロトコルの場合、Camel は独自の ID ジェネレーターを採用します。
Camel メッセージのヘッダーは、送信者識別子、コンテンツのエンコードに関するヒント、認証データなどのメタデータを含むキーと値のペアとして機能します。各ヘッダー名は一意で大文字と小文字を区別しない文字列ですが、値は任意のオブジェクト (java.lang.Object) にすることができ、Camel のヘッダー タイプの柔軟な処理を反映しています。すべてのヘッダーはメッセージ内にマップとして保存されます。
さらに、メッセージには、Web サービスや電子メール トランザクションに関連するコンテキストで一般的に使用されるオプションの添付ファイルが含まれる場合があります。メッセージの本文も java.lang.Object 型であり、汎用性があり、あらゆる形式のコンテンツに対応します。この柔軟性により、アプリケーション設計者は、さまざまなシステム間でコンテンツの理解を保証する必要があります。これを支援するために、Camel は、必要に応じて自動型変換を含むさまざまなメカニズムを提供し、送信者と受信者の両方で互換性のある形式にデータを変換し、多様な環境間でのシームレスなデータ統合を促進します。
Apache Camel では、Exchange は Camel ルートを通じてデータをナビゲートする重要なメッセージ コンテナです。 (図 9) に示すように、メッセージをカプセル化し、Camel ルート内で事前に定義された一連のステップを通じてその変換と処理をサポートします。 Exchange は、次の org.apache.camel.Exchange インターフェイスを実装します。
図 9 – Apache Camel 交換
Exchange は、さまざまなスタイルのメッセージングに対応できるように設計されており、特に要求と応答のパターンを重視しています。メッセージの処理中に例外が発生した場合でも、障害やエラーに関する情報を伝達できるほど堅牢です。
取引所 ID: これは取引所の一意の識別子であり、追跡可能性を確保するために Camel によって自動的に生成されます。
メッセージ交換パターン MEP: メッセージング スタイル (InOnly または InOut) を指定します。 InOnly の場合、トランザクションには受信メッセージのみが含まれます。 InOut の場合、応答を開始者に中継するために追加の送信メッセージ (Out Message) が存在します。
例外 - Exchange はルーティング中に発生する例外をキャプチャし、エラー管理を一元化して処理と緩和を容易にします。
Body: 各メッセージ (受信および送信) には java.lang.Object 型のペイロードが含まれており、多様なコンテンツ タイプを許可します。
ヘッダー: マップとして保存されるヘッダーには、メッセージに関連付けられたキーと値のペアが含まれ、ルーティング キュー、認証キー、その他のコンテキスト情報などのメタデータが含まれます。
プロパティ: ヘッダーと似ていますが、交換全体にわたって持続するプロパティは、メッセージ処理ライフサイクル全体にわたって関連するグローバル レベルのデータを保持します。
メッセージ内: 基本コンポーネントであるこの必須要素は、受信チャネルからの受信リクエスト データをカプセル化します。
アウトメッセージ: InOut 交換に存在するオプションのコンポーネントで、応答データをアウトバウンドチャネルに伝送します。
Apache Camel では、Exchange は Camel ルートを通じてデータを運ぶメッセージ コンテナです。これはメッセージをカプセル化し、Camel ルートで定義された一連の処理ステップにわたってメッセージを変換および処理できるようにします。また、Exchange は要求と応答のメッセージングのパターンを容易にし、メッセージ処理中に例外が発生した場合に障害またはエラー情報を伝達する可能性があります。
Apache Camel コンテキストは、Apache Camel 内の重要な要素であり、統合フレームワークの機能を調整するコア フレームワークとして機能します。ここには、ルーティング ルール、構成、コンポーネント、および追加の統合要素が集中します。 Camel コンテキスト (図 10) は、すべてのコンポーネントとそれに含まれるルートのライフサイクルを初期化、構成し、監視します。
図 10 – Apache Camel コンテキスト
Camel コンテキスト内では、次の重要な操作が容易になります。
コンポーネントとデータ形式のロード: これには、さまざまなルートで使用されるコンポーネントとデータ形式の初期化と可用性管理が含まれます。
ルートの構成: メッセージがどのように処理され、さまざまなエンドポイント間で仲介されるかに関するルールなど、メッセージがたどるパスを定義するメカニズムを提供します。
ルートの開始と停止: Camel コンテキストはルートのアクティブ化と非アクティブ化を管理し、これらの操作がスレッドセーフな方法で実行されることを保証します。
エラー処理: コンテキスト内のすべてのルートで利用できる集中エラー処理メカニズムを実装します。
リソースの管理: スレッド プールや接続などのリソースを効率的に管理し、不要になったときにリソースを適切に解放します。
Camel コンテキストはプログラムまたは宣言的に設定できます。たとえば、Java ベースのセットアップでは次のようになります。
import org.apache.camel.CamelContext; import org.apache.camel.impl.DefaultCamelContext; public class MainApp { public static void main(String[] args) { CamelContext camelContext = new DefaultCamelContext(); try { // Add routes, components, etc. camelContext.start(); Thread.sleep(10000); } catch (Exception e) { e.printStackTrace(); } finally { try { camelContext.stop(); } catch (Exception e) { // Handle exception } } } }
Quarkus のような環境では、通常、Camel コンテキストは次のように取得および管理されます。
@Inject CamelContext context; if (context.isStarted()) { context.getRouteController().startRoute("start_route"); }
Quarkus を利用すると、Camel コンテキストが自動的にプロビジョニングされ、管理されます。
@ApplicationScoped public class DemoRoute extends RouteBuilder { @Override public void configure() throws Exception { from("direct:start_route") .log("Starting route: ${routeId}, headers: ${headers}") .setHeader("header_abc", constant("header_value")) .to("direct:route_1") .to("direct:route_3"); } }
Apache Camel では、エンドポイントは Camel アプリケーションを外部システムまたはサービスに接続するためのインターフェイスを表します。これらは、ルートが開始 (消費) または終了 (生成) するポイントです。
エンドポイントの一般的なタイプには次のものがあります。
// Route to read files from the directory "input" and move processed files to "output" from("file:input?move=processed") .to("file:output");
// Route to consume data from an HTTP service from("timer:foo?period=60000") .to("http://example.com/api/data") .to("log:result");
// Using direct for synchronous call from("direct:start") .to("log:info");
Camel のルートは、一連のプロセッサまたは変換を組み込んで、エンドポイント間のメッセージ フローを定義します。これらは、Camel アプリケーション内で処理ロジックを構築するために非常に重要です。
これは、相互接続された一連のルートを示す例です:
@ApplicationScoped public class DemoRoute extends RouteBuilder { @Override public void configure() throws Exception { from("direct:start_route") .log("Starting route: ${routeId}, headers: ${headers}") .setHeader("header_abc", constant("header_value")) .to("direct:route_1") .to("direct:route_3"); from("direct:route_1") .log("Starting route_1: ${routeId}, headers: ${headers}, thread: ${threadName}") .process( exchange -> { exchange.getIn().setHeader("header_abc", "UPDATED_HEADER_VALUE"); }) .to("direct:route_2"); from("direct:route_2") .log("Starting route_2: ${routeId}, headers: ${headers}, thread: ${threadName}"); } }
ここでは、最初のルートは direct:start_route エンドポイントから開始し、routeId とヘッダーをログに記録し、キー header_abc を使用して新しいヘッダーを設定し、メッセージを次のルート direct:route_1 に転送します。 2 番目のルートは、routeId、ヘッダー、およびスレッド名をログに記録し、メッセージを次のルート direct:route_2 に転送します。 3 番目のルートは、routeId、ヘッダー、スレッド名をログに記録します。
Apache Camel のこの詳細な調査では、Apache Camel をエンタープライズ統合の領域で不可欠なツールにする核となる概念と重要なコンポーネントを調べました。エンタープライズ統合パターン (EIP) の徹底的な調査から始めて、Camel がアグリゲーター、スプリッター、ノーマライザーなどのパターンをどのように利用して一般的な統合の課題に効果的に対処しているかを理解しました。
さらに、Camel のアーキテクチャの基礎を掘り下げ、その多用途なルーティング機能、柔軟なメッセージ モデル、およびこれらの要素の管理と調整における Camel コンテキストの重要な役割を強調しました。また、外部システムとの通信を容易にするさまざまなエンドポイント タイプについて説明するとともに、ルートがどのように定義および管理されるかを示す実践的な側面も取り上げました。
以上がApache Camel のコア機能とコンポーネントの探索の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。