Macromedia ColdFusion 記事

ColdFusionMXを含むMXソリューションの一番の魅力は何と言っても従来のブラウザの限界を超えた『リッチインターネット アプリケーション』を容易に構築できることでしょう。CFML開発者の中でもFlashなどを勉強されている方はたくさんいらっしゃるかと思います。しかしながら、Flashで見栄えのあるコンテンツを作成するにはそれなりの経験とセンスも必要で、なかなか一朝一夕にはいきません。でも、心配には及びません。幸いMXソリューションに携わるコミュニティはコンテンツ作成を得意とする『Flashクリエイター』とシステム開発を得意とする『ColdFusionデベロッパー』がクロスオーバーする世界でも あります。『もちは餅屋』とは言いますが、まさにそうしたコラボレーションが可能であることもMXソリューションの大きな 魅力の一つです。

ここではそうしたリッチインターネットアプリケーション構築に向けてのクリエイターとデベロッパーとのコラボレーション を実現するにあたって、ColdFusion側ではどのようなことに配慮してアプリケーション設計を行えばよいかといったことについてご紹介したいと思います。本記事はFlashのDevNetとの共同企画になっており、対するFlash側でのポイントについても掲載されておりますので、是非そちらも合わせてご覧ください。

ステップ1: MVCモデルへの対応

『MVCモデル』という言葉もすでにだいぶなじみのあるキーワードになってきました。リッチインターネットアプリケーションの実現においてもMVCモデルは非常に重要なポイントとなります。まずは旧来のColdFusionプログラミングのスタイルについて 概観し、MVCモデルのメリットについて考えてみましょう。

図1は旧来の ColdFusion プログラミングスタイルのイメージを示したものです。ユーザーが実際に見る画面一つ一つに対応した cfm ファイルを作成し、そこにデータベースアクセスなどのプログラムコードと表示のためのHTMLを混在させて記述させるおな じみのスタイルです。この方法はまずHTMLのモックアップを作成してユーザーに画面遷移を確認してもらった上で細かいプログ ラムコードを実装できるという点で迅速なアプリケーション開発にはとても適したスタイルです。ですが、システム規模が大き くなり、また多用なデバイスへの対応が求められるようになった昨今では以下のような弊害が出てきました。

• HTMLとプログラムコードが渾然一体になっているので、それぞれのメンテナンス時に誤って他の部分に悪影響を与えてしまいやすい
• 各画面ごとにデータベースアクセスのコードを記述しているので、同じようなコードが複数箇所に散在してしまいやすい

このままではコラボレーションしたくてもお互いの役割分担ができません。そこで、MVCモデルの考え方に従って役割ごとにモジュール化した上でFlashにも対応できるように配慮したものが図2のイメージです。

図2のポイントは以下のとおりです。

• コンテンツ表示部分を切り出して、ブラウザ用とFlash用にそれぞれ別ファイルに分けて作成する。Flash用はもっぱらFlashへ返すデータの生成のみを行う(View)
• データアクセスはCFCに集中させて余計なロジックの重複を防ぐ(Model)
• 表示用ファイルやCFCを呼び出すためのコンテナファイルを設ける。他のファイルを呼び出しているだけで無駄のようだが、表示ファイルの切り替えや複数のCFCを呼び出す場合の制御などの重要な役割を持つ(Controller)

これで表示部分とロジック部分がきれいに分かれたので、役割分担ができるようになります。Flashクリエイターの方に図2の中の「Flash用アクセスポイント」でどのような呼び出し方をして どのようなデータが返されるかの仕様を教えれば、後はFlash側からFlashRemotingを使ってのアクセスが可能になります。

ところが、この方法にはちょっと問題があります。それはブラウザ用とFlash用とで画面遷移が同じになってしまうという点です。せっかくFlashでコンテンツを作成するのですから、わざわざブラウザと同じように[一覧表示画面]→[詳細画面]と遷移する必要はありません。一覧画面からかっこよく詳細画面をポップアップさせた方が見栄えの面でも使い勝手面でもより良いケースも多いでしょう。またFlash Remotingを解説した記事や書籍ではFlashからの呼び出しでは通常のcfm ファイルへアクセスする例はごく少数でCFCにアクセスする方法を解説したものが一般的です。ですので、Flashクリエイターの方から見ると図2のパターンはFlash のメリットを生かしづらく、またなじみの薄いものでもあるのです。

