WebSphere sMash を WebSphere Virtual Enterprise と組み合わせて使用する

sMash が活躍する柔軟なインフラストラクチャーを構築する

IBM® WebSphere® sMash が Web 2.0 アプリケーションの開発とデプロイメントを容易にするからと言って、クラスタリングと高可用性を犠牲にしなければならないわけではありません。WebSphere sMash アプリケーションの JVM を IBM WebSphere Virtual Enterprise 内のクラスターとして使用する方法、そしてこれらの sMash アプリケーションへの要求フローを On Demand Router コンポーネントで簡単に管理できるようにする方法を学んでください。

John Pape, WebSphere Application Server SWAT Team, IBM

Author photoJohn Pape は現在 WebSphere SWAT Team に所属し、WebSphere Application Server と WebSphere Portal Server、そして WebSphere Extended Deployment を利用するユーザーのための CRITSIT サポートを担当しています。この業務には細部に注目する能力と、たえず枠にとらわれない斬新な発想をすることが求められ、それによって可能な限り最高のサポートを IBM のユーザーに保証しています。



2008年 11月 12日

はじめに

Project Zero から生まれた IBM WebSphere sMash は、アプリケーションとマッシュアップを素早くデプロイできるようにする人気の高い Web 2.0 ベースの SOA 指向プラットフォームです。WebSphere sMash は複雑さをなくし、開発者が問題の解決に専念できるように設計されていますが、その一方で複雑さを排除するにはトレードオフが伴います。つまり、アプリケーション開発とランタイム・プラットフォームを単純化することによって、高可用性とクラスタリングなどの面が犠牲になります。そこで朗報となるのが、IBM WebSphere Virtual Enterprise の汎用サーバー・クラスターという概念と、On Demand Router の特殊なルーティング・ポリシーを併用することによって、この犠牲になった部分を埋め合わせる方法です。

汎用サーバー・クラスターとは、WebSphere が管理するセル環境には含まれないサーバーのエンドポイントを表しています。汎用サーバー・クラスターを定義するのは至って簡単で、その方法は新しいクラスターを作成して名前を付け、HTTP リクエストを処理するために使用するホストとポートの組み合わせのリストを定義するだけです。汎用サーバー・クラスターを定義したら、ODR (On Demand Router) に特殊なルーティング・ポリシーを設定する必要があります。特殊なルーティング・ポリシーとは、汎用サーバー・クラスターと連動することを目的に設計されたポリシーで、リクエストを汎用エンドポイントにルーティングする方法を定義します。これらのルーティング・ポリシーはあらゆる点で、WebSphere Virtual Enterprise の他の場所で稼働する Java™ EE アプリケーションに定義できるポリシーと同じく強固なものであり、既存のトランザクション・クラスと実動クラスを使用することも、新しいクラスを作成することもできます。

この記事では、「helloworld」という名前の単純な PHP ベースの WebSphere sMash アプリケーションを例に、このアプリケーションのインスタンスをいくつか作成し、汎用サーバー・クラスターとそれに関連付けるルーティング・ポリシーを定義するプロセスについて説明します。そして ODR をテストして、リクエストが正しくルーティングされることを確認します。この例で使用する環境は、Microsoft® Windows® 32-bit プラットフォーム対応の WebSphere Application Server V6.1.0.17 をベースに WebSphere Virtual Enterprise V6.1.0.3 がインストールされているという構成です。


Hello World

WebSphere Virtual Enterprise 側のセットアップに入る前に、WebSphere sMash 側について検討することから始めましょう。このPHP ベースの Hello World アプリケーションは、index.php という 1 つの Web ページだけで構成されます。リスト 1 に、index.php ファイルのソースを記載します。

リスト 1. index.php のソース
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Hello World!!!</title>
<style type="text/css">
@import "/dijit/themes/soria/soria.css";
@import "/dojo/resources/dojo.css";
</style>
<script type="text/javascript" src="/dojo/dojo.js"  djConfig="parseOnLoad: 
	true"></script> 
<script type="text/javascript">dojo.require("dojo.parser");</script>
</head>
<body class="soria">
<h1>Welcome to PHP Hello World</h1>
<hr>
Brought to you in part by, IBM WebSphere sMash (Silverstone)
<br><br><br>
<?php echo "This request (" . $_SERVER['REQUEST_URI']  . ") was serviced by 
" . $_SERVER['SERVER_NAME'] . ":" . $_SERVER['SERVER_PORT']; ?>
</body>
</html>

このコードを実行すると、図 1 のような出力が表示されます。

