4

私はJavaEEを初めて使用し、いくつかの基本的なミドルウェアの概念に数日間苦労してきました。「tingsのしくみ」の理解に突破口があったかもしれないと信じています。この質問の一部は私の調査結果の確認の要求であり、他の部分は正当な質問です;-)。

確認/明確化してください：サービスバス/ MOM（メッセージ指向ミドルウェア）についての私の理解は、それらが本質的にクライアント要求を非同期的に処理することを目的としているということです。これは、通常、ある種のサービスによって実装される同期的な通常の要求/応答サイクルとは対照的です。Javaでは、このようなバス/MOMはApacheCamelのようなものであり、同期サービスはEJB（3）のようなものである可能性があります。したがって、クライアントが要求をすぐに処理する必要がある場合、HttpRequestはWebサービスに移動し、Webサービスが要求を正しいEJBに転送する可能性があります。そのEJBはメッセージを処理し、結果をサービスに返します。サービスは次に、HttpResponseをクライアントに返します。そのため、クライアントがそれらをブロックせず、単に処理する必要がある要求を持っている場合、Webサービスはそれらを転送しますHttpRequestサービスバス上のあるエンドポイントに転送され、要求はメッセージのように扱われ、さまざまなプロセッサ（フィルタ、トランスなど）によって処理されます。

したがって、最初に、ESB / MOMソリューションが非同期要求の処理に最適であり、EJB（3.x）が同期要求にリアルタイムで応答するのに最適であると述べているのが間違っている場合は、訂正してください。または私が正しいことを確認します。

その場合、大きなアプリケーションでは、同期（ブロッキング）と非同期（非ブロッキング）のクライアント要求を同様に処理するために、両方のタイプのバックエンドが必要になるように思われます。したがって、私の理論は、バックエンドを次のように実装することです。

  • JBossやGlassFishのような本格的なアプリサーバーを使用する
  • アプリサーバーのWebコンテナには、次の2つのWARがWebServices.warありESB.warます。それぞれバックエンドの「ゲートウェイ」とサービスバスを表します
  • アプリサーバーのビジネスコンテナには、すべてのEJBがあります
  • これで、WebService.war（ゲートウェイ）は要求をESBまたはEJBのどちらに中継するかを検出できます。

私の2番目の質問は、私はここでかなりオフベースであり、ミドルウェア101の基本的な概念を見逃したことがありますか、それともこれは中途半端なアプローチですか？

編集：最初の応答から、私は2つの領域で間違っていたことがすでにわかりました：（1）ESBとEJBは実際には同期または非同期のいずれかであり、（2）MDBを使用する場合、EJBは次のように配線できますESB。

したがって、これらの修正は私にとっていくつかの新しい精神的な障害をもたらします：

  • ESBを使用する場合と、MDB/EJBソリューションを使用する場合。と
  • 私はApacheCamelのProcessorsAPI（EIPの実装）が本当に好きです。MDB / EJBを使用できますが、すべてのEJB内でCamelプロセッサ（、など）を使用するだけFilterですWireTapか？
4

2 に答える 2

5

これは大きな質問であり、大きな答えに値します。

ESBは同期または非同期の要求を処理でき、メッセージは通常非同期で使用されます。

ただし、バックエンドの実装理論はかなり間違っています。

JAX WS Webサービスは、EJB jarまたはEARを直接実行でき、任意のアプリサーバーでそのように実行できます。EJBは、メッセージをキューに入れることも、非同期にすることもできます。

ESBにリクエストを中継するのではなく、その逆を行う必要があります。

ESBは、クライアントとバックエンドの間で要求と応答を中継および変換する必要があります。ESBの大きなアイデアの1つは、バックエンドが変更された場合、クライアントはバックエンドではなくESBとの契約であるため、クライアントは知らないか気にしないということです。

とはいえ、アプリケーションがすでにWebサービスを公開している場合は、おそらくESBは必要なく、何かを行うための正しい方法も間違った方法もないことを覚えておいてください。

私はあなたがあなたの特定の問題をカバーするより明確な質問を書くことを提案します、あなたはおそらくそれを解決する方法について豊富なアドバイスを得るでしょう。

アップデート

また、メッセージ駆動型のEJBも取得します。これにより、EJBをバスのようにチェーン化できます。

さらなるアップデート

