33

私は経験の浅いJava開発者であり、いくつかの基本的なミドルウェア/ SOAの概念とテクノロジー、具体的には次のことに頭を悩ませようとしています。

  • サービス指向アーキテクチャー（SOA）
  • メッセージ指向ミドルウェア（MOM）
  • メッセージキュー
  • Apache Camel
  • ラバ
  • EJB
  • エンドポイントとルート
  • サービスバス/ESB
  • JMS

これらのそれぞれをオンライン/ウィキペディアで調べた後、私はこれらのそれぞれについて（ほとんどの場合）まともな定義を得ることができました。私が理解していないのは、これらのテクノロジー/コンセプトのすべてがバックエンドでどのように連携して、第2/ビジネス層ソリューションを提供するかということです。

誰かがこれらのテクノロジー/コンセプトのすべてを使用するアーキテクチャの例を挙げて、ソリューション全体でそれぞれがどのような役割を果たしているかを説明できますか？実用的な例を見ると、ほとんどの点をつなぐのに役立つと確信しています。

編集：私は賞金を追加して以来、本を読むことを示唆するいくつかの答えがありました。ここでのすべてのフィードバックに感謝しますが、基本的に「RTM」に要約される回答に対して300の評判ポイントを手放すことはできません（特に、私がフラットに壊れてマニュアルを買う余裕がない場合）。 、賞賛と決定的な答えは、意味のある、実用的な例でこれらの弾丸のすべてを打つことができる誰かに行きます。これはミドルウェアの概要である必要はありません!!! これらすべてを調和させてJavaビジネス層ソリューションを作成する方法を示す1〜2段落。再度、感謝します。

4

7 に答える 7

23

SOAの主な原則：各サービスが存在するサービスのセットとしてシステムを構築する

  • 粗い
  • 相互運用可能
  • 緩く結合

企業は、長年にわたって開発され、何らかの形でユーザー（人間または他のシステム）に公開されている多くのビジネスサービス（粗粒度）を提供しています。これらの各機能が、上記の3つの原則を念頭に置いて設計および開発されていない可能性が高くなります。さらに、これらの各機能は、異なるテクノロジーなどを使用して、異種の異種プラットフォームで実行されている可能性があります。

これらの異なる機能を統合して新しいソリューションを作成したい場合はどうなりますか（たとえば、Amazonストアフロントは、カタログサービス、ショッピングカートサービスなどで構成される新しいサービスです）。

2つの選択肢があります。

  1. 3つの原則を念頭に置いて、新しい機能をゼロから構築します。しかし、それは非常に費用のかかる取り組みであり、ほとんど成功することはありません。
  2. 効果的でリスクの少ない代替手段は、既存の実績のある（十分にテストされた）サービスから組み立て/構成することです。

オプション2は、ESBがルーティング、変換、監視などのサポートを支援できる場所です。ApacheCamel、MuleはオープンソースのESBです。エンドポイントとルートは、これらのESBが実装するEIP（エンタープライズ統合パターン）で使用される用語です。ESBは、異種プラットフォームで実行されているサービスをルーティング/統合する場合にMOM（メッセージ指向ミドルウェア）を利用できます（たとえば、カタログサービスはメインフレームシステムで実行されている可能性がありますが、ショッピングカートは実行中のステートフルEJBを使用して実装されますJavaアプリケーションサーバー内）。メッセージキューは、送信者と受信者の間のメッセージの一時的な保存として機能するMOMの概念です。この一時ストレージには、非同期配信、保証付き配信などの多くの利点があります。IBM（WebSphere MQ）、オープンソースActiveMQなどのさまざまなMOMベンダーがあります。JMSを使用して、コードをベンダーから独立させることができます。

私はすべての概念を例と関連付けようとしました。私もそれを短くしようとしました。理解を深めるために、フォローアップの質問をしてください。

MOMはSOAを実装するための要件ではありません。たとえば、すべてのサービスがHTTP経由でSOAPを介して公開されている場合、この場合はMOMは必要ありません。

于 2012-04-09T20:33:00.140 に答える
10

