ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

国がクラウド基盤を提供、地方自治体に貸し出し、鳩山首相が実現すれば、電子私書箱も、ありえる?。。

2009-04-01 18:00:00 | Weblog

で、さっきの話の続き。si yue教授のエッセイについて。

どうも、
The key factor to a success of an electronic mail box in Japan is Prime Minister Hatoyama's realization.
(日本における電子私書箱の成功の鍵は、鳩山首相の実現である)

というエッセイのことらしい。

そのエッセイによると、

・The problem of cloud computing-In the case of an electronic mail box
 という論文(前に書いた論文)で、クラウドの問題点を10個出した、
 それは、以下のとおり。

  (1)認証の問題
  (2)データロンダリング
  (3)システムの信頼性
  (4)サービスの継続性
  (5)サービス修正による問題
  (6)テストケースが想定不能
  (7)ネットワークの速度
  (8)セキュリティ
  (9)データのプロパゲーション
  (10)システムの正当性を保障できない

 これらの問題は、じつは、簡単に解決する方法があると述べている。

 その方法とは・・・

   全サービスを提供する、巨大なサーバーを、
   どこかに打ちたて、集中管理し、
   クライアント側をシンクライアントにする

 というものだ。




 そして、その例として、仮にプーチンのロシアで、これを実現したらどうなるか?
 ということを、空想?している。

 まず、国家中心となり、巨大サーバーをたて、開発者は事実上国が管理し、
 地方自治体にソフトを使わせ、自治体では、決まったソフトの一部改修のみしか行わせない。
 そのソフトも国が管理し、開発者も、国が指定した人である。

 改修も、国に申請し、決まった開発者が、開発内容を明示し、その内容に沿った開発がなされているか
 チェックする。改修時期については、国家統制がなされるので、問題はない。

 セキュリティに関しても、ロシアでプーチンに逆らってまでやろうという人はいないだろう。
 認証も、国民の番号をふるのも、プーチンほどの権力を持っていれば、かんたんだ。

 データも、最終的に国がチェックし、故意に不正を行ったものは罰するようにする。

 つまり、比較的簡単に実現できるというものだ。




 したがって、日本においても、強力な権力が生まれ、かつ、クラウドを集中型にすれば、可能である
 と説明している。

 その方法は、こうだ・・・


1.まず、国が、巨大なクラウド環境を構築し、そこに国のデータやソフトを集中管理、
  各省庁には、データはクラウド環境からとってくるが、処理を行うアプリケーションサーバーをおき、
  職員の端末には、シンクライアントを置く。
  このようにすると、

   ・共通データ、アプリは国のクラウドへ
   ・個人で利用するデータ、市販のアプリなど、さほど重要でないものは、
    各省庁のアプリケーションサーバーへ

  となる。

  巨大なクラウド環境のイメージとしては、中国江蘇省無錫市の「Cloud Computing Center」

2.次に、国は、地方自治体用の共通アプリをWebサービスとして開発し、
  それを、まず、財政困難な地方自治体から順次利用させる。
  このWebサービスを国の巨大クラウドにおくと、

   ・共通データ、アプリは国のクラウドへ
   ・個人で利用するデータ、市販のアプリなど、さほど重要でないものは、
    地方自治体のアプリケーションサーバーへ

  となる。
 

3.これにより、国は、各省庁で利用するデータ、各地方自治体で利用するデータ、およびWebサービスを
  クラウド内で集中管理できる。
  そのクラウドにおける、Webサービス開発者を、登録制にする。
  このとき、開発者を追跡できるように、開発者の情報処理試験合格者番号を登録させる
  (住基ネットだと、外国人は?という問題になる。なお、情報処理技術者しか、国のWebサービスは開発させない)
  また、元受会社は、登録する。

4.Webサービスも登録する。そして、登録する際、
   呼び出し利用サービス、
   入力引数
   入力データ(読み込みDBなど)
   出力データ(書き込みDBなど)
   返り値
  を自動的にチェックし、DBに登録する(リポジトリ)
  これにより、リポジトリ検索で、影響範囲を確定できる。