したがって、ESBを使用する場合の1つのシナリオは、レガシーシステムで非標準ベースのサービスをSOAPサービスとして公開する必要がある場合です。ただし、考慮すべき点は他にもあります。組織のデータディクショナリも実装する必要があります。これにより、レガシーシステムを交換しても、ESBで公開されているサービスが同じままである可​​能性が高くなります。

したがって、具体的な例として、組織はデータディクショナリで顧客エンティティがどのように見えるかを定義する必要があります。ESBは顧客を取得するためのサービスを公開できます。ESBは、レガシーベースのシステムでいくつかの呼び出しを実行してから、結果を変換します。将来、顧客を格納するバックエンドシステムが変更された場合、ESBで公開されているサービスはおそらく同じままであり、バックエンドの呼び出しと変換のみを更新する必要があります。

うまくいけば、それを念頭に置いて、次のビットが理にかなっているでしょう。これはすべて、JBossESBやMuleESBなどの「従来の」ESBで可能ですが、EJB + Camel（または他のもの）を使用して行うこともできます。

箱から出してすぐに使えるESBの利点は、コネクタ、リスナー、トランスが用意されていることです。ただし、すぐに使用できる機能がどれも役に立たない場合は、選択する方向にほとんど違いはありません。

ESBを自家栽培することの利点は、保守性です。特殊なESBリソースを見つけたり、リソースをトレーニングしたりするよりも、EJBをよく知っていて、必要に応じてCamelをすばやく学習できるリソースを見つける方がはるかに簡単です。

お役に立てば幸いです。

于 2012-06-22T13:40:54.050 に答える
3

お気づきのように、ミドルウェア/統合の世界は、定義と用語の混乱のようなものです。少し明確にしましょう。

サービスは、機能を提供する「何か」の概念にすぎません。サービスを公開する方法は複数あります。

以下のEJBを指す場合、非同期メッセージングを実装するMDB（Message Driven Beans）を除くEJBを意味します。

  • 同期的に要求/応答-要求の「かなり早く」応答が期待される場合。通常、WebサービスおよびEJB（RMIなど）を介して実装されます。
  • データを消費する多数の加入者への公開メッセージとして（通常、価格表は価格マスターシステムから注文システムなどの情報を必要とするさまざまなシステムにプッシュされます）。
  • あるアプリケーションから別のアプリケーションへのファイアアンドフォーゲットメッセージとして。通常、注文システムは注文を請求システムに送信する必要があります。その後、請求システムはサービスを公開して請求書を作成します。

概念的には、ESBはソフトなものです。これは、企業全体のアプリケーションがそれらのサービスを消費/使用できるようにするために、企業のビジネスサービスをどのように公開するかについての概念/合意です。これは基本的に、「SOAP / WebServicesを使用して許可されるのは要求/応答サービスのみであり、すべてのメッセージはOAGISXML標準に準拠する必要がある」という一連の制約である可能性があります。ただし、ほとんどの場合、ほとんどの企業のアプリケーション/サーバー/システム環境は均一ではありません。COTS製品、COBOLアプリケーションを備えたメインフレーム、.NETアプリ、およびJavaEEアプリケーションがあります。したがって、一般的なアプローチは、ESBソフトウェアスイートを使用してサービスバスをテクノロジーに実装するか、バスに向けてアダプターを構築することです。Apache Camelは、ルーティング、変換、変換などをセットアップするためのESB実装の一部である可能性があります。

ESBと緊密に統合されているものの1つは、メッセージ指向ミドルウェアです。これは通常、メッセージキューを実装する単なるサーバーです。MOMの利点は、EJB/Webサービスを直接呼び出すだけとは対照的にいくつかあります。

  • 非同期パターン（パブリッシュ/サブスクライブ、ファイアアンドフォーゲット、非同期リクエスト/リプライ）の場合、稼働時間が長く、非常に安定しているリレーサーバーを使用すると、全体として、ビジネスメッセージの送信の失敗を減らすことができます。
  • MOMは通常、負荷のピーク、ネットワークの障害、ハードウェア/ソフトウェアの障害に対して非常に回復力のあるアダプターとESBの実装をかなり容易にします。多くの場合、メッセージは永続的であり、中継される前にディスクに保存されます。また、特にJMS準拠の実装では、トランザクションが利用できることがよくあります。これにより、途中でデータが失われないことが保証されます。

以前以上に物事を台無しにしないことを願っています。これは少なくともこれについての私の見解です。

于 2012-06-22T14:25:10.207 に答える