July 6, 2009

クラウドコンピューティング、はじめました

「クラウド」とはいったい何か ITベンダーは本質を語れ
http://itpro.nikkeibp.co.jp/article/COLUMN/20090701/332996/

面白いところを突いています。
というか、このブログに書きたかったことを先に書かれたというか。


最近、「クラウドコンピューティング、はじめました」的なベンダーが多いですよね。

でも、この分野で先行し、成功しているのはGoogle、Amazon.com、Salesforce.comであり、これらのベンダーは「クラウドコンピューティング、はじめました」ではありません。
あくまで各社が独自に提供するサービスが先に存在し、そのために整備してきたインフラの解放という形態です。

Googleは言わずとしれた検索エンジンやGmailその他。
Amazon.comはECサイト。
Salesforce.comはCRM/SFA。

そういう観点では、Yahoo、mixi、楽天などにはその素養がありますね。

果たして、何を提供するのかが不明なままに「クラウドコンピューティング、はじめました」のベンダー(FとかHとかIとかUとかSとか)がうまくいくのでしょうか?
ここに先鞭を付けるのはMicrosoftでしょうか?

「クラウドコンピューティング、はじめました」がうまくいったら、クラウドコンピューティングの時代は新しいフェーズに入るのかもしれません。

June 10, 2009

Google Developer Day 2009へ行ってきました。

Google Developer Day 2009へ行ってきました。

R0014405

午前中はミーティングが入っていたため、午後からの参加でした。

残念ながら基調講演は聴けず。
HTML5やGoogle Waveの話があったようです。

R0014401


聴いたセッションは・・・


Google App Engine
- Life of Google App Engine Request -

スピーカーはGoogleのフレッド・ソオー氏。

主にGAEのDatasotre周りの実装テクニックの話でした。
Entityに関連Entityのキーとなる値であるStringのList Propertyを持たせる話とか
Merge Joinのテクニックとか。

私はハッキリ知らないのですが、恐らくLazy Loadingができないため
このようなテクニックが存在するのでは?と思いました。

Joinの話は、Salesforce.comのForce.comも同様なのでよく理解できます。

既にGAEをバリバリ触っているような上級者向けのセッションでした。


Java で動かす Google App Engine

スピーカーはGoogleの夷藤 勇人氏、鵜飼 文敏氏。

こちらはGAE/Jの紹介セッションといった内容。

GAEが何を提供するのか?
認証・Datasotre・キャッシュ・Email・URLフェッチ等でどんなAPIを提供し、どんな実装をしているのか?
Sandbox制限(Force.comのガバナ制限のようなもの)、
今後実装予定の機能、
スケールを考えたデータ構造の設計・実装テクニック(これは直前に聞いたセッションと多少被る内容も。)
などのお話しがありました。

表面上のAPI仕様と実装とが分かれているため、API Proxyというアーキテクチャが実現でき、これによりAOP/インターセプターっぽいことができるという話があり、ちょっとうらやましかったです。
Force.comにもAOP的な機能が欲しいです。

RDBではないので、データの非正規化を恐れずに!という話はよくわかります。あまり細々と正規化してクエリが複雑になるよりは、クラウドにおいてはシンプルなクエリ一発で必要なデータを取れるようにデータ設計するべきですね。

GAEのDatastoreは、「ソフトスキーマ」というアーキテクチャを採用しているそうです。これは、スキーマを固定せずにJPAやJDOのアノテーションのみでスキーマを定義するというものだそうで。
推測するに、Force.comのメタデータに近い概念なのではないでしょうか?
わかりやすく言えば、Force.comではDB物理層に直接テーブル定義を生成しているわけではなく、"メタデータ"と呼ばれる「データ構造の定義」をDBに格納し、実データは多数のカラムを持つ単一テーブルに格納するというアーキテクチャです。
GAEのDatastoreは実装にBigtableが使われているので、やはり物理層にテーブルを作成しているわけではありません。アノテーション定義によってアプリケーション側からはテーブルがあるように見えていながら、その裏側で動いている実装では個々のテーブルを作成せずにデータはすべてBigtableという多数のカラムを持つ単一のテーブルに格納している・・・というアーキテクチャなのでしょう。たぶん。

GAEには非同期処理・テキスト全文検索・インバウンドメール・データのインポート/エクスポート等の機能はまだ実装されておらず、今後実装予定とのことです。
まだエンタープライズ用途では使えないかな。


クラウドコンピューティングがもたらす5つのメリットとは

スピーカーはGoogleの泉 篤彦氏。
エンタープライズ分野のプリセールスエンジニアをされている方だそうです。
このセッションでハッキリ聞くことができました。
Googleがエンタープライズ向けに扱っているサービスには、GAEは含まれていません。

このセッションは、Google AppsのPremier/Education Editionの紹介セッションという色が濃いモノでした。

クラウドコンピューティングがもたらすメリット、というお題ですが、内容はクラウドのメリット、SaaSのメリット、Googleであることのメリット、Google Apps固有のメリットが混在していました。

まあ、キレイに切り分けるのは難しいのですが、気をつけないと「クラウドコンピューティングってよくワカラナイ」という人がますます増えそうです。

他のクラウドサービスとの連携が容易である、というくだりではSalesforceが紹介されていました。

イメージ 1


Google エンタープライズ エコシステムとは –Google Enterprise Partner–

こちらも引き続き泉氏のセッション。

エンタープライズ向けサービスのパートナー制度の紹介でした。


Google テクノロジー ライトニングトーク

サイオステクノロジー松尾さんによる、自作のGAE向けフレームワーク"Kay"の紹介。
デバッガを使えるのがいいですね。Force.comもブレークポイントを置いて、ステップ実行して、変数の値を確認して・・・とできたらいいのに。

Seessaaの安藤さんによる、Rails on GAE/Jの話。
当初はエライ大変な手順を踏まないとGAE/J上でRailsを動作させることはできなかったのを、とてもとてもカンタンにした、というお話し。

日本Androidの会の近藤さんによる、Androidが組み込み業界へ与えるインパクトのお話し。将来はPCと携帯の垣根が無くなるという展望をお話しされていました。

スパイスボックスラボラトリの神部さんによる、Open Social Hackathonのお話し。Hackathonに参加しよう!というメッセージを熱く語っていました。

E-flowの久野氏による、Dalvik VM実装のお話し。Google謹製のDalvik VMがケータイJavaの2~5倍も遅かったので、自分で実装してケータイJavaと同等まで持って行ったお話し。非常に素晴らしい成果だと思います。一方で、Dalvik VMとは何か?に一切触れなかったので、会場には「そもそもDalvik VMってなに?」な人が多かったのでは?と心配になりました。

最後に、松尾氏がTokyo GTUG(Tokyo Google Technology Users Group)を立ち上げました、と紹介されていました。

Tokyo GTUG
http://groups.google.com/group/tokyo-gtug


個人的に(職業柄?)Googleのエンタープライズ向けサービス戦略の情報を得たかったのですが、今のところGoogleのエンタープライズ向けサービスはGoogle Appsと検索アプライアンス、企業向けGoogle Map APIという内容のようです。
GAEはデータ管理やユーザの権限コントロールが不十分だったり、ワークフローなどが実装されてなかったりと、エンタープライズ用途にはまだまだですね。



なんと、事前登録者全員に携帯電話がプレゼントされました。

R0014524R0014521

Google製OS「Android」搭載のHTC製端末です。

R0014523R0014509

先日、サンフランシスコで行われたGoogle I/Oでも入場者に配られたそうですが
まさか、日本でもやるとは!

R0014470R0014492

Googleさん、太っ腹です。

これはdocomoから発売されるHT-03Aとほぼ同等のものです。
http://www.nttdocomo.co.jp/product/foma/pro/ht03a/index.html

docomo発売前なので、この日この端末を手にした人は
恐らく日本で最も早く日本語入力可能なAndroid端末を入手したことに
なるのではないでしょうか。

あともらったのは、タオルとかステッカーとか。

R0014497

事前登録の時にTシャツのサイズを聞かれたので
てっきりTシャツをもらえるのかと思っていましたが・・・
急遽タオルに変更になったのでしょうか。

January 4, 2009

Google App EngineのJava版「Stax」を触ってみました

Amazon EC2上で提供されるJava版PaaSサービス「Stax」をちょっと触ってみました。今のところはβサービスで、まだ実装されていない機能もあったりしますが無料で試すことができます。
「Google App EngineのJava版」としてニュース記事等でも紹介されています。

Java対応のGoogle App Engineとも言うべき「Stax Networks」ローンチ
http://jp.techcrunch.com/archives/20081216stax-networks-launches-google-app-engine-for-java/


