日本IBMの中島丈夫エグゼクティブ・テクニカル・アドバイザー（技術理事）は、クラウドをもう少し過激に見ている。
「クラウドは現在、IT業界や企業のIT部門が開発したり構築・運用している業務ソフトやITインフラ環境のすべてを収容し代替するパラダイムシフトとなり得る。
クラウドでデータセンターが産業化、工場化すると、ソリューション提供とかシステム構築などの業界用語は死語になる。顧客の欲しい“最終製品” がクラウドから出荷されるからだ」
特許権や意匠権のような絶対的独占権ではない。すなわち、既存の著作物Aと同一の著作物Bが作成された場合であっても、著作物Bが既存の著作物Aに依拠することなく独立して創作されたものであれば、両著作物の創作や公表の先後にかかわらず、著作物Aの著作権の効力は、著作物Bの利用行為に及ばない。・・wikipedia
「クラウド・コンピューティング・サービスを提供する他の企業は、データ・センター内の設備のスケール・アウトを進めている。ところが、インターネット側のスケール・アウトを実施する企業はあまりない。アカマイはそこを狙っていく。グーグルやアマゾンのクラウドを巨大な発電所に例えると、送電線と変電所の役割を果たすのがアカマイだ」（アカマイ日本法人の小俣修一社長）
１．prototype.jsライブラリ改善
・HTMLファイル内のparentをいじる参考
・$()にcacheを持たせる参考
・prototype.jsファイルのサイズ縮小参考
初期表示にかかる時間を計ったところ、9秒強（サーバ経由だと17-18秒） ＝＞ 書き換え後8秒強（サーバ経由だと16-17秒）
２．変数格納
・for文の.lengthを一旦変数に格納
初期表示にかかる時間を計ったところ、変化なし
３．jsファイルの圧縮
・他のjsファイルの圧縮もしてみたが、まったくと言っていいほど変わらなかった。
| 初期ロード | タブ移動 | ページ移動 | |
|---|---|---|---|
| APPL1 | 17.9 | 4.1 | 6.8 |
| APPL2 | 12.5 | 4.0 | 3.8 |
| APPL3 | 18.8 | 5.7 | 6.5 |
| APPL4 | 11.3 | 1.4 | 2.3 |
| 初期ロード | タブ移動 | ページ移動 | |
|---|---|---|---|
| APPL1 | 8.9 | 0.1 | 0.1 |
| APPL2 | 6.1 | 0.1 | 0.1 |
| APPL3 | 15.5 | 0.6 | 0.1 |
| APPL4 | 3.1 | 0.1 | 0.1 |
早く成功したいなら、失敗を二倍の速度で経験することだ。成功は失敗の向こう側にあるのだから・・・・
１）目的がはっきりしているか
２）致命的な失敗にならないか
ロスアンゼルスで開催されている、MSさんのイベント、Professional Developer Conference 2008に出ています。
他のメーリングリストに投稿した内容ですが、次回の僕のCloud研究会での報告に関連していますので、ダブル・ポストします。
---------------------------------------------------------------------------------------------------
初日のレイ・オジー（チーフ・ソフトウェア・アーキテクト）のキーノートは、
すべて、同社のクラウド製品、Azure Software Platformにあてられました。MS
が、公式にCloudサービスへの参入を表明したことは、とても大きな意味のある
ことだと思います。すでに、日本のメディアにも、いろいろな紹介が行われてい
ると思いますが、僕には、とても面白いものでした。
どんなものかといわれると、AmazonのEC2/S3＋SimpleDBにGoogleのGoogle App
Engineを足して、もっと、使いやすくしたようなものです。サービスの中核は、
前から僕が予想していたように、SSDS（SQL Service Data Service）によるデー
タ・サービスです。
AmazonのEC2との対比で言うと、EC2が潜在的には前提にしていた、Cloud上での
サーバやディスク等のリソース管理の機能を、明示的に、「CloudのOS」として
のAzureが担うことを明確にしています。EC2では、Cloudの利用者は、具体的に
は、AmazonのCloud OSが提供する、個々のマシンを利用するのですが、Azureで
は、MSのCloud OSであるAzureの提供するサービスを利用することになります。
同じだろうと思うかも知れませんが、その違いは、大きいのです。
Google App Engineでも、利用者は、知らないうちに、Googleの提供するCloud
サービスを利用しているのですが、Azureでは、Cloudサービスの利用は、もっと
Cloudのリソースの利用に、自覚的です。例えば、EC2のように、個々のサーバ利
用を意識する必要はないのですが、Webのサーバをいくつ立てて、ビジネスロ
ジック用のプロセスをいくつは知らせるかというような設定が、Azureでは可能
になります。その点では、僕のCloud研究会の第一回の資料で指摘した、「Multi
-TierアプリのScale-out戦略」の図を見てもらうと、そのイメージはわかりやす
いと思います。Cloud内のいくつかの基本的なサービスのブロック（ロードバラ
ンサ、Web、Worker）のコンフィグが、AppLogicのように、簡単にできます。
この点では、Azureは、Google App Engineと同様に、エンタープライズでの開発
の中心である、Webアプリの開発のCloud化に、明確に焦点を合わせています。
MapReduceのような、汎用の分散アルゴリズムのサポートは、ありません。た
だ、Cloudで動くWebアプリの開発、deploy、実行は、Google App Engineより、
はるかに、簡単で、直観的です。
余談になりますが、キーノートでは、Cloud上で動く、Hello Worldのデモが行わ
れたのですが、これはちょっとわかりにくかったかも。だって、Hello Worldの
文字列が、直接ページに埋め込まれているのか、あるいは、隣のサーバが返す
ページに入っているのか、はたまた、Cloudから来たものかは、見ている人には
わかりませんからね。もっとも、このあたりは、Cloudを概念的にとらえること
の難しさを示しているのかも知れません。
その他、いくつかの特徴があります。思いつくままに触れると、
・Cloud アプリの開発環境の提供。
・Cloud上でのユーザの認証、アクセス管理。（OpenIDを使うのだと思います）
・既存のWeb Appsをクラウド化する手段の提供。
これは、.NET Servicesという製品群にまとめられていますが、以前の
BizTalkの機能をまとめたものですね。個人的には、SOAの発展形としての
Cloud利用という切り口が明確で、面白かったです。
・Cloud内のサービスの連携に、非同期なメッセージングを使うとか、Queuを
使うという話も、なるほどと思って興味深いものでした。もっとも、この
あたりは、数年前から、SOAの世界では言われてきたもので、大事だと思い
つつ、僕は、爆睡してしまいましたが。
・MSのOffice製品群のCloud利用を可能にする、SharePointとの連携。
・企業内（On Premise）既存サービスと、Cloudとの区別と関連付け
最後の点は、IBMさんにしろOracleさんにしろ、既存の製品群とCloud利用が、あ
る点では競合するという問題を、MSさん自身も抱えているという点を示している
訳で、面白い問題だと思っています。
聞いていたひとの反応は、「地味だった」という声が多かったように、思いま
す。以前、マルメでも書いたのですが、このPDCの焦点の一つが、MSのCloudへの
参入の表明にあるという意識は、事前には弱かったのですが、まだ、ちょっと実
感がわいていないようです。（Vistaの後継としてのWindows 7に対する関心の方
が、ずっと高いですね） 講演者も、例えば、Cloudにとって、本質的に重要
な、SSDSのScale-outする特徴に、踏み込まないまま、SSDSの説明をしようとし
たり、MS内部でも、明確な語り口が統一されていないようなところもありました。
ただ、初日のキーノート、まるまるすべてAzureに使ったわけで、それなりに関
心は高まったとは思います。Bill Gatesが引退して、はじめてのPDCらしいので
すが、僕には、別の意味でも、歴史的な会議になるだろうと思っています。
http://www.microsoft.com/azure/solutions.mspx
に、すでに、情報が出ています。是非、チェックしてください。
P.S. CloudのSOA利用のセッションは、激しく寝てしまったのですが、
寝ようと思って出た、「C#の未来」というセッションは、とても
面白かったです。C# 4.0って、Dynamic言語に対応するんですね。
「静的な型として、dynamicという型を導入するんだ」という彼の
説明に、つい笑ってしまったのですが、なかなかの人でした。
mkdir /usr/local/svn/repos
svnadmin create /usr/local/svn/repos
svn import file:///usr/local/svn/repos -m ""
svn co file:///usr/local/svn/repos
home/hoge/svn/repos
svn up /home/hoge/svn/repos/fuga.csv アップデートや
svn ci /home/hoge/svn/repos/fuga.csv -m "" コミット
＜SVNによるEDI＞
＜SVNをEDIで使うメリット＞
１）一貫性確保 ・・・ コミットしたものと送受信したものが同一であることを保障できる
２）実績確認 ・・・ いつ何をどれくらい送受信したか実績を確認できる
３）リカバリ対応・・・ 履歴から過去データを取り出せるためいつでも再送できる
＜SVNをEDIとして使うケース＞
１）物流 ・・・ 物流業者への出荷指示データの送信と出荷済データの受信
２）商品マスタ ・・・ 商品部からの商品マスタの受信とホームページへの反映
３）在庫管理 ・・・ 倉庫からの在庫データの受信とたな卸しデータの送信
その分野に明るくない人にイメージだけを押し付けたり、「よくわからないが凄そうなこと」を想起させることを目的とした宣伝文句として使うことも可能であり、言葉だけが先歩きして広まることも多いため、事情を知らない多くの人は価値のある言葉として捉えてしまうことがある。
１．どんなにトランザクションが増えてもスケールできること
２．その大規模なシステムを安く利用できること
３．サービスレベルを保証できること
１．企業内クラウド
２．PaaS/SaaS型クラウド
１．抽象的に定義されたデータベースサービスへのアクセス手段である
２．企業内クラウドとPaaS/SaaS型クラウドの融合
１．受け付けた注文を取込む機能
２．送り状発行ソフトに渡す出荷データを出力する機能
３．（送り状発行ソフトから）出荷済となったものを取込む機能
４．納品書発行機能
５．ステータス管理機能（受付、確定、出荷済、キャンセル、配完、返品など）
また、必須ではないが以下のような機能も求められる。
６．確定時のカードオーソリ機能
７．受付時と出荷時に案内メールを送信する機能
１） http://kurashide.com/item/4979247561321.html のように、item/{JANコード}.htmlでJANコードさえ分かれば簡単に商品ページを表示できる。
２） http://kurashide.com/category/sofa_zaisu_cushion/sofa/systemsofa/ のように、category/{大カテゴリ}/{中カテゴリ}/{小カテゴリ}といったように、直感的なURL指定でカテゴリに属する商品の一覧を表示できる。また、{小カテゴリ}を省略すると{中カテゴリ}に属する/{小カテゴリ}の一覧が表示され、さらに{中カテゴリ}を省略すると{大カテゴリ}に属する{中カテゴリ}の一覧が表示される。
最初に述べたように、SOAのブループリント策定はうまく行ってもIT実装は難しい、この理由はごく簡単です。ユートピア(理想郷)の青写真を描くだけなら、つまるところ、誰にでもできるわけです。だが、それを実現するには、"部族間主義"のような人間のもつ自然な本質を越える必要があります。一ベンダがそこまで企業の内部に立ち入るのは難しい。
何千とあるSOA導入失敗例を見てきてつくづく思うことは、SOA導入とは「ロケットの発射」に非常によく似ている、ということです。言うまでもなく、ロケットというのは非常に大きなシステムで、それを発射させるにもさまざまな仕組みが必要です。そして発射が失敗するとき、たいていは大きなシステムの中にある小さなコンポーネントどうしの依存関係に問題があります。SOAも同じです。サービスそのものの大きさ(粗さ)よりも、あるサービスは、別のどのサービスにどれだけ依存しているのか、それに対する認識があいまいだと失敗も生じやすくなります。
トップダウンか、ボトムアップか -- SOAに限らずITシステムの導入/リプレースを議論する際、よく登場するフレーズだが、結局のところ、そのどちらであっても組織内から100%の合意が得られることはまずあり得ない。トップから押しつけられた、下の人間が勝手にやった、といった類の言い訳はいつの時代、どこの組織、どのソリューションを使っていても起こるものである。
だが100%は無理でも、少なからず多くの人々が気持ちよく使えるITシステムがあるとしたら、それはやはり、ある一定のルールの下で運営されていることが条件になるだろう。そしてそのルールは、時代と組織に合わせて柔軟な変更が可能であることも求められる。SOAガバナンスの基本はそこにある。
これは要するに、システム共通のentityを定義して、それをやりとりすることだけに注力しようということだ。SOAPやAtomPubなどのAPIを介さないし、そのような共通APIに該当するものを敢えて開発しない。しかし、最低限は必要になるので、先に挙げたリソース志向を踏まえて定義する。具体的には次のような非常にシンプルなAPIを定義することになる。
＜API例（entityはリソースの１インスタンス）＞
entity = create(entity);
entity = retrieve(entity);
entity = update(entity);
entity = delete(entity);
１．入力ボックスの移動順に入力ボックスIDの配列を作成し
２．タブキーが押されたら
３．次の入力ボックスを取得して
４．focus()→select()
１．入力ボックスの移動順に入力ボックスIDの配列を作成し
２．入力ボックスのtabIndex属性に順番をセットして
３．onfocusイベントにselect()を追加してあげる
