Apache Camel とは一体何ですか?

https://stackoverflow.com/questions/8845186

27-10-2019
|

質問

正確には何なのか分かりませんキャメルそうです。

Camel について 101 語で説明できるとしたら:

正確には何ですか?
Java で書かれたアプリケーションとどのように対話するのでしょうか?
サーバーと連動するものなのでしょうか？
独立したプログラムですか？

キャメルとは何か説明してください。

解決

5〜10分がある場合は、一般的にこれを読むことをお勧めします Apache Camelとの統合 Jonathan Ansteyによる。これはよく書かれた作品で、Camelの概念のいくつかの簡単な紹介と概要を示し、コードサンプルでユースケースを実装しています。その中で、ジョナサンは次のように書いています。

Apache Camelは、開発者が統合を容易にし、アクセスしやすくすることに焦点を当てたオープンソースのJavaフレームワークです。これを提供することでこれを行います。

広く使用されているすべての具体的な実装エンタープライズ統合パターン（EIPS）

多種多様なトランスポートとAPIへの接続

使いやすいドメイン固有言語（DSL）を使用してEIPと輸送を配線します

の無料章もあります動作中のラクダ最初の章でラクダを紹介します。ジョナサンは私と一緒にその本の共著者です。

他のヒント

これをよりアクセスしやすい方法で説明する私の考え...

Apache Camelとは何かを理解するには、エンタープライズ統合パターンが何であるかを理解する必要があります。

おそらくすでに知っていることから始めましょう。シングルトンパターン、工場パターンなど。それらは単に問題に対する解決策を整理する方法ですが、それ自体が解決策ではありません。これらのパターンは、彼らが本を出版したときに、4人のギャングによって私たちの残りのために分析され、抽出されました。デザインパターン. 。彼らは、私たちのコードを最適に構成する方法を考えるために私たちの何人かを救いました。

4人のギャングと同じように、グレゴール・ホーペとボビー・ウルフは本を執筆しましたエンタープライズ統合パターン（EIP）彼らが一連の新しいパターンを提案し、文書化する 青写真 どのようにできるか一番コンポーネントが同じプロセスまたは別のマシンで実行できる大規模なコンポーネントベースのシステムを設計します。

彼らは基本的に私たちが私たちのシステムを構築することを提案します メッセージ 方向 - 入力と出力としてメッセージを使用してコンポーネントが互いに通信する場合、まったく何もありません。それらは、システム全体を形成するさまざまなコンポーネントから選択して実装できるパターンの完全なセットを示しています。

では、アパッチラクダとは何ですか？

Apache Camelは、EIPのインターフェイス、ベースオブジェクト、一般的に必要な実装、デバッグツール、構成システム、およびEIPをフォローするためのソリューションを実装するときに大量の時間を節約する他の多くのヘルパーのインターフェイスを提供します。

MVCを取ります。 MVCは理論的には非常に単純であり、フレームワークの助けなしでそれを実装できます。しかし、優れたMVCフレームワークは、すぐに使いやすい構造を提供し、大規模なMVCプロジェクトを作成するときに必要な他のすべての「サイド」のものをさらに努力して、ほとんどの場合使用します。

それはまさにApache Camelが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 を使用して、標準化された方法でこれを実行することもできます (ほとんどのコネクタがすでに開発されており、セットアップしてロジックを接続するだけです (プロセスと呼ばれます)。)

Camel は次のことをサポートします。

あらゆるソース/形式からのデータを使用
このデータを処理する
データを任意のソース/フォーマットに出力

Apache Camel を使用すると、システムの理解、保守、他の開発者への拡張が容易になります。

Apache Camel は、エンタープライズ統合パターンを使用して開発されています。パターンは、システムを適切な方法で統合するのに役立ちます :-)

CamelはAからBにメッセージを送信します。

なぜこれのための全体のフレームワークがあるのですか？さて、あなたが持っている場合はどうなりますか：