用意されている環境

  • Apache Tomcat/6.0.16
  • MySQL/5.0.51

要するにServlet2.5/JSP2.1環境を使えるってことですね。JVMはJavaSE5相当のようです。
GoogleもSalesforce.comも、Servletコンテナにはより軽いResineを採用していますが、ここはTomcatですね。


サポートするフレームワーク
  • Apache Struts(ただし、1.xではなく2.0.11)
  • Apache Wicket
  • Adobe Flex/BlazeDS
  • Google Web Tool Kit
  • Adobe ColdFusion 8
  • JRuby on Rails
とかドキュメントには書いてありますが、アプリケーションの初期作成時のテンプレートとして、デフォルトで必要なライブラリを入れてくれて、最低限の設定済みのxmlファイル類を入れてくれるってだけです。
逆に、WEB-INF/libにライブラリをつっこんで、web.xmlを編集して、WEB-INFに必要な設定ファイルを追加すれば他のフレームワークも使えます。DI/AOPコンテナもORマッピングフレームワークも使えます。
Struts1.3.8/Spring2.5.6/iBATIS2.3.4とか、JSF1.2RI/Spring2.5.6/Hibernate3.3.1とか、試してみたら動きました。この分ならSeasar2を使ったアプリも問題なく動作するでしょう。


アカウントの作成
StaxのWebサイト http://www.stax.net/ へ行きます。



「Apply for the Beta」をクリックしてサインアップ画面へ行き、メールアドレスを入力して送信すると認証メールが送られてくるので、そこに書いてあるURLにアクセスするとサインアップ終了です。簡単です。



改めてStaxのWebサイトからログインするとアプリケーション管理画面に入れます。



管理画面では、TomcatのログやApacheのアクセスログ等の参照、アプリケーションの作成・DBの作成・設定・パフォーマンスやアクセス監視モニタの参照等を利用できます。




アプリケーションの作成
管理画面左側メニューの「Create App」をクリックすると、アプリケーションを作成できます。ユニークな名前を付けましょう。Application Core Runtimeからフレームワークを選べますが、前述の通り、Servlet2.5/JSP2.1環境で動作するものなら好きなモノを使えます。用意されているもの以外のフレームワークを使うのなら「Basic Servlet and JSP」を選択してもかまいません。



Stax SDK http://stax-downloads.s3.amazonaws.com/sdk/stax-sdk-0.2.12-dist.zip をダウンロードして解凍しておきます。
http://www.stax.net/appconsole/createapp から、任意の名前のアプリケーションを作成します。
解凍したディレクトリ中の「Stax Console」ショートカットを起動します。
コマンドラインコンソールが起動するので、そこから
stax getapp -a [ユーザ名]/[アプリ名] -u [ユーザ名] -p [パスワード]
を実行すると、アプリケーションのひな形がダウンロードされます。このひな形はEclipseプロジェクトになっているので、そのままEclipseへインポート可能です。でもこのプロジェクトはWTP互換じゃないのが残念です。


アプリケーションの構造
  • webapp: JavaEE Webアプリケーションディレクトリ
  • src: Java ソースファイルディレクトリ
  • conf/stax-application.xml: Stax デプロイメントディスクリプタ
webappディレクトリの中は通常のServletアプリと同じなので、WEB-INF/libに好きなライブラリを入れたり、WEB-INF/web.xmlを編集したり、設定ファイルやTLDを追加したり、自由にできます。


DBの作成
管理画面左側メニューの「Create DB」をクリックすると、アプリケーションを作成できます。任意のDB名、ユーザー名、パスワードを設定します。



