Embed Size (px)
Citation preview
1
クラウドの将来性と課題
～多機能チャットプログラムの構造～
日付:2013年 1月 29日
所属:阪南大学 経営情報学部 経営情報学科 花川ゼミ
5109077 北川照樹
2
目次 第 1 章 はじめに・・・・・・・・・・・・・・・・・・・・・・・・・p3 第２章 クラウドの関連研究・・・・・・・・・・・・・・・・・・・・p4 第１節 クラウドとは・・・・・・・・・・・・・・・・・・・・・・p4 第２節 クラウド利用のメリット・・・・・・・・・・・・・・・・・p4 第３節 クラウドが個人にもたらすメリット・・・・・・・・・・・・p5 第４節 クラウドが企業にもたらすメリットと利用例・・・・・・・・p6 第５節 新しいクラウドベンダー・・・・・・・・・・・・・・・・・p8 第３章 多機能チャットプログラムのサンプル例・・・・・・・・・・・p9 第１節 クラウド Web サービス・・・・・・・・・・・・・・・・・・p9 第２節 クラウド Web サービス連携のシステム構成・・・・・・・・・p11 第１項 クラウド Web サービスの種類・・・・・・・・・・・・・・p11 第２項 多機能チャットの概要・・・・・・・・・・・・・・・・・p14
第３節 サンプルプログラムの説明・・・・・・・・・・・・・・・・p15 第１項 ブロック①の説明・・・・・・・・・・・・・・・・・・・p31 第２項 ブロック②の説明・・・・・・・・・・・・・・・・・・・p33 第３項 ブロック③の説明・・・・・・・・・・・・・・・・・・・p33
第４章 まとめ・・・・・・・・・・・・・・・・・・・・・・・・・・p34 参考文献・・・・・・・・・・・・・・・・・・・・・・・・・・・・p34 謝辞・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・p34
3
第１章 はじめに
近年、インターネットの普及により情報化が進んでおりデータの扱いが重要になってい
る。世界ではインターネット人口が 22 億人を超えているといわれており、インターネット
は必要不可欠なものとなっており、情報交換やデータの移行などの方法が多くでてきた。
クラウドコンピューティング（以下クラウドとする）が初めて公の場で使われたのは 2006年である。クラウドの普及によりデータ管理のコストを削減することができるメリットが
大きいが、一方で安全性の問題点や手間がかかると感じる点などのデメリットもある。 本来のパソコンは、そのパソコンの中で膨大な量のデータを収めていた。しかし本論文
で述べるクラウドコンピューティングは、そうした情報処理をインターネット経由でサー
バーに預けるシステムである。近年、パソコンが安価で高機能化してきた。その結果、い
くらでもハードウェアを使い捨てすることができるようになった。その結果、データを預
かるサーバーを多数用意できるようになる。本来のクラウドシステムは、一つのサーバー
に対して情報を預けるというシステムであった。それは、かつてハードウェアが非常に高
価であり、貴重なサーバーを十分な保守をしながら使用する必要があったからだ。しかし、
現在ではハードウェアが非常に安価になったため、多数のサーバーを用意できるようにな
った。データは多数のサーバーに多重化され保存される。その結果、例え一つのサーバー
が破損しても、他のサーバーで補うことができる。また、非常に安価なため、破損しても
ハードの使い捨て感覚で次の新しいハードを設置し、すぐに復旧できることができる。こ
のサーバーは世界中の、人が立ち入らないような様々な場所にデータセンタとして設置さ
れている。 このクラウドシステムの登場は、Google App Engine や Amazon EC２が登場した 2006年頃といわれている[１]。Amazon は、大規模なネットショッピングサイトの複雑な運用の
経験を生かし、リソースを合理的に管理する方法を編み出した。このシステムは、単に
Amazon のネットショッピングサイトをシステム管理の膨大な業務から解放しただけでは
なく、そこで生じたサイトのリソースと、柔軟にスケールアウトする自らのクラウドの余
力を、企業向けのクラウドサービスとして外部に提供した[２]。本論文ではこれからのクラ
ウドの発展を予想して、このクラウドコンピューティングテーマ選択した。 本論文では第２章ではクラウドの利用例等の関連研究を書いている。第３章ではサンプ
ルプログラムの説明を書いている。第４章では本論文のまとめを書く。
4
第２章 関連研究
第１節 クラウドとは
クラウドとは、図１に示したように個の端末のデータや情報をネット経由して中央のデ
ータセンタ等に情報やプログラムを保存できるシステム環境である。ネットを経由してデ
ータ保存できるデータサーバーが、Google やアマゾン等のクラウドベンダーである。クラ
ウドの場合、クラウドというのは雲という意味であり、インターネットのことである。ク
ラウドを利用することで、端末を持ち運ぶ等の手間が必要ない。
第２節 クラウド利用のメリット
クラウドの使い方に関して、いくつかのメリットが存在する。そのメリットは、いくつ
かの面から発生する。まずコスト面でいえば、ハードウェアやソフトウェアの購入費が大
幅に削減される。クラウドサービスを利用のために、パソコンを最新のモデルに買い替え
る必要がなくなる。インターネットにさえつながりさえすれば、クラウド上の様々なサー
ビスを利用することができるからである。また、身近な端末を利用することができるので
高価なハードウェアが必要ない。 次に機能面で、クラウド上でソフトウェアをパソコンの中にインストールする必要がな
図１ クラウドコピューティングシステムの概要イメージ 出所: http://thinkit.co.jp/
ノートパソコン
サーバー群
クラウド
本来のサーバー
デスクトップパソコン
インターネット
5
いため、高機能な CPU(Central Processing Unit)が不要になる。今後は、パソコンの中で
は処理しきれない大規模なデータ処理をクラウドサービスに任せることにより作業が軽減
される。 また、サービス面では、バージョンアップの手間が軽減される。ユーザーが意識しなく
ても、ソフトウェアが自動的に年に何度も更新される。つまり、クラウドサービスの場合
は、ユーザー側の端末で更新作業を行う必要がない。
第３節 クラウドが個人にもたらすメリット
クラウドの個人メリットは、グーグルの G メールやグーグルアップス等の典型的なクラ
ウドサービスの利用によって生じる。このグーグルの G メールやグーグルアップスは、ア
カウントを持てば、メールフォルダを借りることができ、他ユーザーとのファイル共有や
カレンダーの共有が可能である。 そして、最近普及している SNS やブログも広義にはクラウドに入る。ユーザー数が増え
るにしたがい柔軟に設備が増やせるのがクラウドサービスなので、Facebook 等も相互にユ
ーザー情報等を交換できるクラウドシステムとなりつつある。 携帯電話にもクラウドサービスが浸透している。最近はアプリだけではなくデバイスも
クラウド環境を意識したものになっている。今後主流となるのがスマートフォンやその類
似デバイスである。特に iPhone はアップルが提携するモバイルミーというクラウドサービ
スとセットになっており、メールやファイル、カレンダーの同期サービスを提携している。
例えば図２に示すように、iPhone 上でカレンダーに新しい予定を書き込むとネットワーク
経由で自動的にモバイルミーのデータが書き換えられる。今後は、こうしたデバイスにお
いて、クラウドと連携したサービスが実現されていくと予想される。
図２ モバイルミーと iPhone
予定
画像 メール
書き換え
同期サービス 更新
6
またスマートフォンだけでなく、これまでのパソコンの姿も変わりつつある。例えば、
ネットブックはクラウドと最も親和性が高いデバイスとして近年爆発的に市場を広げてい
る。この数年で世界のノートパソコン市場はがらりと変わった。安価なノート型のパソコ
ンが求められる中、世界同時不況が起こり、その結果台湾のパソコンと関連機器メーカー
である Acer(参考 URL: http://www.acer.co.jp/ac/ja/JP/content/home)が目覚ましく台頭す
る。これは、Acer が ASUSTEC computer と広めたネットブックという安価で小型で軽量
なパソコンを普及させたからである。ネットブックはデータの記憶容量も小さく、ネット
につないで使用することが前提とされているパソコンである。例えば、ASUSTEC computer のネットブックは、発売当初より小容量で高速なフラッシュメモリを用いたドラ
イブを採用していた。そこで、その容量の少なさをクラウドで補えるように、データ記憶
領域サービスとセットにして販売した結果成功をおさめる。 上記のように、ネットブックやパソコン化したスマートフォンといったデバイスの普及
で、クラウド利用が加速すると考えられる。また、デジタルカメラ等のこれまでネットワ
ークにつながっていなかったデバイスもネットにつながり始めている。クラウドが存在す
ることで、デバイスをそれほど高機能化しなくても、効率よくネットワークに接続するこ
とが可能となる。 ここ最近、デジカメはカメラ付きの携帯の普及に押され気味であった。それが、2008 年
に登場したアイファイにより一変した。アイファイとは、ワイヤレス LAN の機能を搭載し
た SD メモリカードのことである。これを、デジカメのメモリスロットに挿入しておくこと
により、フリッカーやフォト蔵等のクラウドストレージ上に写真をアップロードすること
ができる。写真をクラウド上で共有する仕組みができれば、デジタルフォトフレーム等、
様々なデバイスからデータに自由にアクセスできるようになる。
第４節 クラウドが企業にもたらすメリットと利用例
次に企業に対するメリットを述べる。クラウドが企業にもたらすメリットについてだが、
企業では図３に示すように支出面や会計面、システムのリードタイム面、品質や機能面等
様々に存在する。 まずは会計面だが、近年企業は余剰資産の少ない軽いバランスシートを目指す、オフバ
ランス経営の考え方が主流だ。また、金融危機の影響でコストに対する意識が高まった。
その結果、IT コストの TCO(Total Cost of Ownership)の見直しが必要とされている。これ
らの点から考えると、クラウドはこのトレンドに当てはまるものがある。ソフトウェアや
ハードウェアを購入しなくてよいので、初期費用がほとんどかからない。また、
IT(Information Technology)をサービスとして使用するので、システムが資産計上されない。
クラウドは、IT 資産の減価償却から企業を解放する。 次に、時間に関して注目すると、クラウド導入によって時間が大幅に短縮される。本来
7
なら企業にとって直接的に価値を生まないアプリケーション利用までのプロセスを大幅に
カットする。まず、クラウド上のインフラを利用できるので、アプリケーション利用開始
の申し込みを行うとすぐにアプリケーションを構築できる。また、クラウド上ではオープ
ンな技術が用いられるので、従来のような制約を気にせずアプリケーションを構築するこ
とができる。このように、クラウドによって業務システムの構築から利用開始までの時間
を大幅に短縮することができる。 最後に、品質や機能面に関して述べる。自社では発想できない機能やサービスが安価に
提供される。新たな IT サービスが登場すると、当初は低評価である。例えば、パソコンが
登場した当時は、本格的な業務に耐えうるもではないと評価されていた。しかし、現在で
はパソコンは日常で一般的に利用されるものとなった。近年の例では、ヤマハのボーカロ
イドも当初はかなりの低評価であった。当初、ヤマハのボーカロイドは直接鑑賞するもの
ではなく、仮歌用途と考えていた。仮歌とは、歌唱を前提とした曲を発表する際に便宜を
はかって当てる歌のことだ。多くの作曲家は楽器を演奏し、自作の曲を演奏したものを録
音して売り込むことは多々ある。最近はシンセサイザーの発達で、楽譜だけで演奏も可能
になった。しかし、シンセサイザーでの音声合成は非常に難しく、歌のみ他に依頼する必
要がある。アマチュア作曲家には、シンガーを探す問題が生じる。ボーカロイドはそのた
めの音声合成システムである。商品化されると、ニコ動等で人気を集めたが、ボーカロイ
ドの歌のクオリティーは独立で発表するには極めて品質が低すぎた。これは、エレクトー
ンにも似たことが言える。エレクトーンも当初はオルガン代用品と考えられていたが、今
では独自の楽器として認識されている。当初は不完全な状態ではあるが、多数のユーザー
によって独自の文化が発達し、製品が改善されていく。ゆえに、一般ユーザー側で利用者
を拡大して、デファクトスタンダードとなることでコストを下げることが期待できる。ま
たクラウドに関しても、期待が高まっている一方で、品質や機能という面から考えると、
会社業務には役立たないといわれている。また、企業での利用にも耐えうるレベルまで運
用品質を少しずつ高めていき、企業ユーザーに浸透した。例えば、クラウドの SaaS サービ
ス[３]等は、すでに多くの企業で実績を上げており、初めから高機能で高品質のサービスが
利用できることがメリットである。新しい製品や技術は、新しいほど説明が難しく、定義
もあやふやである。よって、当初は低評価なことが多々ある[４]。 そして、企業はこのクラウドを具体的にどのように利用するかを述べる。やはり気軽に
導入できるという点で注目なのは Google だ。サービスが安価なことや、不況によるコスト
削減のあおりを受けて Google のサービス利用事例が増えている。グーグルアップスは、Eメールやワープロ、表計算等、これまでマイクロソフトが提供し続けてきたオフィススイ
ートに取って代わる機能を非常に安価で提供している。ユーザーは急増しており、特に Gメールは 25GB のメール容量で、0.2 秒程度の高速検索機能を装備しており、通常利用であ
れば既存のメールソフトよりも使い勝手がよい[４]。Gmail の他にも、Web メールやメー
ラ等もこの機能を装備しているが、Google は非常に安価なこともあり、企業は Google の
8
サービスを利用していることが多い。
第５節 新しいクラウドベンダー
近年普及しているクラウドサービスだが、salesforce.com[５]のサービスが注目されてい
る。salesforce が提供する SaaS は、元々顧客管理や接触管理を目的としてつくられたツー
ルだ。よって、顧客との発生する営業やコンタクトセンター、フィールドサービス、調達、
購買、取引先管理等の業務に適したサービスといえる。 実際、比較的簡単にセールスフォース CRM を操作して、業務フローを設計することがで
きる。このセールスフォース CRM は、画面上に様々なデータ項目が用意されており、それ
をユーザが必要に応じてカスタマイズして様々な検索条件等を設定する。これにより、特
定の業務に必要なアクションを容易にシステム化することができる。 そして、まだスタートアップして間もないベンチャー企業では、料金が比較的安いアマ
ゾンウェブサービスを利用する事例が多くなってきている。例えば、ツイッターやセカイ
カメラの頓智ドットをはじめ、アマゾンウェブサービスの活用事例を出版したことでも知
られる、学び ing や TIS の社内ベンチャー、SONIC GARDEN 等がある。アマゾンウェブ
サービスは非常にシンプルなので、技術的に高度なことを試みたいネットベンチャーとの
親和性も高いと言える。
図３ 企業のクラウド利用のイメージ図
クラウド
サービス提供者
最新技術
企業
企業
企業
サービス
安価
9
第３章 多機能チャットプログラムのサンプル例
第２章でクラウドの利用例は様々あることは述べたが、第２章で述べたことはその利用
例の表にしか過ぎない。この第３章で、サンプルの解説を行うことによってクラウドシス
テムの具体的な構造、クラウドシステムがどのように作用するかを知る目的で述べる。そ
のために今回多機能チャットプログラムについて述べるが、このプログラムは第２章で述
べたクラウドシステムの代表である Google の機能を利用する。
第１節 クラウド web サービス
図４で示すように、クラウドを web サービス化するということは、web クライアントで
の JavaScript 記述によって、GAE(Google App Engine)の Bigtable へのアクセスが可能に
なることと同じである。Bigtable とは、Google のサービスの、クライアントの情報処理を
助ける分散型巨大データストアである。クライアントこの Google の bigtable に情報処理を
行う。Google 検索サービスにおける膨大なコンテンツやインデックスを保持して、高速検
索を可能にするための専用データストアとして開発された。これらによって、クラウドサ
ービスと、例えば Google Maps 等のサービスがマッシュアップすることが可能になり、ま
た web クライアントで注目されている HTML5 とクラウドのスマッシュアップを、
JavaScript の記述のみで行うことができる。
まず図５で示すように、クラウドサービスにある３つの形態、SaaS(Software as a
図４ クラウドの web サービス化のイメージ 出所: http://www.highone.co.jp/cloud/google/index.html
ユーザー ユーザー ユーザー
Javascript 記述
bigtable
アクセス OK
クラウドの
web サービ
ス化
10
Service)、PaaS(Platform as a Service)、IaaS(Infrastructure as a Service)とある中で、
SaaS と PaaS の違いを述べる。 ①SaaS(Software as a Service) 直訳すると「サービスとしてのソフトウェア」となり、一般的に最も普及しているサー
ビスといえる。アプリケーションなどのソフトウェアを直接購入するのではなく、ネット
経由でサービスとして購入する。例えば、Google の Gmail や Google カレンダー等、ユー
ザがそのまま使用できる完成されたアプリケーションのこと。無料のものから、利用分に
ついて費用を払うものまで、色々なタイプが存在する。 ②PaaS(Platform as a Service) 「サービスとしてのプラットフォーム」である。このプラットフォームとは、アプリケ
ーションの開発環境やソフトウェアのための基本的なモジュール群のことである。つまり、
ユーザが自分の好みに合わせたアプリケーションを作ることができ、そのアプリケーショ
ンを巨大なクラウド環境のもとで動作するものとして作ることができる。 ③IaaS(Infrastructure as a Service) 「サービスとしてのインフラ」である。ここでいうインフラとは、サーバーやデータベー
ス等のハードウェアのことだ。これらのリソースやストレージをネット経由で利用できる
サービスである。
しかし、クラウド上で利用できるアプリケーションを開発することは非常に難しい。例
えば Bigtable を見ても、これまで web アプリケーションで使用されたものとはデータ構造
が全く異なってくる。これを、プログラムアクセスする場合、API を使用することになり、
Bigtable のスキルだけではなく他のそれに合わせたそれ相応のスキルも必要になってくる。 しかし、Javascript によって GAE を操れたとするならば、クラウドアプリケーションの
図５ SaaS、PaaS、IaaS の３つの形態の図解
SaaS サービスとしてのソフトウェア。ネット経由でサー
ビスとして購入する。
PaaS サービスとしてのプラットフォーム。アプリケーションの開
発や、ソフトウェアのための基本的なモジュール群。
IaaS サービスとしてのインフラ。サーバーやデータベース等のハードウェ
アのこと。
11
作成のために身に着けなければならないスキルの量も減り、またそのための労力や手間も
省くことができる。したがって、アプリケーション作成の敷居がこれまでと比べてはるか
に低くなる。そして、それを可能にするのに開発されたのが gaedirect である。 この gaedirectを使用すれば Javascriptの記述だけでGAE のサーバー機能を利用可能と
なる。つまり、世の web サービスを Javascript のみでアクセス可能となるのである。 さらに具体的にすると、gaedirect を使用してクラウドアプリケーションを開発する場合、
GAE のデータストアアクセスや、Channel API を使用したサーバプッシュ機能、画像や動
画のアップロードと表示や再生などをサーバー側に頼らず、クライアント側の Javascript記述のみで使用することができるようになる。よって、gaedirect はクライント側の
Javascript 記述のみでアプリケーションを作成できるので、自分用のクラウドアプリケー
ションの作成が容易になる。
第２節 クラウド web サービス連携のシステム構成
第１項 クラウド Web サービスの種類
図６はこの章で紹介するサンプルの全体構成図で、gaedirect でクラウド web サービスと
様々な HTML５の機能とのマッシュアップの構成である。マッシュアップとは、複数の APIを組み合わせて、一つの web サービスとみなすことだ。つまり、表１の HTML５のそれぞ
れの機能を Javascript の記述によって GAE にアクセスする。GAE より bigtable にアクセ
スでき、この一連の流れがクラウドの web サービス化になる。
JavaScript
gaedirect
gaedirectAPI Google Maps API
Web Storage
Web SQL
図６ クラウドwebサービスとwebサービスマッシュアップおよびHTML5 の
連携 出所: http://thinkit.co.jp/story/2012/01/31/3148?page=0,1
bigtable
クラウド web サービス
12
表１はこの章で紹介するサンプルで使用されるライブラリ・モジュールとサービス機能
を一覧にした表だ。ここからそれぞれのライブラリ・モジュールを解説する。 まず gaedirect についてだが、gaedirect でクラウド web サービス化により、ここでのア
クセスは全て Javascript で行うことができ、サーバー側のプログラミングは全く必要なく
なる。
２-１-１ Bigtable
今回の gae クラウドのメイン機能である。Google インフラ上につくられた大型分散デー
タベース。テーブルをまとめ合わせる。
２-１-２ Channel API
Channel API は GAE のバージョン１.４.０からサポートされるようになった比較的新し
い通信機能だ。Channel API では、ユーザーから送信されたデータを、他のユーザーにサ
ーバプッシュ形式で送信することができる。サーバプッシュ形式とは、サーバー側から webブラウザ側へデータを送信することである。これによって双方で永続的な通信が可能にな
表１ ThinkIT 使用されるライブラリ・モジュールとサービス機能の一覧 出所: http://thinkit.co.jp/story/2012/01/31/3148?page=0,1
名前 機能
GAE ・Low-Level API
・Channel API
・memcache
Javascript からの bigtable アクセス
Javascript からのメッセージサーバプッシュ
Channel API アクセス時に memcache をキャッシュで使用
HTML5 ・Drag＆Drop
・Web Workers
・Web Storage
・Web SQL Database
・Geolocation
他のドキュメントから書き込みメッセージをドラッグ＆ドロップ
バックグラウンドスクリプトで非同期通信で Channel サーバ送信
PC ローカルストレージに名前、E-mail を書込み・自動表示
PC ローカルストレージにチャットメッセージを SQL 書込・参照
書込み者の位置情報取得と表示
Google Maps チャット参加者の位置を地図上にマーカ表示
jQuery Javascript ライブラリ
DOM ノード操作 タグノートツリーの操作
Ajax 生の Ajax コードで非同期通信
13
る。
２-１-３ memcache
Memcache とは高性能の分散型メモリオブジェクトキャッシュシステムのことである。
このサンプルでは、gardirect は Channel API でユーザから送信されたメッセージを
memcache でキャッシュして、検索レスポンスのパフォーマンス向上をはかっている。次
に HTML５であるが、HTML５ちは HTML４に代わる HTML として策定を進めている
HTML の仕様である。
２-１-４ Web SQL Database
Javascript から SQL 構文を使用して、データ等を PC のローカルストレージ、サーバ側
に保存する機能である。この章で紹介するサンプルでは、チャット参加者が個人的に注目
したメッセージをワンクリックでローカル PC に保存可能にしている。
２-１-５ Web Storage
Web Storage はキー・バリュー型のデータストアである。保存や上書きや削除全クリア
などの操作は Javascript で行うことができる。Webstorage を利用すると、ユーザごとにカ
スタマイズされた情報を提供することあ可能になる。この仕組みはクッキーによく似てい
る。
２-１-６ Geolocation
Geolocation API は HTML５のユーザーの位置情報を取得する機能である。Javascriptで位置情報を取得できるように標準化されている。本来は、位置情報を扱うことができる
API は HTML にはなかったが、HTML５では位置情報を取得するための統一した
Geolocation API が定められている。よって、Geolocation API を備えているブラウザであ
れば、デバイスに関係なく同プログラムで位置情報の取得を行うことができる。
２-１-７Drag＆Drop
HTML５では、ドラッグ＆ドロップの専用の新しいイベント、新しいメソッド等が追加
されている。
２-１-８ Web Workers
Javascript でバックグラウンドでのスクリプト実行を可能にする機能である。よって、
これまで Javascript では不可能であった２つのスクリプトを並行して実行することができ
る。このサンプルでは、WebWorkers のバックグラウンドスクリプトから gaedirect の
Channel サーバにプッシュデータを非同期で通信するプログラムを処理している。次に
14
Web サービスについて。
２-１-９ Google Maps API
Google Maps API とは、指定した座標の地図を表示させマーカーしたり、道のりをしめ
したりするものである。
第２項 多機能チャットの概要
ここからは多機能チャットを詳しく解説する。多機能チャットは Channel API を使用し
てメッセージのやり取りを行うサンプルだ。まず、図を示して解説する。
図７は多機能チャットのシーケンス図である。最初に実行される処理が、(１)の画面のロ
ード完了時に、それまでの bigtable に登録されているメッセージを一覧表示する処理にな
る。次に、(２)で Channel API でメッセージのやりとりをするためにチャンネルをオープ
ンする。 ここからは、ユーザインタラクションによって任意の処理になる。(３)の処理は、ユーザ
ーの書き込みメッセージは Web Workers のバックグラウンドスレッドで Channel サーバ
ーに非同期で通信される。送信されたメッセージは(４)でキャッシュとデータストアへ書き
図７ ThinkIT 多機能チャットのシーケンス図概要 出所: http://thinkit.co.jp/sites/default/files/articles/314803.png
15
込みが行われる。そして、(５)でサーバーに Channel をオープンしている全てのユーザー
に、サーバーからメッセージが送信される。 チャット参加者の画面には、受信したメッセージが画面ロード時に表示されたメッセー
ジ一覧の前に自動で追加される。(６)は、表示メッセージの中に気になるものがあれば、マ
ウスクリックでローカルストレージに保存することができる。
第３節 サンプルプログラムの説明
ここからは、この多機能チャットを構成しているサンプルプログラムの説明を具体的に
解説する。 (１)多機能チャットの初期画面表示
図８ ThinkIT 多機能チャット初期画面表示 出所: http://thinkit.co.jp/sites/default/files/articles/314804.png
16
上記の図８が多機能チャットで初期設定をした時に表示される初期画面である。ここで
は、gaedirect の Channel を経由して Bigtbble に登録されていることが表示される。そし
て、初期設定を行うのは Channel API の初期化を行えばよい。図９の部分で Channel APIの初期化を行っている。そのための初期化の処理は以下の方法と手順である。
①034 行目 clientId = ""+Math.floor(Math.random()*1000000);
Channel APIを行うWebクライアントは必ずChannelクライアントを識別するための
ID を持つ必要がある。この Channel API はクライアントとサーバーの間で永続的に通信
を可能にする。しかし、この場合サーバーとクライアント間でどのようにしてお互いを認
識するかが大きな問題となる。そして、サーバーが通信をクライアント対してどのように
行うかという問題も発生する。そのために、両者をつなぐための両者間できっちりと認識
できる ID を用意するひつようがある。チャンネルキーとも呼ばれる。
②035 行目 token = getToken(clientId);
getToken は gaedirect の関数であり、引数で指定された ID をサーバーに送信する。そし
てこのトークンとはチャンネルごとに割り当てられる英数字をランダムに組み合わせた値
である。クライアントが作成した ID とこのトークンは対になっており、これでチャンネル
の用意が完了する。
③036 行目 channel = goog.appengine.Channel(token);
図９ Think IT リスト２ http://thinkit.co.jp/story/2012/02/06/3175?page=0,0
17
サーバーから返されたトークンに対して、引数でサーバーにリクエストを送信する。そ
の時返されたトークンに対して goog.appengine.Channel を作成しリクエストを送信して、
そこからチャンネルへと通信を開始する。
④038 行目 socket = channel.open():
このプログラムが実行されると、サーバーはクライアントとの Channel をオープンして、
goog.appengine.Channel を返し、goog.appengine.Channel を取得したクライアントは
Channel を使用したサーバプッシュ通信が可能となり、クライアントの初期処理は完了と
なる。
次にメッセージの送受信が行われる。この時のオブジェクトはクライアント側とサーバ
ー側で違うものとなる。まず、クライアント側では XMLHttpRequest オブジェクトを使用
する。この時に、どのチャンネルから送信されたものかをはっきりさせるようにチャンネ
ルキーを受け渡す必要がある。この時、サーバー側は doGet や doPost で処理する。サーバ
ー側は、ChannelService の sendMessage というメソッドを呼び出す。このメソッドでは、
送信するチャンネルを指定するためのチャンネルキーと送信メッセージをまとめた
ChannelMessage というインスタンスを用意しこれを渡すようになる。一方、受け取るク
ライアント側は、goog.appengine.Channel を作成した時、このオブジェクトの onmessageに割り当てられたメソッドが呼び出され、ここでメッセージを受け取った際の処理を用意
する。
(２)多機能チャット画面へのコメント書き込み この多機能チャットでは、名前と E-mail の登録は WebStorage が使用されている。入力
された名前と E-mail は自動的にローカルストレージに記録されて、そのまま自動的に表示
されるようになっている。
18
図 10 ThinkIT 多機能チャット画面にコメントを書き込み 出所: http://thinkit.co.jp/sites/default/files/articles/314805.png
図 11 ThinkIT ChannelAPI のサーバプッシュによる書き込みメッセージ表示 出所: http://thinkit.co.jp/sites/default/files/articles/314806.png
19
上記の図 10 は、上側の画面が本文も書かれている状態だ。そして名前と E-mail のフィ
ールドに入力して書き込みボタンを押すと、図 11 のように表示される。図 11 は、同じ画
面が２つ表示される。よって、図 11 の上側の画面も下側の画面も内容は同じだ。
上記の図 12はチャット参加者が自分の書き込み位置を知られたくない場合に表示される
画面である。図 11 の赤丸で囲った部分の、位置表示 NO のボタンを選択すると、経度と緯
度それぞれに-9999.99 が表示されるようになっている。
上記の図 13 は web storage への書き込みデータ表示をするプログラム例である。HTML５のローカルストレージアクセスは、Key-Value 型と SQL 型の２種類が主なものになる。
図 12 ThinkIT チャット参加者が位置表示を行いたくない場合 出所: http://thinkit.co.jp/sites/default/files/articles/314807.png
図 13 ThinkIT リスト２ http://thinkit.co.jp/story/2012/02/06/3175?page=0,0
20
ローカルストレージとは HTML の中で規定されている、ブラウザ内部の Key-Value 型デー
タストアのことである。名前と Email をローカルストレージに書き込み、２回目からは自
動表示で再入力が必要ないようにする。 ローカルストレージのオブジェクトは、基本的に以下の４つがメインとなる。
①値の書き込み localStorage['key'] = 'value'; ['key']=キーの名前、'value';=値となる
②値の読み取り var value = localStorage['key']; こちらも１と同様['key'];=キーの名前となる
③キーを指定して値を読み取り delete localStorage['key']; 値を削除するには、上記のオブジェクトで実行する
④ローカルストレージ内のすべてのデータの削除 localStorage.clear(); このオブジェクトでローカルストレージ内のすべてのデータの削除が完了となる
ここでは、042 行目と 046 行目でそれぞれ名前とメールアドレス読み取りを行っている
が、それぞれの書き込みデータの取得は、きっちり書き込みがあることを確認してから、
それぞれ localStorage.uname、localStorage uemail で行っている。
21
(３)ドラッグ＆ドロップでのメッセージ書き込み
上記の図 14 の操作で、多機能チャットではドラッグ＆ドロップ機能によって web 画面上
のメッセージやファイル等を書き込みメッセージに追加することができる。
図 14 ThinkIT ドラッグ＆ドロップでのメッセージ書き込み 出所: http://thinkit.co.jp/sites/default/files/articles/314808.png
22
図 15 ThinkIT キー入力テキストの後に表示されるドロップテキスト 出所:http://thinkit.co.jp/sites/default/files/articles/314809.png
図 16 ThinkIT 長文テキストをドラッグ 出所: http://thinkit.co.jp/sites/default/files/articles/314810.png
23
上記の図 15 は、メッセージフィールド上にキー入力メッセージがある場合、図 10 のよ
うに追加されて、メッセージフィールドにドロップされる。赤丸で囲んだところが、メッ
セージフィールドだ。上記の図 16 は wikipedia のようなサイトの文章をドロップしている
が、図 17 の赤丸で囲ったとこのように書き込みの後に問題なくドロップされている。
図 17 ThinkIT 長文テキスト 出所: http://thinkit.co.jp/sites/default/files/articles/314811.png
24
図 18 は送信ボタンをクリックした後の画面である。長文ではあるが、テキストがワンク
リックで他のチャット参加者の画面に表示される。
図 18 ThinkIT 長文テキストの Channel 送信とサーバプッシュ表示 出所: http://thinkit.co.jp/sites/default/files/articles/314812.png
25
上記の図 19 はドラッグとドロップのサンプルプログラムだから、052 行目と 055 行目で
は、テキストのドラッグとドロップを行っている。
①052 行目 ドラッグオーバー時のイベント処理を行っている。addEventListener でオブジェクトに
イベントを追加している。つまり、うえの処理ではドラッグオーバーの処理を呼び出して
おり、このオブジェクトの場合 ondragover ではなく on をつけずに追加する。 ここで preventDefault();とは、このイベントをキャンセル可能という意味合いである。
②055 行目 ドロップ時の処理を行っている。
これも 052 行目と同様、addEventListener でオブジェクトにイベントを追加しているのだ
が、ここでは、ドロップしたいメッセージを入力するフィールドにキー入力等によるテキ
スト表示がある時の処理を行っている。
③057 行目 フィールドに書き込まれているテキストを変数 utmp にセットして 056 行目のドロップ
テキストをその直後につなげる。
④058 行目 057 行目でつなげたテキストをメッセージフィールドに表示するようになっている
図 19 ThinkIT リスト２ 出所: http://thinkit.co.jp/story/2012/02/06/3175?page=0,0
26
(４)ローカルストレージへのメッセージ書き込み
図 20 ThinkIT ローカルストレージへのメッセージ書き込み 出所: http://thinkit.co.jp/sites/default/files/articles/314813.png
27
上記の図 20 のように、表示メッセージの左端のチェックボックスにチェックを入れるだ
けで、書き込み内容がローカルストレージに書き込まれる。矢印で示した部分がチェック
ボックスだ。そして、図 21 のように、ローカル PC データ参照のボタンをクリックすると、
書き込み内容が表示される。図 21 の赤丸で囲んだのがローカル PC データ参照のボタンだ。
(５)チャット参加者の Google Maps 表示
図 21 ThinkIT ローカルストレージの内容を確認 出所: http://thinkit.co.jp/sites/default/files/articles/314814.png
28
図 22 ThinkIT チャット参加者の Google Maps 表示 出所: http://thinkit.co.jp/sites/default/files/articles/314815.png
図 23 ThinkIT マーカクリックで最後の書き込み内容を吹き出しで表示 出所: http://thinkit.co.jp/sites/default/files/articles/314816.png
29
上記の図 22 は、画面上の Google Maps 参照ボタンをクリックすると地図が表示され、
書き込み位置がマーカで示される。マーカとは図 22 の赤丸で囲んだところ。そして、その
マーカをクリックすると図 18 のように表示される。図 23 の赤丸で囲んだとこのように、
最後にやりとりされたメッセージが表示される。
図 24 のように、図 22 のマーカーの部分、つまり図 22 の赤丸をクリックする。すると、
図 23 の赤丸で囲ったようにそのメッセージが表示される。
図 24 図 22 と図 23 の違い 出所: http://thinkit.co.jp/story/2012/01/31/3148?page=0,2
30
上記の図 25 では、ボタンクリック動作への対応処理となっている。
①092 行目 書き込みボタンのクリックにより、入力されたメッセージを gaedirect の Channel サー
バに送信する処理になっている。しかし、実際の送信処理は HTML５のバックグラウンド
スクリプトからライブラリ関数を使用しない非同期通信で行われる。 通信では画面上の、位置情報OKと位置情報NOのラジオボタン選択情報を変数 shoelock
に当てはめ、103 行目で位置情報を取得できた場合に geolocation で位置情報を取得できる
か否かを判定する。Geolocation API とは、ユーザーの位置情報を扱うための API である。
Geolocation API は JavaScript で位置情報を取得できるように標準化されている。
図 25 ThinkIT リスト２ 出所:http://thinkit.co.jp/story/2012/02/06/3175?page=0,0
①
31
上記の図 26 ではユーザー環境で Geolocation API が利用できるかをチェックするため
の JavaScript ソースである。navigator.geolocation を参照することでチェックすることが
できる。
第１項 ブロック①の説明
①104 行目 位置情報の取得をしている。Geolocation API でユーザーの位置情報の取得をする場合、
上記の図 27 の３つである。そして、もし OK な場合は位置情報をそれぞれ変数にセットし
て、108 行目のクラウドへのプッシュ情報アップロード関数 up_to_channel を呼び出す。
位置情報の取得に成功した場合、関数内ではPosition オブジェクトの coords 属性から経度、
緯度、高度などの値を取得する。よって、送信データには Geolocation API で取得された位
置情報も含まれているが、このサンプルの場合スマホは対象外なので、Android 用の gearsに関する外部 JS ファイル指定と、初期設定は行われていない。
図26 HTMLクイックリファレンス ユーザー環境でGeolocation APIが利用でき
るかどうか 出所: http://www.htmq.com/geolocation/
図 27 HTML クイックリファレンス 位置情報取得に関する３つのメソッド 出所 http://www.htmq.com/geolocation/:
32
よって、上記の表２から分かるように 106 行目が緯度情報、107 行目が経度情報で、そ
れぞれ取得している。
表２ クイックリファレンス 位置情報の取得に成功した場合の処置 出所: http://www.htmq.com/geolocation/
図 28 ThinkIT リスト２ 出所: http://thinkit.co.jp/story/2012/02/06/3175?page=0,0
②
③
33
第２項 ブロック②の説明 図 28 は位置情報が取得できない場合の処理である。126 行目の else 以下で仮の値を設定
して、以前と同様に 129 行目で up_to_channel を呼び出して、サーバへのメッセージのア
ップロードを行う。 Channel サーバへのメッセージ送信はバックグラウンドのワーカスクリプトから行われ、
送信完了後のメッセージが返されると 134 行目の匿名関数が起動され、その中でステータ
ス表示を行う。
第３項 ブロック③の説明 142 行目の、メッセージの送受信が終了しソケットがクローズされると、その後 150 行
目～155 行目でクリックに対応した関数がそれぞれ呼び出される。
34
第４章 まとめ
本論文は、クラウドコンピューティングシステムの今後の発展を予想してクラウドにつ
いて述べた。まず始めに、クラウドの概要を簡単に述べることにより、クラウドの基本的
な部分を理解することができた。その基本的な概要を理解したうえで、クラウドの具体的
な利用例を述べることでクラウドが日常にどのように存在しているかを理解することがで
きた。そして、クラウドの概要と利用例を理解したうえで、クラウドのシステムをプログ
ラミングの解説という方面から解説することで、クラウドのシステム構成を理解すること
ができ、クラウドというものになじむことができた。 本論文を述べている途中経過で、公共機関のクラウド利用について述べようとすると、
本論文とは別に論文を作成する必要があることが分かった。公共機関のクラウド利用は、
これからも発展の余地があると判断したため、このことについては追って研究したい。
参考文献
[１]http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0
[２]http://thinkit.co.jp/article/1024/1?page=0,1
[３]八子知礼:図解クラウド早わかり、中経出版、2010 年.
[４]http://www.computerworld.jp/blogs/d/205895
[５]http://www.salesforce.com/jp/
謝辞
同ゼミで共に励んだゼミ生一同に感謝します。プログラミングの知識が全くない状態の
中、熱心に分かりやすく教えてくださった大学院生の方々に感謝します。三回生より、プ
35
ログラミングの知識が全くないままゼミに参加した中で、優しく温かい目でお世話してく
ださり、時には厳しいアドバイスをしてくださった花川典子教授に感謝致します。