多くの送信者と多くのレシーバー
数十のプロトコル（ftp, http, jms, 、など）
多くの複雑なルール
- 受信機AとBのみにメッセージAを送信する
- メッセージBを受信機に送信しますc XMLとして, 、しかし部分的に翻訳それ、 豊かにします それ（メタデータを追加）と 条件xの場合, 、その後、レシーバーDにも送信しますが CSVとして.

だから今あなたは必要です：

翻訳プロトコル間
のり一緒にコンポーネント
ルートを定義する - どこに行くのか
フィルター 場合によってはいくつかのことがあります

ラクダはあなたに上記の（そしてもっと）箱から出してくれます：

クールな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");
}

参照してくださいこれとこれそして、キャメルの行動（他の人が言ったように、素晴らしい本！）

図は数千の説明よりも優れています。この図は、ラクダのアーキテクチャを示しています。

enter image description here

類推に基づいています

ラクダベースのルーティングは、航空会社の所有者の靴に身を置くことで、非常に簡単に理解できます（例：アメリカン航空、ジェットエアウェイズ）。

「あなたの航空会社」の目的は、「乗客」を「乗客」から世界の別の都市に「運ぶ」ことです。乗客を運ぶために、ボーイング、エアバス、HALなど、さまざまな「航空機会社」の航空機を使用します。

航空会社のボードの乗客は、都市から「空港」を使用し、都市の空港を使用して装飾します。乗客は複数の都市に「旅行」することができますが、どこでも空港を通り、航空会社の航空機と都市の間を移動する必要があります。

市から「出発する」乗客は、本質的に航空会社の航空機に「到着」していることに注意してください。そして、都市に「到着する」パッセガーは、本質的に航空機から出発しています。私たちは航空会社の所有者の靴にいるので、「到着乗客」と「出発する乗客」という用語は、都市の観点に基づいた従来の概念から逆転しています。

各都市の同じ「空港」インフラストラクチャは、「出発」の乗客と「到着」の乗客によって使用されます。空港は、乗客を出発するための「出発インフラストラクチャ」を提供します。これは、乗客が到着するために提供される「到着インフラストラクチャ」とは異なります。

乗客は、旅行中に航空会社が航空機内で提供するさまざまな「アメニティ」のために、自分の活動に一日をやり続けることができます。

それに加えて、あなたの航空会社は、「地元の言語を理解する」、または「旅行」の準備をするなど、特別な治療のためのラウンジ施設も提供しています。

上記のいくつかの単語/フレーズを次のものに置き換えましょう。

あなたの航空会社：アパッチ・ラクダ

航空機企業：輸送メカニズム

あなたの航空会社の航空機：ApacheCamelの基礎となる輸送機構

キャリー：ルート

乗客：メッセージ;

市：システム;

空港：ラクダコンポーネント。

ローカル言語の理解：タイプ変換。

出発：生産、生産

到着：消費、消費

旅行：ルーティング

アメニティ：提供

単語を置き換えた後、ここにあなたが得るものがあります：

「アパッチラクダ」の目的 「メッセージ」を1つの「システム」から世界の別のシステムにルーティングすることです。 Apache Camelは、メッセージルーティングにさまざまな輸送メカニズムを使用しています。

Apache Camelは、「From」システムの「キャメルベースのコンポーネント」を使用してメッセージを受け取り、「ラクダベースのコンポーネント」から「システム」を使用してドロップします。メッセージは複数のシステムにルーティングする場合がありますが、どこでも「ラクダベースのコンポーネント」を通過して、「Apache Camelの基礎となる輸送メカニズム」とシステムの間を移動する必要があります。

システムから「作成された」メッセージは、基本的に「消費」されていることに注意してください。システムによって消費されるメッセージは、本質的に「Apache Camelの基礎となる輸送メカニズム」によって生成されます。

