3

私はすでにSOAPを使用しましたが、SOA、ESB、およびその他のエンタープライズアプリケーション統合パターンを使用したことはありません。そして、ESBに関するドキュメントは非常に紛らわしいと思います。

ESBで理解できないことがあります。企業のネットワークをバスとして表現するという概念であり、具体的なものではないことは承知していますが、それでもなおです。

ESBがレガシーサービスでプロトコルとメッセージの変換を提供し、オーケストレーションを可能にし、メッセージの宛先のロジックがESBによって行われることを理解できます。しかし、私はESBを異なるESBサーバー間のミドルウェアとしても考えました（Webサービスインターフェイスだけではありません）。

ServiceMixを例にとると、共通のバス/プロトコル（NMR？JMS？）を介して相互作用する異なるサーバー上に複数のServiceMixプラットフォームがあるのは自然なことだと思いました。したがって、CAMELで作成されたServiceMix（a）のサービス（たとえば、いくつかのWebサービスを使用）は、同じくCAMELで作成されたServiceMix（b）のサービスを消費する可能性があります。

したがって、サービスに別のサービスが必要な場合は、その識別子を指定するだけで、ESBがリクエストを正しいServiceMixプラットフォームにルーティングします。

しかし、ServiceMixの例について読んだとき、ServiceMixはスタンドアロンのアプリケーションサーバーとして主に使用されているように思われます。サーバーのクラスターではありません。

ESBは単にブーストされたアプリケーションサーバーですか？（それが提供する統合機能は別として）

実際にSOAには複数のESBがありますか？ESB内部のプロトコルにリンクされていますか？または、ESB（a）に実装されたサービスは、ESB（b）がそのサービスを使用できるように、SOAPなどの外部インターフェイスを提供する必要がありますか？

4

3 に答える 3

2

簡単に言えば、Enterprise Service Bus はアーキテクチャの概念に近いものです。アイデアは、ビジネス サービスの観点から統合を実現することです。ESB は実際には、アプリケーションが特定のフォーマット セットと特定の通信プロトコル (SOAP/WS、メッセージングなど)、サービスなどを記述する方法に同意する一連のポリシーとガイドラインとして実装できます。

ESB サーバー (Service Mix、IBM WebSphere Message Broker、JBoss ESB、Mule ESB、MS BizTalk Server など) は、基本的にこれを実現するためのツールボックスを提供します。サーバーの数、トポロジ、使用するプロトコル/データ形式などは、多くの場合、状況や企業環境ごとに決定する必要があります。バッチ制御のレガシー/メイン フレーム システムで構築されたアプリケーション環境には、たとえばイベント駆動型の Java EE または .NET アプリケーション スタックなどとはまったく異なる統合セットアップが必要です。

于 2012-04-24T19:41:26.027 に答える
2

ESB は、マーケティングの概念としてよく使用され、すべてを簡単に差し込むことができる中央のバーとして描画します。ESB の内部では、以前の外部と同じ混乱が発生する可能性があるため、これはエンタープライズ統合を非常に単純化します。

多くの場合、ESB は、アダプターとルーティング コアを備えたアプリケーション サーバーとして実装されます。私の個人的な意見では、1 つのアプリ サーバーと統合するのは適切なアーキテクチャの選択ではありません。その理由は、この方法で統合するにはシステムからあまりにも多くの情報を漏らしてしまうからです。中央プラットフォームは、DB 構造や独自の接続プロトコルなどと統合するアプリの内部詳細を認識します。

一方、ルーティングと変換を考慮できるプラットフォームのアイデアは、正しく行われれば大いに役立つ優れたコンセプトです。

より良いアーキテクチャーとは、SOA で共通のトランスポートとフォーマットを持ち、ビジネス言語と思考に依存するモデルでサービスを作成するという概念だと思います。これを実現するには、統合するシステムの近くにアダプターを配置する必要があります。これは、あなたが説明したものに似た分散型 ESB につながります。ただし、共通のトランスポートとデータ形式を非常に標準化することに注意してください。

メッセージング システムを中央トランスポートとして使用し、純粋な XML または SOAP をデータ形式として使用した経験があります。もう 1 つの適切なオプションは REST です。両方を組み合わせることも可能です。

Servicemix または Karaf + Camel + CXF は、アプリケーションへのアダプターと、ルーティングおよび変換ロジックをホストできます。さらに、camel と CXF を使用してアプリケーションにアダプターを組み込むことができます。JMS または REST を使用すると、コンテナーと外部アダプターを接続できます。

于 2012-04-24T08:32:10.787 に答える
0

古いトピック-しかし、メッセージバスシステムを中心にESBを構築する必要があると思います。

ESBは、HTTP、FTPなどの他のアクセス方法を提供する場合があります。ESBは本質的にアプリケーションをホストしたり、内部で仲介を行うためプロトコルに関係なく、別の外部アプリケーションにシームレスに接続したりできます。必要に応じてスケーリングできます。たとえば、同じアプリをESBの3つのインスタンスにデプロイし、メッセージ指向ミドルウェアで負荷分散することができます。つまり、メッセージをキューに送信し、すべてのESBインスタンスがそれをリッスンし、1つだけがポイントツーポイントでメッセージを取得します。モデル。次に、MoMのクラスターを作成し、同じキューをホストしているインスタンスのいずれかにメッセージを送信することで、さらに拡張できます。

于 2013-03-05T09:15:47.700 に答える