―BEA WebLogic Server編―
日本BEAシステムズ
プロフェッショナル・サービス
2001/3/30
| WebLogic Serverのセッション管理（基礎編） |
|
今回の内容
|
 1.WebLogic
Serverでのsession idの維持方法2.session
id関係のweblogic.properties3.URL
rewritingの使い方
|
「BEA WebLogic Server編」は、日本BEAプロフェッショナル・サービスのコンサルタントが持ち回りで執筆し、BEA WebLogic Server（以下WebLogic Server）のコンフィグレーションやJ2EEアプリケーション構築のTIPSを紹介していきます。
第1回目は WebLogic Serverにおけるセッション(HttpSession)の扱いについて解説したいと思います。
本稿におけるコーディングは、すべてJSPを前提に記述しています。また、WebLogic Server 6.0になって変更されている点については脚注の形で補足させていただきます。なお、本稿ではセッションとは何かといった説明や、セッションを扱うための基礎的なプログラミングの解説は割愛させていただきますのでご了承ください。
 |
1.WebLogic Serverでのsession idの維持方法 |
セッションとブラウザ（クライアント）との関連づけはsession idによって行われます。セッションに関与しているブラウザから来るリクエストには、何らかの方法でsession idが付いてきます。アプリケーションサーバは、この id からクライアントに関連づいたセッション・オブジェクト （HttpSession） を特定し、ServletやJSPへセッション・オブジェクトを供給します。ServletやJSPのAPIを通してセッションを扱う場合、session idの発行やセッション・オブジェクトの維持・管理はJ2EEのフレームワーク（を実装したアプリケーション・サーバ）が行ってくれます。
WebLogic Serverでは、下記のいずれかの方法でsession idを維持します。
(1)cookieによるsession idの維持
新しいセッションの最初のブラウザへのレスポンスと一緒に、そのセッションのidを保持するcookieが送り返されます。以降、ブラウザからのリクエストにはこのcookieが付随してきますので、サーバはsession
idを知ることができるわけです。このcookieの生成・維持はサーバによって自動的に行われます。
(2)URL rewriting によるsession idの維持
cookieが使えない環境（例えば携帯電話向けのコンテンツなど）では、cookieの代わりに URL rewritingと呼ばれる方法を使ってsession
idを維持します。簡単にいえば、URLの後ろにリクエスト・パラメータの形でsession idを埋め込む方法です。URLにsession idを埋め込むのは、レスポンスを生成するプログラム（ServletやJSP）の責任となります。URL
rewritingについての詳細は後述します。
|
2.session id関係のweblogic.properties |
WebLogic Serverでは以下のプロパティでsession idに関する設定を変更することができます。() 内はデフォルト値です(http://www.beasys.co.jp/weblogic/docs/admindocs/
http.html#session) (*1)。
|
|
|
|
3.URL rewritingの使い方 |
例えば、以下のURLへのアンカーを含むページをレスポンスとして返すとします。
|
|
URL rewritingを使用する場合は、このURLを次のように動的に変更しなければなりません。
<a href="/order/Submit.jsp?WebLogicSession= |
この “WebLogicSession”がsession idをサーバに渡すためのリクエスト・パラメータの名前で、“=”以降の
OmaIxZ228eN3gmewQSFaRUhnmQQRfmq27fWi6Q8qhdyI1hyDgU5G
がsession idです。このように、URLを書き換えてsession idを埋め込むのでURL rewriting と呼ばれています
( http://www.beasys.co.jp/weblogic/docs/classdocs/
API_servlet.html#128997)。
URL rewritingは以下のようなコーディングをしておくと半自動的に行うことができます。
|
|
HttpServletResponse#encodeURL(String url) メソッドは、cookieが使えるか否かを自動的に判別し、使えない場合は与えられたURLの後ろにsession idを埋め込んで返してくれます。cookieが使えるか否かの判定ですが、これはsession idをcookieから取得したか否か（つまり、request.isRequestedSessionIdFromCookie () == trueであるか否か）で行いますので、セッション開始時の最初のレスポンスを生成する際には常にURLへのsession idの埋め込みが行われます。
一般的には、上記のようなコーディングをすべてのURLについて行っておけば、cookieが使えないクライアントに対しても機能するアプリケーションを構築することができるわけです。ただし、URL rewritingを使用する場合はすべてのページを動的に生成する必要がある点に注意してください。セッションを維持する必要がある間は、ページの遷移の途中で静的なHTMLを挿入することはできないということです。この制限は、携帯電話向けの小規模なサイトではあまり問題にならないとは思います。
携帯電話向けのコンテンツといえば、URL rewritingを使用せざるを得ないにもかかわらず、URL 長に制限が設けられている場合があります。form入力項目もリクエスト・パラメータで渡すことを考えると、URL
はさらに長くなります。URL長の制限に触れそうな場合は、「2.session id関係のweblogic.properties」で説明したcookie.nameやsessionIdLengthのプロパティを短く設定することで回避することができます。
|
本稿に関するご質問やご意見は下記のメールアドレスまでお願いします。
|
||||||||||||||||||||||||||||||||
(*1) weblogic.propertiesではサーバに共通の値しか設定できませんが、web applicationのデプロイメント・ディスクリプタを利用できれば、web
applicationごとに異なる値を設定することができます。WebLogic Server 6.0 では、このようなセッション関係の設定はすべて
weblogic.xml(WebLogic Server 固有の web application デプロイメント・ディスクリプタ) で行うよう変更されています（http://www.beasys.co.jp/
e-docs/wls60e/programming/weblogic_xml.html）。
(*2) jsessionid というJ2EE準拠の名前に変更されています。
(*3) WebLogic Server は、数カ月に１度の割合でSP(サービス・パック)をリリースし、機能の追加やバグ・フィックスなどのマイナーバージョンアップを行います。また、Web上で公開しているマニュアル (http://www.beasys.co.jp/weblogic/docs/resources.html) も随時更新されています。ですから、そのうちSPで8bytesまで短くできるようになるかもしれませんし、マニュアルを更新して10bytesまでしか短くできないのが正式な仕様になるかもしれません。
(*4) マニュアルどおり、最短8bytesまで短くできます。
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