私たちはラクダを理解しようとしているので、ここのラクダの視点から考えなければなりません。したがって、「消費者メッセージ」と「プロデューサーメッセージ」という用語の意味は、システムの視点に基づいた従来の概念から逆転します。

同じ「キャメルベースのコンポーネント」のコーディングインフラストラクチャは、「プロデューサーメッセージ」と「コンシューマーメッセージ」によって使用されます。「キャメルベースのコンポーネント」は、「プロデューサーメッセージ」の「プロデューサーエンドポイント」と「消費者メッセージ」の「消費者エンドポイント」を提供します。

メッセージは、ルーティングされているときにラクダによって処理できます。

このルーティングに加えて、キャメルは「タイプ変換」などの特別な機能を提供します...

Apache Camelを理解しようとする前に、理解する必要があることの1つは、エンタープライズ統合パターンです。現場の誰もが実際にそれらを認識しているわけではありません。 Enterprise Integration Patterns Bookを確実に読むことはできますが、それらを高速化するためのより迅速な方法は、Wikipediaの記事のようなものを読むことです。エンタープライズアプリケーション統合.

主題領域を読んで理解したものの1つは、Apache Camelの目的を理解する可能性がはるかに高いでしょう。

Hth

エンタープライズ統合パターンを知っている場合、Apache CamelはすべてのEIPを実装する統合フレームワークの1つです。

また、WebコンテナーにスタンドアロンアプリケーションとしてCamelを展開できます。

基本的に、いくつかのアプリケーションを異なるプロトコルとテクノロジーと統合する必要がある場合は、Camelを使用できます。

別の観点からの定義：

Apache Camelは統合フレームワークです。これは、Javaプラットフォームに統合問題を実装するのに役立つJavaライブラリで構成されています。これが何を意味し、それが一方の側のAPIとどのように異なるか、反対側のエンタープライズサービスバス（ESB）が私の記事で説明されています。Apacheキャメルを使用するタイミング".

それは正確に何ですか？

アパッチラクダ すべてのエンタープライズ統合パターンを実装する軽量統合フレームワークです。必要なパターンを使用して、さまざまなアプリケーションを簡単に統合できます。

Java、Spring XML、Scala、またはGroovyを使用できます。想像できるほぼすべてのテクノロジー、たとえばHTTP、FTP、JMS、EJB、JPA、RMI、JMS、JMX、LDAP、Nettyなど。

これを見てください論文と EIPパターンの記事

Javaで書かれたアプリケーションとどのように相互作用しますか？

ラクダはaを使用します Javaドメイン固有言語またはDSL 以下にリストされているように、さまざまなドメイン固有の言語（DSL）でエンタープライズ統合パターンまたはルートを作成するため。

Java DSL -Fluent Builderスタイルを使用したJavaベースのDSL。

エンタープライズ統合パターンのストーリーは、これらの概念を中心に解決します。

メッセージ、エンドポイント、プロデューサー、消費者、ルーティング、バス、変革、プロセス.

これを見てください論文リアルタイムユースケースの1つについては、Anirban Konarによる。

それはサーバーと一緒になるものですか？

複数のエンタープライズサブシステムを越えた橋として機能します。

それは独立したプログラムですか？

統合フレームワークであるApache Camelは、さまざまな独立したアプリケーションを統合します。

ラクダの主な利点 ：統合ごとに同じ概念を使用することにより、異なるテクノロジー（および異なるプロトコル）と異なるアプリケーションを統合できます。

コンピューティングの「新しい」もののほとんどは、まったく新しいものではありません。彼らは、すでによく理解されているものについての単なる神秘的なラッパーです。彼らが理解しにくいとき、それは通常、誰かが新しい言語用語を発明するか、異なる目的のために既存の用語を植民地化することを決めたからです（の良い例それ X開発者の「クライアント」と「サーバー」の意味の逆転です。）

Camelは、アプリケーション間のミドルウェア用のJavaベースのラッパー/APIです。

ミドルウェアは、共通言語やデータ型を共有しないエンティティ間で解釈サービスを提供するソフトウェアの一般的な用語です。

