WebSphere DataPower 開発ガイド: 第1回 「DataPowerの構成概念とサービス設計」

この連載では、WebSphere DataPowerの設計・開発を行う際に必要となる、ルール設計の考慮点や指針、開発方法のTIPS等について解説します。
第1回は「DataPowerの構成概念とサービス設計」です。
この回では、WebSphere DataPowerの設計・開発の知識として必要となるDataPowerの構成概念と、サービス設計について解説します。

田中 直美 Naomi Tanaka, WebSphere Technical Sales, IBM

田中 直美 Naomi Tanaka, WebSphere Technical Sales, IBM



2013年 5月 02日

1 DataPowerの構成概念

1.1 アプリケーション・ドメインとオブジェクト

ドメインとは、1つのDataPowerアプライアンスを、1つ以上の複数の環境に分離することができる、論理的な構成単位です。DataPowerの構成情報やファイルは、アプリケーション・ドメインという単位で保持されます。アプリケーション・ドメインは、1つのハードウェアを複数のOS環境に論理分割できる仮想化の概念に似ていますが、DataPowerのアプリケーション・ドメインは、CPUやメモリ、ネットワーク等のシステムレベルのリソースをドメインを跨って共有する点で異なります。

ドメインの種類として、アプリケーション・ドメイン以外に、デフォルト・ドメインがあります。デフォルト・ドメインは、DataPowerに必ず1つ構成されており、デバイス全体に対する設定やネットワーク設定、ユーザー管理等の設定が保持されます・また、許可された管理ユーザーのみがログインすることができ、アプリケーション・ドメインの作成や削除も、デフォルト・ドメインの中から行います。DataPower上で開発/設定するアプリケーションは、管理上の理由から、デフォルト・ドメインではなく、アプリケーション・ドメインに構成するようにします。

DataPowerの構成作業においては、ユーザーおよびグループの概念があり、アプリケーション・ドメインの単位でユーザー・グループに対するアクセス制御を設定することができます。

DataPowerの構成情報はオブジェクトという概念で定義され、このオブジェクトの単位で作成・更新、起動/停止、ステータス確認を行うことができます。オブジェクトはアプリケーション・ドメインの中で階層的に保持されます。
DataPowerでは、このオブジェクトやアプリケーション・ドメインの単位で、構成情報のエクスポート/インポートを行うことができ、この機能を使うことで、構成情報のバックアップ/リストアをしたり、他のDataPowerへ構成情報をコピーしたりすることができます。

図1: アプリケーション・ドメインとオブジェクト
図1: アプリケーション・ドメインとオブジェクト

1.2 プライマリー・サービス

プライマリー・サービスとは、アプリケーション・ドメイン内に定義する、フロントサイドとバックサイドの接続設定と、メッセージに対する処理内容を定義する処理ポリシーにより構成される定義です。DataPowerが受け付けるメッセージは、プライマリー・サービスを経由して処理が実行され、後段サーバーへ割り振られます。

図2: プライマリー・サービス
図2: プライマリー・サービス

DataPowerには用途に応じていくつかのプライマリー・サービスの種類が提供されています。
DataPowerで提供されているプライマリー・サービスの種類については、「プライマリー・サービスの種類」の章を参考にしてください。

プライマリー・サービスの種類ごとに、WebGUI上で構成を定義するウィザードが提供されています。プライマリー・サービスは、提供されているウィザードに従って設定することで基本的な設定が定義できます。

図3: WebGUIのコントロール・パネル
図3: WebGUIのコントロール・パネル

1.3 処理ポリシーとルール

処理ポリシーは、プライマリー・サービスの中に定義する、メッセージに対する処理を定義するもので、各プライマリー・サービスに対して必須の構成オブジェクトです。処理ポリシーは複数のルールにより構成されます。ルールは、マッチング・ルールと処理ルールという2種類のルールのペアにより構成されます。マッチング・ルールでは送付されてきた要求電文が当該ルールによって処理されるべきかを判断します。処理ルールではメッセージへの処理内容を定義します。

図4: 処理ポリシー
図4: 処理ポリシー

送信されたメッセージは、優先順位に従って並べられた処理ポリシー内のルールの各マッチング・ルールによって評価され、最初に適合したルールによって処理されることになります。ルールはWebGUIの処理ポリシー設定画面の上から順番に優先順位が高くなっており、画面上で優先順位を入れ替えることができるようになっています。

図5: WebGUIの処理ポリシー設定画面
図5: WebGUIの処理ポリシー設定画面

処理ルールのフローとしては、以下のタイプを定義することができます。

  • Client-to-Server: ルールはクライアントからのリクエストへ適用されます。
  • Server-to-client: ルールはサーバーからのレスポンスへ適用されます。
  • Both: ルールはクライアントからのリクエストおよびサーバーからのレスポンスの双方へ適用されます。
  • Error: 処理中にエラーが発生した場合にのみ適用されます。

