To: bodyさんへ
木村です。
例えば、ロードバランシングによるサーバ分散への対応を考えています。
サーバより受け取ったCookieを使い続けることで、分散環境においても
特定サーバにのみ向かうよう仕向けるわけです。
（複数メソッドの実行で１オペレーション完了となるようなWebService
です）
上記例は、セッション管理が必要となるごく一般的な事例だと思います。
この場合「特別な意味を持つ」ので、やはりすべきではないのでしょうか？
そうではありません。
WebサービスのCookie値は、『業務ロジックとして意味を持たないIDのみに
限定すべきであって、Bodyさんの元々の質問にあったようにCookieに複数の
値を格納しようとしたり、その格納値に業務的な意味を持たせるような使い
方は、Webサービス的ではない』という意味です。前述のロードバランシング
の例も、乱数などのユニークなセッションIDがCookie値に格納されるだけで
実現可能な訳です。
また、axis間以外を考えた場合、Cookieによるセッション管理の動作は期待
するべきではないと考えてよいのでしょうか？
（例：Client axis / Server .Net）
（例：Client .Net / Server axis）とかです。
恐らく、かなり古いバージョンのランタイムでなければ、期待とおりに動作
すると思います。しかし、各種仕様としては、Cookieによるセッション管理が
必須項目でない以上、全てのクロスプラットフォームの相互接続性を保証する
のは難しいとは思います。安心するためには、利用するランタイムを決定して
自ら動作検証する必要があります。
宜しくお願いします。
---
Toshi <[EMAIL PROTECTED]>
On Wed, 30 Aug 2006, hayakawa wrote:
bodyです。
木村さんへ
返答ありがとうございます。
WS-Iにそういった記載がありますね。
その旨は理解しているつもりです。
一番bodyさんが知りたい点は、WebブラウザでのCookieのように複数
の意味ある値をWebサービスで送受信する方法だと思うのですが、それ
はすべきではない、という事になります。Webサービスでのセッション
管理とは、(特別な意味を持たない乱数的な)ユニークなIDをサーバと
クライアント間で送受信することにより、連続したWebサービス通信で
あることを示す、というハンドリングを指します。
例えば、ロードバランシングによるサーバ分散への対応を考えています。
サーバより受け取ったCookieを使い続けることで、分散環境においても特定サー
バにのみ向かうよう仕向けるわけです。
（複数メソッドの実行で１オペレーション完了となるようなWebServiceです）
この場合「特別な意味を持つ」ので、やはりすべきではないのでしょうか？
また、axis間以外を考えた場合、Cookieによるセッション管理の動作は期待する
べきではないと考えてよいのでしょうか？
（例：Client axis / Server .Net）
（例：Client .Net / Server axis）とかです。
--
hayakawa <[EMAIL PROTECTED]>
To: bodyさん
木村です。
まず、「通常のWebブラウジング」と「Webサービス」でのCookieの
利用方法には違いがあります。Webブラウザでの動作や仕組みについて
はご理解頂いているという前提として、「Webサービス」では
・Cookieを使ったセッション管理を試みても良いが、それが確実に
機能する保証はない
・Webサービスの正常動作のために、クライアントのCookie対応を
必須とすべきではない
・Cookieで転送される値が、クライアントにとって意味のある値を
利用すべきではない
という考えがあります。これは、Webサービスの根本的な考え方として
意味のあるデータはSOAPメッセージの中でやり取りすべきであって、
特定のトランスポートプロトコル(HTTPなど)に依存すべきではない、
という思想が強く影響しています。
Cookieは、HTTPプロトコルに蜜に依存している他、SOAPメッセージ
の外側でデータ交換する仕組みであることから言って、Webサービス界
では「異端」と言っても良いかも知れません。しかし、現実世界では
Cookieを利用したセッション管理が最も普及していて、確実な手法で
あるのも事実です。このため、AxisではCookieを利用したセッション
管理に対応しました。
セッション管理は、サーバ側とクライアント側双方が対応する必要
がありますが、Axisでは以下の変更が必要です。
・サーバ側
WSDD内のSessionスコープパラメタにより、スコープを設定
・クライアント側
「service.setMaintainSession(true);」によりCookieを受付ける
[EMAIL PROTECTED]
をご理解いただけるものと思います。
一番bodyさんが知りたい点は、WebブラウザでのCookieのように複数
の意味ある値をWebサービスで送受信する方法だと思うのですが、それ
はすべきではない、という事になります。Webサービスでのセッション
管理とは、(特別な意味を持たない乱数的な)ユニークなIDをサーバと
クライアント間で送受信することにより、連続したWebサービス通信で
あることを示す、というハンドリングを指します。
以上でご理解頂けたでしょうか？
---
Toshi <[EMAIL PROTECTED]>
On Mon, 28 Aug 2006, hayakawa wrote:
木村さん
bodyです。レスありがとうございます。
＃とりあえずＭＬが機能していて助かりました。
下記本文中で「Cookie認証」という言葉が用いられている
のですが、何を意図しているのかよく分かりません。
言葉足らずですみません。
Cookieを使ったセッションの管理です。
@ITサイトからの引用ですが、
-----------------------------
セッションを利用できるようにするには、Webブラウザが持っている
機能をWebサービス・クライアントにおいても実現することです。
いちいち記述することは大変面倒ですが、Axisには便利なAPIが用意
されているため、大変容易にセッションを利用することができます。
Axisには「setMaintainSession()」メソッドが用意されています。
このメソッドはServiceインスタンスに対して実行することで、
Cookieを扱えるようにしてくれるものです。利用方法は、次のように
Webサービス・クライアントプログラムを変更するだけです。
-----------------------------
とあります。
その回答として、
service.setMaintainSession(true);
をクライアントにて記述すればよい、との記載例なのですが、
例えば、
・１サーバに対し１Cookieの保持なのか
・Cookieの容量はどのくらいまで大丈夫なのか
などの疑問があります。
このように色々懸念材料があるにも関わらず、
setterひとつで簡単に実装できてしまうの？ということです。
とりあえず前提として、Cookieでのセッション管理は可能であると
いう認識でよいのでしょうか？
環境は、
◆Client
axis1.1
J2SE1.4
◆Server
WebSphere 5.1 or 6
で行っています。
＃現状Cookieセッション管理無しでWebServiceは動作しています。
＃今手元にコードがないので、用意しておきます。
よろしくお願いします。
--
hayakawa <[EMAIL PROTECTED]>
To: bodyさん
はじめまして。
木村と申します。
下記本文中で「Cookie認証」という言葉が用いられている
のですが、何を意図しているのかよく分かりません。
具体的にどのようなことを実現したいのかにつてもう少し
詳しく教えていただくことはできますでしょうか？
よろしくお願いします。
---
Toshi <[EMAIL PROTECTED]>
On Sat, 26 Aug 2006, hayakawa wrote:
はじめまして。bodyと申します。
axis1.1を用いたWebサービスにおいて、Cookie認証の情報を探しています。
http://www.atmarkit.co.jp/fjava/rensai2/wbsrvic05/wbsrvic05_3.html
上記URLにおいて、axisのセッションについて書かれていますが、
このようにクライアントに、
service.setMaintainSession(true);
のコードを埋め込むだけで、認証が行われるのでしょうか？
（ClientにCookieを受け取ったり、維持するようなハンドリングは不要なのか？）
また、これはサーバクライアント共にaxisを用いた場合にのみ保障されるもので、
例えサーバ側からCookieが発行されていたとしても、サーバがaxis以外のエンジ
ンを使用している場合には動作しないものなのでしょうか？
参考情報ありましたら、ご提供ください。
--
<[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