それがラクダの底です。 EIPタイプのミドルウェアを提供していることに注意することで、説明を具体化できます。

アプリケーションが通信する必要があるものの詳細がわからないため、ミドルウェア自体を提供しません。ただし、そのミドルウェアの不変部分を作成するためのAPIを提供します（開始点を作成し、エンドポイントを作成し、開始と終了の条件を作成するなど）

それが役立つことを願っています。

これが別の試みです。

WebMethods、Ican Seebeyond、Tibco BW、IBM Brokerのようなものがあることを知っています。彼らは皆、企業の統合ソリューションを支援しました。これらのツールは、一般的にEnterprise Application Integration（EAI）ツールという名前で知られています。

これらのテクノロジーの周りに構築されたドラッグドロップツールがほとんどあり、一部ではJavaにアダプターを作成する必要があります。これらのアダプターコードは、テスト中にテストされていないか、ツール/自動化が不十分でした。

プログラミングの設計パターンと同様に、共通統合ソリューションのエンタープライズ統合パターンがあります。彼らは、グレゴール・ホーペとボビー・ウルフによって同じ名前の本によって有名になりました。

1つまたは多くのEIPを使用する統合ソリューションを実装することは非常に可能ですが、CamelはXML、Java、Groovy、またはScalaのいずれかを使用してコードベース内でこれを実行する試みです。

Camelは、豊富なDSLおよびルーティングメカニズムを介して、本にリストされているすべてのエンタープライズ統合パターンをサポートしています。

したがって、Camelは、統合コードのテストをよりよくサポートする他のEAIツールに競合するテクノロイです。ドメイン固有の言語（DSLS）のため、コードは簡潔です。ビジネスユーザーによっても読みやすく、無料で生産的になります。

メッセージングやメッセージングの問題解決を容易にするフレームワークがたくさんあります。そのような製品の 1 つが Apache Camel です。

一般的な問題のほとんどには、デザインパターンと呼ばれる実証済みの解決策があります。メッセージングの設計パターンは、よく説明されているエンタープライズ統合パターン (EIP) です。ここ. 。Apache Camel は、EIP を使用したソリューションの実装に役立ちます。

統合フレームワークの強みは、EIP やその他のパターン、トランスポートとコンポーネントの数、そして Apache Camel がリストのトップに立つ開発の容易さを通じて私たちを容易にする能力です。

各フレームワークには独自の利点があります。 Apache Camel の特別な機能のいくつかは次のとおりです。

これは、多くの DSL、つまり人気のある Java DSL および Spring xml ベースの DSL に含まれるコーディングを提供します。
使いやすく、使い方も簡単です。
Fuse IDE は、UI を介したコーディングを支援する製品です

平易な英語では、キャメルはボイラープレートコードの多くなしで（多くの）ことをします。

視点を与えるために、以下に示すJava DSLは、製品のリストで構成されるXMLを受け入れ、複数の製品に分割し、それを使用してブランドプロセッサのプロセス方法を呼び出すことができるRESTエンドポイントを作成します。また、.ParlallelProcessingを追加するだけで（コメントされた部分に注意してください）、すべての製品オブジェクトを並列処理します。（製品クラスはXSDからJaxB/XJC生成されたJavaスタブであり、XMLに限定されています。）この多くのコード（ラクダの依存関係はほとんどありません）は、Javaコードの100行を摂取するために使用されるジョブを完了します。

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);

これは単なるサンプルであり、ラクダはただの休憩所以上のものです。プラグ可能なコンポーネントリストをご覧ください http://camel.apache.org/components.html

ラクダは、ルーティング、変換、監視に役立ちます。

ルートを使用します。これは次のとおりです。

サービスバスが特定のメッセージを受信すると、キュー/トピックなどのサービス/ブローカーの目的地がありません。このパスはルートとして知られています。

