ASP.NETでのWebサービス開発に関するメモ

→ASP.NET関連

※注：ここで書いてる話はVisual Studio .NET 2003と2005の話が混ざっています。後々整理しつつ2005中心にシフトします

参考Web†

• Visual Studio .NETとWebサービス
• ASP.NET Webサービスが機能する方法
• クライアントサイド・スクリプトからXML Webサービスを非同期呼び出しするには？（サーバサイド編）［2.0のみ、C#、VB］
• Webサービスパフォーマンスの向上 (ひどい翻訳！）
• Webサービスクライアントの作り方(.NET)
• ASP.NET クイックチュートリアル XML Webサービスとは

プロジェクト作成†

• 【VS.NET 2005の場合】プロジェクトの新規作成→Webサイト→ASP.NET Webサービス
  • SP1以後は普通のプロジェクトとしても作成が可能になった模様。(2008.6.12)
• 【VS.NET 2003の場合】プロジェクトの新規作成→プロジェクト→Webサービス

.asmxファイル†

• .asmxファイル 　テキストファイル

• Webサービスには先頭のディレクティブとして以下の記述が必要

  <%@ WebService Language="C#" Class="<クラス名>" %>

• ソースが別になっている場合はこうなる

  （例）
  <%@ WebService Language="c#" Codebehind="SrvTst.asmx.cs" Class="Test.SrvTest" %>

• ただしクラスがプリコンパイル済みの場合はソースは要らない。

サービス用のクラス†

• System.Web.Services名前空間をインクルードする
• サービスのクラスは WebService クラスから派生させる
  • ただしWebServiceクラスの継承は必須ではない
• パブリッククラスである必要がある
• サービス用メソッドには属性として[WebMethod]をつける

Webサービス（もしくはSOAP)の名前空間とは?†

• ここでいう名前空間とは、SOAPで使うXMLの名前空間
• 要はそのサービスを他のサービスと区別できれば良いので被らなそうな名前ならなんでも良いと思われる。

「規定の名前空間とは?」†

• 最初に作ったのを実行する時に出てくるメッセージの意味は？

  ・この Web サービスは、http://tempuri.org/ を既定の名前空間として使用しています。
  ・XML Web サービスをパブリックにする前に、既定の名前空間を変更してください。

  「XML Web サービス名前空間」を変更しないといけないらしい。

どうやって変更する?†

• → サービスのクラスの属性でセットする

  [WebService(Namespace="http://＜適当な名前＞/")]
  public class SrvTest : System.Web.Services.WebService
  {
  	public SrvTest()
  	{
  		//CODEGEN: この呼び出しは、ASP.NET Web サービス デザイナで必要です。
  	  InitializeComponent();
  	}
  	[WebMethod]
  	public string HelloWorld()
  	{
  		return "Hello World";
  	}
  }

複数端末から同時に呼ばれたときの動作は?†

• 再入は起きるのか？→起きません
• ２つの呼び出しは同じプロセスの２つのスレッドで動いているが、サービス用クラスが別のインスタンスになっている模様。
• したがって、クラスにstaticなメンバを持つことで複数の処理で情報を共有できる。

クライアント側から参照するサービスのURL変更†

• サービスクラスのUrlプロパティを変更する

  //サービスのURL WSDLのURLじゃなくてもＯＫな模様
  svc.Url = "http://www.hoge.net/hogeSvc/hogeSvc.asmx" 

• ヘルプにて「Web サービスの Url プロパティの設定 」を参照

WSE(Web Services Enhancements)†

• WSE Home@MS
• WSEのインストール
  • WSE 3.0 Download page
  • WSE 2.0 Download page
• 3.0を入れれば2.0は要らない

基礎知識†

• Web上ではWSE1.0に関する記事が多く見つかるのだが、これはもはや古い仕様になってしまっている模様(2008.5.7)
• Web Services Enhancements 1.0 for Microsoft .NET によるプログラミング
• Web Services Enhancements を使用したアタッチメント付きの SOAP メッセージの送信

