9

軽量のESBのように見えるApacheCamelに頭を包み込もうとしています。Camel / ESBを正しく理解していれば、CamelRouteはノードとエッジのグラフと考えることができます。各ノードはルート上のエンドポイントです（メッセージを消費/生成できます）。各エッジは、2つの異なるエンドポイント（1つのプロデューサーと1つのコンシューマー）間のルートです。

それが正しいと仮定すると、実際的な質問があります。アプリケーションのESB / Camelルートのデプロイについてベストプラクティスは何を指示しますか？それを独自のJARとしてパッケージ化する必要がありますか、それとも、EJB、Webサービス、およびその他のJARでいっぱいの独自のEARにする価値がありますか？

キャメルルートまたはESBをどのように展開/設計する必要があるかを尋ねていると思います。

my-esb.ear/
    ejb1.jar/
        MyEJB_1.class
    ejb2.jar/
        MyEJB_2.class
    webservice.war/
        MyWebService.class

または...

my-esb.jar/
    MyEJB_1.class
    MyEJB_2.class
    MyWebService.class
4

5 に答える 5

7

私の理解では、Camel を実行するにはいくつかの方法があります。

  1. Java アプリケーションへの埋め込み : Camel をスタンドアロンの Java アプリケーションに埋め込むことができます。このシナリオでは、ルートなどを開始するアプリケーション内で Camel コンテキストを開始します。これは、アプリケーションがサービスなどと通信する必要がある場合に最適です。クラスパス。

  2. Web アプリケーションへの埋め込み: 人々がすでに指摘しているように、これは一般的なオプションのようです。Camel jar とサード パーティの jar は WAR ファイルにラップされ、基本的に Tomcat などの Web コンテナーにデプロイされ、Camel サービスをホストします。

  3. アプリケーション サーバーへの組み込み: Camel を JBoss などのアプリケーション サーバーにデプロイする方法に関する記事を読みました。また、Glassfish にデプロイする人々についても読みました。これは、Tomcat にデプロイする方法と非常によく似ています。JBoss には、対処しなければならないクラス ローディングの問題がいくつかあり、扱いが難しくなります。はい、WAR ルートを使用してアプリケーション サーバーにデプロイできます。

  4. OSGi へのデプロイ: Camel jar を比較的迅速に OSGi バンドルにして、Apache Felix などの OSGi フレームワークにデプロイできます。jar を適切な OSGi バンドルに変換してからデプロイするのは比較的簡単です。ここでの 1 つの大きな問題は、一部のサード パーティが、展開する OSGi 互換バンドルを提供していない可能性があることです。

私の個人的な好みは OSGi ルートです。これは簡単で軽量で、キャメル ルートを永続的なサービス (つまり、ウィンドウ サービス、Unix Deamon) として非常に小さなフット プリントでホストできます。

ここで認識すべきことは、Apache Camel はいくつかの方法でデプロイできることであり、実際にどのようにデプロイするかはユーザー次第です。Camel の展開方法を理解するには、さまざまな展開モデルを試して感触をつかむ必要があったため、しばらく時間がかかりました。これらのサーバーのほとんどは十分に重いと感じたため、私が触れていないのはアプリケーションサーバーへの展開だけでした。

アーキテクチャに関する限り、私はさまざまなルート/アプリケーションをさまざまな jar に保持したいと考えています。私は OSGi を使用しているので、すべてを再デプロイすることなく、特定のルートを更新してデプロイできるようにしたいと考えています。すべてを 1 つの jar にデプロイした場合は、ワールドを再構築して jar を再デプロイする必要があります。ただし、これは個人的な好みであり、走行距離は異なる場合があります

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

于 2012-06-22T07:23:39.510 に答える
4

あなたの質問に一つずつ答えさせてください：

ESB を最適に展開する方法を決定するために使用する必要がある一般的な要素の説明的で曖昧でないリストを提供します (各エンドポイントが埋め込まれた JAR である単一の EAR または単一の「モノリシック」JAR として)。

埋め込みまたはモノリシック jar は関係ありません。重要なのは、バンドルまたは戦争展開です。スタンドアロンバンドルの場合、依存関係を解決するための多数の jar を持つ非常に分厚い展開アーカイブになる可能性があります。

Camel が JBoss や GlassFish などの Java EE アプリ サーバーでうまく動作しない理由を完全に説明します。

  1. App-Server/Container のスレッド/リソース/ポート管理は、制限を課す場合があります。

  2. 一般的に使用されるライブラリ バージョンの競合

  3. ClassLoading メカニズムの競合

論理的には、コンテナーが OSGi をサポートしている場合、Camel で問題が発生することはありません。

  1. Apache Camel は非常に軽量なメッセージ ルーターであるため、Web アプリケーションと一緒にwarファイルとして耳にパッケージ化できます。Maven/Ivy を使用していて、Web コンテナーが osgi をサポートしている場合は、Bingo! 人生はずっと楽になります。
  2. 2 番目のオプションは、アプリケーションをバンドルとしてデプロイすることです
  3. もう 1 つはスタンドアロンの Java SE jar です。

以下のリンクに従ってください[ただし、十分に時代遅れです]。これらは、パッケージングに関する段階的な指示を提供し、少なくともパッケージ化メカニズムを明確にします。

キャメルステップバイステップ

Web アプリケーションのキャメル

Camel Real Life パッケージングと OSGi 環境での展開

于 2012-06-25T18:19:00.747 に答える
1

他の回答と同様に、ニーズによって異なりますが、ESB は通常、必ずしも同じライフサイクルを共有するとは限らないさまざまな統合プロセスの組み合わせです。

このような場合は、jar統合プロセスごとのアプローチを使用することをお勧めします。そうすれば、異なる開発ライフサイクルごとに異なる開発ライフサイクルを持つことがjarでき、その中のコード以外には触れていないことをクライアントに保証できますjar。

earこれは、ソリューションを使用する必要があるという意味ではありません。オーバーヘッドwarなしで、さまざまなプロセスのコードをファイルに完全にパッケージ化できます。ear

于 2012-06-21T16:28:19.583 に答える
0

それはあなたのニーズに依存します。より良い単一の真実の答えはありません。

Camelは、既存のインフラストラクチャとランタイムプラットフォームに適応できます。したがって、このプラットフォームが実行できる方法と希望する方法で、Camelを組み込んだアプリケーションをパッケージ化します。

たとえば、Webアプリケーション（WAR）でCamelを使用するには、次のリンクを参照してください：http: //camel.apache.org/tutorial-on-using-camel-in-a-web-application.html

于 2012-06-19T03:48:13.257 に答える
0

.ear の埋め込みを検討されているようですね。

完全な機能を備えた Java EE サーバー内に Camel をタイトに埋め込むことについては、よく考えることをお勧めします。確かに実行可能ですが、それらを接続するための作業が必要になります (commonJ、WorkManagers、JNDI 参照などを使用)。具体的には、キャメルにスレッド化を処理させることは大きなプラスです。

春の Web アプリ (.WAR) 内に Camel を埋め込むことは、Jetty または Tomcat で展開するための私の個人的なお気に入りです。次に、適切なサーブレット コンテナー、何かを実行できるランタイムなどにアクセスします。

実際、私はキャメルが埋め込まれた一部の実稼働環境で ActiveMQ の標準ダウンロードを使用しましたが、ESB ではなくアダプター目的で使用しましたが、それでも ActiveMQ が ESB のメッセージング バックボーンである場合は有効な選択かもしれません。

于 2012-06-19T20:45:28.437 に答える