ステップ2: MXソリューションの作法にならう

それではFlashクリエイターの方にとってもコラボレートしやすいパターンはどのようになるのでしょうか。そのイメージを図示したものが図3です。

ここでのポイントはFlashからは直接CFCにアクセスしているという点です。ColdFusionプログラミングの観点からするとWEBアプリケーションとC/Sアプリケーションが混在しているような感じで慣れないうちは違和感を覚えるかも知れません。ですが、こうすることでいろいろなメリットも出てきます。CFC にはセルフドキュメンテーションの機能があります。それを使えばFlashクリエイターの方にCFCのインターフェース仕様を伝えるという作業がとても楽になります。また、CFCをWEBサービスとして公開すればFlashアプリケーション以外のもっと多種多様なクライアントや外部システムと連携させることもできます。現時点ではこのパターンが最も一般的といえるでしょう。

ステップ3: さらなる発展

ここからは発展編になりますが、図2のパターンにも考慮すべきことが残っています。図2の中で赤い星印で記したのは外部からアクセス可能なポイントです。 ブラウザとFlashアプリケーションそれぞれ別の入り口がありますが、セキュリティを考慮するとそれぞれの入り口で何らかの対処ができるようにしておいた方が良いことになります。ですが、ブラウザからのアクセスではCFCにもアクセスしますから、単にCFCにセキュリティ的な対処を施しただけではセキュリティ チェックを2回通過することになりいささか冗長です。図2ではCFCは一つだけですが、様々な機能を組み合わせたより複雑で規模の大きいシステムになれば CFCの数も増えてきます。そうするとそれらにアクセスするFlashアプリケーション側でもたくさんのアクセスポイントを把握しなければならなくなって大変です。機能を追加するといった場合にもいろいろな場所で修正が必要になってしまいます。この点を考慮したのが図4です。

画像をクリックすると拡大画像を表示します。

ブラウザ・Flashいずれの場合も「エントリポイント」というものを設けます。クライアントからの全てのアクセスはここで受け取ります。クライアントからは どの処理を呼び出したいかを示すインデックスをURLパラメータなどの形でサーバーに引渡し、エントリポイント内でそれに応じて処理をディスパッチします。 またエントリポイントではクライアントから受け取ったデータについてセキュリティのチェックを行います。また新規に機能が追加された場合でもクライアント側ではcfmファイルやCFCの名前を新たに付け加える必要はありません。そうすることでシステムのポータビリティもまた同時に向上させることができます。このように外部からの入り口を一箇所にまとめることによって、セキュリティやメンテナンス性にも配慮したコラボレーションのためのシステムを構築することができるわけです。

弊社で開発・販売しているEIP構築プラットフォーム『リンコム ネクスト』はこの図4のような設計になっています。このプラットフォームの上に実に様々な ColdFusionデベロッパーの方がアプリケーションを開発されています。それらは『リンコム ネクスト アプリケーション』と呼ばれます。そうして、Flashクリエイターの方が開発したリッチなネクストアプリケーションの第一弾としてFlashコミュニティでは著名なセカンドファクトリー様が『TimeManager』という製品をリリースされます。Flashの強みを存分に生かし、ユーザービリティに高度に配慮しされたアプリケーションです。FlashクリエイターとColdFusionデベロッパーのコラボーレーションの成果の一つとして是非ご覧いただければと思います。

今回はリッチインターネットアプリケーションを実現するにあたって、まずはFlashクリエイターとColdFusionデベロッパーとでコラボレーションをしてみましょうという点、そしてそれを実践するにあたってColdFusion側ではどのような点に配慮したアプリケーション設計を行えばよいかということについてご紹介させていただきました。本稿がこれからのリッチインターネットアプリケーション開発に向けての一助になればまことに幸いです。