説明するアーキテクチャは単純です。アプリケーションに対して暗黙の複雑さが保証されるかどうかは、決定できるものです。
私はCamelの詳細に精通していないので、その上に概念をマッピングしてみる必要があります。しかし、これは本当に大したことではないはずです。このレベルでは、ESBはESBです。ESBはESBです。
＃1には、2つのオプションがあります。GAEにはキューがpushあります。キューはユーザーが設定し、GAEが管理し、GAE環境内でのみ使用できます。キューはユーザーが設定および管理しますが、GAEと外部アプリケーションの両方を駆動できます。pullPushPull
アプリケーションにとってのpushキューは、通常のWebリクエストにすぎません。詳細は、GAEが実際のリクエストを行うクライアントであるということです。キューに送信先のURLとそのペイロードを投稿すると、GAEはURLへのリクエストをキャプチャ、ルーティング、スロットルします。Camelにリクエストを挿入するために、サーブレットまたは任意のJavaクラスからCamelパイプラインをポンプできる場合は、ここでそれを行うことができます。Camelにはたくさんのコネクタやリスナーなどがあることは知っていますが、この場合は、単純なコードベースのインジェクションポイントが必要です。キャメルがこれを行うことができることは間違いありません、私はただ詳細を言うことができません。
pullキューはまったく異なります。ここでは、（GAEリースメカニズムを使用して）キューからタスクをプルして処理するフリーランニングスレッドが必要になります。一部のCamelインフラストラクチャを活用して、pullキューに準拠したスレッドエンドポイントを作成し、Camelにキット全体を管理させることができる場合があります。ただし、最終的には、スレッドをスプールし、実行する数を管理し、監視し、シャットダウンする必要があります。したがって、pushキューとは対照的に、ここで実際に行う作業は少し多くなります。PushGAE内にすべてを含めることが合理的な要件である場合、内部インフラストラクチャの観点からキューはより簡単です。pull外部統合が必要な場合は、HTTPリクエストを介して外部ソースからキューをプルできます。
したがって、CamelにはGAEpullキューを管理するためのすぐに使用できる機能がない場合がありますが、これを処理するために既存のコンポーネントを適応させるのは非常に簡単です。そうすれば、Camelにすべてを管理させることができます。このレベルのCamelにすでに慣れている場合は、これを使用する方が簡単な場合があります。
＃2の場合、GAEバックエンドの2つの主な利点は、安定性と寿命です。通常のインスタンスは、負荷分散に適した汎用Webアプリとして存在します。GAEは、トラフィックと応答パターンに基づいてこれらのインスタンスを動的に作成および破棄します。ただし、特定の時点でアプリのインスタンスが実際に実行されていない可能性は十分にあり、GAEは最初のリクエストを確認したときにそれらをスピンアップします。したがって、内部（つまり、DBに永続化されていない）管理状態では、実際の寿命が保証されません。
バックエンドは、ユーザーが制御できるインスタンスです。それらは他のクラウドプロバイダーのインスタンスによく似ています。あなたはそれを起動し、あなたはそれをサイズ設定し、あなたはそれらにトラフィックをルーティングし、あなたはそれらをシャットダウンします。そのため、稼働時間とシステム容量のより良いアサーションが得られます。
リクエストがCPU時間やリソースに関して特に要求が厳しくない場合は、特にpushキューの場合、バックエンドインスタンスは必要ないかもしれません。基本的に、Webブラウザーから要求を受け取り、GAEタスクシステムに情報を渡すことを想像してください。GAEが行うのは、他のリクエストと同じように、すぐにコールバックすることだけです。アプリにとっては、通常のWebトラフィックと同じように見えますが、GAEからのものであることを「認識」していません。
したがって、1000個のリクエストを一度にキューに入れると、GAEは、バケットレートとメッセージレートを満たすために必要な数のアプリのインスタンスを起動します。これらの1000の要求が完了すると、GAEはすべてのクワイエットインスタンスをシャットダウンします。あなたが突然あなたのアプリケーションに1000人の訪問者を迎えた場合と同じように、彼らは突然去ります。
キューの場合pull、トラフィックを待機しているキューにある長時間実行スレッドを処理できるのは実際には唯一の種類であるため、長時間実行インスタンスが必要になります。しかし、それはあなたが常に、トラフィックを実行しているかどうかを意味します。
＃3の場合、これはほとんど簡単です。
最も基本的な形式では、EJB（ほとんどの場合ステートレスセッションBeanを意味すると思います）は、基本的に、トランザクションコンテキストにラップされた定義済みのライフサイクルを持つPOJOです。独自の「ミニ」コンテナを作成できるため、SSBをかなり簡単に複製できます。
YourTrnCtx ctx = startNewTransaction();
registerContextToThread(ctx);
YourBean b = new YourBean();
injectResources(b);
b.start();
b.service();
b.end();
commitTransaction(ctx);
10,000フィートで、それがその要点です。幸い、実際にこれを自分で書く必要はありません。SpringとGuiceはどちらも、特にリソースや他のBeanの注入など、この多くを処理できます。EJBライフサイクル、インターセプター、またはトランザクションメカニズムを多用しない場合（またはまったく使用しない場合）、これにより作業も簡素化されます。
結局、SSBに静的な値がないと仮定すると、リクエストごとに新しいインスタンスを作成するだけなので、スレッドの安全性についてそれほど心配する必要はありません。サーブレットとは対照的に、問題を大幅に単純化します。
また、Webリクエストの周りにこれらのライフサイクルパターンなどの多くを提供するStripesやStruts2のようなまともなアクションフレームワークを見ることができます。物事を簡素化することができます。
とはいえ、私は「戦闘で使い古された」GAEのベテランではなく、GAEアプリは非常に小さく、これらのテクノロジーを使用したことはありません。それはすべて「本の学習」です。