「Windows Azureのクラウド開発」って、どんな感じなの？

ここの記事
マイクロソフトが次期Visual Studio 2010のベータ版を公開
.NET Framework 4.0 Beta 1も
http://codezine.jp/article/detail/3972
によると（以下斜体は上記サイトから引用）


　Visual Studio 2010は、現行のVisual Studio 2008に続く次期統合開発環境。ユーザーインターフェイスの改良や、並列プログラミングのサポートなど機能の強化が図られている。また、 JavaScriptによるウェブ開発や、Windows Azureのクラウド開発といった新しいアプリケーション環境にも柔軟に対応している。


ってあるけど、Windows Azureのクラウド開発って、どんな感じなの？

P.S ちなみに、その「Visual Studio 2010のベータ版」は、
http://www.microsoft.com/japan/msdn/vstudio/2010/
にあるみたい（ただし英語版）。

クラウド＆ユビキタス環境において、課金のための利用履歴情報はどこに持つのがいい？

　前に、ユーザーから見て、あちら側（サーバー側）がどうでもいいのが、クラウド
　　　　こちら側（クライアント側）が何でもいいのがユビキタス
　という話を書きました。

　で、このとき、いろんな端末（ユビキタス側）で、サーバーの情報（クラウド側）を利用し、
　その利用履歴を（課金するためなどで）どこかに持つつとした場合、
　ユビキタスとクラウド、そこでも処理、保存が可能だとすると、
　どこに持つのがいい？というお話。

---

　なんで、こんな話をするのか？というと、NHK技研公開２００９の

映像配信サービスにおける複数受信機間認証情報連携
～ 受信機を替えてもログイン操作がいりません ～
http://www.nhk.or.jp/strl/open2009/tenji/t04.html
で、

・いろんな端末（テレビ、ケータイ）で利用できる
・利用した分、お金が引かれるわけだが、
・その利用情報（権利情報といってたと思う）は、各端末で持つ
・端末を変えたとき（テレビ→ケータイとか）、利用情報を移転する操作をする。

というしくみになっていた。これについて、ちょっと考えたいので。

---

　このように、もし、端末側で利用情報を持っていると、端末が壊れたときに、問題が起こる。

　上記の展示の場合、ケータイで見ていたあとで、テレビから見るように変えたい場合、
　ケータイで利用した情報を、テレビ側にうつすという操作を行う。

　で、ここでもんだい。
　もし、ケータイを見ているときに、ケータイが壊れちゃうと・・・？
　テレビで見れない？？

　となってしまう。こまった（＞＿＜！）

　また、上の場合、移転操作があるが、

・家でテレビを見ていて、外へ出てきた。
・そとでケータイから見たい！といっても、利用情報をケータイにうつしていないので、
・家に帰ってテレビをつけて、移転しないと・・って家に帰ったらわざわざケータイで見なくても・・・
　　・・・いつでもどこでも、ユビキタスじゃない

　ってことで、やっぱ、いつでもどこでも見るには、端末側におくのは無理があって、
　サーバー側にあって、つねにどんな端末からでも見えないと。。。ってことになってくる。

---

　そーすると、サーバー側で利用状況を管理することになるが、問題は、
　　・サーバーが倒れたとき
　　・クライアントが倒れたとき
　利用履歴はどーなるか？ということだろう。

　これを、ダウンロード型とストリーム型で考える。

●ダウンロード型の場合

１．サーバーからダウンロードし（暗号化して渡す）、
２．ダウンロード完了時、サーバーが、ダウンロードしたことを履歴に書いて、暗号化の鍵も書き込む
３．書き終わった通知をクライアントに知らせ
４．クライアントは書き終わった通知を受け取ったことを、サーバーに知らせる。

とする。
このとき、クライアントが、４までの間で倒れ、サーバーとのセッションがきれた場合、
セッションが切れたら、サーバーは、ダウンロードした記録を取り消す（暗号鍵情報も消す）
そうすると、利用していないことになるので、

５．クライアントから利用するとき、鍵情報をサーバーに要求する、
　　鍵を渡した時点で、利用開始＝課金

　　→このとき、４までの間で倒れていれば、鍵情報が消されているので、受け取れないから、使えない。
　　　同時に利用情報も消されているので、課金もされない
　　　結局、何もしていないのと同じ状況になり、
　　　再度ダウンロードする
　　→５の最中でダウンしても、何回この要求を出してもOKなので（課金フラグ１で何度も上書きされるだけ、
　　　課金開始日は見ていない）また、要求してもらえばいい。

サーバーが、３以前で切れた場合は、書き終わった通知がクライアントに行かないので、
クライアントはダウンロード失敗と判断し、再度ダウンロードする。
（一度も利用されない＝課金されない）

４で倒れたとして、５の要求を出したとしても、すでに３のところで、ダウンロードした情報、
かぎ情報は書いているので、正常に、５の処理は行える。問題ない。

●ストリーム型の場合

　ずーっとサーバーから情報が流れている。
　一定時間ごとに、クライアントから、サーバーにリクエスト電文を投げる。
　この電文を受け取ると、サーバーは、利用情報を更新し、サービスを続ける

　クライアント側が切断すると、このリクエスト電文がこない。
　そうすると、サーバーがサービスをストップする。

　サーバー側が切れて、サービスがストップされると、クライアント側は電文を投げない
　ので、利用情報は更新されず、その時点でサービスストップになる。

---

ま、ざっと考えると、こんなかんじかしら・・・