木村さんへ bodyです。
ご教授どうもありがとうございます。 当初の疑問は解決しました。 本日、Cookie実装のテストも完了し、 別のWebServiceライブラリまでも動作を確認できました。 このたびは、ありがとうございました。 > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