5.改修を行いたい場合は、国に申請を(電子的に)だす。
  国は、自動的にリポジトリをチェック、影響範囲を導き出し、
  一定期間内に判断し、改修してよいかどうかの結果を通知する。
  その後、改修を行う。
  改修したら、4の修正を行う。

6.ここで、5の修正により、影響を受けるWebサービス開発者、
  開発会社(元受)には、すぐに連絡が行き、修正を行う
  なお、前もって、登録していた人(開発者以外でも)にも、
  連絡が行く。

7.修正完了後、国が自動的に回帰チェックを行い、
  問題がなさそうなら、リリースする
 (それまでは修正は反映されない)
  修正した旨、関係者に通知される

8.国は、集中して集めたデータ間に関して、矛盾がないかの
  チェックをいろいろ行う。

9.ここまでの体制ができたところで、国民に電子私書箱構想をだす。
  認証は、住基ネットでSSOとする。認証サーバーは巨大クラウド内
  につくる。




 つまり、重要なことは、国が、アプリもデータも集中管理するということ。

 しかし、実際の場所は、自然災害もふくめ、冗長構成、分散のほうがいいかもしれない。
 地震対策として地下(冷却に地下水の利用)を利用し、電気エネルギー取得価格の安い地域
 にクラウドを建設することになる。
 戦時に備えるため、候補地は日本国内のみになるだろう。

 人材は集中管理が必要である。
 現在の、電子政府のCIO補佐官の年齢は高すぎ、最新の技術をキャッチアップするには
 ふさわしくない。

 そこで、CIO補佐官補佐を立て、その候補者として、優秀な技術者を
 東京の中心にあり、補佐官との連絡を取りやすい、
 神保町、田町などにある大学院に集める。




 問題は、このような地方自治体および通信業界に対する強大な権力の行使が可能であるか
どうか、また、野党の反対無しに行えるかどうか。。ということである。

 しかし、日本の場合は、このような強大な権力があつまる省庁がある。

 総務省である。

   総務省は、地方自治体を監督し、
   通信業界も監督し、
   さらには、日本郵政にたいして、物言う株主として、

 絶大な権力をもった省庁である。

 この省庁に現在君臨するトップである、総務大臣の鳩山邦夫氏は、国民の人気も厚い。

 そこで、まず、

 ・疲弊した地方自治体に対し、Webサービス+シンクライアントにより、
  国が、ソフト開発、管理をしてあげるという案を出し、

 ・さらに、国のソフトをWebサービスとしてまとめることにより、シンクライアント化
  でき、時代遅れのパソコンでもOK,電気代の安いところにもっていくことにより、
  経費削減、東京が電気使用量ピークのときでも、だいじょうぶ

 ・さらにさらに、救急に関しては、旧制帝大の医学部病院にドクターヘリを数十台
  搭載、救急を、広域体制にし、もし、地元で病院が見つからない場合、その
  ドクターヘリを出動させ、遠くの病院に搬送できるという、
  「ネットワーク体制」を整える

 ・などなどの案を出して、選挙をたたかう。

 ・このとき、麻生氏だけだと選挙は弱いので、麻生氏と、鳩山氏の2枚看板で、
  自民は戦う。

 ・自民勝利、鳩山邦夫首相となる

 ・そうなると、実は民主もスキャンダルで自民と戦っている=政策的にはそんなにかわらない
  ので、民主のなかでも、鳩山由紀夫氏が率いる民主党議員が自民と劇的再編、
  結果として、たしかな野党の共産党と、みずほ議員ひきいる社民党以外は、
  みんな鳩山首相のもとへ・・・という大政翼賛的な政府となる。

 ・ここに、日本においても、プーチンなみの強力権力ができ、
  情報を統制することが可能となる。
  そうなると、強大なサーバーを基にした、データ集中、プログラム集中が可能になる。




そうな・・・

なるほどお・・・(@_@!)

いったい、si yue教授は、どこの大学出身なんだろうって、調べたら、

どうも、バカボンのパパと同級生だったらしい、

四月 (si yue)教授は・・
馬鹿的(maluda)大学で・・・



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