処理ルールにおける個々の処理をアクションといいます。WebGUIの処理ポリシー設定画面上で図のように処理パイプライン上にアクションをドラッグアンドドロップすることで処理ルールを構成します。

図6: ルール
図6: ルール

その際、必ず左端にマッチング・ルールが配置され、マッチング・ルールの後ろに左→右の順番で処理ルールを定義します。マッチング・ルールにマッチしたメッセージは必ずこの順番で実行されます。

1.4 アクションとコンテキスト

アクションは、各処理の種類ごとに提供されている部品であり、処理ルール上に並べられた順番でシーケンシャルに実行されます。定義可能なアクションは、親となるプライマリー・サービスによって異なります。

図7: アクション
図7: アクション

アクションには、インプットおよびアウトプット(一部どちらかのみ)を指定することで、リクエストやレスポンスに対する処理を実施します。インプット/アウトプットにはコンテキストを指定します。コンテキストとは、実際のデータ(XML、バイナリー形式)と変数等で構成されています。例えば、XML変換をするTransformアクションでは、インプットで指定したものが、XML変換される対象のコンテキスト(XMLデータ)となり、アウトプットで指定したものが、XML変換された後のコンテキスト(XMLデータ)となります。
アクションで設定できるコンテキストには以下の種類があります。

  • INPUT
    処理ポリシーが最初に受け取るリクエストのコンテキストとなります。
    例えば、クライアントからHTTPのPostメソッドで送信されたデータや、同様にサーバーからのレスポンスであるXMLデータとなります。
  • OUTPUT
    処理ポリシーがバックエンドサービスに渡すコンテキストです。
  • NULL
    “アウトプット”に指定した場合、データを破棄します。
    “インプット”に指定し場合、そのアクションでは空のデータを利用して処理をします。
  • PIPE
    アクションのアウトプットは次のアクションのインプットになります。
    “アウトプット”にPIPEと指定した場合、次のアクションも“インプット”にPIPEを指定する必要があります。
  • 任意名称コンテキスト

DataPowerでは、コンテキストの単位で変数を保持することができ、後段のアクションでこの変数に格納された値を利用するような処理を定義できます。

以下は、Transformアクションにおけるインプットとアウトプットの設定例です。
Transformアクションを配置し、ダブルクリックで設定画面を開くと下図のようにインプットとアウトプットが(auto)と指定されていることが分かります。(auto)はDataPowerにより自動で設定が行われることを表しています。アクションの設定を完了し、処理ルール上でアクションのアイコン上にマウスを合わせると、インプットにINPUT、アウトプットにPIPEが、自動で設定されていることが分かります。

図8: Transformアクションにおけるインプット/アウトプットの指定例
図8: Transformアクションにおけるインプット/アウトプットの指定例

2 サービス設計

2.1 要件の確認

サービスの設計を行う前に、確認するべき要件とポイントを以下にまとめています。以下を参考に、DataPowerでの実装の要件を確認してください。

表1: 要件の確認
No要件確認内容
1連携の種類と数処理する連携処理の種類を確認します。
各連携の種類ごとに、以降の要件を確認します。
2連携先の伝送プロトコルどの伝送プロトコルで送受信する必要があるのか確認します。
-フロントエンドのプロトコル
-バックエンドのプロトコル
<参考>DataPowerで扱うことができるプロトコル
HTTP(S)、FTP(S)、SFTP、WebSphere MQ、MQFTE、WebSphere JMS、NFS、IMS Connect、Raw XML、TIBCO EMSなど(※モデルにより扱えるプロトコルが一部異なります。一部のプロトコルは有償オプションのフィーチャーです。)
3送受信するデータフォーマットどのようなメッセージフォーマットで送受信するのかを確認します。
-XML
-SOAP
-JSON
-non-XML
(※non-XMLのメッセージを扱う場合には、有償オプションのフィーチャーが必要となる場合があります。)
4メッセージ変換、処理要件送受信のメッセージの変換要件の有無、変換の内容を確認します。
-メッセージ変換の有無、内容
-ルーティング処理の有無、内容
-データベースアクセス処理の有無、内容
5セキュリティ要件以下のようなセキュリティの要件の有無、実装方式を確認します。
-暗号・復号
-署名・署名検証
-認証、認可、監査
-XMLスキーマ検証
-XML攻撃の防御
6障害対応障害やエラー発生時の処理要件について確認します。
-処理エラー時の処理
7その他その他の要件について確認します。
-リクエストのモニター(モニター対象と実施アクション)
-ロギング

2.2 ドメイン設計

サービスの設計を行う前に、アプリケーション・ドメインをどのような用途でいくつ作成し、どのようにサービスを配置するのか、どのユーザー/グループからのアクセスを許可するのかを検討する必要があります。
以下のような点を考慮して、ドメインを設計するようにします。

-複数の開発ユーザーが同時に同一アプリケーション・ドメイン内で開発することは避けるようにします。

-リリースの単位が異なるサービスを同一ドメインに配置しないようにします。

-起動/停止、バックアップ等の運用管理の単位が異なるサービスを同一ドメインに配置しないようにします。

