回答:
5分から10分あれば、Jonathan AnsteyによるApache Integration with Apache Camelを読むことをお勧めします。これは、Camelのいくつかの概念の簡単な紹介と概要を提供する、よく書かれた作品であり、コードサンプルを使用してユースケースを実装します。その中で、ジョナサンは書きます:
Apache Camelは、統合を容易にし、開発者がアクセスしやすくすることに焦点を当てたオープンソースのJavaフレームワークです。これは、以下を提供することによって行われます。
- 広く使用されているすべてのエンタープライズ統合パターン(EIP)の具体的な実装
- さまざまなトランスポートとAPIへの接続
- EIPとトランスポートを一緒に配線するための使いやすいドメイン固有言語(DSL)
Camel in Actionの無料の章もあり、最初の章でCamelを紹介しています。ジョナサンは私と一緒にその本の共著者です。
これをよりアクセスしやすい方法で説明するための私の見方...
Apache Camelとは何かを理解するには、エンタープライズ統合パターンとは何かを理解する必要があります。
おそらくすでに知っているものから始めましょう。シングルトンパターン、ファクトリーパターンなどです。これらは単に問題の解決策を整理する方法ですが、それ自体が解決策ではありません。これらのパターンは、Gang of Fourが彼らの本「Design Patterns」を発行したときに、残りの人たちのために分析および抽出されました。彼らは私たちの何人かを、コードを最適に構造化する方法を考える際に多大な労力を省きました。
Gang of Fourと同様に、Gregor HohpeとBobby Woolfは、Enterprise Integration Patterns(EIP)を著し、コンポーネントを配置できる大規模なコンポーネントベースのシステムを最適に設計するための一連の新しいパターンと青写真を提案および文書化しています。同じプロセスまたは別のマシンで実行されています。
彼らは基本的に、システムがメッセージ指向になるようにシステムを構築することを提案します -コンポーネントは、メッセージを入力および出力として使用し、他のものは絶対に何も使用せずに互いに通信します。これらは、システム全体を形成するさまざまなコンポーネントから選択して実装できるパターンの完全なセットを示しています。
では、Apache Camelとは何ですか?
Apache Camelは、EIP、基本オブジェクト、一般的に必要な実装、デバッグツール、構成システム、およびその他の多くのヘルパーのためのインターフェースを提供します。これにより、EIPに従うためのソリューションを実装したい場合に時間を大幅に節約できます。
MVCを取る。MVCは理論的には非常に単純であり、フレームワークの助けがなくても実装できます。しかし、優れたMVCフレームワークは、すぐに使用できる構造を提供し、大規模なMVCプロジェクトを作成するときに必要な他のすべての「副次的な」ことを考え抜いたため、ほとんどの場合それらを使用しています。
これがまさに、AIPキャメルがEIPに使用するものです。これは、EIPに従うためのソリューションを実装したい人向けの完全な本番環境対応フレームワークです。
プロジェクトの説明の作成は複雑であってはなりません。
私は言う:
Apache Camelは、ルーティングと接着するメッセージングテクノロジーです。メッセージングの開始点と終了点を結合して、異なるソースから異なる宛先へのメッセージの転送を可能にします。例:JMS-> JSON、HTTP-> JMSまたはファネリングFTP-> JMS、HTTP-> JMS、JSON-> JMS
ウィキペディアは言う:
Apache Camelは、ルールベースのルーティングおよびメディエーションエンジンであり、ルーティングおよびメディエーションルールを構成するために、API(または宣言的なJavaドメイン固有言語)を使用して、エンタープライズ統合パターンのJavaオブジェクトベースの実装を提供します。ドメイン固有の言語とは、Apache Camelが、大量のXML構成ファイルなしで、通常のJavaコードを使用してIDEでルーティングルールのタイプセーフなスマートコンプリーションをサポートできることを意味します。ただし、Spring内のXML構成もサポートされています。
見る?それは難しくなかったのですか?
要するに:
システムを接続/統合する必要がある場合、おそらくいくつかのデータソースに接続してから、このデータを処理してビジネス要件に合わせる必要があります。
それを行うには:
1)あなたはそれを行うカスタムプログラムを開発することができます(時間がかかり、理解するのが難しいかもしれません、他の開発者のために維持する)
2)あるいは、Apache Camelを使用して標準化された方法でそれを行うこともできます(ほとんどのコネクタがすでに開発されているので、セットアップしてロジックを接続するだけです-プロセスと呼ばれます)。
ラクダはあなたを助けるでしょう:
Apache Camelを使用することで、システムを簡単に理解/維持/他の開発者に拡張することができます。
Apache Camelはエンタープライズ統合パターンで開発されています。パターンは、システムを良い方法で統合するのに役立ちます:-)
キャメルはAからBにメッセージを送信します。
なぜこれのための全体のフレームワークですか?さて、あなたが持っている場合はどうなります:
ftp
、http
、jms
、等)だから今あなたは必要です:
キャメルは、上記の(そしてそれ以上の)を箱から出してくれます:
あなたが何をどのように定義するためのクールなDSL言語で:
new DefaultCamelContext().addRoutes(new RouteBuilder() {
public void configure() {
from("jms:incomingMessages")
.choice() // start router rules
.when(header("CamelFileName")
.endsWith(".xml"))
.to("jms:xmlMessages")
.when(header("CamelFileName")
.endsWith(".csv"))
.to("ftp:csvMessages");
}
図は何千もの説明よりも優れています。この図は、キャメルのアーキテクチャを示しています。
アナログに基づく
キャメルベースのルーティングは、航空会社のオーナーの立場に立つことで、非常に簡単に理解できます(例:アメリカン航空、ジェット航空)。
「あなたの航空会社」の目的は、世界のある「都市」から別の都市へ「乗客」を「運ぶ」ことです。乗客の輸送には、ボーイング、エアバス、HALなどのさまざまな「航空機会社」の航空機を使用します。
あなたの航空会社は、出発都市の「空港」を使用して乗客に搭乗し、到着都市の空港を使用して乗車します。乗客は複数の都市に「旅行」することができますが、どこでも、航空会社の航空機と都市の間を移動するために空港を通過する必要があります。
都市から「出発」する乗客は、基本的に航空会社の航空機に「到着」することに注意してください。そして、市内に「到着」する乗客は、基本的に航空機から出発します。私たちは航空会社のオーナーの立場にいるので、「到着客」と「出発客」という用語は、都市の視点に基づく従来の概念とは逆になっています。
各都市の同じ「空港」インフラストラクチャは、「出発」の乗客と「到着」の乗客が使用しています。空港は、出発する乗客に提供される「到着インフラ」とは異なり、出発する乗客に「出発インフラ」を提供します。
旅客は、旅行中に航空機内で航空機内に提供されるさまざまな「アメニティ」により、1日の活動を続けることができます。
その上、航空会社は「地元の言語を理解する」や「旅行」の準備などの特別な治療のためのラウンジ施設も提供しています。
上記で使用したいくつかの単語/フレーズを次のように置き換えます。
あなたの航空会社:Apache Camel
航空機会社:輸送メカニズム
航空会社の航空機:Apache Camelの基礎となる輸送メカニズム
キャリー:ルート
乗客:メッセージ;
都市:システム。
空港:キャメルコンポーネント;
ローカル言語の理解:型変換;
出発:生産、生産
到着:消費、消費
旅行:ルーティング
アメニティ:提供
単語を置き換えた後、次のものが得られます。
「Apache Camel」の目的は、「メッセージ」を1つの「システム」から別のシステムにルーティングすることです。Apacheキャメルは、メッセージルーティングにさまざまなトランスポートメカニズムを使用します。
Apache Camelは、「from」システムの「Camelベースのコンポーネント」を使用してメッセージを取得し、「to」システムの「Camelベースのコンポーネント」を使用してメッセージをドロップします。メッセージは複数のシステムにルーティングされる可能性がありますが、「Apache Camelの基になるトランスポートメカニズム」とシステムの間を移動するには、「Camelベースのコンポーネント」を経由する必要があります。
システムから「生成された」メッセージは、本質的にはApache Camelの基になるトランスポートメカニズムに「消費」されたことに注意してください。そして、システムによって消費されるメッセージは、本質的に「Apache Camelの基になるトランスポートメカニズム」によって生成されます。
キャメルを理解しようとしているので、ここからはキャメルの視点から考える必要があります。したがって、「消費者メッセージ」と「生産者メッセージ」という用語の意味は、システムの視点に基づく従来の概念とは逆になっています。
同じ「キャメルベースのコンポーネント」のコーディングインフラストラクチャは、「プロデューサーメッセージ」と「コンシューマーメッセージ」で使用されます。「キャメルベースのコンポーネント」は、「プロデューサーメッセージ」の「プロデューサーエンドポイント」と「コンシューマーメッセージ」の「コンシューマーエンドポイント」を提供します。
メッセージはルーティング中にCamelで処理できます。
このルーティングに加えて、キャメルは「タイプ変換」などの特別な機能を提供します...
Apache Camelを理解する前に理解する必要があることの1つは、エンタープライズ統合パターンです。現場の誰もが実際にそれらを認識しているわけではありません。Enterprise Integration Patternsの本は確かに読めますが、それらに慣れるためのより早い方法は、エンタープライズアプリケーション統合に関するWikipediaの記事のようなものを読むことです。
サブジェクト領域を読んで理解した方は、Apache Camelの目的を理解する可能性がはるかに高くなります。
HTH
別の観点からの定義:
Apache Camelは統合フレームワークです。これは、Javaプラットフォームでの統合問題の実装に役立ついくつかのJavaライブラリで構成されています。これが何を意味し、それが片側のAPIと反対側のエンタープライズサービスバス(ESB)とどのように異なるかは、私の記事「いつApache Camelを使用するか」で説明されています。
正確には何ですか?
Apache Camelは、すべてのエンタープライズ統合パターンを実装する軽量統合フレームワークです。必要なパターンを使用して、さまざまなアプリケーションを簡単に統合できます。
Java、Spring XML、Scala、またはGroovyを使用できます。HTTP、FTP、JMS、EJB、JPA、RMI、JMS、JMX、LDAP、Nettyなど、想像できるほぼすべてのテクノロジーを利用できます。
Javaで記述されたアプリケーションとどのように相互作用しますか?
Camelは、Javaドメイン固有言語またはDSLを使用して、以下に示すように、さまざまなドメイン固有言語(DSL)でエンタープライズ統合パターンまたはルートを作成します。
Java DSL-流暢なビルダースタイルを使用したJavaベースのDSL。
エンタープライズ統合パターンのストーリーは、これらの概念を中心に解決します。
メッセージ、エンドポイント、プロデューサー、コンシューマー、ルーティング、バス、変換、プロセス。
リアルタイムの使用例の1つとして、Anirban Konarによるこの記事をご覧ください。
サーバーと一緒に行くものですか?
複数のエンタープライズサブシステム間のブリッジとして機能します。
独立したプログラムですか?
統合フレームワークであるApache Camelは、さまざまな独立したアプリケーションを統合します。
Camelの主な利点:すべての統合で同じ概念を使用することにより、さまざまなアプリケーションをさまざまなテクノロジー(およびさまざまなプロトコル)と統合できます。
コンピューティングにおけるほとんどの「新しい」ものはまったく新しいものではなく、すでに十分に理解されているものに対する単なる不可解なラッパーです。とき、彼らは、それを理解するのは難しい誰かが別の目的のために新しい言語の用語や植民地化し、既存の用語を発明することを決定したので、通常だ(良い例だことは何『クライアント』と『サーバー』の平均のX開発者の反転です。)
Camelは、アプリケーション間ミドルウェア用のJavaベースのラッパー/ APIです。
ミドルウェアは、共通の言語またはデータ型を共有しないエンティティ間で解釈サービスを提供するソフトウェアの一般的な用語です。
それがキャメルです。EIPタイプのミドルウェアに対応していることに注意して、説明を具体化できます。
アプリケーションが通信する必要のあるものの詳細を知ることができないため、ミドルウェア自体は提供されません。ただし、そのミドルウェアの不変部分を作成するためのAPIを提供します(開始点の作成、終了点の作成、開始と終了の条件の作成など)。
お役に立てば幸いです。
ここで別の試みがあります。
Webmethods、ICAN Seebeyond、Tibco BW、IBM Brokerなどがどのように存在していたかを知っています。彼らはすべて、企業の統合ソリューションを支援しました。これらのツールは、一般にエンタープライズアプリケーション統合(EAI)ツールの名前で知られています。
これらのテクノロジーを中心に構築されたドラッグドロップツールがほとんどあり、一部はJavaでアダプターを作成する必要があります。これらのアダプタコードはテストされていないか、テストに関連するツール/自動化が不十分でした。
プログラミングの設計パターンと同様に、一般的な統合ソリューション用のエンタープライズ統合パターンがあります。彼らは、Gregor HohpeとBobby Woolfの同名の本で有名になりました。
1つまたは複数のEIPを使用する統合ソリューションを実装することは十分に可能ですが、Camelは、XML、Java、Groovy、Scalaのいずれかを使用してコードベース内でこれを行う試みです。
Camelは、豊富なDSLおよびルーティングメカニズムを介して、本に記載されているすべてのエンタープライズ統合パターンをサポートしています。
したがって、Camelは他のEAIツールと競合するテクノロジーであり、統合コードのテストをよりよくサポートしています。ドメイン固有言語(DSL)のため、コードは簡潔です。ビジネスユーザーでも読みやすく、無料で生産性を高めます。
メッセージングおよびメッセージングにおける問題の解決を容易にするフレームワークがたくさんあります。そのような製品の1つがApache Camelです。
一般的な問題のほとんどは、設計パターンと呼ばれるソリューションが証明されています。メッセージングの設計パターンは、ここで詳しく説明されているエンタープライズ統合パターン(EIP)です。Apache camelは、EIPを使用してソリューションを実装するのに役立ちます。
統合フレームワークの強みは、EIPまたはその他のパターン、トランスポートとコンポーネントの数、およびApacheラクダがリストのトップに立つ開発の容易さを通じて私たちを促進する能力です。
各フレームワークには独自の利点があります。Apacheキャメルの特別な機能には、次のようなものがあります。
わかりやすい英語では、ラクダはボイラープレートコードをほとんど使わずに(多くの)作業を行います。
見通しを与えるために、以下のJava DSLはRESTエンドポイントを作成します。RESTエンドポイントは、製品リストで構成されるXMLを受け入れ、それを複数の製品に分割し、それを使用してBrandProcessorのProcessメソッドを呼び出すことができます。.parallelProcessing(コメントアウトされている部分に注意)を追加するだけで、すべての製品オブジェクトが並列処理されます。(製品クラスは、入力xmlが制限されているXSDからJAXB / XJCで生成されたJavaスタブです。)これだけのコード(およびCamelの依存関係がほとんどない)は、何百行ものJavaコードを使用するジョブを実行します。
from("servlet:item-delta?matchOnUriPrefix=true&httpMethodRestrict=POST")
.split(stax(Product.class))
/*.parallelProcessing()*/
.process(itemDeltaProcessor);
ルートIDとログステートメントを追加した後
from("servlet:item-delta?matchOnUriPrefix=true&httpMethodRestrict=POST")
.routeId("Item-DeltaRESTRoute")
.log(LoggingLevel.INFO, "Item Delta received on Item-DeltaRESTRoute")
.split(stax(Product.class))
.parallelProcessing()
.process(itemDeltaProcessor);
これは単なるサンプルであり、Camelは単なるRESTエンドポイントではありません。プラグイン可能なコンポーネントのリストhttp://camel.apache.org/components.htmlを見てください。
Camelは、アプリケーションを統合するための一貫したAPIおよびプログラミングモデルを備えたフレームワークです。APIは、エンタープライズ統合パターンの理論に基づいています。つまり、メッセージングを使用する傾向がある設計パターンの束です。これらのパターンのほとんどをすぐに実装でき、さらに200を超えるさまざまなコンポーネントが同梱されているため、他のあらゆる種類のシステムと簡単に通信できます。Camelを使用するには、最初にPOJOでビジネスロジックを記述し、メッセージを中心としたシンプルなインターフェースを実装します。次に、CamelのDSLを使用して、アプリケーションを接着するための一連のルールである「ルート」を作成します。
表面的には、Camelの機能は従来のEnterprise Service Bus製品に匹敵します。キャメルルートは通常、サーバー側に存在する「メディエーション」(別名オーケストレーション)コンポーネントであると考えられますが、これはJavaライブラリであるため、簡単に埋め込むことができ、クライアント側のアプリにも存在して統合を支援できます。ポイントツーポイントサービス(振付とも呼ばれます)。キャメルルート内のメッセージを処理するPOJOを取得して、独自のリモートコンシューマープロセスに簡単にスピンオフすることもできます。たとえば、1つのピースだけを個別にスケーリングする必要がある場合などです。Camelを使用して、必要に応じて、任意の数の異なるリモートトランスポート/プロトコルを介してルートまたはプロセッサを接続できます。非常に効率的で高速なバイナリプロトコルが必要ですか、またはより人間が読みやすく、デバッグしやすいものですか?切り替える場合はどうなりますか?Camelを使用すると、これは通常、ルートの1行または2行を変更するのと同じくらい簡単で、ビジネスロジックをまったく変更しません。または、両方をサポートすることもできます。キャメルコンテキストで一度に多くのルートを自由に実行できます。
単一のプロセスまたはJVMで実行する単純なアプリケーションでは、Camelを実際に使用する必要はありません-やり過ぎです。しかし、概念的には、自分で記述したコードよりも難しくありません。また、要件が変化した場合でも、ビジネスロジックとグルーコードを分離することで、長期にわたる保守が容易になります。Camel APIを習得すれば、スイスアーミーナイフのように簡単に使用でき、さまざまな状況ですばやく適用して、他の方法で作成する必要があるカスタムコードの量を削減できます。1つのフレーバー(たとえば、Java DSL、例えば、簡単にチェーン接続できる流暢なAPI)を学び、他のフレーバーを簡単に取得できます。
マイクロサービスを行う場合は、全体的にキャメルが最適です。問題ドメインの詳細を知るまで、プロトコル、トランスポート、およびその他のシステム統合の問題に関する多くの難しい、「簡単に間違える」決定を先送りできるので、私はそれが進化的アーキテクチャにとって非常に貴重であるとわかりました。EIPとコアビジネスロジックに焦点を合わせ、詳細を確認しながら「適切な」コンポーネントを使用して新しいルートに切り替えるだけです。
はい、これはおそらく少し遅れています。しかし、他の皆のコメントに付け加えておくべきことの1つは、Camelは実際には機能の完全なセットではなくツールボックスであるということです。開発時にさまざまな変換やプロトコル変換を行う必要がある場合は、このことを覚えておく必要があります。
Camel自体は他のフレームワークに依存しているため、ニーズに最も適したものを理解するために、それらも理解する必要がある場合があります。たとえば、RESTを処理する方法は複数あります。これは最初は少し混乱する可能性がありますが、使用およびテストを開始すると、安心できるようになり、さまざまな概念についての知識が増えます。
Apache Camelは、エンタープライズ統合のためのJavaフレームワークです。例:-多くのベンダーAPIと相互作用するWebアプリケーションを構築している場合、外部統合ツールとしてラクダを使用できます。ユースケースに基づいて、さらに多くのことができます。マニングの出版物からのキャメル・イン・アクションは、キャメルを学ぶのに最適な本です。統合は以下のように定義できます。
Java DSL
from("jetty://0.0.0.0:8080/searchProduct").routeId("searchProduct.products").threads()
.log(LoggingLevel.INFO, "searchProducts request Received with body: ${body}")
.bean(Processor.class, "createSearchProductsRequest").removeHeaders("CamelHttp*")
.setHeader(Exchange.HTTP_METHOD, constant(org.apache.camel.component.http4.HttpMethods.POST))
.to("http4://" + preLiveBaseAPI + searchProductsUrl + "?apiKey=" + ApiKey
+ "&bridgeEndpoint=true")
.bean(Processor.class, "buildResponse").log(LoggingLevel.INFO, "Search products finished");
これは、REST APIエンドポイントを作成するだけです。RESTAPIエンドポイントは、外部APIを呼び出し、リクエストを送り返します。
Spring DSL
<route id="GROUPS-SHOW">
<from uri="jetty://0.0.0.0:8080/showGroups" />
<log loggingLevel="INFO" message="Reqeust receviced service to fetch groups -> ${body}" />
<to uri="direct:auditLog" />
<process ref="TestProcessor" />
</route>
あなたの質問に来る
それが役に立てば幸い
Apache Camelは、すべてのエンタープライズ統合パターンを実装する軽量の統合フレームワークです。必要なパターンを使用して、さまざまなアプリケーションを簡単に統合できます。Java、Spring XML、Scala、またはGroovyを使用できます。
Apache Camelは、Java仮想マシン(JVM)で実行されます。... Apache Camelのコア機能は、そのルーティングエンジンです。関連するルートに基づいてメッセージを割り当てます。ルートには、フローと統合ロジックが含まれています。EIPと特定のDSLを使用して実装されます。
接続するパイプラインのようなもの
From---->To
uの間に、チャネルとパイプをいくつでも追加できます。蛇口は、データのフローとフローをチャネル化するルートの自動または手動の任意のタイプにすることができます。
すべてのタイプと種類の処理をサポートし、実装しています。また、同じ処理の場合、多くのコンポーネントがあり、各コンポーネントはその下でさまざまなメソッドを使用して目的の出力を提供できるため、多くのアプローチを使用できます。
たとえば、ファイル転送はキャメルでファイルを移動またはコピーしたタイプで実行でき、フォルダ、サーバー、またはキューからも実行できます。
-from-->To
- from-->process-->to
- from-->bean-->to
- from-->process-->bean-->to
-from-->marshal-->process-->unmarshal-->to
from / to ---- folder、direct、seda、vmは何でもかまいません
別の視点(より基本的な数学的トピックに基づく)
最も一般的なコンピューティングプラットフォームは[ https://en.wikipedia.org/wiki/Turing_machine]です。
チューリングマシンに問題があります。すべての入力/出力データは、チューリングマシン内にとどまります。現実の世界では、チューリングマシンの外部に入力ソースと出力シンクがあり、一般的には制御外のシステムによって管理されています。つまり、これらの外部システムは、希望するデータスケジューラを使用して、任意の形式で自由にデータを送受信します。
質問:各チューリングマシンがピアを入力データのソースまたは出力データのシンクのいずれかとして認識するように、独立したチューリングマシンが最も一般的な方法で互いに対話できるようにする方法を教えてください。
回答:キャメル、ラバ、BizTalk、または他のESBなど、別個の「物理」(または仮想ソフトウェア)チューリングマシンを完了する間のデータ処理を抽象化するものを使用します。