Document Actions
IBMには悪いですが、Notesの正統な後継者の一番手はsalesforceかもしれない、という思い
salesforceのTour de Force Tokyo(-ツール・ド・フォース-)に行ってきました。
去年のGoogle Developer Dayでは昼食も夕食もでました。今年のGoogle Developer Dayではどちらも無くなりました。salesforceのTour de Force Tokyoは昼食も夕食もでました。この論評は差し控えます。
開発者向けセッションを聞いてきました。
ApexとVisualforceを、MVC的に説明すると次のようになります。
- カスタムオブジェクト...RDBでのテーブルスキーマ定義相当。model相当
- コントローラ...Apex言語で記述。後述するように、伝統的MVCのcontrollerと言うより、ビジネスロジック層に見えます
- ページ...PHPやJSPのようなファイル。サーバで処理されて結果はクライアントへのレスポンスになります。view相当
- コンポーネント...JSPで言うところのカスタムタグ(ライブラリ)。コントローラから渡されたデータ(model)を参照します。view相当
構成はWebアプリの伝統的スタイルに準拠しています。Javaで言えば、カスタムオブジェクトがRDBを隠蔽する層で、言わばエンティティ層と思ってよいでしょう。ページがJSPファイル、コンポーネントがカスタムタグファイルです。
少し変則的なのは、ページ(MVCのviewそのもの)に、対応するコントローラを記述させる部分です。伝統的MVCでの、controllerとviewの参照関係と逆方向に感じます。これは、「コントローラ」(以下、カッコ付きコントローラはsalesforceの固有名詞のコントローラ)の用語の使い方の問題だと思います。「コントローラ」はサービス層もしくはビジネスロジック層に近くて、伝統的MVCのmodel寄りです。伝統的controllerはフレームワークに隠蔽されています。ページに記述する「コントローラ」への参照は、伝統的controllerに解釈させる宣言的記述(viewがどのmodelに依存するかの宣言)と見なせます。
ページには<apex:foo>のような独自カスタムタグを書けますが、それ以外は、普通のHTMLです。CSSもJavaScriptも書けますし、望むならばFlashも埋め込めます。仕組み自体はJSPやPHPと同じです。つまり、サーバが中身を解釈して、その出力はブラウザへのレスポンス(普通はHTML)になります。
ページの記述の自由度の高さがsalesforceを際立たせるポイントです(ビュー周りの開発環境を総称して、salesforceではVisualforceと呼んでいます)。
ユーザにページ相当のファイルをポストさせて、それをサーバサイドのビューとして使う仕組み自体は誰でも作れます。例えば、RailsでユーザにERbのコードをポストさせて、それを表示に使うアプリは10分で書けるでしょう。しかし、それを愚直にやると、普通はセキュリティホールだと認識されます。
実現できることと、それを現実的に機能させることには大きな差があります。
Googleも登場当時、サーチエンジンが特別に奇特なサービスではありませんでしたが、高速に、そしてずっと高速にやり続けていることが凄い点です。同様に、salesforceも、ユーザにサーバサイドで動くコードをポストさせる仕組みを、きちんと動作させ続けていることが凄い点です。
ちなみに、情報ソースが一ヶ所なので、信頼度はその程度と思ってほしいですが、salesforceのサーバは、月に2,3回程度はメンテナンスのために停止するようです(停止は事前予告あり)。もしsalesforceが24時間365日ノンストップだったら、負けましたとあやまるしかないですが、幸いなことにそこまで進化はしていないようです。
「ページ」相当の機能は、facebookも同様の仕組みを提供しています(FBML)。これはこれで両者とも凄いのですが、salesforceが行っちゃったなと思うのがApexコードです。これは、サーバで動作するビジネスロジック層(上に書いたように、salesforceは「コントローラ」と呼んでいました)をユーザに自由に書かせる機能です(正確に用語を使うとApexはそのための言語)。これも、仕組みだけなら誰でも作れます。ブラウザからperlのコードをポストさせて、CGIとして実行させる仕組みと言えば、実現の簡単さがイメージできるはずです。しかし、普通はできません。現実の様々な障害(セキュリティやパフォーマンス)が多すぎるからです。しかし、salesforceはやってしまいました(Google App Engineよりずっと先に実現)。
Notesもユーザがアプリを作成して、サーバ上で動作させる仕組みがあります。機能だけを見ればsalesforceを凌駕しています。しかし、今、IBMがNotesの開発実行環境をPaaS(Platform as a Service)としてインターネットに公開できるでしょうか。恐くてできないはずです。社内アプリなら開発者の自己責任ですが、インターネットへの開発環境の公開はそうもいきません。
サーバサイドで実行することの意味は、サーバのCPU資源を利用できる利点もありますが、一番の利点はサーバ上のストレージへのアクセスです。事実、Webサービス(いわゆるWeb APIを使ったアプリ)と比較した利点として、トランザクションをサポートしている点をApexコードの利点だと強調しています。
ApexはORMを持っています。SOQLはSQLに似たyet anotherクエリ言語です。
次のようにLINQっぽく書けるのがクールです。個人的には、LINQっぽい方がActiveRecordのようなメソッドで頑張る記法より好きです。
// 記憶で書いているコード
List<Contact> contacts = [SELECT FirstName FROM Contact];
for (Contact contact : contacts) {
System.debug(contact.FirstName);
}
にあるように、SOQLはjoinを明示的には指定できませんが、限定的に似たようなことは書けるようです。
似たような話を、最近facebookのAPIで見ました(Associations)。
この辺りの話は、「クエリをどう記述するか」という問題点につながり、興味深い点がある気がしていますが、まだ自分の頭の中で整理しきれていません。整理できたら、何か書きます。現状は、SQLより優れたクエリ記法には感じていませんが。
追記
そういえばコードを書くデモがほとんど失敗しませんでした。コードを書くデモって失敗率高いのですが。今年のGoogle Developer Dayのデモの失敗率の高さと対照的でした。
- Category(s)
- カテゴリなし
- The URL to Trackback this entry is:
- http://dev.ariel-networks.com/Members/inoue/salesforce/tbping