-デフォルト・ドメインにサービス・オブジェクトを構成しないようにします。

-アプリケーション・ドメインの名前は、最大128文字の長さまで許容されますが、長い名前は避けるようにします。WebGUI上でドメイン名が見づらくなり、作業や運用のミスを招きます。

-デフォルト・ドメインへは、限られた管理ユーザーのみにアクセスを限定するようにします。

-開発環境、テスト環境、本番環境といったステージングの環境は、ドメインで分割するのではなく、アプライアンスの単位で環境を分けるようにします。

2.3 プライマリー・サービスの種類

以下は、DataPowerで構成することができるプライマリー・サービスの種類と特徴です。DataPowerでは、以下のいずれかのプライマリー・サービスを使ってアプリケーションの開発を行います。

表2: プライマリー・サービスの種類
プライマリー・サービス説明
XSLアクセラレーター (XSL Accelerator)XSLアクセラレーターは、負荷の高いXML処理をアプリケーション・サーバーからDataPowerにオフロードするためのプライマリー・サービスで、アプリケーション・サーバーの前段にプロキシーとして配置します。SOAPやXMLの送受信や、XMLのスキーマ検証、XSLTによる変換等のXMLの基本的な機能のみを提供します。
利用可能なプロトコルは、HTTP(S)のみです。
XMLファイアウォール (XML Firewall)XMLファイアウォールは、XSLアクセラレーターを拡張したサービスで、XSLアクセラレーターの機能に加え、メッセージの暗号化/復号、署名/検証、認証/認可等のセキュリティ機能を実装することができます。
利用可能なプロトコルは、HTTP(S)のみです。
Webアプリケーションファイアウォール (Web Application Firewall)Webアプリケーションファイアウォールは、Webアプリケーションに対するHTTPリクエスト/レスポンスをハンドリングするために、Webアプリケーション・サーバーの前段にプロキシーとして配置します。HTTPヘッダーやCookieの値、URIに基づいたフィルタリングを行うことができます。
利用可能なプロトコルは、HTTP(S)のみです。
Webサービスプロキシー (Web Service Proxy)Webサービスプロキシーは、XMLファイアウォールの拡張サービスであり、インターフェースとしてWSDLを持つWebサービスのプロキシーとして機能させることができます。XMLファイアウォールの機能に加え、WSDLレベルでの定義や管理、モニタリング等の機能を提供します。また、複数の通信プロトコルでのリクエストの受信を定義することができます。
マルチプロトコルゲートウェイ(Multi-Protocol Gateway)マルチプロトコルゲートウェイは、XMLファイアウォールの拡張サービスであり、さまざまな通信プロトコルとのAny-to-Anyでの通信と通信プロトコルの変換を可能にします。
Webトークンサービス (Web Token Service)Webトークンサービスは、HTTPプロトコル上のOAuthのトークンをハンドリングするためのLoopbackサービスです。DataPowerをOAuthのエンドポイントとして機能させる場合に利用します。
図9: プライマリー・サービスの関係
図9: プライマリー・サービスの関係

2.4 サービス設計

どのプライマリー・サービスを使うのかを検討します。
XSLアクセラレーター、XMLファイアウォール、Webアプリケーションファイアウォール、Webトークンサービスは、利用目的が限定されているプライマリー・サービスです。汎用性はありませんが、特定の機能を実装する場合に必要な項目のみが設定できるようになっているため、容易に目的の機能を実装できるという利点があります。実装したい機能や通信プロトコルが、これらのプライマリー・サービスが持つ機能と一致している場合には、開発生産性の観点でこれらの利用目的特化型のプライマリー・サービスを選択するのもよいでしょう。但し、処理可能な通信プロトコルが限られていたり、利用できない機能があるため事前に確認が必要です。

一方で、Webサービスプロキシーや、マルチプロトコルゲートウェイは、多くの通信プロトコルをサポートしており、柔軟な構成が可能です。これらのどちらを選択するかについてですが、特別な要件がない場合にはマルチプロトコルゲートウェイを選択するようにします。マルチプロトコルゲートウェイはもっとも柔軟で汎用性の高く、さまざまな要件に対応することのできるプライマリー・サービスです。
Webサービスプロキシーは、定義にWSDLを利用するため、WSDLをベースとした定義や管理が実装しやすくなっています。従って、WSDLをインターフェースとして持つWebサービスがあり、かつDataPowerでもWSDLベースの管理や開発を行いたい場合には、Webサービスプロキシーを選択します。但し、Webサービスのインターフェースが追加になる場合には、WSDLの単位で都度設定が必要になり、また、サービスの数が多い場合には、DataPower上の定義に逆に工数がかかってしまう場合がありますので、インターフェースの数や、将来のサービスが増加する頻度や数も含めて検討するようにしましょう。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。プロフィールで選択した情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=926627
ArticleTitle=WebSphere DataPower 開発ガイド: 第1回 「DataPowerの構成概念とサービス設計」
publish-date=05022013