DB作成後、テーブルやら何やらを作成するには、なんとTCP:3306が開いているのでMySQL Query Browser や mysql コマンドが使えます(^^;(←いいのか?)
アプリケーションのconfディレクトリにあるstax-application.xmlに、下記の設定を追記します。

<resource name="jdbc/db01" auth="Container" type="javax.sql.DataSource">
<param name="username" value="[ユーザ名]" />
<param name="password" value="[パスワード]" />
<param name="url" value="jdbc:stax://[DB名]" />
</resource>

Javaアプリケーションからは、JNDI参照名「java:comp/env/jdbc/[DB名]」でLookupできます。


アプリケーションのデプロイと動作確認
コマンドラインから
stax deploy -a [ユーザ名]/[アプリ名] -u [ユーザ名] -p [パスワード]
とすると、作成したアプリケーションをアップロードできます。
Antを使ってWARファイルからのデプロイも可能です。WARファイルをそのままアップロードできるUIがあればいいのに。。。

次のURLからアプリケーションの動作を確認できます。
http://[アプリ名].[ユーザ名].staxapps.net/

何度アップロード/デプロイし直しても反映されるので、クラスローダはカスタマイズしていじっているっぽいですね。Tomcatのデフォルトのリロード機能ではヒープメモリがすぐに破綻しますから。

[追記]
サーバのログを見るとTomcatまんま再起動しているっぽいです。


一度デプロイしたアプリケーションは削除できません(^^;削除機能はまだ未実装のようです。


ちょっと触った所感
Tomcat/MySQL/Eclipse環境に慣れた人ならすぐに開発できるのが良いですね。フレームワークもお仕着せのものだけでなく好きなものを選べますし、使い慣れたRDBがそのまま使えます。Python/Django/webappsにどうしてもなじめず、Google App Engineを放り出してしまった私には嬉しいポイントです。
懸念としては、サーバの信頼性・可用性・セキュリティと正式サービス開始後の料金体系です。まあ、これはすべてのクラウドサービスに言われていることですが。Amazon E2Cを利用しているのでこのレベルではある程度の信頼性はありますが、その上で動作しているアプリケーションサーバレベルではStaxの技術力・資金力・信頼性が問われるところでしょう。

Amazon EC2上に構築されたってのが、次世代のビジネスモデルを予感させます。自前のデータセンターを持たずにSaaS/PaaS事業を展開するという例はこれからも増える可能性がありますね。

December 31, 2008

2008年を振り返って

2008年は「SaaS元年」とも言われましたが、振り返ってみると「SaaS」よりも「クラウドコンピューティング」という言葉の方が幅を利かせていた感があります。

SaaSはクラウドコンピューティングの使い道の1つ・クラウドコンピューティングの1形態ではあります。

クラウドコンピューティングの現状は、まだまだ多くのベンダーが研究開発段階・試験サービス段階だったり、多くのユーザー企業が評価段階だったりするためか、サービスよりもクラウドそのもののアーキテクチャに目を向ける人が多かったような気もしました。


でも、クラウドがどんなアーキテクチャで構成されているのかなんて、わからなくていいんです。マルチテナントとか、内部がP2P的構成になっているとか、メタデータアーキテクチャとか、仮想化レイヤーの構成とか、内輪の話であって、ユーザにとってはどうでもいいんです。


そんなことはわからなくていいのが、「クラウド」なのですから。


そういう意味では、各社のクラウドコンピューティングのインフラが整いつつあり、その上でユーザに対してどんなサービス/プラットフォームが提供されるのか?が問われ、内容と質が比較される2009年こそが、真の「SaaS/PaaS元年」になるのかもしれません。


「クラウドコンピューティングはバズワードに過ぎない」と言う人もいますが、違います。確実に、実用化・事業化・収益化している大手が存在する分野ですから。



今年もあとわずか。ありがとうございました。
来年からは私自身の立ち位置が少々変わるため、これまでのように思いつきでふらっと書くことはできないと思いますが、今後ともよろしくお願い申し上げます。


2008年12月31日

liebejudith拝


December 7, 2008

世界初のJava-PaaSはMSが実現?

この週末、Windows AzureのPDC2008と公式ページでの発表資料を見てました。

AzureがJavaをサポート?

AzureのWebサイトの至る所に「Windows Azure welcomes third party tools and languages such as Eclipse, Ruby, PHP, and Python.」
とあるので、.NET以外のアプリケーションもサポートしそうですね。
How Does It Work?というタイトルのページのComming Soon のところにある図には、Eclipse/Python/Ruby/PHPのロゴが掲載されています。
http://www.microsoft.com/azure/howdoesitwork.mspx

個人的に注目したいのは「Eclipse」です。Javaもサポートされるのでしょうか?
この、PDC2008発表資料の5ページ目には、Javaのロゴが出てきます。
http://mschnlnine.vo.llnwd.net/d1/pdc08/PPTX/BB01.pptx
確かに、現在Windows Server上で動作するモノは基本的にAzureでもサポートすると言ってますし。
でも「Eclipse」ではなく明確に「Java」と記載されている記述は、他には見つけられませんでした。

Google App Engine がサポートを予定している Python 以外の言語に Java が含まれるという噂もありますが、世界初のJava-PaaSを提供するのがMicrosoftということになったら面白いですね。

まあ、Application Serverは開発者側で用意しなければならないと思うので、ミドルウェアやアプリケーションフレームワークまで用意されている Google App Engine や Force.com よりは一段低いレイヤーになるとは思いますが。
とは言え、独自のアプリケーションサーバやフレームワークよりも、使い慣れたモノが使える方が嬉しい人も多そうではあります。


AzureはWindows?

それにしても・・・

まだスクリーンショット等が公開されていないので詳細は不明ですが、ネット上で稼働するということは、クライアントPCからは専用クライアントツール・ブラウザ・開発環境のエクステンション等から接続し、利用するのでしょうか?

もしそうなら、初のGUIの無いWindowsということに。

Windowsの登場以降、「ウィンドウ」という概念によるGUI操作こそが「Windows」という名前の由来だと思っていたのですが。




スケーラビリティの俳句

余談ですが。

これは、PDC2008での講演資料資料にあったものです。

The Haikus Of Scalability(スケーラビリティの俳句)
http://mschnlnine.vo.llnwd.net/d1/pdc08/PPTX/BB54.pptx

You are born nameless You cannot afford the truth You are one of many
初雪や
水仙の葉の
たわむ迄

Your words echo loss
You fail fast, safely return You try again, again
谷水や
石も歌詠む
山櫻

芭蕉・鬼貫ですね。

スケーラビリティを絡めて何を言いたいのか、全然わかりません(^^;


November 29, 2008

セールスフォース・ドットコム岡本君が語るクラウドコンピューティング

差別化できないところにリソースを割くべきか:
クラウドサービス提供ベンダーの視点からみたクラウドの現状
http://www.itmedia.co.jp/enterprise/articles/0811/28/news043.html


この記事を読んで、日本のIT業界ではクラウドコンピューティングへの認識がいかに遅れているかを再確認しました。


岡本君ほどの男がこの内容で講演をしなければならない現実。

彼が、こういう活動に「やれやれ」と思っているのか、充実感を感じているのかは聞いてみないとわかりませんが。

あ・・・なんか誤解を招いていたかも知れません(汗;
ようやく気づきました。
岡本君ほどいろいろ知っていてアイディアも持っている人が話す内容が、聞き手の目線に合わせて会社紹介とクラウドって何?とクラウド使いましょうだけじゃもったいないですよね。岡本君ならもっと面白い話ができるのにね。でも周りがついていかないんだろうなぁ。

・・・って言いたかったのです。
叩いたワケじゃないんです。岡本君、ごめんね。
会社としては、今はこういう場でこういう話をすることは重要なんだろうね。



マルレクという、日本のエンタープライズ系IT業界の最先端に興味を持つ人々が集まるこのセミナーで、この内容で講演が行われる現実。
まだまだ認知度低いんですね。


この程度の内容なら、私にだって喋れます。


クラウドコンピューティングを「市場を形成するビジネス」として認識できていない層がまだまだ多いということなのでしょう。
国内ではまだまだ黎明期なのでしょうか。

事実、実用化・収益化できているベンダーはごくわずかです。



・・・。


このブログでも何度か言及してるので繰り返しになりますが、「どんなビジネスをやるのか?」が無いままに、ビジョンも不明確なままデータセンターだけ作って「SaaS参入」「クラウド参入」などと言い出すベンダーが多いがために、クラウドコンピューティングという言葉は「バズワード」とさえ言われるようになってしまいました。

春頃に、このブログで「SaaSありきでうまくいくはずはない」と書きましたが、この有様です。
「SaaSの収益化は難しい」
「SaaS(という言葉)はサービスの打ち上げにはいいが、利益には結びつきにくいのが現状だ」
http://www.itmedia.co.jp/enterprise/articles/0811/07/news118.html


未だにこんな発言をする大手SIerが幅を利かせていますし。
クラウドに興味を持っている顧客はいる。だが必ず「信頼性は?」と聞かれる。それは残念ながら,今のところないに等しい。「自己責任で使ってください,その代わり安いですよ」。そういうものだと理解している。
http://itpro.nikkeibp.co.jp/article/COLUMN/20081031/318289/


まだまだですね。はぁ・・・


November 6, 2008

Salesforce.comが新サービスを発表

Salesforce.comが、米サンフランシスコで開催中のDreamforceで、様々な新サービスを発表しました。

  • Force.comアプリを外部公開サイトにできるForce.com Sites
  • Force.comアプリでGoogle Visualizationを利用できる
  • Force.comアプリのAmazon EC2/S3対応
  • Force.comアプリからFaceBook APIを利用できる


各機能の解説は各種ニュースサイトにお任せするとして・・・


この中で私が注目するのは「Force.com Sites」です。
http://developer.force.com/sites
単なる外部公開するWebアプリケーションPaaSプラットフォームとして強力なGoogle App Engine対抗となり得るばかりか、独自ドメインも使えるようですし、SFDCがこれまで提供してきたCRM等と連携して、アンケートやお問い合わせ・サポートなど、マーケティングツールとして幅広く使えそうですね。
Google App Engineで同じことをやろうとしたら自分で作り込まなくてはならない部分があまりにも多すぎます。
SaaSベースのCRMを提供している他ベンダー(OracleやSugarCRMなど)が同じことをやろうとしてもまた、自分で作り込まなくてはならない部分があまりにも多すぎます。
この機能はまだDreamforce参加者限定のプレビュー版ということですが、この機能を使うにはライセンス料がそれほど安くはなさそう・・・と予測しますが・・・。


それから、Amazon EC2/S3対応。
http://wiki.apexdevnet.com/index.php/Amazon_Toolkit
つい先日のエントリーで、オープン性・互換性についての懸念を書いたばかりですが、SFDCはちゃんと対応を考えていました。

まだチュートリアルをちゃんと見ていませんが・・・

Force.comで作成したアプリをAMIにしてAmazon VM上で動作させることができるのかな?

私は、ユーザがクラウドコンピューティングへの抵抗を感じるポイントとして、セキュリティ面の他に互換性の問題があると思います。
クラウドコンピューティングプロバイダのサービス廃止は、フェイルオーバー、サービス障害、プロプライエタリ技術による囲い込み以上に大きな問題です。ユーザは、SFDCのアプリを使えば使うほど、「これが無くなったらどうしよう?」と思いますから。
作成したアプリが、SFDCのクラウド上でも、Amazonのクラウド上でも動作できるならば、ユーザにとって大きなメリットになるでしょう。

ストレージとしてS3が使えるのも大歓迎です。


Facebook連携は・・・
日本国内ユーザはあまり多くないのでまぁいいでしょう(笑)

October 19, 2008

Force.comのApex

約1年前に発表されたSalesforce.comが提供するアプリケーション開発環境・動作環境「Force.com」。
Salesforce.comは「SDKを配布するからインストールしてアプリ開発してね」ではなく、アプリケーションの統合開発環境・テスト環境までもWeb上に乗っけてきました。統合開発環境のSaaS化です。アカウントを取得すればブラウザを起動するだけでSalesforce.comのクラウド上でアプリ開発可能です。
しかも既に実用化・収益化できています。Salesforce.comの強みであり、他社がなかなか追いつけない要素の1つでしょう。
はじめて知ったときは、何てスゴイモノを作ったんだ!と驚愕しました。

しかし・・・

プログラミング言語が「Apex」という独自言語なのが惜しいところ。

中身を開けてみればJavaに似ているし、シンプルで覚えやすいのですが・・・
開発者の視点から見るとどんなにカンタンでも「新しい言語を覚えなくてはいけない」というだけで壁が1枚できるものです。

「マルチテナント」と「安全性」を両立するためには、Salesforceのプラットフォームのコア部分が動いているモノ(ここはJavaです)を共有させるわけにはいかず、もう1層上にVM(のようなモノ)を乗っける必要があることは理解できます。

でも、そこがJavaであってもいいはず。

やはり、過去のSunと他社との経緯を無視できなかったのでしょう。

Sunは、Java標準仕様に独自の拡張や独自の制約を設けることに関しては煩いですから。

MicrosoftはJavaに独自の拡張をしたためにSunに訴えられ、長い法廷闘争の末にJava2以降の実装を許されなくなりました。

最近では、GoogleのAndroidも独自のアーキテクチャゆえ、SunとGoogleの間で少し揉めました。


そんなわけで、Sunが進めているProject Carolineには注目しています。SunはProject Carolineで、JavaによるPaaSを実現しようとしています。

Sunの中の人に聞いた限りでは、Project CarolineがSunのクラウドコンピューティング戦略のメインストリームというわけでもなく、SunのPaaSはProject Carolineで行くと決まっているわけでもなく、ただの研究開発プロジェクトの1つでしかない、ということですが・・・

将来的には、EclipseもSaaS/PaaS化したいという噂もちらほら。

Amazon/Oracleあたりで、Xenベースのオープンなアーキテクチャなクラウドコンピューティングという流れもあります。


これらが実用化されたらForce.com/Apexやばいかも。

今はSalesforce.comが先行しています。他社が追いつくまでに時間がかかるので、その間にデファクトを握ってしまおうという方針でしょうか。
それとも、オープンなアーキテクチャへの大幅な方針転換の可能性も視野に入れているのでしょうか。

個人的には、Force.comのプログラミング言語がJavaになってくれたら言うことナシです。

October 5, 2008

最近のクラウド・SaaS・PaaS

Cloud Computing
最近、データセンターを作っただけで「クラウド参入」とか言ってる企業、多くないですか?
「データセンター」を「クラウド」と言い換えているだけのような。
「クラウド・コンピューティング」は「仮想化」以来の“乱用語大賞”
「過大な情報がIT業界に混乱を招く」とガートナーが警鐘
  ※「MSとIBMが使い出した時点でバズワード化する」とはS社のO氏の発言。(^^;


SaaS
実態はただのWebアプリやASPなのに「SaaS参入」とか言ってる企業、多くないですか?
SaaSと言いながらクラウド環境・マルチテナント環境ではないため、いったいどれだけスケールするのか不安で仕方ない「SaaSもどき」が増えてきました。


PaaS
これを実用化・収益化できている企業はごくわずか。さすがに猫も杓子も「PaaS」と言い出すまでには至っていませんね。




各社の動向
最近の各社の動きはどうなっているのでしょうか?
大きく分けると、

  1. クラウドインフラのみ提供
  2. アプリケーションを提供(SaaS)
  3. アプリケーション動作環境を提供(PaaS)
といった分類になるでしょうか。


Yahoo/HP/Intel連合
まだ研究開発段階。クラウドインフラと、もしかしたらPaaSも?
HP、インテル、ヤフーの3社、クラウド・コンピューティングの共同研究プロジェクトを発表


ユニシス
「SaaSはじめます」と言ったが、その後進んでいるのだろうか?「乗り遅れたくない」感で言ってみただけ?
日本における早急なPaaS、CaaSの確立を目指す~ユニシス


富士通
「SaaSはじめました」と言ったが、その後進んでいるのだろうか?「乗り遅れたくない」感で言ってみただけ?
富士通が SaaS 3 サービスを開始


IBM
データセンターをばんばん作っている。その上で何をやるのだろう・・・。クラウドインフラと、もしかしたらPaaSも?
IBM、「Blue Cloud」コンピューティング計画を発表
IBM、世界4カ所にクラウド・コンピューティング・センターを開設


Sun
Project Carolineは大注目。Salesforce.comが成し得ていない、標準言語(Java)によるPaaSを実現しようとしている。でもまだ研究開発段階。
サン、PaaSモデルの研究プロジェクト「Project Caroline」を披露


Google
Google App Engineはアプリケーション実行環境の提供という形式でPaaSをやっているけど、アプリケーションの開発作業はローカルマシン上で行ってそれをアップロードするしかない。
ここ1年ぐらい、エンタープライズ分野では最近目立った動きがないが、Mobile側(Android)からクラウドの使い道を広げようとしている。うまくいけばこっちの切り口からエンタープライズ分野へ食い込んでいけるのかも。
「独創的な」という言葉がぴったりなこの企業の動きには常に要注目。


Amazon.com
インフラの提供はしっかりやっているけど、その上で何をするのか?は利用者任せ。今のところ、Amazon.com自身はECサイト以上のサービスをしていない。Amazon WSは、実質はレンタルサーバっぽい使われ方がほとんどなのでは?


Microsoft
クラウド上にWindows Serverが乗っかって、何が嬉しいのだろうか・・・
MSのクラウドへの取り組みは、Office Suiteにしろ、OSにしろ、結局クライアントパッケージをインストールしないと使えない「非SaaS」なものになるでしょう。
MSのバルマーCEO、「Windows Cloud」の詳細に言及


Oracle
Siebel on Demandなど一部SaaSを提供しているけど、いったいどのぐらい儲かっているのだろうか。MS同様、パッケージライセンスの売上によって過去最高利益を更新し続けているこの企業が、本気でSaaS/PaaSに取り組むとは考えにくい。
Amazon WS上にOracle Databaseを乗っけるパッケージの提供も始めるらしいけど、自社パッケージをクラウドに乗せますという点ではWindows Cloudと同じ。自分でアップロードして展開して設定してね、という点ではもっとひどいかも。すぐに使えるDaaS(Database as a Service)を用意していたらちょっとは「ほう」と思ったかも。
オラクルのクラウドへの第一歩


RedHat
Amazon WS上でJBossが動くようになるらしい。
Red Hatが見据える次世代のアーキテクチャ


Salesforce.com
結局、「クラウドだけどSaaS/PaaSではない」サービスは、ユーザーにとってはハードウェア準備・運用の手間は省けるけど、サーバソフトウェアの構築・管理、アプリケーション開発をしなければならないことは変わらず。MSのアプローチはまた独特だけど。
また、クラウドはそれだけではその存在に意味は無く、クラウド上で提供されるサービスがビジネスとして確立しないと成り立たない。エンタープライズ分野でインフラ・ミドルウェア・アプリケーション・開発環境まで(クラウドからSaaS/PaaSまで)トータルに提供し、実用化・収益化できているのは、事実上SFDCのみか・・・


今のところ、Salesforce.comが独走態勢で、他企業が技術・サービス両面で追いつくのはもう少し先になると思う。

SFDCを脅かすのは、オープン化の波かもしれない。
Amazon WSがXenベースであるため、JBossやOracleは対応できた。
アメリカではAmazon WS互換の他社サービスも始まっているらしい。Amazon WSのバックアップやフェイルオーバー用途に使えるとのこと。
数年後にはプロプライエタリなテクノロジによる囲い込みをオープンソースが切り崩すという波がクラウドコンピューティングの世界にも来るかもしれない。

July 3, 2008

Tour de Force Tokyo 2008 へ行ってきました

Salesforce.com の開発者向けイベント Tour de Force Tokyo 2008 へ行ってきました。

午前に行われた基調講演は US 本社CEO兼会長であるマーク・ベニオフ氏の講演。
立ち見を含めてギッシリ満員御礼でした。

以前から Salesforce.com に興味を持ち、開発者アカウントでいろいろいじっていた私にはあまり目新しい内容ではありませんでしたが、その中で PaaS こそが Web3.0 であると言い切っていたのが印象的でした。
これには、多方面からいろいろな意見があるかとも思いますが・・・
いつもながらマーク・ベニオフ氏のメッセージはわかりやすく、しかし日本で発言するには少々刺激的にも感じます。

午後のセッションはシステム管理者、IT管理者およびビジネスアナリスト向け (アプリケーション構築初級)、開発者、プログラマ向け (Apex/Visual Force を駆使したプログラミング上級者向け)、ISV,起業家向けと分かれていました。もちろん私は開発者、プログラマ向けのセッションに参加しました。SFDC へ転職した後輩はシステム管理者、IT管理者およびビジネスアナリスト向けのセッションを担当していたらしいのですが・・・。

セッションの内容そのものは私には新しい情報ではありませんでしたが、デモコーナーで SFDC のエンジニアの方とお話しして、作成したアプリケーションのテストについての情報を得られたのが収穫でした。

Force Builder (Web上での開発環境) では、作成したアプリケーションには JUnit のようなメソッド単位のテストコードを書くことができ、75%以上のカヴァレッジが得られないと本番環境へのリリースができないようになっているそうです。
ただしテストコードは Force Builder に限られていて、ForceIDE (Eclipse プラグインでの開発環境) でのユニットテスティングフレームワークが提供されていないのが残念ですが・・・
UI 上のテストは、セレニウムなどを使うしかなさそうです。
しかし、SFDC のすべてのエンジニアがそのあたりを把握しているわけではなさそうです。初めに私が質問した方はテストについてはほとんど答えられませんでした。
後でSFDC へ転職した後輩に聞いたらすべてクリアになりましたが(笑)

エンタープライズ向けアプリケーションの開発では、手動&目視によるテストのみなどという状況はありえません。
少し規模のあるカスタムアプリケーションを作成した場合はユニットテスティングフレームワークが必要になると思われますので、開発者向けの機能に関する今後の展開に期待したいところです。
カスタムオブジェクトを扱う、DbUnit のように更新系テストのための機能を提供するテスティングフレームワークも欲しいですね。


それから、せっかくのテクニカルセッションなので、電源と無線LANを用意して、ノートPCをお持ちの方はその場で試せます!みたいになってるとよかったかも。
体験コーナーの台数も多くなかったし。


June 9, 2008

SaaSを取り巻くIT政策

看過できない言葉が並んでいます。

「システムの完成が半年遅れたら、サービスの開始も半年、1年遅れてしまう。これが原因でライバルに負けてしまうことだってあります。」
「事業者数で中堅・中小企業の8~9割を占める、10人以下の小規模な企業では、パソコンはあるんだけれども、電子メールくらいにしか使っていないという現状があります。」
「8~9割の小規模事業者は永遠にITを使わなくなるかもしれないといったくらいの危機感があります。」
「ITを活用する企業とそうでない企業の二極化は、深刻という言葉では表現しきれないところまで進んでいるといっていい。」

http://itpro.nikkeibp.co.jp/article/Interview/20080603/305821/

この、経済産業省 商務情報政策局 情報処理振興課長 八尋 俊英さんという方、ちゃんと見ているな、という印象です。

官公庁のIT戦略は現状を見ていない、使われ方も予想できないずさんなものも多いのですが、こういう方が日本のIT政策を牽引するなら、と期待します。


・・・というか、このレベルで議論される時点で日本のITを取り巻く状況ははまだまだとも言えます(笑)
当然の認識とされてしかるべきで、議論の余地など無いとも言えますが。

先日のこの記事を見て、SaaSありきでうまくいくはずはないと思いましたが、
http://www.atmarkit.co.jp/news/200806/04/unisys.html
この八尋さんという方はそれをわかっていらっしゃいますね。

まずは何をサービスとして提供するのか?が先にないと。。。

May 31, 2008

SalesforceをVPNで利用可能に。

少し前の記事ですが・・・

セールスフォースのSaaS型アプリがVPNでも利用可能に--NTTグループと連携
http://japan.zdnet.com/security/story/0,3800079245,20373964,00.htm

それほど大きく取り合げられたニュースではないのですが、これは日本で普及するための大きな武器になるのではないでしょうか?

導入を検討企業にとっては、Google Apps との連携よりもこちらの方が、よっぽど大きなアピールになり得ます。

通信内容は暗号化されていようと、データセンターはどんなにセキュアだと言われようと、それでも重要な社内情報や顧客情報をインターネットに晒すことに大きな抵抗があると考える企業は多いですから。

May 12, 2008

SaaS 普及のカギ

今 SaaS を手がける代表的な企業といえば、Google と SalesForce.com です。

しかし、両社のサービスに私は不満です。

何がって?

SaaS Office Suite
(残念ながら?)世の中の人々(特に企業ユーザー)は、MS Office を手放せません。SaaS ドキュメントにも MS Office 完全互換を求めています。
Google Document が MS を打倒できない理由は、ズバリ MS Office 完全互換でないからです。一応 MS Office 形式でエクスポートは可能ですが、マクロは動作しないし、レイアウトが崩れたりします。
OOo の普及が進まないのも、MS Office 完全互換ではないからという理由に他ならないからでしょう・・・

MS さん!何やってるんですか?
Office ドキュメントと Web 上のドキュメントのインポート/エクスポートを完全に行える SaaS 形式の Office Suite をリリースすればみんな使うのに・・・
結局、最終的にはローカルへのインポート/ローカルからのエクスポートの需要はあるのだから、ユーザーが増えれば(減らなければ)Office は売れ続けるのに・・・
マクロも消えない、完全互換の SaaS ドキュメントは(現在のところ) MS だけが作れるものなのに・・・
「オープンである」とかはきれい事。特に企業ユーザからは MS Office 完全互換が求められているのが事実だと思います。
Web にインポート/エクスポートできる MS Office ドキュメントは厳密に言えば SaaS ではないのですが、ユーザが求める物を提供することは大事ですよね。


クラウド/ PaaS
SalesForce.com の Force.com は Apex という独自言語と独自 API がネックですね。他のプラットフォームへ移植できませんから。
Google App Engine も、同じ理由で Bigtable がネックです。

Sun さん!何やってるんですか?
完全 Pure Java なクラウド環境をリリースすればみんな使うのに・・・
Glassfish が使えて、H2 や Derby (JavaDB) が動作すれば言うことナシです。
Google App Engine なんてメじゃないのに・・・
完全 Pure Java なクラウド環境がリリースされれば Java テクノロジはますます躍進するでしょう。そして、Sun は PaaS 分野のリーダーとなれるでしょう。

・・・とここまで書いて思い出しました。たしか、Sun は非営利団体等へ仮想化サーバスペースを無償で提供するというソリューションをやっていたはず。・・・
ただし、米 Sun のサービスで日本語文字コードセットの扱いに問題があったような。
具体的な資料は探し出せず。。。残念。



Web メール
SaaS の普及がもっとも進んでいる分野が Web メールでしょう。Gmail、Hotmail (Windows Live! Mail)、Yahoo! Mail を利用している人はとても多いと思います。
しかし、メインではメーラーによる POP アクセスが主で、Web メールの利用はプライベートでは 30%、ビジネス利用では 10% 以下です。(2007年9月の記事による)

Web メールメイン利用、仕事では約9%・自宅では約30%
http://japan.internet.com/research/20070920/1.html

Web メールの利用はセカンドアドレスや「漏洩・流出してもかまわない、いざとなったら捨てられるアドレス」としての利用が大多数なのではないでしょうか。企業ユースではさらに比率が下がりますが、これは情報漏洩対策等の結果でしょう。


SaaSを使わない理由
こんな記事もありました。

SaaSを使わない理由――IT投資調査から
http://www.itmedia.co.jp/enterprise/articles/0805/14/news015.html
それなりに多いSaaS普及への課題
http://www.itmedia.co.jp/enterprise/articles/0804/25/news007.html

May 11, 2008

au one メール

au は Google と提携して、au one メールに Gmail を採用しているのですが・・・

Gmail の新バージョンになかなか対応しません。

au one メールは POP や IMAP を禁じているなど、標準の Gmail そのままではなくてかなりカスタマイズしている模様です。
おそらく、このカスタマイズゆえに Gmail 新バージョンへの対応が追いついていないのでしょう。

バージョンアップや機能追加に対応できないのなら、SaaS の意味が半減してしまいます。

変にカスタマイズしないで、デフォルトのまま Google Apps を利用すればいいのに・・・

ちなみに、livedoor mail がそのスタイルですね。

April 30, 2008

Google App Engine で Web アプリケーション ~ その2

Google App Engine は、Django というフレームワークがデフォルトで利用できます。この Django には強力なテンプレートエンジンが含まれています。

前回までのような方法で画面を出力するのは少々骨が折れますが、Django のテンプレートエンジンを使うと HTML ベースの画面を作りやすくなります。

Javaで言うところの、Velocity や FreeMarker のようなモノですね。


というわけで、今回はこれを利用してみました。


テンプレートとなるファイルを作成する

拡張子は .html で OK です。


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>ようこそ</title>
</head>
<body>
  <center>
    <br />
    <h3>ようこそ!{{username}}さん!</h3>
    <br /><br />
    <a href="/index.html">戻る</a>
  </center>
</body>
</html>


Django テンプレートでは、動的に値を埋め込みたい箇所は、{{...}} で囲み、括弧の中に変数名を記述しておきます。オブジェクトの属性にアクセスするには、user.username のように、. (ドット) で区切ってネストを指定します。


テンプレート出力処理を行うには

こんな風に書きます。

# テンプレートを取得
templatefile = os.path.join(os.path.dirname(__file__), 'テンプレートファイル名')
# パース・コンパイル・出力処理
self.response.out.write(
  template.render(templatefile, {'変数名':オブジェクト}))

template.render() メソッドの引数には、出力したいオブジェクトと、そのオブジェクトの変数名を連想配列の形式で記述します。複数指定したい場合は

template.render(templatefile, {'変数名1':オブジェクト1, '変数名2':オブジェクト2, '変数名3':オブジェクト3}))


のように書きます。



というわけで、前回のアプリケーションを、Django テンプレートを使ったものに書き換えてみると、こうなります。


[index.html]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>ようこそ!</title>
</head>
<body>
  <form action="welcome" method="post">
    <center>
      <br />
      <h3>お名前は?</h3>
      <input type="text" name="username" size="30" />
      <br /><br />
      <input type="submit" value="送信" />
    </center>
  </form>
</body>
</html>


前回と同一です。


[WelcomeRequestHandler.py]

# coding: UTF-8

import os
import wsgiref.handlers

from google.appengine.ext import webapp
from google.appengine.ext.webapp import template

# webappのインポート
from google.appengine.ext import webapp

class WelcomeRequestHandler(webapp.RequestHandler):

  # HTTP post リクエスト処理
  def post(self):
      # リクエストパラメータ "username" の取得
      userName = self.request.get("username")

      # テンプレートファイルを取得
      templatefile = os.path.join(os.path.dirname(__file__), 'welcome.html')
      # パース・コンパイル・出力処理
      self.response.out.write(
        template.render(templatefile, {'username':userName.encode('UTF-8')}))

def main():
  # リクエスト URL パターンと、実行するクラスの関連づけ
  application = webapp.WSGIApplication([('/welcome', WelcomeRequestHandler)],
           debug=True)
  wsgiref.handlers.CGIHandler().run(application)

# アプリケーション起動時に main() 関数が実行されるようにする
if __name__ == "__main__":
  main()


前回は、HTML タグなどを直接出力していましたが、今回はテンプレートを利用してレスポンス出力を行っています。


[welcome.html]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>ようこそ</title>
</head>
<body>
  <center>
    <br />
    <h3>ようこそ!{{username}}さん!</h3>
    <br /><br />
    <a href="/index.html">戻る</a>
  </center>
</body>
</html>


「ようこそ!{{username}}さん!」の箇所に注目です。WelcomeRequestHandler.py で、リクエストパラメータから取得した値を "username" という名前でテンプレートオブジェクトとして指定しました。この welcome.html では、その "username" という名前の変数の値を出力しています。


[app.yaml]

application: liebejudith-helloworld
version: 1
runtime: python
api_version: 1

handlers:
- url: /welcome
  script: WelcomeRequestHandler.py
- url: /index\.html
  static_files: index.html
  upload: index.html
- url: /
  static_files: index.html
  upload: index.html


前回と同一です。


実行結果




実行結果も前回と同一です。


HTML センシティブな文字・記号のエスケープについて

Webアプリケーションでは、正しい表示やクロスサイトスクリプティング対策のために、< や、> など、HTML や JavaScript コードとして認識されてしまう文字をエスケープする必要があります。
現在のバージョンの Django では、デフォルトでエスケープが有効になっています。もし何らかの理由でエスケープ処理を無効にしたい場合は、


こんにちは {{ username|safe }} さん


のように、safeフィルタを利用します。
あるいは、


{% autoescape off %}
    こんにちは {{ username }} さん
{% endautoescape %}


のように、autoescape タグを使って、off オプションを指定します。Django テンプレートでは、タグの表記に {% ... %} を使います。


ループ処理を行うには

for タグを使います。Velocity や FreeMarker を使ったことのある方なら直感的におわかりでしょう。


{% for 要素 in リスト %}
    ・・・・
{% endfor %}


ループの中では、次の変数を利用できます。

forloop.counterループカウンタ(1から開始)
forloop.counter0ループカウンタ(0から開始)
forloop.revcounterループの終わりからのインデックス(1から開始)
forloop.revcounter0ループの終わりからのインデックス(0から開始)
forloop.firstループの最初の繰り返しの場合、True になる
forloop.lastループの最後の繰り返しの場合、True になる



条件分岐を行うには

if タグあるいは ifequal/ifnotequal タグを使います。

if タグを使った評価

指定した変数が存在するか・空ではないか(リストの場合)・Trueかを評価します。


{% if name_list %}
    ・・・・
{% else %}
    ・・・・
{% endif %}


or not and を使って複合的な評価も可能です。


{% if name_list or order_list %}
    ・・・・
{% endif %}



{% if not name_list %}
    ・・・・
{% else %}
    ・・・・
{% endif %}



{% if name_list and order_list %}
    ・・・・
{% endif %}



{% if name_list and not order_list %}
    ・・・・
{% endif %}



ifequal/ifnotequal タグを使った評価

2つの値が同一かどうかを比較します。
ifnotequal は同一でないかどうかを比較します。
2つの値はスペース区切りで指定します。


{% ifequal user.id comment.user_id %}
    ...
{% endifequal %}



{% ifnotequal user.username "liebejudith" %}
    ...
{% endifequal %}




画面部品をインクルードするには

include タグを使います。
ファイル名は、文字列リテラルで直接指定することもできますし、変数を使っての動的指定も可能です。


{% include "foo/bar.html" %}



{% include template_name %}




コメントを記述するには

{# ... #} で囲みます。


{# comment #}




テンプレートの継承

Django では、テンプレートを継承することができます。この機能は、同一レイアウト、同一部品を使った似たデザインの画面が多数存在する場合に非常に便利です。
子テンプレートでオーバーライドする部分は、{% block ブロック名 %} ~ {% endblock %} で囲んで記述しておきます。ブロック名はユニークな任意の名前です。


<html>
<head>
    <title>{% block title %}タイトル{% endblock %}</title>
</head>

<body>
    <div id="content">
        {% block content %}{% endblock %}
    </div>
</body>
</html>


あるテンプレートを継承したテンプレートを作成するには、{% extends "親テンプレート名" %} を記述します。そして、親で定義された {% block ブロック名 %} ~ {% endblock %} を任意にオーバーライドできます。


{% extends "base.html" %}

{% block title %}子ページ{% endblock %}

{% block content %}
content 部分のオーバーライド
{% endblock %}




変数値の出力、条件分岐、ループ処理、インクルード、テンプレートの継承と見てきました。これでたいていの画面は作成できるのではないでしょうか?


Django の翻訳ドキュメントも見つけました。Yasushi Masuda さん、Takanao Endoh さんという方が翻訳されています。

Django
http://ymasuda.jp/python/django/index.html

Django オンラインドキュメント和訳
http://michilu.com/django/doc-ja/index/

Django は、テンプレートエンジンだけでなくアプリケーション全体をカバーするフルスタックのフレームワークです。今回取り上げたテンプレートのリファレンスはこちらです。

テンプレート作者のための Django テンプレート言語ガイド
http://michilu.com/django/doc-ja/templates/

Django のユーザコミュニティも存在するようですが、残念ながら現在はサーバが止まっているようです・・・
http://djangoproject.jp/


私は Python 初心者のため、定石もお作法も知りません。バリバリの Python 使いの方から見たらとんでもないコードを書いているかもしれませんがご容赦下さい。間違いや「こうするもんだ」を指摘していただけるととても嬉しいです。

環境: Python 2.5

April 22, 2008

Google App Engine で Web アプリケーション ~ その1

Google App Engine には webapp という、Webアプリケーションのためのシンプルなフレームワークが用意されています。
前回はとりあえず Hello World まで行ったので、次はこの webapp フレームワークを使ってリクエストパラメータを受け取り、それを表示するアプリケーションを作ってみました。





私は Python 初心者のため、定石もお作法も知りません。バリバリの Python 使いの方から見たらとんでもないコードを書いているかもしれませんがご容赦下さい。間違いや「こうするもんだ」を指摘していただけるととても嬉しいです。

環境: Python 2.5


ソースコードを UTF-8 で書くには

ソースコードの1行目または2行目に


# coding: UTF-8


と書きます。

こうしないと、文字列リテラルの前には u'こんにちは' のように、毎回 u をつけないといけなくなってしまいます。それはあまりに面倒です。


HTTP post リクエストを受けるには

webapp.RequestHandler を継承したクラスを定義し、post() メソッドを定義します。

(例)


class WelcomeRequestHandler(webapp.RequestHandler):
  def post(self):


HTTP get リクエストを受けるには、post() ではなく get() メソッドを使えば OK です。使い方は post() と全く同一です。他にも、Restful なアプリケーション構築のために put() delete() head() trace() options() が用意されています。

 ※ Python って、メソッド?関数?どう呼ぶんでしょう?


リクエストパラメータ値を取得するには

RequestHandler オブジェクトに用意されている属性 request の get() メソッドを利用します。引数にはリクエストパラメータ名を指定します。

(例)


userName = self.request.get('username')


これは、"username" という名前のリクエストパラメータ値を取り出し、変数 "userName" に入れておく、という処理になります。


リクエストパラメータが来なかった場合のデフォルト値を同時に指定することができます。

(例)


userName = self.request.get('username', default_value="anonymous")


上記の場合、リクエストパラメータ"username"が来なかった場合は変数"userName"の値が"anonymous"になります。

同名のリクエストパラメータが複数来る場合は

(例)


userNames = self.request.get('username', default_allow_multiple=True)


この場合、変数 userNames は配列になります。


レスポンスを出力するには

こう書きます(^^;



self.response.out.write('出力したい文字列')




変数の値を出力するには

こう書きます。



self.response.out.write(変数名.encode('文字エンコーディング名'))


これ、ハマりました。self.response.out.write(変数名) とするだけでは、実行時に UnicodeDecodeError とエラーになります。Python を使い慣れている方なら何でもないことなのでしょうけど・・・


リクエスト URL パターンと、実行するクラスを関連づけるには

こう書きます。



def main():
  application = webapp.WSGIApplication([('URLパターン', クラス名)],
           debug=True)
  wsgiref.handlers.CGIHandler().run(application)




アプリケーションが起動したら main() 関数が呼ばれるようにするには

こう書きます。



if __name__ == "__main__":
  main()




ある URL にリダイレクトするには

redirect() メソッドを使います。


self.redirect('http://www.google.co.jp/', False)

2番目の引数に True を指定すると、HTTP Status 301 での Redirect になります。False を指定した場合は HTTP Status 302 での Redirect を行います。

 ※Python の True/False って、大文字からはじめるんですね・・・


例外発生時の処理を記述するには

RequestHandler クラスの handle_exception() メソッドを使うらしいのですが、使い方がよくわかりません・・・



以下、全ソースコード。

[index.html]


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>ようこそ!</title>
</head>
<body>
  <form action="welcome" method="post">
    <center>
      <br />
      <h3>お名前は?</h3>
      <input type="text" name="username" size="30" />
      <br /><br />
      <input type="submit" value="送信" />
    </center>
  </form>
</body>
</html>


テキストボックスとsubmitボタンが一つずつあるだけのシンプルなフォームを実装した単純な HTML です。


[WelcomeRequestHandler.py]


# coding: UTF-8

import wsgiref.handlers

# webappのインポート
from google.appengine.ext import webapp

class WelcomeRequestHandler(webapp.RequestHandler):

  # HTTP post リクエスト処理
  def post(self):
      # リクエストパラメータ "username" の取得
      userName = self.request.get("username")

      # レスポンス出力
      self.response.out.write('<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">')
      self.response.out.write('<html>')
      self.response.out.write('<head>')
      self.response.out.write('<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">')
      self.response.out.write('<title>ようこそ</title>')
      self.response.out.write('</head>')
      self.response.out.write('<body>')
      self.response.out.write('  <center>')
      self.response.out.write('    <br />')
      self.response.out.write('    <h3>ようこそ!')
      # 変数値を出力する際には encode() 関数で処理する必要がある
      self.response.out.write(userName.encode('UTF-8'))
      self.response.out.write('さん!</h3>')
      self.response.out.write('    <br /><br />')
      self.response.out.write('    <a href="index.html">戻る</a>')
      self.response.out.write('  </center>')
      self.response.out.write('</body>')
      self.response.out.write('</html>')

def main():
  # リクエスト URL パターンと、実行するクラスの関連づけ
  application = webapp.WSGIApplication([('/welcome', WelcomeRequestHandler)],
           debug=True)
  wsgiref.handlers.CGIHandler().run(application)

# アプリケーション起動時に main() 関数が実行されるようにする
if __name__ == "__main__":
  main()


リクエストパラメータを受け取り、その値を使って「ようこそ!○○さん!」と出力するスクリプト。


[app.yaml]


application: liebejudith-helloworld
version: 1
runtime: python
api_version: 1

handlers:
- url: /welcome
  script: WelcomeRequestHandler.py
- url: /index\.html
  static_files: index.html
  upload: index.html
- url: /
  static_files: index.html
  upload: index.html


/ あるいは /index.html が要求された場合は index.html を返し、/welcome が要求された場合は WelcomeRequestHandler.py が実行されるように設定しています。
app.yaml では、リクエスト URL パターンの関連づけを行いますが、.py スクリプトとの関連づけは、前回の Hello World で出てきました。
URL パターンと静的ファイルを関連づける場合は、static_files: エントリでファイル名を指定し、同時にサーバへアップロードするファイルを相対パスまたは絶対パスで指定します。


前回、「次回は掲示板でも・・・」なんて書きましたが、いきなり掲示板なんてとんでもなかったです。文字エンコーディングごときで大ハマリするぐらいですから。もっと少しずつ進めていきたいと思います。

April 18, 2008

GoogleAppsとSalesForcecomの提携

日本国内でも発表されましたね。

Salesforce for Google Apps
http://www.salesforce.com/jp/googleapps/?d=70130000000Dsim

プレスリリース
http://www.salesforce.com/jp/company/news-press/press-releases/2008/04/080417.jsp


SalesForce.com は来週に国内イベントを控えていることもあり、米国から幹部が来日して日本でも記者会見が行われました。

「Salesforce+Google Apps」の統合、日本で初のデモ (@IT)
http://www.atmarkit.co.jp/news/200804/17/sf.html

グーグルとセールスフォースが提携--その狙いと勝算 (CNET Japan)
http://japan.cnet.com/column/pers/story/0,2000055923,20371533,00.htm

「グーグルと“ソフトの終焉”に寄与」(ITpro)
http://itpro.nikkeibp.co.jp/article/NEWS/20080417/299412/

「グーグルと我々は同じビジョンを共有している。それはソフトウエアの終焉をもたらしたいということだ」は、
正直に「グーグルと我々は同じビジョンを共有している。それはMSの終焉をもたらしたいということだ」と言えばいいのに(笑)


大本営発表では「『ソフトウェアの終焉』が始まった」「ユーザーのSAP、オラクル、マイクロソフトへの依存が終わる」等、なかなか刺激的な言葉が並んでいますが・・・

今回の提携が Google Apps のシェアを一気に伸ばしたり、SaaS というサービス形態が一気に認知され普及するほどのインパクトを持つとは考えにくいです。
現実には既存の SalesForce ユーザの一部が恩恵を受けるのと、SaaS CRM 製品の導入を検討している新規のユーザにとって、SalesForce.com と競合する他社の Saas CRM 製品に対して多少のアドバンテージができる程度のものでしょう。今回の提携によって実現する機能は SalesForce を利用しないユーザにとって全く関係ありませんし、SalesForce を利用するユーザでもメールやオフィス等を Google Apps へ移行しないとメリットがありませんから。

とはいえ今回の提携は、SaaS アプリケーションのマッシュアップという、1つの事例を作ったと言えるでしょう。


「GoogleとSalesforceの提携は長続きしない」ZohoのCEOがコメント (INTERNET WATCH)
http://internet.watch.impress.co.jp/cda/news/2008/04/15/19219.html

まあ、これはライバル企業の発言なのでそれを勘案しておく必要がありますが・・・(^^;
Zoho としては何かコメントをしないで指をくわえているだけというワケにはいかない・・・という理由だけで出てきたコメントでしょう。


刺激的な言葉で満たされた大本営発表に、対抗しなければならないという理由だけで出てくるライバル企業のポーズ的な発言。
こういったやり方はとてもアメリカ的で、日本文化とは異質なモノを感じざるを得ません。日本の市場にしっかり根を下ろしたいのなら、それなりのマーケティング/プロモーションをしないと外資系ベンダの日本でのシェア拡大は難しいかもしれませんね。

April 9, 2008

Google App Engine が公開されました

Google App Engine が公開されました。

http://code.google.com/appengine/

Googleが提供するインフラ上に自作のWebアプリを乗せられ、データベースまで利用できるというモノです。

しかも、初期費用無料で。

私自身このニュースを見たとたん「来たっ!」と思いましたが、
マスコミの反響も大きいようです。

Googleのインフラでアプリを動かせる「Google App Engine」(ITmedia)
http://www.itmedia.co.jp/enterprise/articles/0804/08/news056.html

グーグル、「App Engine」を発表--オンラインアプリケーション開発用にインフラ提供 (CNET Japan)
http://japan.cnet.com/news/media/story/0,2000056023,20370974,00.htm

クラウドサービスに参入【詳報】「Google App Engine」ってなんだ (@IT)
http://www.atmarkit.co.jp/news/200804/08/appengine.html

「Google App Engine」発表、Googleのインフラ上でWebアプリ構築 (マイコミジャーナル)
http://journal.mycom.co.jp/news/2008/04/09/002/index.html

技術系ブログでも大盛況ですね。
Google ブログ検索の結果

Google App Engine は、Amazon の EC2/S3/SimpleDB や、Salesforce.com の force.com と競合するサービスになり得ますね。

Amazon や Salesforce.com がこれらのサービスを始めたときよりも反響が大きい印象です。改めて Google の影響や注目の大きさを感じます。

Salesforce.com に転職した後輩が、「Google が始めたとしても、Salesforce.com はもう8年もやっている実績がありますから」と言ってました。

Salesforce.com の force.com は、既存の高機能なCRMシステムを持っていて連携できるのが強みでしょうか。さらにリッチな GUI 開発環境を SaaS 形式で提供しているのが特徴です。アプリケーションのコードは Apex という、Java によく似た独自言語で記述します。

Goole App Engine は、背後に GoogleのBigTable、GFSという基盤を持っているのが強みだと思います。これは非常にスケーラビリティの高いシステムを構築できる可能性を持っていることを意味します。
mixi のような大規模 SNS もホスティングできたら、これはすごいことになりますね。世の中のインターネットサービスやエンタープライズシステムのあり方を一変させる可能性を秘めています。自らインフラを持たずとも初期投資ほぼ0からスタートして、大規模エンタープライズシステムやmixi のような規模を持つコンシューマサービスを運営できることになるのです。
多くのサービスやエンタープライズシステムが、自社サーバではなく Amazon や Google のクラウド上に移行するということがさらに現実味を帯びてきた感があります。Google のことですから、それぐらいの野望は持っているでしょう。

Web 上で Service を提供する SaaS から、プラットフォームを提供する PaaS (Platform as a Service) 時代へシフトする未来が見えてきた感があります。

Goole App Engine の正式サービス開始時の料金体系がまだ発表になっていませんが、Google の大容量ストレージを格安で利用できるメリットを打ち出してきそうな予感がします。

プログラム言語としては、現在は Python のみのサポートですが、将来的には他言語にも対応予定とのこと。Salesforce.com の force.com が独自開発言語と SaaS 形式のリッチな GUI 開発環境を提供するというアプローチに対して、Google App Engine は多言語対応で、開発環境は「自分の好きなものを使ってね」的なアプローチです。

Salesforce force.comGoogle App Engine
開発言語ApexPython
他言語もサポート予定
開発環境専用GUI環境(SaaSで提供)SDK提供
統合開発環境は無し。
開発者が好きなものを利用。
インフラSalesforce.com
(恐らく市販商用サーバ + 商用DB)
GFS + Google BigTable
最低限の
初期投資
0円0円
他サービス
との連携
強力・高機能なCRMシステムGoogleアカウントを利用した
認証等
独自ドメイン
の利用
不可


Yahoo! や MS はこの流れに追従するのでしょうか?MS はやりそうな気がしていますが・・・

まあ、Google と SalesForce.com ではターゲットとするユーザ・アプリが違う気もしますが・・・
平たく言うと Web2.0 的コンシューマサービスをゲリラ的に立ち上げやすい Google と、あくまで企業ユーザをターゲットにした SalesForce.com という感はあります。



ともあれ、Getting Started Guide に従って少しいじってみました。
(Windows XP Professional 環境です。)

トップページ http://code.google.com/appengine/ から、サインアップし、SDK をダウンロードします



msi 形式の Windows インストーラが用意されているので、それをダウンロードしました。

さて、インストール・・・

と思いインストーラを起動したら、Python2.5 が必要なので、まずはそっちをインストールしなさい・・・と怒られました。



Mac OS X 10.5 Leopard ならデフォルトで入っているんですけどね。

というわけで、Python をインストールしてから、GoogleAppEngine SDKのインストール。



インストール作業は、ライセンス同意と、インストールディレクトリの選択のみのシンプルな構成。「I Agree」とか「Next」を押しているだけで特に問題なく終了しました。
インストール時に、インストーディレクトリに PATH を通すかどうかのチェックボックスがありますが、チェックを入れておくとサーバの起動やアプリケーションのアップロードの時にコマンドをフルパス指定しなくて済みます。というだけです。

開発環境(SDK)には、開発用アプリケーションサーバ、ローカル環境専用データベースが含まれています。

Getting Started Guide に従って、最も簡単な Hello World アプリケーションを作ってみました。

まず、適当な場所にhelloworldディレクトリを作成し、その中にテキストベースで helloworld.py という名前のファイルを作成します。
ファイルの中はこんな感じ。


print 'Content-Type: text/plain'
print ''
print 'Hello, world!'



Google App Engine では、app.yaml という名前の設定ファイルが必要なので、同じディレクトリ内に作成します。


application: helloworld
version: 1
runtime: python
api_version: 1

handlers:
- url: /.*
script: helloworld.py



application: App Engine がアプリケーションを識別するためのユニークな名前を付けます。
  • version: アプリケーションのバージョン番号。アップロードする前にバージョン番号を編集する必要があるそうです。App Engine はバージョン番号を認識しているので、管理コンソールで前のバージョンに戻したりできるらしいです。
  • runtime: と api_version: エントリは、現在は python、1 で固定です。将来別の言語を使えるような計画もあるので、その際に拡張されるみたいです。
  • handlers: 上記の設定は、すべてのリクエストに対して helloworld.py スクリプトが動作するということを意味します。スクリプトの他にも、ディレクトリを指定したり、指定したURIは管理者のみがログイン可を指定したりが可能です。
YAMLのリファレンスはこちら。
http://code.google.com/appengine/docs/configuringanapp.html


これで準備完了です。

コマンドラインから Google App Engine のサーバを起動します。その際にスペース区切りでアプリケーションの配備ディレクトリを指定します。


dev_appserver.py アプリケーションのディレクトリパス




あとは、ブラウザから http://localhost:8080/ にアクセスすると・・・



これを、Google App Engine のサーバにアップロードすれば公開できます。

アップロードするには、まず http://appengine.google.com/start/createapp からアプリケーションを作成します。



このとき、Application Identifier の項目は app.yaml の application エントリに登録した文字列と合わせておく必要があります。
この文字列はアプリケーションの識別子となるのですが、ユニークであるスコープはユーザ単位ではなく、Google App Engine サーバ全体です。つまり、同一のアプリケーション名を他人に使われていたら使えません。
というわけで、helloworld が(当然のように)使われていたので、ここでは「liebejudith-helloworld」に変更しました。app.yaml の application エントリもこれに合わせて修正しています。

そして、アップロード。Web 管理インタフェースからアップロードするのかと思いきや、Google App Engine ではコマンドラインから appcfg.py コマンドを実行してアプリケーションをアップロードします。


appcfg.py --email=登録メールアドレス update アプリケーション配備ディレクトリ



これで完了。ブラウザから次のURLにアクセスします。


http://アプリケーション名.appspot.com/







Google App Engine は、Pure Python アプリも動作しますし、アプリケーションと一緒にアップロードすれば多くのフレームワークを動作させることができます。

SDKに同梱されているのは、Django v0.96.1 と、オリジナルのWebアプリケーションフレームワーク "webapp" です。

webappフレームワークには、下記のような機能が含まれています。
  • Google アカウントと連動したユーザ認証API
  • データストアAPI。データ操作には、SQLによく似たクエリ言語"GQL"を利用
  • Webページ作成のためのテンプレートエンジン
  • Mail API


私は Java しか知らない人間なので Python はほとんど触ったことはないのですが、Google App Engine アプリを作るために Python を覚えてもいいかな?という気にさせてくれます。


次回は、Getting Started Guide で紹介されているゲストブックアプリケーションを参考にして、掲示板アプリでも作成してみたいと思います。

January 15, 2008

Salesforce

最近、Salesforce関連のニュースが目に付きます。

ソフトバンクBB、Salesforceと連携可能なASP型Web会議サービス
http://www.softbankbb.co.jp/news/press/2008/p0115_01.html

SaaS型プロジェクト管理ツール『@task』がSalesforceと連携
http://japan.cnet.com/release/story/0,3800075553,00025977p,00.htm

Salesforce上で稼働するメール配信システム、トライコーン
http://www.atmarkit.co.jp/news/200712/17/tricorn.html
http://www.tricorn.co.jp/press/207.phtml

Salesforceと連携する帳票アプライアンス「帳票くん」、12月発売
http://enterprise.watch.impress.co.jp/cda/hardware/2007/12/18/11895.html
http://www.sunbridge.com/news/press/2007/12/salesforce.html

私も少し前まで、自分の勤務先の会社でforce.comプラットフォームアプリケーションのSIが実現できないか?と考えていました。

T氏には一度、自分の勤務先へ来ていただいたことがあり、
それをきっかけに、ネット上で調べてみたら
T氏が尊敬すべき素晴らしいエンジニアであることを知り・・・

このT氏と仕事ができるかもしれない!というのが
私のforce.comプラットフォームアプリケーションの仕事をしたい!
と思う原動力の一つだったのですが・・・

非常に残念なことに、Salesforce社からT氏が退社したと知り、
その意欲がすこし減退気味です・・・



でも、多くのアナリストが2008年はSaaSの時代、サービスの時代と提言しています。

私の、Salesforceへの直近のモチベーションは下がったものの
今年、SaaSへのアンテナはより敏感に張っておく必要がありそうです。