クラウドコンピューティングの問題点-電子私書箱の場合-だって!

2009-04-01 12:00:00 | Weblog

で、さっきのsi yue教授について調べてみた。
どうも、maluda Univercityの教授らしく、ほかに

The problem of cloud computing-In the case of an electronic mail box

「クラウドコンピューティングの問題点-電子私書箱の場合-」

という論文をだしている。

一般的なクラウドコンピューティングの問題点をだし、
さらに具体例として、電子政府で行おうとしている、電子私書箱の場合
についてとりあげている。




アウトラインはこんなかんじ。

・クラウドコンピューティングの10の問題点として以下のことをあげている

(1)認証の問題
  サービスごとに認証を取ると認証が煩雑になる可能性がある

(2)データロンダリング
  本当は不確かな情報が、権威あるサービスから提供されると、
  その権威を信じて、情報を確かなものだと思い込む可能性

(3)システムの信頼性
  複数のサービスを利用すると、どれかひとつのサービスが
  落ちただけで、利用できなくなったり、情報が不確かになったりする

(4)サービスの継続性
  サービスが常に提供され続けるかどうかわからない。
  突然、提供企業自体や、ホスティング会社が倒産する可能性がある。
  この場合、予告無しにサービスが終わる
  ここまでいかなくても、サービスが都合により、突如終わる可能性は
  否定できない。

(5)サービス修正による問題
  インターフェースに関するサービス修正が行われると、そのサービスを
  利用しているサービスは、修正を知らなければ、旧インターフェースで
  アクセスするので、サービスを利用できなくなる可能性がある。
  インターフェースは一緒でも、修正によるデグレードや多機能の多くは
  スピードアップしているが、一部機能が急激に遅くなるといった場合、
  利用するサービスによっては、不利益をこうむるかもしれない

(6)テストケースが想定不能
  ユーザーUがサービスAを使い、
  そのサービスAが、サービス1,2,3を呼び出している場合、
  クラウドコンピューティングでは、ユーザーUには、サービス1,2,3
  の存在をしらぜず、サービスAのインターフェースしか知らない場合が
  多い。
  このようなケースでは、サービス1に、まれに起こる障害があったとき、
  ユーザーUは、どのような問題が起こるか把握できず、これに対するテストは
  できない。

(7)ネットワークの速度
  クラウドになると、利用しているサービス全体を理解できない。
  ということは、サービス全体のネットワーク像を理解できない。
  そのため、どこかのサービス回線のスピードが何らかの形で遅くなると、
  それを呼び出しているサービスが遅くなり、さらにそれを呼び出している
  サービスが遅くなり・・・

  ・・・と、ドミノ倒し的にサービス提供が遅くなる可能性がある。
  しかし、ネットワーク全体をだれも理解していないので、
  なぜ、遅くなったのかは、だれもわからない。。。

(8) セキュリティ
  すべてのサービスのセキュリティレベルを合わせることは事実上無理であり、
  そうなると、セキュリティの甘いサービスに入り込んで、
  ここをサービス停止に追い込んだり、データを朗詠させたりすることで、
  そのサービスを利用しているさまざまなサービスが、そのサービス自体は
  セキュリティを強化していても、結局セキュリティに問題を起こす。

(9)データのプロパゲーション
  クラウドでは、いろいろなルートでいろいろなサービスが、同一のデータを
  見る可能性がある。
  このような状況では、DNSのプロパゲーションみたいに、データを変更したとき、その直後では
    あるサービスは変更後の値を見て
    ほかのサービスでは、変更前の値をみて
  同一のデータが違う値になってしまう。
  このとき、トランザクションをつければよいが、サービス間にトランザクションを
  はってしまうと、予期せぬ、ないしは悪意のある利用者が、トランザクションのための
  資源排他制御順を、逆順に行って、デッドロックを起こさせてしまう可能性がある。
  そして、1資源のデッドロックがいろいろなサービスに派生していく可能性がある。  