例：株式アプリケーションはアナリストからある程度の入力を受けており、アプリケーション/Webコンポーネントを介して処理され、結果が特定の株式更新のためにすべての関心/登録メンバーに公開されます。

101ワードイントロ

Camelは、アプリケーションを一緒に統合するための一貫したAPIおよびプログラミングモデルを備えたフレームワークです。 APIはの理論に基づいていますエンタープライズ統合パターン - つまり、メッセージングを使用する傾向があるデザインパターンの束。これらのパターンのほとんどのボックスからの実装を提供し、さらに200を超える異なるものがありますコンポーネント他のあらゆる種類のシステムと簡単に話し合うために使用できます。キャメルを使用するには、まずPOJOでビジネスロジックを書き、メッセージを中心とした単純なインターフェイスを実装します。次に、CamelのDSLを使用して、アプリケーションを接着するためのルールのセットである「ルート」を作成します。

拡張イントロ

表面的には、Camelの機能性は従来のエンタープライズサービスバス製品に匹敵します。通常、ラクダのルートはサーバー側に住んでいる「調停」（別名オーケストレーション）コンポーネントであると考えていますが、Javaライブラリであるため、埋め込みが簡単で、クライアント側のアプリに住んでいて、統合するのに役立ちます。 Point to Point Services（別名振り付け）を使用しています。キャメルルート内のメッセージを処理するPOJOを使用して、たとえば独立して1つのピースのみをスケーリングする必要がある場合に、それらを独自のリモートコンシューマプロセスに簡単にスピンオフすることもできます。キャメルを使用して、ニーズに応じて、さまざまなリモートトランスポート/プロトコルを介してルートまたはプロセッサを接続できます。非常に効率的で高速なバイナリプロトコル、またはより人間の読みやすく、デバッグしやすいプロトコルが必要ですか？切り替えたい場合はどうなりますか？ラクダでは、これは通常、ルートで1つか2つのラインを変更し、ビジネスロジックをまったく変更しないのと同じくらい簡単です。または、両方をサポートすることもできます - ラクダの文脈で一度に多くのルートを自由に実行できます。

単一のプロセスまたはJVMに住む簡単なアプリケーションにラクダを使用する必要はありません - それはやり過ぎです。しかし、それはあなたが自分自身を書くことができるコードよりも概念的に難しいことではありません。また、要件が変更された場合、ビジネスロジックと接着剤コードの分離により、時間の経過とともに維持が容易になります。キャメルAPIを学習すると、スイスのアラミナイフのように使用し、多くの異なるコンテキストで迅速に適用して、他の方法で書かなければならないカスタムコードの量を削減できます。 1つのフレーバー - Java DSL、たとえば、一緒に簡単にチェーンできる流fluent APIなど、他のフレーバーを簡単に拾うことができます。

全体的なラクダは、マイクロサービスを試みている場合にぴったりです。進化的アーキテクチャにとって非常に貴重なことを発見しました。なぜなら、問題のドメインについてもっと知るまで、プロトコル、トランスポート、その他のシステム統合の問題に関する多くの困難な「手頃な」決定を延期できるからです。 EIPとコアビジネスロジックに焦点を合わせて、詳細を確認するにつれて、「正しい」コンポーネントを使用して新しいルートに切り替えてください。

はい、これはおそらく少し遅れています。しかし、他のすべてのコメントに追加することの1つは、Camelが実際には完全な機能セットではなくツールボックスであるということです。開発する際にこれを念頭に置いておく必要があり、さまざまな変換とプロトコル変換を行う必要があります。

キャメル自体は他のフレームワークに依存しているため、どちらがあなたのニーズに最適かを理解するために、それらを理解する必要がある場合があります。たとえば、休息を処理する方法は複数あります。これは最初は少し混乱する可能性がありますが、使用してテストを開始すると、簡単に感じられ、さまざまな概念に関する知識が高まります。

