→ASP.NET関連
※注:ここで書いてる話はVisual Studio .NET 2003と2005の話が混ざっています。後々整理しつつ2005中心にシフトします
参考Web†
プロジェクト作成†
- 【VS.NET 2005の場合】プロジェクトの新規作成→Webサイト→ASP.NET Webサービス
- SP1以後は普通のプロジェクトとしても作成が可能になった模様。(2008.6.12)
- 【VS.NET 2003の場合】プロジェクトの新規作成→プロジェクト→Webサービス
.asmxファイル†
- ただしクラスがプリコンパイル済みの場合はソースは要らない。
サービス用のクラス†
- System.Web.Services名前空間をインクルードする
- サービスのクラスは WebService クラスから派生させる
- ただしWebServiceクラスの継承は必須ではない
- パブリッククラスである必要がある
- サービス用メソッドには属性として[WebMethod]をつける
Webサービス(もしくはSOAP)の名前空間とは?†
- ここでいう名前空間とは、SOAPで使うXMLの名前空間
- 要はそのサービスを他のサービスと区別できれば良いので被らなそうな名前ならなんでも良いと思われる。
「規定の名前空間とは?」†
どうやって変更する?†
複数端末から同時に呼ばれたときの動作は?†
- 再入は起きるのか?→起きません
- 2つの呼び出しは同じプロセスの2つのスレッドで動いているが、サービス用クラスが別のインスタンスになっている模様。
- したがって、クラスにstaticなメンバを持つことで複数の処理で情報を共有できる。
クライアント側から参照するサービスのURL変更†
WSE(Web Services Enhancements)†
基礎知識†
FAQぽいこと†
- SoapContextクラスがインテリセンスに出てこないんだけど?
- Microsoft.Web.Services.dllってどこにあるの?
- →WSEを別途ダウンロードしてきてインストールしないと無い。最新版は3.0(2008.5.7時点)
- インストールすれば通常は C:\Program Files\Microsoft WSE\v3.0 に出来る
- Webサービスから Microsoft.Web.Services3を参照する
- using Microsoft.Web.Services3;する
- 注意:WSE 3.0は ASP.NET 2.0で動作するのが前提
- クライアント側にもWSE3.0をインストールしないといけないの?
- 基本的にはその通り
- ただし、クライアント側がClickOnceアプリならば、Microsoft.Web.Services3.dllをアプリと一緒にダウンロードするようにすれば、クライアント側へのWSEインストールは不要。そのためには、参照設定からSystem.Web.Services3の参照プロパティを表示し、「ローカルコピー」をfalseからtrueにすれば、ClickOnceアプリと一緒に配布されるファイルに含まれるようになる。
- その他、.msiでセットアップさせることも可能な模様(未確認)ヘルプの「Deploying a WSE-Enabled Application 」のページを参照のこと
- サービス側プロジェクトの「WSE Settings 3.0...」から出てくるダイアログの「General」タブの「Enable Microsoft Web Services Enhancement Soap Protocol Factory」のチェックをオンにしろってヘルプに書いてあるんだけど、チェックボックスが無効になっててオンにできないではないか!?
- 最初にプロジェクトを作るときに「新規作成」−「プロジェクト…」の下にある「ASP.NET Webサービス アプリケーション」から作った奴だとこうなってしまう模様。
- このプロジェクトはVisual Studio .NET 2005 の SP1から追加されたものらしい(2003から2005になるときにWebサービスプロジェクトはWebサイト扱いになってしまったが、これが不評だったらしい)
- 「新規作成」−「Webサイト…」の下にある「ASP.NET Webサービス」から作ったプロジェクトならチェックボックスを触ることができる。
- この現象の原因は不明。おそらくWSEはWebサイトとしてのWebサービスプロジェクトしか想定してないと思われる。そもそも2種類のWebサービスプロジェクトで具体的に何が違うのか不明。app.configの有無など、ファイル構成が微妙に異なるようだが…
添付ファイルのサイズ上限について†
WSE3.0でMTOMを使うには?†
- 所定の設定をした上で、普通にByte配列を引数なりクラスメンバにしてやりとりすれば良い。
- 参考:MTOMエンコーディング
- サーバ側:ヘルプの「How to: Enable a Web Service to Send and Receive Large Amounts of Data 」を参照(英語)
- クライアント側:ヘルプの「How to:Send and Receive Large Amounts of Data to and from a Web Service」を参照
- RequireMtomとは?
- WebServicesClientProtocolクラスのRequireMtom プロパティのこと。
- これをTRUEにするとメッセージがMTOMエンコーディングされる
- WebServicesClientProtocolクラスは、WSEを使う場合のクライアントプロキシクラスの基本クラス。Web参照を作成するとこのクラスからクライアントプロキシが生成される。
- 生成されたプロキシクラスはHogeHogeWse みたいな名前のクラスになる。末尾にWseのつかない通常版(WSEなし版)も同時に作られるようだ。両者は持っているメソッドは同じだが継承元のクラスが異なる。MTOM使うなら当然Wse版の方を使う
- クライアントとなるプログラムからプロキシクラスのメソッド(Webサービス側処理)を呼び出す前にこのプロパティを明示的にTRUEにしておく必要がある。
- ASP.NETリクエストのサイズ上限4MBの問題についてはMTOMを使っていても同じです
WSE910の例外について†
- サーバとクライアントの時計の時刻が5分以上ずれていると、Webサービスを呼んだときに以下のようなメッセージの例外が発生する
WSE910: An error happened during the processing of a response message,
and you can find the error in the inner exception. You can also find
the response message in the Response property.
- Inner Exception:
An error was discovered processing the <Security> header
- Inner Inner Exception:
"WSE066: Timestamp is expired.
This indicates a stale message but may also be caused by lack of
synchronization between sender and receiver clocks.
Make sure the clocks are synchronized or use
the timeToleranceInSeconds element in the microsoft.web.services3
configuration section to adjust tolerance
for lack of clock synchronization.
- WSEをかまさない通常のWebサービスであればこの問題は発生しない
- この仕様はセキュリティ上の理由で設けられているものらしい
- 参考URL:http://www.developmentnow.com/g/16_2006_4_0_0_729576/WSE3-Error-WSE910.htm
- As for the time synchronizing, it
is due to the requirement of the message security and reliability. For WSE
message it follows the WS-I BSP spec. The SOAP message
transfered(especially for those security specific message), it will
contains timestamp and a lifetime cycle, this prevent other malicious users
from performing replay attack. However, use such timestamp and message
lifetime mechanism require both client-server utilize the same time system,
usually it is the internet time system, and for our scenario, the client
and server boxes should synchronize their system clock:
- 参考:WS-I BSP(Basic Security Profile) Interoperability GUidance
- Message Age and Clock Skew
- The timestamp within a secure message is often critical to an effective replay detection strategy because it can be used to limit the number of items that need to be cached when checking for a replay attack.
- WSE includes a setting that determines how long a message is valid for after creation. The <defaultTtlInSeconds> element specifies the number of seconds after creation that every outgoing SOAP message is valid. The default value is 5 minutes, but the WS-I SCM architecture document recommends that this is set to 900 seconds (15 minutes).
- To reject messages reliably, you must ensure that clocks on the sending and receiving servers are synchronized. Clocks of client and server computers must be synchronized to prevent messages from being rejected unduly. However, because not all vendors have the ability to ensure that their clocks are synchronized with Internet time services, WSE 3.0 has a clock skew setting that allows you to specify a tolerance factor for time synchronization. The <timeToleranceInSeconds> setting corresponds to the acceptable time difference (clock skew) between the sender and the recipient of a message. By default, it is configured to 300 seconds or 5 minutes. However, you can change this value in the service's Web.config file if you require a different value. The WS-I SCM Architecture document recommends that this is set to 900 seconds (15 minutes).
- The <timeToleranceInSeconds> setting is shared, so changing it may also affect security token managers and other policy assertions operating in the same virtual directory as the service.
- While the clock skew function can help with interoperability, reducing the need for clock synchronization effectively reduces the security of your environment. Therefore, wherever possible, you should use Internet time services to ensure that your clocks are synchronized and remove the need for significant clock skew.
- ヘルプ"<timeToleranceInSeconds> Element "のページより抜粋
- Use the <timeToleranceInSeconds> element when there is a clock difference between the SOAP message sender and receiver.WSE invalidates SOAP messages that have expired or are created in the future during its message validation phase. --That is, during message validation, WSE verifies that the value of the <Created> element within the timestamp is in the past and that the <Expires> element of the timestamp is in the future. When there is a difference between the two clocks such that the sender's clock is ahead of the receiver's clock, the <Created> element within the timestamp might be in the future in relation to the receiver's clock. In that scenario, WSE would reject the SOAP message during its validation phase.
- A similar scenario exists for expired security tokens. To alleviate this problem, add an <timeToleranceInSeconds> element to the configuration file for the receiver and set its value to the number of seconds that will account for the difference between the clocks on the sender's and receiver's computers. The default time buffer is five minutes.
- 参考URL: