エンタープライズ・サービス・バスおよびレジストリの概要

エンタープライズ・サービス・バスの概念

エンタープライズ・サービス・バス (ESB) は、SOAP、REST、またはその他のネットワーク API を使用するアプリケーションへのアクセスとそれらのアプリケーションの管理を行うための単一ポイントを提供します。ESB には、以下の機能が用意されています。

• サービスの検出とサービスへのアクセスを行うための一元化された場所を提供します。

• サービスの詳細情報からアプリケーションを分離することにより、ユーザが単一箇所でサービスの説明を変更できるようにします。このとき、そのサービスに依存しているすべてのアプリケーションを更新する必要がありません。例えば、サーバのアドレスや、サービスの API を変更することもでき、それらの変更を ESB で処理できます。これによって、アプリケーションに対してプロトコルの独立性が確保されます。SOAP API を使用して開発したアプリケーションだが、新しいサービスで REST API を使用する追加機能を提供する場合、ESB はこの新しい REST サービスを REST と SOAP の両方の API として使用可能にできるので、ユーザは既存アプリケーションとの互換性を維持しながら新しいサービスの機能を追加できます。

• 企業によって使用されるアプリケーション、およびそれらのアプリケーション間の依存関係を編成および追跡するメカニズムを提供します。例えば、アプリケーションに関する問題が起きたときにユーザは、ESB からテクニカル・サポートの問い合わせ先情報を入手できます。

ESB が必要な理由。以下のシナリオを検討してください。

1. 企業で重要なアプリケーションがたくさん開発されています。それぞれのアプリケーションが独自の環境とユーザ・インタフェースを有しており、他のアプリケーションから独立しています。

2. 効率性の向上において、新しい問題と厳しい要件に直面しています。これらの問題を解決するには、これらの独立したアプリケーションが互いに通信し、対話するように設定する必要があります。

3. SOAP API または REST API を使用したアクセスを提供するように、アプリケーションを変更します。

4. SOAP API および REST API を呼び出す新しいアプリケーションの開発を始めます。新しいアプリケーションに、既存アプリケーションの機能を組み込むことができ、ワークフローを組み込んで、手順を合理化することが可能になります。

5. ただし、新しいアプリケーションそれぞれに、使用するアプリケーションの詳細情報、つまり、そのアプリケーションを実行するサーバのアドレスおよびそのアプリケーションへのアクセスに必要な特定の API が必要です。

6. 新しいアプリケーションの数が増えるにつれ、アプリケーション全体をまとめて保守管理することが難しくなっていきます。サービスを新しいサーバに移動したり、サービスの機能に変更を加えるだけで、そのサービスに依存している各アプリケーションを更新する必要が生じます。サービスに依存しているアプリケーションを見つけ出すことさえ難しい場合があります。

7. ユーザは、問題が発生したときにどこに問い合わせればよいのかよくわかりません。

Ensemble を ESB として使用すれば、サービスにアクセスするための統合メカニズムを作成できます。これによって、一連のアプリケーションの保守管理が簡単になり、使用を追跡したり、潜在的な阻害を特定したりするメカニズムが実現されます。

エンタープライズ・サービス・バス・アーキテクチャ

Ensemble ESB アーキテクチャのコンポーネントは、次のとおりです。

• 受信要求をサーバに接続するルーティング・メカニズム。これは、専用のビジネス・サービスとビジネス・オペレーション、およびビジネス・プロセスのプロダクション (オプション) によって実装されます。

• パブリック・サービス・レジストリ。このサービス・レジストリには、ESB パブリック REST API を使用して ESB クライアントからアクセスできます。開発者は、これを使用して、ESB 経由で使用可能なサービスに関する情報を取得できます。

• 外部サービス・レジストリ。このサービスは、ESB プロダクション内でのみアクセス可能です。これは、ESB ビジネス・ホストにエンドポイントの情報を提供します。

• SAML トークン検証サービス。

ESB プロダクションとサービス・レジストリの両方を、ESB 専用のネームスペースで定義する必要があります。

この最も単純な形では、ESB はパススルー・サービス、パススルー・オペレーション、およびサービス・レジストリで構成されます。次の図は、単純な ESB のアーキテクチャを示しています。