図 1. index.php の出力例
index.php の出力例

ポート 10080 をリッスンするように zero.config の構成値を変更し、/hw のコンテキスト・ルートを構成すること以外、AppBuilder ツールを使って新しい WebSphere sMash アプリケーションを作成するときに空白のアプリケーションに対して加える変更はありません。アプリケーションを完全に機能するスタンドアロンのアプリケーションとしてデプロイするにも、AppBuilder GUI に用意された Package オプションを使用すればよいだけです。Package オプションには AppBuilder のメイン画面からアクセスすることができます。図 2 のマウスの矢印が指している Package アイコンをクリックすると、図 3 の画面が表示されます。

図 2. AppBuilder の Package アイコン
AppBuilder の Package アイコン
図 3. スタンドアロン・ランタイム用アプリケーションのパッケージ化
スタンドアロン・ランタイム用アプリケーションのパッケージ化

Package ボタンをクリックすると、ファイル・システムの太字で示されたパス (図 3を参照) に .zip ファイルが生成されます。このファイルは、WebSphere sMash がサポートするランタイム・プラットフォームであればどのプラットフォームに移動して解凍しても、実行することができます。


WebSphere Virtual Enterprise でのクラスターのセットアップ

テスト対象の WebSphere sMash アプリケーションが用意できたので、後はこのアプリケーションを「デプロイ」して起動するだけです。

  1. WebSphere sMash AppBuilder ツールによって取得した .zip ファイルを、テスト・サーバーの新しいディレクトリーに解凍します。ここに記載する例では、アプリケーション・インスタンスはポート 10080 および 10081 で実行されるため、どのポートでアプリケーションが実行されているかを追跡しやすいディレクトリー構造に .zip ファイルを解凍してください。図 4 に、この例でのディレクトリー構造を示します。

    図 4. ディレクトリー構造の一例
    ディレクトリー構造の一例
  2. それぞれのポート番号が名前として付けられたフォルダー (10080 フォルダーと 10081 フォルダー) の下に helloworld フォルダーがありますが、このフォルダーは各ポート番号のフォルダー内で .zip ファイルを展開すると作成されるディレクトリーです。10081 フォルダーでアプリケーションの .zip ファイルを解凍したら、アプリケーションのディレクトリー構造に含まれる zero.config ファイルにアクセスしてください。これは、アプリケーションがリッスンするポートを 10080 から 10081 に変更する必要があるためです (作成したディレクトリー構造に一致させるため)。それには、C:\u\WebSphere\zero\ports\10081\helloworld\config に置かれた zero.config ファイルで以下の行を変更するだけで済みます。

    /config/http/port = 10080
    変更後: /config/http/port = 10081

    これで、アプリケーションを起動すると、アプリケーションは送られてくる HTTP リクエストをポート 10080 および 10081 でリッスンするようになります。

  3. 次に、デプロイメント・マネージャーで WebSphere Virtual Enterprise のセルに対して汎用サーバー・クラスターの定義を作成する必要があります。汎用サーバー・クラスター構成パネルにアクセスするには、管理コンソール左側の Servers リストを展開し、Generic Server Clusters を選択してください (図 5を参照)。この操作によって、図 6 の画面に WebSphere Virtual Enterprise のセルに対して既に構成済みの汎用サーバー・クラスターの定義が一覧表示されます。

    図 5. 管理コンソールの Generic Server Clusters オプション
    管理コンソールの Generic Server Clusters オプション
    図 6. セル内の汎用サーバー・クラスターのリスト
    セル内の汎用サーバー・クラスターのリスト
  4. New ボタンをクリックして新しい定義を作成し、クラスターの名前を入力します。この例での名前は HelloWorld_sMash_Cluster です。これで Apply ボタンをクリックすると、図7 のようなパネルが表示されます。

    図 7. HelloWorld_sMash_Cluster 定義の作成
    HelloWorld_sMash_Cluster 定義の作成

    重要: 同じホストに汎用サーバー・クラスターの複数のメンバー・サーバー表現を作成することを計画している場合には、サーバーごとに「server」という名前のカスタム・プロパティーを作成する必要があります。このプロパティーには任意の値を設定できますが、セル内で一意に決まる値でなければなりません。

  5. 今度はこのクラスターに、実際のメンバー定義を追加する必要があります。メンバー定義を追加するには、Additional Properties の下に表示されている Portsリンクをクリックします。次のパネルでは、このクラスター内にあるサーバーのポート番号リストが空の状態で表示されるので、新しいエントリーを作成するために New ボタンをクリックします。表示されるパネルに、WebSphere sMash アプリケーションを実行するサーバーのホスト名と、インスタンスに対して構成済みのポート番号を入力します。図 8 に示しているのは、このテスト環境での構成です。このサーバー表現は、ポート 10080 でリッスンするように構成した WebSphere sMash アプリケーション・インスタンスに相当します。ポート 10081 に構成したもう一方のアプリケーション・インスタンスに対しても同じ作業を行ってください。

    図 8. ポート 10080 の作成
    ポート 10080 の作成

    前述のとおり、2 つのアプリケーション・インスタンスは両方とも同じホストで実行することになるので、汎用サーバー・クラスターに定義するメンバーごとにサーバー・カスタム・プロパティー (ホスト/ポート定義) を構成する必要があります。図 9 は、「server」のカスタム・プロパティーの例です。このプロパティーには、セル内で一意に決まる値である限り、任意の値を設定して構いません。

    図 9. サーバー・カスタム・プロパティー
    サーバー・カスタム・プロパティー
  6. 最後に、ポート 10081 で実行中のアプリケーションを表現するために、汎用サーバー・クラスターにもう 1 つのサーバー定義を作成します。最初のサーバーと同じく、この表現にも必ずサーバー・プロパティーを追加してください。

  7. すべての変更を保存し、その内容を (手動または自動で) セルと同期させます。以上のステップが完了すると、汎用サーバー・クラスターの一覧に新しい汎用サーバー・クラスターが表示されているはずです (図 10 を参照)。

    図 10. 正常に作成された新規汎用サーバー・クラスター
    正常に作成された新規汎用サーバー・クラスター