すべての技術のためのJavaクラス/例。あなたが尋ねたのは、進化産業が過去10年間に経験し、まだ進化しているということなので、単一の投稿では不可能かもしれません。したがって、過去10年間に起こったことは、1つの投稿でカバーすることはできません。ただし、このフェーズがどのように行われたか、新しいテクノロジースタックが必要な理由、およびそれが解決する問題の種類を理解することは良いことです。

  • EJBエンタープライズJavaBeansサーバーサイドコンポーネントアーキテクチャ。迅速かつ簡素化された開発を可能にします

    1）分散（複数のアプリケーションサーバーが相互に通信する場合、サーバーコンポーネント（たとえば、異なるサーバーでホストされている他のサービスを呼び出すサービス）。

    2）トランザクション-永続化Bean（DB TXN）、単純/Web/分散アプリケーションの最も重要な部分。構成ベースなどの簡単な開発。トランザクションを処理するXMLを記述します。たとえば、いつコミットするか、いつロールバックするか（例外の場合）などです。JPAJava Persistance APIは、オブジェクト関係のマッピングを提供します。テーブルの行などは、xml構成を介してJavaオブジェクトにマップされます。

    3）安全-認証（uid / pwd）と承認（役割ベース-ログインしているユーザーとそのユーザーが実行できるすべてのタスク）。

これは、エンタープライズアプリケーションを開発するためのある時点では良さそうに見えますが、非常に重い（すべてのjarファイルが含まれている）などの欠点があります。Beanとして使用されるクラスは、EJB標準に準拠している必要があります（クラスは、EJBエンジンがどのタイプのBeanであるかを理解するための特定のインターフェースを実装している必要があります）。

このようなシナリオを克服するために、EJBには多​​くの代替手段が業界で利用可能です。たとえば、HibrnateはORマッピング、EJBの永続Beanによって提供されるTXN処理などの同じことを行います。春の軽量フレームワークであり、ビジネスロジックを簡素化します（インターフェイスを実装したり、例外をチェックしたり、必須の抽象クラスの一部を拡張したりする必要のない、既にビルドされたクラスを使用できます）。

現在、Spring、Hibernate、IBatis、Axis-2など、軽量フレームワークを実際に使用している企業のほとんどがいます。

  • サービス指向アーキテクチャー（SOA）サービス指向アーキテクチャーは、エンタープライズレベルでのプラットフォームの独立性に対する答えです。またはアプリケーションをより高速に統合するため、異なるアプリケーションサーバー間で通信するため。

    世界中のホテル予約のオプションを提供しているソリューションを実装したいと考えてください。あなたの要件は、それらのホテルの空室状況を確認することです。つまり、一度に複数のホテルアプリケーションを操作する必要があるということです。すべてのホテルが同じ標準を使用している必要はありません。または、それらのアプリケーション（サーバー、プログラミング言語）が異なるアプリケーションサーバーに展開されている場合があります。同時に、すべての異なるタイプのアプリケーションサーバーと通信できる異なるアプリケーションを作成することは実用的ではありません。この問題を解決できる標準ベースのソリューションが必要です。それはWebサービスを通じて可能です。

これは、WebサービスがXMLに基づいてSOAP（Simple Object Access Protocol）でメッセージを送信しているために可能です。XMLは、任意の言語、プラットフォーム、またはネットワークプロトコル間でデータを交換するために使用されます。

Webサービスは、SOAPベースとRESTに分類できます。SOAPベースのサービスJAX-RPCおよびJAX-WS（http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc/index.html）

Webサービスは最初にコントラクトで開発できます-最初にWSDLを記述します。最初のコード-最初にコードを記述します。

それでは、実際にWebサービスを開始する方法について説明しましょう。

最も単純なWebサービスまたはhelloworld（JAXWS）は、次のように記述できます。- http ://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/java_first_jaxws/

  • メッセージ指向ミドルウェア（MOM）
  • JMS

  • メッセージキュー（ポイントツーポイント）

    MOMは、要求/応答スタイルの通信の欠点を克服する必要があります。クライアントが応答を送信するとき、サーバーは稼働している必要があります。クライアントは、サーバーが実行されて応答するまで応答を待ちます。

    要求応答-サーバーまたはクライアントがダウンしている場合、アプリケーションは失敗します。MOM-処理のために要求メッセージを送信するときに、どちらのエンドポイントも時間どおりである必要はありません。

    MOMは概念であり、JMSはこの概念の仕様です。多くのベンダーがこの仕様を実装しています。たとえば、IBMにはMQ、OpenJMSオープンソース実装、TibcoのEMSなどがあります。

JMS仕様には、主に2つのパターンがあります。Pub/subおよびponin-to-point。