(10)システムの正当性を保障できない
  つまり、日々刻々とシステムが変わっているので、現在、正しく動作しているサービスでも、
  次の瞬間(修正等されて)、動かなくなる可能性は否定できない。
  それを監督している人がいない上、修正するとしても、サーバー側のサービスと、それらを
  マッシュアップして使っているクライアント側のプログラム、さらにユーザー側業務の専門
  知識が必要になる。これらをすべて持ち合わせている人は、少ない。

  このような状態では、はたして、システムが正しく動いているかの正当性が、保障できない
  (内部監査報告書などで、正当性やリスク分析をただしく行えない)




・これらについて、具体的に、電子政府の電子私書箱で説明している

(1)認証の問題
 国の書類にアクセスする際、すべての認証のベースになりえるのは、住基ネットだが、
 これに基づいた、国税庁の電子申告ですら、十分な利用といえるかどうか・・・

(2)データロンダリング
 国の情報は信じてしまうが、実は入力者は国民という場合、悪意のある人等が悪意のある
 データを入力してしまった場合、国の権威ある情報として信じ込む危険性がある。
 この問題の例は、EDINETのテラメント株式会社に対する大量保有報告書が  
 あげられる。

(3)システムの信頼性
 (4)との問題とも絡むが、そもそも、システムメンテナンス時間があるので、
 24時間、365日動かすのは大変である。

(4)サービスの継続性
 (3)の問題もあるが、それ以上に、レンタルサーバーなど業務委託していた
  会社が倒産等してしまう問題がある。例としては、
  三重県いなべ市がセカンドライフ内に開設した支所が突然閉鎖したケース
  などがあげられる
  かといって、政府の公務員がすべての作業を行うのは、無理である。

(5)サービス修正による問題
  この問題は、構成管理やデグレードの問題として、すべてのソフト
  でありえる。この緩和策として、回帰テストの自動化があるが、
  クラウドにおける回帰テストの自動化は、まだ研究途上である。

(6)テストケースが想定不能
  これも(5)における話と同様であるが、そもそも、電子私書箱の場合、
  ユーザーが利用するサービスインターフェースは公開されるだろうが、
  そのサービスが、どのようなサービスや技術を利用しているかについて
  (とくに地方自治体が提供するサービスなど)は公開されるのだろうか
  (というより、公開できるのだろうか?)

(7)ネットワークの速度
  地方自治体のデータもクラウドで利用可能とした場合、サーバーを
  どこにおくかで問題になる。
   すべて国が一元管理するのであれば、巨大データセンターによって、
  この問題は起こらないかもしれないが、地方自治体が、自分たちのデータ
  をもつとすると、過疎化した村において、小さなサーバーにした自治体が
  何かの事件で、急激にサーバーアクセスが増加すると、いきなり速度が
  遅くなる可能性がある。

(8) セキュリティ
  地方までも同じセキュリティレベルを実現することはむずかしい例としては、
  長野県で行った、住基ネット侵入実験結果などがあげられる。

(9)データのプロパゲーション
  そもそも、クラウドで、トランザクション処理を求められても、
  厳しいものがある。

(10)システムの正当性を保障できない
  いままで見てきた危険要素から明らか。
  電子私書箱を使いこなすWebアプリ開発には、行政書士なみの知識が必要にならないか?




そして、一般的に考えると、これらの問題から、「電子政府の電子私書箱」は難しいと考えられる。
しかし、si yue教授いわく、日本を侮ってはいけないと・・・
これらの難題を解決する方法があり、
それについて、エッセイを書いているそうである。

そのエッセイも報告されているらしい。

ちょっと、しらべてみる。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「オブジェクト指向開発-時代遅れの開発手法」という論文発見!

2009-04-01 06:00:00 | Weblog

CiNiiを見ていたら、こんな論文が(@_@!)

Object-Oriented development - The outdated development technique -

えーっと、つまり、
「オブジェクト指向開発-時代遅れの開発手法」
って表題なわけです。まじっすか、やばくないっすか、こんな題を論文にしちゃ・・・

どうも、クラウド時代には、オブジェクト指向は破綻する。
アスペクト指向などの導入が必要というものなのだが。。




アウトラインは、こんなかんじ

