アマゾンも企業内クラウドなのね・・・

ここのニュース
Amazon、企業向けクラウドサービス「Virtual Private Cloud」を発表
http://headlines.yahoo.co.jp/hl?a=20090827-00000026-zdn_ep-sci

　クラウドは、ＧｏｏｇｌｅがＡＰＩを提供するとか、そーいったパブリッククラウドより、企業内クラウド（プライベートクラウド）のほうが、やっぱ、はやりなんでしょうね。

　でも、それって、単なるアウトソーシングなんじゃあ・・・・

　・・・って思っちゃうことは、内緒です（＾＾；）

Strutsの要素技術の基本的構造（その２ 基本的ソースを画面定義書から）

まえに、Strutsの要素技術の基本的構造というのを、その１だけ書いて、以降、何も書かなかったので、これから、続きを書いてみる。

　まず、前に書いた流れだと、はじめ、

○Strutsを基本的に構成するもの
　　　Ａｃｔｉｏｎ
　　　ＡｃｔｉｏｎＦｏｒｍ
　　　Ｓｔｒｕｔｓ－ｃｏｎｆｉｇ．ｘｍｌ
　　　ＪＳＰファイル


　なので、これらのファイルと、画面定義書の関係を示して、設計から、プログラムにどのように落ちてくるかについて、書きたいと思います。
　で、画面定義書は、主に、画面遷移図と、各画面レイアウト説明（っていうのかな？）に分かれると思います。
　今回は特に、「各画面レイアウト説明」のどの部分から、それぞれのソースが出来てくるかについて、書きたいと思います。