Pub / subがトピックであり、アプリケーションは特定の情報をすべての関係者に公開したいと考えています。例：ダッシュボード。（ストックアプリケーションは、登録されているすべてのリスナーに特定のメッセージを通知したい）。

ポイントツーポイント通信は、メッセージキューを介して行われます。

ビジネスユースケース-カスタマーケアへのカスタマーリクエストなどのアプリケーションがあると考えてください。反対側には複数のカスタマーケア担当者がいて、反対側の顧客にはカスタマーケア担当者よりも多い場合があります。一度に1人の担当者だけがリクエストを処理し、タスクが完了するまで次のリクエストを受け取りません。（同じ1つのキューに複数のウィンドウがあり、空いているウィンドウがリクエストを処理します）。これには他の複雑さも考えられます。たとえば、ノードの1つに障害が発生し、要求が処理されず、特定のタイプの要求を特定のノードで処理する必要がある場合はどうでしょうか。等

コードを生成する：-http：//docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleProducer.java

コンシューマー同期コード:-(POJOクラス） http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleSynchConsumer.java

http://www.java2s.com/Code/Java/J2EE/ThisexampleisasimpleJMSclientapplication.htm

非同期コードを消費します:-(例による春-プログラムが停止しないまで宛先からメッセージを読み取ります。） http://www.springbyexample.org/examples/simple-spring-jms-listener-config.html

ただし、このMOMでカバーする必要のある基本的な側面はたくさんあります。たとえば、フェイルオーバーメカニズム、セレクター、永続メッセージ、メッセージ確認モードなどです。

  • サービスバス/ESB
  • エンドポイントとルート
  • Apache Camel
  • ラバ

さて、あなたがずっと前にSOAとMOMを採用していて、企業全体のタスクを達成するために互いに通信するたくさんのサービスを持っているとしましょう。非常に面倒な場所からリダイレクトする必要がある複数の宛先などのロジックを管理することを想像してみてください。このアプリケーションロジックと呼ぶ人もいます。サービスバスは、アプリケーションロジックを削減し、ビジネスロジック（アプリによって提供される機能）に重点を置くために使用されます。

簡単に言うと、エンドポイントはサーバー上で公開されているURLと見なしてください。このURL/エンドポイントを使用してサービスを呼び出します。

例： http：// localhost：8888 / Context / MyService？wsdl

コードで：-

    String endpointAddress = "http://localhost:8080/jaxws/services/hello_world?wsdl";

    // Add a port to the Service
    service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING, endpointAddress);

    HelloWorld hw = service.getPort(HelloWorld.class);
    System.out.println(hw.sayHi("World"));

ルート サービスバスが特定のメッセージを受信すると、キュー/トピックなどのサービス/ブローカーの宛先を経由せずにルーティングします。このパスはルートと呼ばれます。

たとえば、株式アプリケーションがアナリストによって入力された場合、それはアプリケーション/ Webコンポーネントを介して処理され、結果は特定の株式更新のためにすべての関心のある/登録されたメンバーに公開されます。

ApacheCamelとMuelhttp ://camel.apache.org/how-does-camel-compare-to-mule.html は、エンタープライズ統合のためのソリューションを提供します。

于 2012-04-13T04:35:27.653 に答える
5

エンタープライズ統合パターンは、すべてがどのように組み合わされているかを理解するのに役立ちます。

[更新：]別の回答に対するあなたのフォローアップの質問は、あなたが特定の製品について混乱していることに気づきました。これは、実際のソフトウェアが複数の概念にマッピングされる傾向があることと、実際には提供されていないのに、さまざまな企業が「すべて」を提供すると主張しているためです。

ESBは、すべてを相互に接続できるツールキット/ライブラリです。それらはサービス自体でもメッセージングの実装でもありませんが、その間の奇妙な小さなギャップを埋めるグーです。すべてをゼロから作成している場合は、必要ないかもしれません。なぜなら、それらが得意とするのは、さまざまなテクノロジーの山全体の不一致を修正することであり、ゼロから開始する場合は、その混乱を回避できるからです。

サービスは、まあ、サービスです。実装時にいくつかのEJBを使用する場合があります（何らかの理由でEJBを質問に含めるため、これについてのみ言及します）。

メッセージングミドルウェアは、AからBへのメッセージを取得するソフトウェアです。これは非常に便利ですが、複雑でもあり、誰も彼も自分で発明しました。したがって、ロックインを回避できる抽象化が必要です。これはESBの場合もあれば、すべてJavaの場合はJMSの場合もあります。ただし、JMSを使用するすべてのJavaの場合でも、ESBは、作成する必要のあるJavaコードのすべてのビット（ルーティングロジックのランダムビット、メッセージの再フォーマットなど）のライブラリであるため、ESBを使用することをお勧めします。

お役に立てば幸いです。私の最初の答えは、これらのツールを使用して構築する抽象的なパターンに関するものです。物事を相互に配線していると、同じ問題が何度も発生します。

于 2012-04-09T16:08:07.517 に答える
3

エンドポイントとルート：情報の出所と行き先。メッセージキューはエンドポイントの一種です。もう1つのタイプはメッセージトピックです。

エンドポイントは「モノの論理名」であり、たとえばPRICE.MSFTであり、パブリッシャーまたはコンシューマーアプリケーションがモノを取得または送信するために使用します。トピックは、サブスクライブされたすべての人（1対1または1対多）に情報を配信し、キューは、最初に情報を取得した人（通常は1対1）にメッセージを配信します。キューを忘れて、すべてをトピックで実行することもできます。トピックにはいくつかの利点があります。

メッセージ指向ミドルウェア（MOM）：トピック間またはキュー間で情報を配信するソフトウェアインフラストラクチャ。TCPのように「パケット指向」ではなく「メッセージ指向」です。したがって、各情報BLOBは、1つの、できれば自己記述的なメッセージで配信されます。MOMを実装すると、msg.get（ "bid"）などを実行できるAPIが提供されます。

JMSとAMQPは、MOM仕様の例です。MOMの実装は、TIBCO EMS、Websphere MQ、MSMQ、Solace、およびその他多くの仕様を実装する実際の製品です。

ApacheCamel-このMOMの世界でワークフローを構成する方法に関する非常に興味深いアプローチ。しかし、より高度な概念。

サービス指向アーキテクチャ（SOA）、サービスバス/ ESBは、以前はEAI（Enterprise Application Integration）と呼ばれていたものの単なる新しい流行語です。これらは、「MOM」の使用方法と高額なコンサルタントへの支払い方法に関する推奨事項です。「ESB」がMOMに追加するのは、パブリッシャーを「サービス」がサービスを提供するものと考えるという考え方です。言い換えれば、ある消費者が今何を望んでいるのかをあまり考えないでください。将来的には5人の消費者がいる可能性があり、その発行者は「消費者Aが必要とする情報を作成する」のではなく、サービスを提供する必要があります。（アーキテクチャが5つ以上のアプリケーションに成長すると、より明確になります）。また、アプリケーション間で物事を単純化するために、おそらくXMLでいくつかの共通のオブジェクトモデルを用意する必要があります。

ラバ-ESBの1つの形式ですが、厳密には主流ではありません。5年間で、ほとんどのミドルウェアアクションはAMQPまたは他の何かに完全に移動された可能性があります。

EJB：コンテナで実行される洗練されたJavaクラスに関するSunのアイデア。アプリケーション開発を容易にすることを目的としています。しかし、多くの場合、それは物事をより複雑にしました。より良い代替手段は「Spring」ですが、EJBは（MOMだけでなく）他の何かに関するものです。より大きなアプリケーションを開発する方法についての詳細（IoCパターンを参照）。

どこから始めればよいかを検討している場合：JMSについて学ぶことをお勧めします（他のすべてのMOMは類似しており、JMSはEJB / Muleの基礎です...）。非常に高いパフォーマンス要件がない限り、メッセージは次のようになります。 XMLを含むTextMessage。ほとんどのツールはその領域で利用できます。または、さらに単純ですが、それほど洗練されていない、キーと値のペアを持つMapMessageです。

于 2012-04-17T09:31:06.393 に答える
1

さまざまな抽象化レベルで、さまざまな概念やテクノロジーを組み合わせます。しかし、すべての概念は、（エンタープライズ）アプリケーション統合と関係があります。私はあなたの定義にコメントしようとします：

  • サービス指向アーキテクチャー（SOA）
    SOAは、既存のアプリケーションを疎結合ユニットとして統合するための一連の原則と方法論を提供します。エンタープライズ統合パターン（以下を参照）から：「SOAは統合と分散アプリケーションの間の境界線を曖昧にします」。
  • Service Bus / ESB
    ESBは、SOA内のアプリケーション内の依存関係を減らすためのSOAの主要な概念です。アプリケーション間の多くの依存関係の代わりに、各アプリケーションはESBに接続されます。
  • メッセージ指向ミドルウェア（MOM）
    MOMは、分散システム間でメッセージを送受信するためのインフラストラクチャです。これは、アプリケーションを統合するために使用されます。MOMは、SOAの誇大宣伝が登場する前の黄金のハンマーでした。どちらも便利なので、大きな統合スイートはESBとMOMの両方を提供します（またはESB内でMOMを使用します）。
  • メッセージキュー
    メッセージキューは、MOMアーキテクチャの技術的な詳細の側面にすぎません。メッセージの送受信が分離されると、受信者の準備が整うまでメッセージはキューに保存されます。
  • Apache Camel 「エンタープライズ統合パターン：メッセージングソリューションの設計、構築、および展開」
    という本が市場に出回ったとき、この本のパターンの実装を提供するいくつかのソフトウェアソリューションが作成されました。ApacheCamelはその1つです。Camelは、オープンソースのESBでもあるApacheServiceMixの一部でもあります。FuseSourceとTalendは、Apache ServiceMix、Apache Camel、Apache Active MQ（MOM）を商用サポート付きのバンドルにパッケージ化しています。
  • Mule
    Muleは、オープンソースのESBおよび統合プラットフォームでもあります。

  • WikipediaのEJB ： Enterprise JavaBeans（EJB）は、エンタープライズアプリケーションのモジュール式構築のための管理されたサーバー側コンポーネントアーキテクチャです。これは、EJBがアプリケーション内のコンポーネントであり、アプリケーションの統合とは主に関係がないことを意味します。
  • エンドポイントとルートApacheCamel
    を使用してエンドポイント間のルートを設計する場合は、チュートリアルを参照してください。つまり、メッセージはエンドポイントを介してシステムに出入りし、ルートによって定義されたフローで処理されます。
  • JMS
    JMSまたはJavaメッセージサービスは、標準化されたJava APIを備えたメッセージ指向ミドルウェア（MOM）です。
于 2012-04-16T14:10:23.840 に答える
1

すべての要件を取得してクエリにパッケージ化すると、ニーズを満たす優れたケーススタディが見つかりました。

私は先に進み、Amazonの「この本の中を検索」機能を使用して本を全文検索しました。これまでに説明したすべての統合ケースを網羅しており、徹底しているように見え、設計と実装のプロセス全体を順を追って説明します。

私はこれを自分で読んでいないと言うのは恥ずかしいですが、コピーに投資する前に、それがあなたのニーズに合うかどうかを確認するために私が行ったのと同じツールを使用することを強くお勧めします。不完全なドキュメントを大量に作成したり、コンテンツをここで回答にまとめたりするよりも、より徹底的で、より完全で、役立つように思われます。

于 2012-04-09T19:00:15.920 に答える
0

エンタープライズアプリケーション統合（EAI）は、ビジネスアプリケーションを異種システムに接続するための鍵です。長年にわたり、統合ソリューションのアーキテクトは、さまざまな方法で独自のパターンのブレンドを発明してきました。しかし、これらのアーキテクチャのほとんどには類似点があり、統合パターンの設計において広く受け入れられている一連の標準を開始します。これらの標準のほとんどは、http ：//www.eaipatterns.com/toc.htmlで入手可能なエンタープライズ統合パターンカタログに記載されています。

WSO2 ESB

WSO2エンタープライズサービスバス（ESB）4.7.0のドキュメント！WSO2 ESBは、Apache Software License v2.0の下で配布される、高速、軽量、100％オープンソースのユーザーフレンドリーなESBです。WSO2 ESBを使用すると、システム管理者と開発者は、メッセージルーティング、メディエーション、変換、ロギング、タスクスケジューリング、フェイルオーバー、負荷分散などを簡単に構成できます。最も一般的に使用されるエンタープライズ統合パターン（EIP）をサポートし、トランスポートスイッチング、イベント、ルールベースのメディエーション、および高度な統合要件のための優先度ベースのメディエーションを可能にします。ESBランタイムは、Apache Synapseメディエーションエンジンに基づいて、完全に非同期、非ブロッキング、ストリーミングになるように設計されています。

于 2013-11-05T06:32:13.340 に答える