これまでの手順で、WebSphere sMash アプリケーションがデプロイされ、WebSphere Virtual Enterprise に新しい汎用サーバー・クラスターが構成されました。ODR を介してリクエストを WebSphere sMash アプリケーションにルーティングできるようにするためには、最後のステップとして、ODR にルーティング・ポリシーを定義する必要があります。

  1. まず始めに、リクエストをルーティングするための ODR 定義までナビゲートします。この例での ODR の名前は、ODR01 です。新規ルーティング・ポリシーの構成を開始するには、On Demand Router Settings という見出しの下にある Generic Server Cluster Routing Policies リンクをクリックします。図 11 に、この Generic Server Cluster Routing Policies リンクが表示されている場所を示します。

    図 11. 汎用サーバー・クラスターのルーティング・ポリシーの構成
    汎用サーバー・クラスターのルーティング・ポリシーの構成
  2. 次のパネル (図 12) では、Work classes for HTTP requests を展開し、New ボタンをクリックして、この例の helloworld アプリケーションに固有の作業クラスを新規に作成します。新しい作業クラスには、何か意味のある名前を付けてください。図 12 に示されている新規作業クラスには、HelloWorld_WC という名前が付けられています。

    図 12. HelloWorld_WC 作業クラスの作成
    HelloWorld_WC 作業クラスの作成
  3. HelloWorld_WC 作業クラスの定義を展開して、ポリシー基準を表示します (図 13 を参照)。ポリシー定義の URI patterns セクションに、/hw/* というパターンを追加してください。これは、この ODR に到達したリクエストがこの URI パターンと一致する場合にポリシーが成立することを意味します。

    図 13. HelloWorld_WC 作業クラスのルーティング・ポリシー基準
    HelloWorld_WC 作業クラスのルーティング・ポリシー基準
  4. 仮想ホストの構成は、WebSphere sMash アプリケーションがリッスンする 2 つのポート番号を含めるようにはなっていませんが、こうした構成内容は default_host 仮想ホストの定義で指定することになるので、ポリシーの仮想ホスト・オプション (For virtual host) には必ず default_host を選択してください。そして最後にこのポリシー定義の If no routing rules apply セクションで、アクションを Permit Routing To に指定します。これを指定しない場合は、Permit routing with affinity to オプションが選択されます。このディレクティブが ODR に対して指定するのは、受信したリクエストの処理方法です。ここではリクエストがルーティングされることになるアクションを選択したので、リクエストの送信先とするターゲット・クラスターまたはサーバーを指定する必要があります。前に作成した汎用サーバー・クラスターを選択してください。図 13 の例では、「HelloWorld_sMash_Cluster」という名前の汎用サーバー・クラスターが選択されています。

  5. すべての変更および追加作業が完了したら、ルーティング・ポリシー構成パネルの先頭までスクロールして、Apply をクリックして変更内容をすべて保存し、変更をセル内のノードと (この場合も手動または自動で) 同期させてください。


テスト

これまでの手順で、汎用サーバー・クラスターを作成し、デプロイした WebSphere sMash アプリケーションにリクエストをルーティングするためのポリシーを定義しました。これでいよいよ、今までの作業内容をテストすることができます。

まずは、WebSphere sMash アプリケーションを起動するところから始めます。コマンド・プロンプト (シェル・セッション) で、前に作成した ports/10080 ディレクトリー構造の配下にある helloworld ディレクトリーまでナビゲートします。アプリケーションを起動するには、このディレクトリーで zero start というコマンドを入力します。コマンドの実行からコマンド・プロンプトに制御が戻るのを待って、図 14 に示すような出力が表示されることを確認します。

図 14. WebSphere sMash アプリケーションの起動
WebSphere sMash アプリケーションの起動

ports/10081 ディレクトリーにあるもう 1 つの helloworld アプリケーションに対して zero start コマンドを繰り返します。両方のアプリケーションが実行中になったら、汎用サーバー・クラスターのルーティング・ポリシーが構成されている ODR インスタンスを開始します。

この例では、1 つの ODR インスタンスに対してのみルーティング・ポリシーを構成しましたが、このポリシーを設定した複数の ODR を構成することも可能です。ODR が起動してリクエストを処理できる状態になったら、ブラウザーを開いて http://<odr_hostname>:<odr_proxy_port>/hw までナビゲートしてください。

すると一瞬のうちに、ブラウザーには以前と同じ出力 (図 1) が表示されるはずです。これで間違いなく、ルーティング・ポリシーは意図したとおりに機能していることになります。なぜなら、ODR を介して /hw コンテキスト・ルートを要求したのに対し、適切なルーティング・ポリシーが作動し、HelloWorld_sMash_Cluster に対して構成した2 つのエンドポイントのうちの 1 つにリクエストが送られたからです。同じリクエストを ODR を介してもう一度送出すると、ポート 10081 でリッスンする WebSphere sMash アプリケーションからのレスポンスが表示されます。

図 15. ODR をプロキシーとして介したポート 10081 のアプリケーションからのレスポンス
ODR をプロキシーとして介したポート 10081 のアプリケーションからのレスポンス

ルーティング・ポリシー定義で Permit routing with affinity to ではなく Permit routing to オプションを選択した場合、URL を要求し続けると、ODR は 2 つのサーバーに交互にリクエストを送信します。アフィニティーを使用してルーティングするように選択した場合には、ODR を介してアクセスした最初のアプリケーション・インスタンスにリクエストの送信先が固定されることになります。

ポート 10080 で実行中の WebSphere sMash アプリケーションを停止し、それから ODR でこの URL を再試行すると、10080 ポートのアプリケーションが再び使用できるようになるまで、ポート 10081 のアプリケーションにのみリクエストがルーティングされることがわかります。これはつまり、WebSphere Virtual Enterprise で ODR を介してアクセスできるサーバーのクラスター化グループの作成に成功したということです。


まとめ

この記事で説明したのは、新しく開発した IBM WebSphere sMash アプリケーションをインフラストラクチャー・リソースにデプロイしなければならないというシナリオです。このシナリオでは、さまざまな選択内容に応じてアプリケーションをデプロイした後、WebSphere が管理するセル環境には含まれないアプリケーションであるにもかかわらず、IBM WebSphere Virtual Enterprise のアセットを利用してアプリケーションへのアクセスを可能にすることができました。これはつまり、汎用サーバー・クラスターを使用すれば、ほとんど無制限の数の HTTP スタイルのエンドポイントを WebSphere Virtual Enterprise のアセットとして表し、専用に設定されたルーティング・ポリシーによって、これらのエンドポイントでのリクエストを対象にできるということです。さらに、汎用サーバー・クラスターのサービス・ポリシーを定義し、WebSphere Application Server (またはその他のミドルウェア) クラスターの場合と同様に、On Demand Router の能力を活用してクラスターへのリクエストの量を調節することも可能です。


謝辞

この記事のレビューに時間を割いてくださった以下の方々に感謝します。

  • WebSphere Virtual Enterprise Architecture and Development の Ann Black 氏
  • WebSphere Extended Development の Ben Parees 氏
  • TechWorks Americas の WebSphere IT スペシャリスト、Nitin Gaur 氏

参考文献

コメント

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, Web development
ArticleID=357322
ArticleTitle=WebSphere sMash を WebSphere Virtual Enterprise と組み合わせて使用する
publish-date=11122008