　で、画面定義についてなんですが、今回は、発注者ビューガイドラインのVer1.0(2008年７月）版、第一部－７１ページ（ＰＤＦのページ数は８８／２９１）の右の図



著作権表示：CopyrightまるＣ2008 IPA
（まるＣは、著作権のコピーライトのＣです）

をもとに説明します。

---

■各ファイルの概要

まず、各ファイルの概要について書きます。

（１）Ａｃｔｉｏｎクラス
　ここのexecuteに処理内容が書かれる。

（２）ＡｃｔｉｏｎＦｏｒｍ
　画面の内容のＢｅａｎ（フォームＢｅａｎ）
　　・画面項目
　　・項目のＳｅｔｔｅｒ
　　・項目のＧｅｔｔｅｒ
　が基本的に書かれている。
　　・初期化のresetや、
　　・値チェックのvalidate()
　もここにかかれることがある
　（validatorを使う場合、ActionFormでなく、ValidatorFormを使う）

（３）Ｓｔｒｕｔｓ－ｃｏｎｆｉｇ．ｘｍｌ
　以下の内容が書かれる
　・data-sources
　　データベース接続に関して使うこともある

　・form-beans
　　ActionForm等のフォームBeanをかく

　・action-mappings
　　Actionの定義と、forward先について

　・global-exceptions、global-forward
　　全体として、飛ばし先を決めたり、例外・エラー画面を決めたりするとき

　・message-resources
　　メッセージをまとめたメッセージリソースについて

　・plug-in
　　プラグイン(validatorはプラグイン）

　・その他もろもろ
　　controllerにかかれることもある
　
（４）ＪＳＰファイル
　画面を記述する。ここで、strutsタグを使って、ActionFormの入出力項目と結びつけたり
　bean:writeをつかって、beanやセッションの内容を画面に記述する

---

■画面定義書からプログラムへ

　では、上述の画面定義書が、どのようにプログラムに関係していくかという話なのですが・・・

（Ａ）画面定義書の「使用する部品」から、
　　　「ＪＳＰ」、「ＡｃｔｉｏｎＦｏｒｍ」、「Ａｃｔｉｏｎクラス」が決定します。

　使用する部品（項目）の「画面部品の種類」（＝型）が、
　　テキストボックスのような入力するものであれば、該当項目を
　　　　　　ＪＳＰでは、HTMLタグなどを使って、入力項目のタグを作り
　　　　　　ActionFormでは、対応する部品のフィールド、setter,getterをつくります
　　　　なお、「画面部品の種類」と表示範囲から、エラーチェックがかけますが、これは
　　　　　　・ＪＳＰにjavascriptとして書く
　　　　　　・Validatorを使って書く
　　　　　　・validateで書く
　　　　　　・action内に書く
　　　　と、いろいろありますので、てきとーに決めて（決める基準あります）かきます。　　　　　

　　ボタンであれば
　　　　　　Ａｃｔｉｏｎをつくります。
　　　　このとき、１画面にボタンが複数ある場合
　　　　　　１画面１アクションでメソッドがボタンごとに変わる
　　　　　　１画面１アクション１メソッドでメソッド内切り替え
　　　　　　１ボタン（イベント）１アクションでつくる（１画面で複数アクション）
　　　　の３通りの作り方がある。詳しくは何回か先に話す。
　　　　Ａｃｔｉｏｎの内容は、「操作手順」から読み取るしかない？？

　　出力のみの項目であれば
　　　　Strutsタグのbean:writeを使って書きます。
　　　　値はSessionに入れておけば、nameで指定すればかけます。
　　　　bean（フィールド、setter,getterがあるクラス）の場合、それをsessionに入れれば、
　　　　　　name=セッションに入れたbeanのキー名　property=フィールド名

　　表示しない場合
　　　　StrutsのHTMLタグのhiddenでかけます。　　

（Ｂ）画面定義書のレイアウトからＪＳＰが決まります。
　　ですが、たぶん、このレイアウト、ＨＴＭＬで書いているから、その場合、
　　拡張子をＪＳＰにして、その後、上記の
　　　　HTMLタグ
　　　　bean:writeタグ
　　などのstrutsタグをいれます(logicも）

（Ｃ）(A)で決まった、ＡｃｔｉｏｎとActionFormからstruts-config.xmlがかけます
　　　Action=actionタグ（action-mapping内）
　　　ActionForm=form-beanタグ（form-beans内）

---

　次回は、画面遷移図と、action,struts-config.xmlの関係

ホワイトスペースを通信に使うと、放送のニュービジネスとインフラをつぶす

　で、まえに電波オークションはニュービジネスを阻害し、地方格差を広げるということを書いたときに、「ホワイトスペースで、もっと顕著な話があるんだけど」って書いておきながら、それについて書かなかった。

　予備知識は書いたので、じゃあ、今度はこのホワイトスペースの話。

---

■ホワイトスペースとは・・・

・・・空白のこと？？
じゃなくって、ここでいうホワイトスペースは、

・テレビの割り当て周波数帯なんだけど
・テレビが映って無い周波数。

　関東アナログVHFだと、１，３，４，６，８，１０，１２が映っているので、
　あいているチャンネルは
　２，５，７，９，１１になる。このあいてるチャンネルがホワイトスペース。

　実際には、３チャンと４チャンの間はすごく離れてる（だからFMでテレビが聞けるラジカセは、３チャンまでが多い）。そのため、実質交互になっているわけだけど、このように、交互にして、きっちり使わないことにより、混信が避けられる。

　とはいえ、VHFはそうだけど、UHF(Uチャン）は、かなりあいているわけで・・・
　地デジになっても、開いている周波数はたぶん、多いだろう。

　なお、このチャンネルは、地域によって違う。UHF、VHF帯は、あまり遠方へはめったなことでは電波は届かない（スポラディックEs(イースポ）というのがあると、確かに届くことは届くけど、めったに起こらない）。そこで、届かない地域同士では、同じチャンネルで違う局が放送しても、混信が起きない。そこで、地域によって、混信が起きないように、チャンネルを変えて放送しているが、遠方では、同じチャンネルで放送していることもあり得る。

---

■で、このホワイトスペースを・・・

　ホワイトスペースは、混信を避けるためとはいえ、基本的には、ここには、番組が映らない。そこで、この周波数帯を利用しようという考えもあり得るわけだ。

で、その空き周波数についてなのだが・・・

ホワイトスペース：電波の90％以上は空いている
http://blog.goo.ne.jp/ikedanobuo/e/7fea36450315ddd8c2992556b99f1352

に書かれているように、このホワイトスペースをケータイなどの通信に使おうという考えがある。

　たしかに、アメリカでは、通信（WiFiとか)にも、使うことを考えているようだ

　でも、この考え方で、ケータイなどの通信に使ってしまうのは、ニュービジネスをつぶし、せっかくの放送インフラをどぶに捨てる行為だと思う。筋が悪すぎる。

---

■ホワイトスペースを通信に使うと、放送のニュービジネスをつぶす

　話を単純化しよう。
　ホワイトスペース、すべてをケータイに使ったとする。
　その後、新たな放送局をそこに作ろうとしたら、どうなるか？

　ケータイが使っているホワイトスペースを一部削り、その放送局に割り当てることになる。ところが、ケータイをつなぐには、基地局への大きな投資がかかる。その投資をどぶに捨て、そのあとに、放送局を作ってもらうことになる。

　これは無駄だ。それなら、初めからケータイは、ずっと動かないで、安定した周波数帯で、全国一律で、サービスを提供したほうが、投資・研究の安定化につながる。
　電波は周波数によって、入り方などが違い、ベストな基地局の場所（２基地局間の距離）も違ってくる。だから、できるだけ周波数は動かない方がいいだろう。
　LTEも含め、その後も１．５G～２G、２．５Gあたりで安定させるのが無難じゃないかな・・・

　さらに、無駄という話でいうなら、ホワイトスペースは基本的に、テレビを受信するように受信機が出わまっちゃっているという問題がある。ここを通信に使うと、果たしてそれらのテレビに影響が出ないか？って問題がある。

　たしかに、電波の形式が違うし、ケータイは基本的に盗聴できない仕組みなので、通話がばれるということはない。しかし、ケータイを話してテレビを見ているとき、本当に近接している周波数だったら、まったくテレビは影響をうけないのか（＝テレビにホワイトノイズが出ないか）、テレビをスキャンして調べる方式の受信機に、影響が出ないか（まちがって、番組と思って止まっちゃわないか？）などは、やってみないとわからない。

---

■で、地方にとって、メリットがあるのか？

　で、ホワイトスペースが多いのは、たぶん、地方だろう。
　そこで問題なのだが、この案、地方にとってメリットはあるのだろうか？

　ホワイトスペースも多いかもしれないけど、ケータイを使う人も（都会よりは）少なくないか？そーすると、ホワイトスペースを使ってまでやる意義は。。。

　地方から見たら、既存の通信ビジネスではなく、これから起ころうとしている放送ビジネス（デジタルサイネージと放送の融合など。詳しくは次回書くけど）のほうが、お金になる。つまり、ニュービジネスを起こしたほうが、地方にとってはメリットがある。

---

■じゃ、どーするのがいいの？

　ってことで、ホワイトスペースを通信に使うアメリカのような方式では、

　日本のメリットより
　放送ニュービジネスをつぶし、地方は恩恵を受けらないというデメリット
　のほうが、大きく思える。

　もし、ホワイトスペースを利用するなら、
　新しい放送ビジネスに利用すべきである。

　そのビジネスは、もう起きているし、
　総務省も、考えているわけだが、
　それについては、次回、書いてみたいと思う。