• SOAPメッセージとファイル添付
  • DIME仕様、WS-Attachmentについて。
  • 古い仕様となりつつあるので今後はMTOMを使った方が良いと思われる

FAQぽいこと†

• SoapContextクラスがインテリセンスに出てこないんだけど？
  • →Microsoft.Web.Services(2|3).dllを参照しないとダメです

    例）
    using Microsoft.Web.Services3;
    ...
    SoapContext ctx = RequestSoapContext.Current;

• 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で動作するのが前提

• WSEのHelpファイルが見られないんだけど？
  • VISUAL STUDIO.NETのページの「HxS(Microsoft Compiled Help2)ファイルの使い方」を参照
  • 具体的に言うと、以下のページを参照して該当ファイルにチェック→更新ボタン→VS.NET再起動

    ms-help://MS.VSCC.v80/dv_vscccommon/local/CollectionManager.htm

• クライアント側にも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の有無など、ファイル構成が微妙に異なるようだが…

添付ファイルのサイズ上限について†

• WS-Attachmentのファイルサイズについて
  • WSEの標準設定では、4MBのサイズの制限があります。
  • もっと正確に言うと、ASP.NETのHTTPのリクエストメッセージのサイズ制限がデフォルトで4MBになっています。
  • これらは、Webサービスの構成ファイル(web.config)を編集することでもっと大きなサイズのファイルも扱えるように変更可能です。

    [ web.configの記述例 ]-----------
    <configuration>
      <system.web>
         <httpRuntime maxRequestLength="8000"
                      useFullyQualifiedRedirectUrl="true"
                      executionTimeout="45" />
       </system.web>
      <microsoft.web.services2>
        <messaging>
          <maxRequestLength>8000</maxRequestLength>
        </messaging>
        <diagnostics />
      </microsoft.web.services2>
    </configuration>

  • 上の構成ファイルは、8MBに上限を引き上げた例になります。
  • httpRuntimeとWSE2.0の２箇所を設定する必要があるのでご注意下さい。
  • もちろん、ファイルサイズが大きくなればなるほど、多くの処理時間が必要となり Webサービスの呼び出しがタイムアウトする恐れがでてきます。

• WSE3.0でMTOM使用の場合はconfigurationタグの記述が多少ことなる(ヘルプで「<maxMessageLength> Element」を参照)

  サイズを1MBにした例
  <configuration>
    <microsoft.web.services3>
      <messaging>
        <maxMessageLength value="1024" />
      </messaging>
    </microsoft.web.services3>
  </configuration>

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の例外について†

• サーバとクライアントの時計の時刻が５分以上ずれていると、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.

• 対策1:サーバとクライアントの時刻を合わせる
• 対策2:Web.Configで以下のような設定をする

    <microsoft.web.services3>
      <security>
       <timeToleranceInSeconds value="3600" /> 許容時間を秒数で指定する
      </security>
     </microsoft.web.services3>

  • この設定はサービス側だけでなく、クライアント側のapp.configでも指定する必要がある。サーバ側だけやっても効かないので注意。
  • app.config記述例

     <microsoft.web.services3>
       <messaging>
         <mtom clientMode="On" />
       </messaging>
       <security>
         <!-- defaultTtlInSeconds value="3600" /-->
         <timeToleranceInSeconds value="3600" />
       </security>
     </microsoft.web.services3>

  • timeToleranceInSecondsだけでなくdefaultTtlInSecondsも設定せよという説もあるようだが…確認した感じではtimeToleranceInSecondsだけ設定すれば良さそう
  • 上記WS-I BSPでは900秒=15分くらいの設定を推奨している。セキュリティ上あんまりゆるくしすぎるのも考え物

• ヘルプ"<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:
  • http://forums.msdn.microsoft.com/en-US/asmxandxml/thread/331de690-7496-40c5-9bd5-3926375d34ea/
  • http://geeknotes.wordpress.com/2007/03/21/more-wse-issues-timestamp-validation-and-clock-skew/

最新の50件