Apache Camelは、エンタープライズ統合のJavaフレームワークです。例： - 多くのベンダーAPIと対話するWebアプリケーションを構築している場合、Camelを外部統合ツールとして使用できます。ユースケースに基づいて、さらに多くのことができます。 Manning Publicationsからのアクション中のキャメルは、キャメルを学ぶための素晴らしい本です。統合は以下のように定義できます。

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");

これは、外部APIを呼び出してリクエストを送り返すREST APIエンドポイントを作成するだけです

スプリング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>

あなたの質問に来る

それは正確に何ですか？ ANS： - エンタープライズ統合パターンを実装するフレームワークです
Javaで書かれたアプリケーションとどのように相互作用しますか？ ANS：-HTTP、FTP、AMQPなどの利用可能なプロトコルと対話できます
それはサーバーと一緒になるものですか？ ANS： - Tomcatのようなコンテナに展開するか、Javaプロセスとして独立して展開することができます
それは独立したプログラムですか？ Ans： - それが可能です。

それが役に立てば幸い

Amazonのようなeコマース会社を作成し、販売する製品の戦略/選択にのみ焦点を合わせることを望んでいると仮定します。 Amazon Delivery Fleetとは異なり、販売者から倉庫への商品の移動を処理し、パッケージングのような倉庫で他の都市や顧客に送信するのではなく、自分自身ではなく。これをすべて行う会社を雇い、すべての倉庫の場所、車両の種類、配達場所、いつ何をするかのリストを提供するだけです。それから彼らはそれを自分で扱います、それはアパッチ・ラクダです。あなたが他のことに自由に集中することができるように、彼らはあなたがそれらに引き渡すと、彼らに物を片方からもう一方の端に移動することに世話をします。

パイプラインの接続のようです

From---->To

間にUは、多くのチャネルとパイプを追加できます。蛇口は、データの流れのためのあらゆるタイプの自動またはマニュアルであり、流れをチャネル化するためのルートを使用できます。

すべてのタイプと種類の処理をサポートし、実装しています。また、同じ処理の場合、多くのコンポーネントがあり、各コンポーネントがその下にさまざまな方法を使用して目的の出力を提供できるためです。

たとえば、ファイル転送は、タイプのファイルを移動またはコピーしたタイプで、またフォルダー、サーバー、またはキューからのキャメルで実行できます。

-from-->To
   - from-->process-->to
   - from-->bean-->to
   - from-->process-->bean-->to
   -from-->marshal-->process-->unmarshal-->to

from/to ----フォルダー、ダイレクト、セダ、VMは何でもできます

別の視点（より基本的な数学的トピックに基づく）

最も一般的なコンピューティングプラットフォームは[https://en.wikipedia.org/wiki/turing_machine

チューリングマシンには問題があります。すべての入出力データは、チューリングマシン内にとどまります。現実の世界には、チューリングマシンの外部に入力ソースと出力シンクがあり、一般に制御以外のシステムによって支配されています。つまり、これらの外部システムは、任意の任意のデータスケジュールを使用して、あらゆる形式でデータを自由に送信/受信します。

質問：各チューリングマシンが仲間を出力データのソースまたはシンクのいずれかと見なすように、どのようにして最も一般的な方法で互いに話しかけることができますか？

回答：ラクダ、ラバ、ビズトーク、または異なる「物理的」（または仮想ソフトウェア）チューリングマシンの完成の間のデータ処理を抽象化する他のESBのようなものを使用します。

Apache Camelは、すべてのエンタープライズ統合パターンを実装する軽量統合フレームワークです。必要なパターンを使用して、さまざまなアプリケーションを簡単に統合できます。 Java、Spring XML、Scala、またはGroovyを使用できます。

Apache CamelはJava Virtual Machine（JVM）で実行されます。 ... Apache Camelのコア機能は、そのルーティングエンジンです。関連するルートに基づいてメッセージを割り当てます。ルートには、フローと統合ロジックが含まれています。 EIPと特定のDSLを使用して実装されています。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow