第1部ESBによるアプリケーション統合の簡素化エンタープライズサービスバス(ESB)は、コストがかかり脆弱なポイントツーポイント統合ソリューションの代替を求める多くの組織で人気が高まっています。多くの組織は多数のアプリケーションを統合する必要があります。ハンドコーディングされた複雑な接続に基づくインフラストラクチャは、維持するのが難しく、壊れやすく、いずれかの接続で問題が発生した場合には修正が困難です。ESBは、面倒なスパゲッティコードを作成する代わりの解決策となります。SoapUIを使用して、サービスを展開し、ロードバランシングを実装し、CRM統合をテストします。ESB入門パワーガイド」シリーズの第1部では、以下について紹介しました。ESB入門パワーガイド」シリーズの第2部では、以下について紹介しました。Camelを使用してロードバランシングを実装して、エンドポイントの可視性を高めます。最後に、完全にロードバランシングされたSOAPベースのWebサービスプロバイダーをテストして、CRM統合が正しく機能していることを確認します。SoapUIでのテストサービスの準備が整ったので、オープンソースのWebサービステストアプリケーションであるSoapUIでテストを実行できます。以下に示す画面では、テスト目的でダミーのエンドポイントやサービスをStudioで直接使用できます。Project]を開始してWSDLを起動し、このテスト環境での顧客の操作を確認します。SoapUIのプロジェクトの下の「getCustomer」操作を確認し、[request]をクリックして操作内を確認すると、操作のペイロードが表示されます。これには、「custId」という単一のパラメーターが使用されています。次に、統合している元のソース情報を含む顧客のCSVファイルに戻り、顧客IDが10桁であることを確認します。SoapUIに戻り、有効な10桁の顧客IDをサービスに渡します。Flintstoneに関する情報を返し、この名前を連結して詳細をすべて返します。検証するために、元のCSVファイルに戻り、一致していることを確認します。Studioウィンドウ(下)に戻って、サービスをテストしたときにサービス内で発生した情報の流れを確認します。1つの要求があり、元の顧客リソースに5人の顧客が含まれていました。そのうち1つが一致し、標準の応答を得ました。これで、サービスを展開する準備が整いました。Studioからランタイムコンテナーにサービスをエクスポートします。Service」が表示されます。Assigned」という警告画面が表示されます。割り当てられた実装はありませんが、問題ないので、[OK]をクリックします。第1部では、2つのランタイムコンテナーを起動しました。Service]を使用します。プライマリーコンテナーに移動して「list」と入力することで、このエクスポートを検証します。0.1」が起動して利用可能になります。Studioが使用しているポート(8040)と一致しないため、サービスが正しく応答していることを確認するためにテストする必要があります。endpoint]で[localhost:]を8040に変更し、SOAPを介して要求を実行します。結果は、期待された顧客データを示しているので、サービス応答が正しく実行されていることがわかります。ロードバランシング統合パターンの実装サービス応答の準備が整ったら、次のステップはロードバランシングアルゴリズムを実装し、利用可能なメディエーションとルーティング機能のいくつかをチェックすることです。Service]を使用しますが、今回はそれをセカンダリーランタイムコンテナーに送信します(これはまだ使用していません)。これで、ロードバランシングのフレームワークが完成し、2つの異なるコンテナー上で機能的に同等の2つのサービスが実行されるようになりました。サービスをエクスポートした後、2番目のコンテナーを調べて、デフォルトポート8041で「demoCustomer」が展開され実行されていることを確認します。上記のサービス応答をテストしたときと同様に、SoapUIに戻って別のエンドポイントを追加します。今度は、[localhost:]を8041に変更し、SOAPを介してコンテナー#2に対して要求を実行します。コンテナーの内容を表示するインターフェイスに戻り、顧客サービスを表示します。標準出力を通じて、サービスに組み込んだロギング要素がXML出力を直接ロギングしているので(以下に示すスクリーンショットの一番下)、応答を得ていることを確認できます。リーダーの1社である理由をご確認ください。ESBに戻ってルーティング機能とメディエーションの機能を確認し、顧客エンドポイントへの単純なロードバランシングプロキシを作成します。Resource]の順にクリックして、「demoCustomer」WSDLをアップロードします。Camelのカプセル化された機能が表示されます。Camel機能を確認できます。ルーティングの実装を「cCxF」エンドポイントから始めて、名前を「proxyCustomer」に変更します。次に、[Component]タブをクリックして、このコンポーネントにメタデータを適用し、この新しいサービスエンドポイントをルートとして表す方法を指定します。このルートに「DemoCustomer」の他のサービスと同じ(このプロキシエンドポイントがポート8050で開始されていること以外)契約上のインターフェイスを引き続き提供します。これで、2つのコンテナーにすでに配置した2つの顧客サービス間でこれをロードバランシングしたいと思います。これを構成するには、さらに2つの「cCxF」を中央にドラッグし、それぞれに同じ契約インターフェイスを与えます。それぞれのサービスには異なるコンテナーポート(8040、8041)を適用します。最後に、左側のナビゲーションで[Routing]に移動し、[cLoadBalancer]を選択します。Camelロードバランサーです。標準の「ラウンドロビン」アルゴリズムを使用して、2つのコンテナー間でロードバランシングを行うことを選択します。Studioから直接これを実行して、展開を確認します。事実上、ポイント8050でデモカスタマーサービスへのプロキシインターフェイスを開始しています。このルートは現在要求を待機しています。SoapUIに戻り、8050で別の新しいエンドポイントを開きます。2つの顧客サービスエンドポイント間でロードバランシングが行われていることを確認するために、プライマリーコンテナーとセカンダリーコンテナーが順番に要求を受信していることを確認します。プライマリーコンテナーでロードバランシングが行われ、セカンダリーコンテナーがより多くの応答をサービスに提供するよう調整されたようです。ロードバランシングが行われていることを確認できました。これで、ルーティングメディエーションのフレームワークを使用して、効果的にサービスを作成して公開し、既存のリソースに統合し、単純なロードバランシングパターンを生成できました。ESBを使用して皆さんご自身が試すことができます。Talendの無償ESBを利用して、ここで紹介したのと同じパターンを、お使いのネットワークで簡単に実装できます。