通常、アプリケーション開発者は、使用可能なサービスについて検索し、基盤となるサービスへのアクセスを提供するパススルー・ビジネス・サービスの URL を取得するために、Web ページまたはアプリケーションを使用して ESB サービス・レジストリにクエリを実行します。このクエリおよびサービスの検出プロセスは、開発者がクライアント・アプリケーションを作成しているときに実行されます。開発者が、サービスへのアクセスに必要な URL や説明などの情報を取得した後は、クライアント・アプリケーションからは、サービスを呼び出すためにサービス・レジストリにアクセスする必要はありません。環境によっては、クライアント・アプリケーションからパブリック API に実行時呼び出しを行って、レジストリ・エントリが前回のアクセス以降に変更されていないことを確認する場合があります。

クライアント・アプリケーションは、パススルー・サービスを呼び出します。パススルー・サービスは、ターゲットの設定に指定されているパススルー・オペレーションにメッセージを送信します。そのパススルー・オペレーションは、外部サービス・レジストリでエンドポイント URL を検索するよう構成されています。パススルー・オペレーションは、エンドポイント URL を使用して外部サービスを呼び出します。外部サービスは、パススルー・オペレーションに応答を返し、パススルー・オペレーションはその応答をパススルー・サービスに転送します。次にパススルー・サービスは、その応答をクライアント・アプリケーションに返します。

パススルー・サービスとパススルー・オペレーションに加えて、より複雑なサービス、オペレーション、およびビジネス・プロセスを定義して、次のような機能を追加することができます。

• 1 つの受信サービスからの呼び出しを、呼び出しの内容に応じて複数の外部サービスにルーティングする処理。これによって、ESB は、1 つの外部サービスからでは使用できないサービスを提供できます。クライアント・アプリケーションが、拡張されたサービスの実装に必要な外部サービスの影響を受けることはありません。

• サービスに使用されるパラメータまたはプロトコルの変更。1 つのサービスを使用する一連のアプリケーションを開発したが、後に異なる API を使用するより優れたサービスが使用可能になった場合、ESB では、各アプリケーションを変更するのではなく、変換を実行できます。クライアント・アプリケーションが、1 つの外部サービスから別のサービスへの切り替えに必要な変更の影響を受けることはありません。

• ESB へのサービスの直接の実装要件を満たす外部サービスがない場合、ObjectScript を使用して ESB に外部サービスを実装できます。

ただし、このようなより複雑なサービスを ESB に追加すると効率性が犠牲になります。複雑なサービスにより追加の処理が必要になり、ESB による要求の処理が遅くなり、スループットが低下します。

きわめて高度なスループットが必要な ESB システムの場合、永続メッセージを排除することによって、要求処理のオーバーヘッドを削減できます。永続メッセージは、パススルー・サービスからパススルー・オペレーションに送信され、オペレーションからサービスに返されるオブジェクトです。これらのオブジェクトは、Caché データベースに格納されます。これらの永続メッセージは、ESB で処理された呼び出しの追跡とレポート、および問題が発生した場合のトラブルシューティングに役立ちます。ただし、これらのオブジェクトの作成にはリソースが必要で、スループットがきわめて高度なシステムの場合、これらのオブジェクトに必要なストレージはかなり大きくなることがあります。システムを保持するためには、これらのメッセージを頻繁にパージする必要があります。永続メッセージの使用を抑止し、柔軟性を下げることによって効率性を高めることができます。詳細は、“パススルー・サービスおよびパススルー・オペレーションでの永続メッセージの抑止” を参照してください。

エンタープライズ・サービス・バスの構成

Ensemble のインストールと構成は、Ensemble 使用の準備で説明されています。このドキュメントでは、ESB として使用する Ensemble インストール固有の構成手順について説明します。これらの手順は、次のとおりです。

• ESB プロダクションおよびサービス・レジストリを格納するための Ensemble ネームスペースを作成します。

• CSP ゲートウェイを構成します。

• ESB で使用する外部サービスのエンドポイントを定義する外部サービス・レジストリのエントリを作成します。

• ESB プロダクションを作成し、ビジネス・サービス、およびそれらのサービスを提供するビジネス・オペレーションを追加して、プロダクションを開始します。

• Ensemble ポータルからパブリック REST API を使用してパブリック・サービス・レジストリにアクセスするときに必要なロールとユーザを作成します。

• クライアントでビジネス・サービスを使用できるようにするために必要な Web アプリケーションを作成します。

• ESB からアクセス可能なサービスを記述するパブリック・サービス・レジストリのエントリを作成します。

詳細は、“ESB としての Ensemble の構成の概要” を参照してください。