Chipstar Lightのメモ

Silverlight3

• ブラウザにプラグインをAdd-onする事によって動作する
• JavaScriptで開発できる
• Visual C#やVBでも開発できる
  • だからと言って、.NET Framework上で動くものではない
    • クライアント環境に.NET Frameworkは必要ではない
  • ブラウザプラグインに含まれる、Silverlight用の.NET Frameworkのサブセットを利用して動く
    • .NET Framework CLRとは似て非なるものである、Silverlight CoreCLRで動く
    • つまり「.NET 互換言語を使用して Web クライアントのプログラムを記述できる」という事
• Microsoft Visual Studio+Microsoft Expression Blendで開発するのが一般的

• Sliverlight用の.NET言語向けランタイム
• .NET Frameworkとは別物
  • .NET Framework向けに作成した、DLL（クラスライブラリ）はSilverlightアプリケーションからは利用できない

• 基本的にUTF系しか扱えません。
  • UTF-8 UTF8Encoding
  • UTF-16 UnicodeEncoding (little-endian)
  • UTF-16BE UnicodeEncoding (big-endian)
  • UTF-16LE UnicodeEncoding (little-endian)

• Encodingを自分で実装すればShift_JISなども使えるが、非現実的

何もせずにSilverlightモジュールが配置されている場所と異なるサーバーと通信をしようとすると、SecurityException」が発生する。
ドメイン間通信させるためにはセキュリティ上の設定が必要。
設定方法は次の２つのうちのどちらか

• 設定方法１:Silverlight クライアント アクセス ポリシー ファイル (clientaccesspolicy.xml)
  • clientaccesspolicy.xmlファイルをアクセスするドメインのルート直下に配置

設定例

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
   <cross-domain-access>
      <policy >
         <allow-from http-methods="*">
            <domain uri="http://www.xxxx.com"/>
         </allow-from>
         <grant-to>
            <resource path="/" include-subpaths="true"/>
         </grant-to>
      </policy>
   </cross-domain-access>
</access-policy>

• 設定方法２：Adobe Flash ドメイン間ポリシー ファイルのサブセット (crossdomain.xml)
  • crossdomain.xmlファイルをアクセスするドメインのルート直下に配置

設定例

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">  
<cross-domain-policy>  
    <site-control permitted-cross-domain-policies="all" />  
    <allow-access-from domain="*" />  
</cross-domain-policy> 

• テストページを使ったデバッグ起動時の注意
  • サーバーサイドをEclipse+任意のAPサーバー+Javaで開発する場合、クライアントサイドはVisualStudioでテストページを作成してデバッグすると、実運用時はドメイン間通信じゃなくても、デバッグ時は必然的にドメイン間通信になる。
  • この場合、上記いずれかのドメイン間ポリシーファイルが必要になるが、なぜかclientaccesspolicy.xmlファイルはうまく動作しなかった。
  • crossdomain.xmlなら問題なく動作している。

SLアプリを作る上で、クライアントはSL、サーバーはASPやJavaなんて事はよくある話。
そんなときに、サーバーサイドでセッション管理をする場合は、やはりクッキーを使う。
そのクッキーを扱う方法は、次の２つの方法がある。

HttpWebRequestを生成する前に、以下のコードを記述しておくと、WebRequest.Create(url)メソッドは、ブラウザのHTTP処理を利用するHttpWebRequest実装インスタンスを返す。
このインスタンスを利用して通信を行うと、ブラウザのクッキー管理機構が動作して、サーバーサイドは通常のブラウザアプリと同じような形でセッション管理ができる。

WebRequest.RegisterPrefix("http://", WebRequestCreator.BrowserHttp); // このコード
HttpWebRequest request = WebRequest.Create(url) as HttpWebRequest;

WebRequest.RegisterPrefixの第二引数に"WebRequestCreator.BrowserHttp"を指定することがポイント。
実は、何もしなくてもデフォルトの設定は"WebRequestCreator.BrowserHttp"になっている。
※この方法を使うと、HttpWebRequestのCookie にはアクセスできない。Cookie にアクセスしようとすると、例外がスローされる。

HttpWebRequestを生成する前に、以下のコードを記述しておくと、WebRequest.Create(url)メソッドは、ブラウザに依存しない独自のHttpWebRequest実装インスタンスを返す。
このインスタンスは、以下の処理を実装したい場合に用意されている。

• GET および POST 以外の HTTP メソッドを使用する場合。
• 応答のステータス コード、本文、およびヘッダーを使用する場合。
• SOAP サービスや REST サービスへのメッセージなど、HTTP XML 要求を送信する場合。
• 手動で Cookie を管理する場合。

これにより、Cookie管理を独自に実装する事ができる。

WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp); // このコード
HttpWebRequest request = WebRequest.Create(url) as HttpWebRequest;

WebRequest.RegisterPrefixの第二引数に"WebRequestCreator.ClientHttp"を指定することがポイント。
Cookieの管理方法は、通常の.NET Frameworkを利用する場合と同様に、HttpWebRequestに関連付けるCookieContainerを独自に永続化する形で行う。

SilverlightはHTTP 処理を、ブラウザーとクライアントのどちらで行うかを指定できるようになっている。
この指定を行う処理が、上記WebRequest.RegisterPrefixになる。
既定で HTTP 処理を実行するのはブラウザーなので、デフォルトでは、BrowserHttpになっている。
つまり、

• BrowserHttpはブラウザ上でSLアプリを利用する場合の設定
• ClientHttpは、ブラウザ外部でSLアプリを利用する場合の設定

となる。

MSDN: CoreCLR を使用して Silverlight のプログラムを記述する
MSDN: Silverlight による HTTP 通信とセキュリティ
yoshiweb.NET-blog: カスタムポリシーファイル crossdomain.xml について
MSDN: WebRequest.RegisterPrefix メソッド

InfoQ: SilverlightとJavaのインターオペラビリティ