・オブジェクト指向は、かつては、カプセル化、継承、ポリモーフィズムによって、それないの成功を得てきた。
 しかし、それは、あくまでも、
   開発期間が与えられ、
   モデル部分のデータ構造があまり変わらない場合で
 有効な手段であり、これらの前提が崩れた途端に、逆に悪影響を及ぼしてしまう。

・たとえば、あまりに複雑な継承をさせてしまうと、継承元のほうのクラスをいじったとたんに(メソッド削除するとか、引数をかえるなど)、継承先のクラスに悪影響を及ぼしてしまう。しかし、あまり継承を使わないと、オブジェクト指向化する意味はない。
 また、カプセル化がすすむと、全体像が見えにくくなり、自分の修正が、どこまで波及するかわからなくなる。




 例として、受注において、商品のマイナスは許さなかったのが
   返品処理を受注で表現するため、マイナスを入れたら返品という修正をこっそりした
   (カプセル化して、関係者にしかわからない)

 その後、この話を知らない人が、受注を派生したクラスの「ハンバーガー注文」において、
   ハンバーガーのオニオン抜きを
   ハンバーガー - オニオンと、マイナスをつけることで表現しようとした。
 マイナスの修正をしていたので、これは入力でき、一方、オニオンはデータベースになく、検索エラーになって、0円
 ということで、うまくいった。 
 うまくいったので、ま、いっか!ということで、このまま利用していた。

 ところが、1ヵ月後、販売集計をしたところ、オニオンという商品データベースにない商品が、数量的には
 かなり多く出ている・・・という結果になった。
 こりゃーなんだ!!と本部は、
   ・ハンバーガー注文に限らず、マイナスでの入力をストップせよ
 という指示を、ハンバーガー受注のシステムを出しているところに出した。

 ハンバーガー受注の開発会社は、へいへい!と、(ハンバーガー注文に限らずあるので)継承もとの受注を
 マイナス不可にしたら・・・

 ・・・返品は??




・クラウドにおいては、だれが作成しているのかよくわからないデータを、いろいろラップして、サービスとして提供する可能性がある。このとき、データ作成元が修正を加えることによって、ある日突然、サービスが不適合になる場合がある。

・その場合、通達ぬきで送られる可能性もある

・つまり、クラウドにおいては、開発期間はまったく与えられず、何が起こったのかもよくわからない状態で、サービスが激変し、そのための修正をさせられる可能性がある。

・さらに、最近のセキュリティの問題は、開発当時には予見できず、開発後、かなり時間がたったところで、作りこまなければいけないことになる。このように、後から見つかった、共通処理(横断的関心事)をオブジェクト指向に取り込むには、継承元の修正しかなく、継承元を修正すると、上記の問題が起きる。





・この状況下に対応するには
  ・継承元までの距離を短くして、
  ・継承関係をてもとでわかるようにして
  ・問題が起きたとき、旧バージョンにすぐに切り替えられる

ようにしなくてはならない。それには、設定ファイルを利用した切り替え、あらかじめ横断的関心事を継承という形で作りこむのでなく、あとからでも横断的関心事を抽出し、組み込めるようにしなくてはならない。

 それを実現する方法は、DIやアスペクト指向である。

・クラウドの場合、同じ機能だが、効率的な新しいサービスが出てきた場合、そのサービスに切り替えることが可能だが、これを効率的に行うには、DIを利用し、サービスを柔軟に切り替えるという手法は、かなり有効に思われる。

 そのように考えると、仕様の硬直性のあるオブジェクト指向は、もはや、時代遅れの開発指向であり、
 クラウドのように、すぐにサービスを切り替えたり、修正を元に戻したり、開発後かなりたってから、処理を修正する必要がある場合は、DI、さらにはアスペクト指向を利用すべきである。




 ってものなんだけど・・・

 おおおお・・・

 ちなみに、この論文は、si yue教授だそうな。
 しー ゆえ?日本語の名前??ちょっとへん。
 韓国?中国??(声調が抜けてる??)

 ちょっときょうみあるので、この教授のことを、しらべてみる。。。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする