ASP.NET Web Solution Guide

～ Multi UI Web Application 編 ～

 Multi UI Web Application の構築とその考慮点

サンプルアプリケーションのダウンロード (自己解凍形式、1.30 MB)

目次

はじめに
ASP.NET Web Solution Guide
ASP.NET の概要
    ASP.NET の基本コンセプト
    Web アプリケーションの UI 生成
    XML Web サービスの実現
    Web アプリケーションを支えるインフラストラクチャサービス
サンプルアプリケーションについて
アプリケーションに対しての要求
    Web アプリケーションとして
    Mobile Internet Toolkit の利用
Multi UI Web アプリケーションの設計
    ASP.NET によるコードと UI の分離
    設計手法と開発指針
おわりに
参考資料

はじめに

インターネットをプラットフォームのひとつとして捕え、それを視野に入れたアプリケーションの構築が提唱されはじめてから幾年か経ちました。マイクロソフトの提唱したアーキテクチャである、Windows DNA（Windows Distributed Internet Application）もそのひとつであったということができるでしょう。そして、時間の経過に伴いアプリケーションへ新しい要求が発生し、そのための技術が提供されていくことは、当然の流れであるといえるでしょう。このようなニーズに応えるため、マイクロソフトでは、.NET という構想を発表し、これを実現するために .NET Framework というフレームワークを提供しました。

この .NET という構想では、インターネットをプラットフォームとしたアプリケーション環境をよりシームレスに実現することを目指しています。XML Web サービスに代表されるような考え方は、これらの具体例のひとつであると考えることができるでしょう。

構想は、掲げられるだけでは意味を成しません。実現するための実装も必要になってきます。今回取り上げる ASP.NET は、実際に XML Webサービスや Web アプリケーションとの連携などを実現するプラットフォームであるといえます。当ガイドでは、.NET 構想や新たな Web ソリューションに対してのアプローチを具体的に提示することで構想となっている世界を実現するための手段のひとつとなるように作成しました。開発者の皆さんが新たなアプリケーション世界へ入り込んでいくきっかけとなれば幸いです。

ASP.NET Web Solution Guide

当ガイドでは、Multi UI Web アプリケーションの構築に焦点を当てています。.NET Framework によって提供される ASP.NET の持つ機能を十二分に発揮させることで、単に Internet Explorer に代表される Web ブラウザをクライアントとするだけではなく、携帯電話や PDA といったさまざまなデバイスにアプリケーションを展開させてゆくことができます。

ASP.NET の概要をまとめながら、実際にサンプルアプリケーションを利用し、Web アプリケーションにおいてどのようにマルチデバイス化させるのか、そしてそのための設計上の考慮点などをご紹介します。

ASP.NET の概要

ASP.NET は、.NET Framework において提供されている新しい Web アプリケーションのためのプラットフォームです。これまで Windows 2000 Server などの環境において提供されていた Active Server Pages（以下、ASP）と似通った考え方をもっています。それは、Web ソリューションを実現していくためにサーバー上でプログラミングされているアプリケーションを実行し、クライアントへその結果となる UI を表示させるという部分です。しかし、今までの ASP とは根本的に異なっている部分もあります。

ASP.NET は、.NET Framework の実行環境である共通言語ランタイム（Common Language Runtime）上で動作するプラットフォームです。つまり、ASP.NET の機能を利用してプログラミングされたアプリケーションは、共通言語ランタイム上で実行され、そのメリットを享受することができるのです。

今までの ASP と、この ASP.NET の大きな違いは、スクリプトとして実行されるのか、それともアプリケーションとしてコンパイルされ実行されるのかという点です。ASP では、基本的にクライアントから要求が行われるたびにコード（アプリケーションロジック）を Active Scripting というエンジンが解釈し、インタプリタ上で実行されていました。ASP.NET では、クライアントから要求が行われると、コードはコンパイルされ、バイナリ化された後、結果を返します。また、一度リクエストが行われたあとであれば、あらかじめコンパイルされたアプリケーションから結果が返ることになります。

ASP における実行プロセス

ASP.NET における実行プロセス

アプリケーションの実行にかかわる部分だけではありません。ASP では、VBScript やJscript といったスクリプト言語のみがサポートされ、これらの言語で開発が行われていましたが、ASP.NET では、共通言語ランタイムによってサポートされる言語を利用して開発することができるようになっています。Visual Basic をはじめ C# や C++、Jscript や Perl といった多くの言語をサポートしていることから、開発者の得意とする言語、もしくは、開発が行いやすい言語を選択して実装していくことができるようになっています。単純なサーバーサイドスクリプトのエンジンから Web アプリケーションの実行環境へと発展した結果、このように開発言語の選択にも幅が広がったといえるでしょう。

開発言語のサポート

このように、今までの ASP と ASP.NET は大きな違いがあるように見えます。しかし、開発者の視点から見た場合、プラットフォームに対してのアプローチは変わりましたが、プログラミングモデルに対しての変更が行われていないことから、これまで培ってきた知識をそのまま活用することができるという大きなメリットがあります。つまり、今までと同じ開発手法によって、新しく提供されるプラットフォームの信頼性を活かしてゆくことができるのです。

では、ASP.NET によって提供される Web ソリューション実現のためのさまざまな機能を簡単にまとめておきましょう。

■ ASP.NET の基本コンセプト

ASP.NET は、前述のとおり今まで提供されていたサーバーサイドのスクリプティングエンジンである ASP からは、多くの機能において改良がなされています。これは、共通言語ラインタイムという実行環境に対応するために追加されたもの、また、今までの Web アプリケーションの開発環境における問題点を解決したものなどが含まれています。ASP.NET 自身をひとつのフレームワークのように捕らえると、大きく 3 つの機能に分けて考えることができます。

これら 3 つの機能とは、

• Page
• Services
• Infrastructure

です。

ASP.NET の構成

ASP.NET では、これらに対しさまざまな機能を提供しており、そして、Web アプリケーションの展開を行う上で必須ともいえる拡張が施されています。では、ASP.NET をこれら 3 つの機能に分けて紹介していきましょう。

■ Web アプリケーションの UI 生成

Web アプリケーションの利用者は、ユーザーインターフェイスを介してアプリケーションの機能にアクセスします。したがって、ユーザーインターフェイスは、アプリケーションの顔ともいえる重要な部分です。

ASP.NET では、このユーザーインターフェイスを生成する機能として Web フォームを提供しています。Web フォームでは、ユーザーインターフェイスの各部品（テキストボックスやボタン、ラベルといったコントロール）をライブラリとして実装しています。このライブラリを利用することで Windows アプリケーションと全く同じような手法によって、Web アプリケーションを開発してゆくことが可能になりました。また、ユーザーへ出力されるコードをブラウザに応じて切り替えるといったことも実現できます。たとえば、Internet Explorer に対しては、ユーザーインターフェイスを DHTML として生成し、他のブラウザに対しては、HTML 3.2 として生成するといった具合です。これは、コントロールにかかわる実装がライブラリとして隠蔽されているため、開発者が直接出力コードを操作しなくてもいいという Web フォームの持つ柔軟性がもたらした恩恵でもあります。

また、これらのコントロールによって操作された結果は、サーバー上に送信されイベントとして処理をするという仕組みになっています。これをサーバーサイドイベントドリブンプログラミングモデルと呼びます。入力確認やさまざまな処理をクライアントサイドスクリプトを利用して行うのではなく、サーバー上で処理することで、スクリプトなどが利用できないクライアント環境でもアプリケーションを利用できるように配慮されているわけです。

開発のフェーズにおいては、Visual Studio .NET の活用によってより迅速な開発作業の遂行が実現できます。これらのライブラリは、コントロールのように開発環境上に用意されており、Web のユーザーインターフェイスに対してドラッグアンドドロップで配置を行い、ダブルクリックによってイベントロジックを記述するという、いままでのVisual Basic ライクな操作で開発作業を行うことができます。Look & Feel のデザインからロジックの記述までを ASP.NET の Web フォームと Visual Studio .NET によって、一貫して行うことができるわけです。

■ XML Web サービスの実現

.NET の構想の中で大きく取り上げられているのが、XML Web サービスです。これは、インターネットをプラットフォームとしたコンポーネントウェアの実現であると考えることができるでしょう。アプリケーションのもつさまざまな機能をサービスとしてインターネット上に公開することで、これらを組み合わせ利用していくことができるようになります。これを実現するためには XML や SOAP といった標準化団体で定めた規格を利用します。ASP.NET は、この XML Web サービスを実現させるための機能を装備しています。ASP.NET アプリケーションとして実装した後に [WebMethod()] という属性を公開したいメソッドに対して付記することで、XML Web サービスとしてネットワーク上へ公開することができます。また、標準化されている技術に基づいて実装されていることから、プラットフォームやアーキテクチャの垣根を越えたアプリケーション間の連携を実現することができます。

作成された XML Web サービスへアクセス

テスト用の UI を提供している

Column: XML Web サービスとは？ ある業務アプリケーションがあると仮定します。 このソリューションでは、アプリケーションの要件を満たすためにさまざまな機能が提供されます。流通企業などを例にとるのであれば、在庫管理や販売管理、配送依頼、在庫照会といったものが必要とされる機能でしょう。これらは、コンポーネントとしてインプリメントされ、一つのソリューションとして動作しています。コンポーネントによって提供された機能は、ソリューションにおけるサービスと捕らえることができます。つまり、ソリューションは、サービスの組み合わせによって構築され、顧客要求を満たすものとして提供されているわけです。 このようなソリューションは、最善のものであると考えることもできますが、また、その中にいくつかの問題点も考えることができます。 たとえば、実際の業務に当たっているとせっかくのアプリケーションがあっても、従業員の手によって作業を行わなければならないケースなどもあります。配送業者への発送依頼のために伝票を FAX しなければならなかったり、在庫データを倉庫業者から受け取り、自社内システムへ反映させるための作業など、人が介在しない作業は、実はそれほどないということです。 このようなソリューションは、もちろん、この例にあげている流通企業だけが問題を抱えているわけではありません。その取引先である配送業者や倉庫業者であっても、同じようなソリューションを持ち、そして、同じような問題を抱えていることになります。 ソリューションの中で問題を抱える要因は、何なのでしょうか。いままで一般的に推奨されていたコンポーネントをベースとした多階層アプリケーションとして構築していたにもかかわらず、このような問題点を持ってしまったのです。 実は、その「コンポーネント化されたソリューションの持つ制限事項のためである」というのが、一つの問題を生む結果となっています。 コンポーネント技術というものは、さまざまなものがあります。COM や CORBA といった技術がこれらに当たります。これらのコンポーネント技術では、相互に関係づいて動作することができないという欠点を持っています。つまり、COM は、COM のクライアントから、そして、CORBA は、CORBA クライアントから呼び出すということを前提に作成されているものであり、互いに利用しあうということができませんでした。（現在では、ブリッジといわれる互いを呼び出しあうための機構がありますが、残念ながらそれほどの機能を持っていないなどの点で、実運用時には不安が残ってしまいます。）コンポーネント技術は、欠点だけではありません。さまざまなサービスを提供するために構築されたコンポー ネントは、他のアプリケーションからも再利用することができ、それによって、アプリケーションの共通機能をカプセル化して提供できるようにもなりました。また、構造上明確なものとなるために、メンテナンスにおける効率を向上することができますし、クラスタシステムの対応やロードバランシングシステムの活用などでパフォーマンスの向上を図ることもできるようになってきました。これらのコンポーネント間がネットワークを通じて連携することができるようになれば、互いのシステムがつながり、そして、今まで手作業などで解決していたプロセスを自動化していくことができるようになるはずです。また、コンポーネントの持つ多くのメリットをより活用できる環境が整備されていくことになります。 そこで登場することになったのが XML Web サービスです。これによって、さまざまな環境に存在しているサービスをお互いに結び付け新しいアプリケーション世界を創造 しようとしていくことになります。 XML Web サービスが展開されていくにあって、一つの懸案事項があります。それは、今までのコンポーネント技術などと同じように独自の世界での接続性だけが保証され、結局のところ、閉じた世界になってしまわないかという点です。 現在、インターネットにおける標準に技術がさまざまに存在します。その中から、この Web サービスを実現していくために必要なものを組み合わせていくことで、独自の世界に閉じこもることなく、オープンなアプリケーション環境を提供することができるのではないかと考えられるようになりました。 XML（Extensible Markup Language）をベースとした標準技術である SOAP（Simple Object Access Protocol）は、分散環境にあるオブジェクトを呼び出し、その結果を取得するために定義された新しいプロトコルです。このプロトコルを応用し、ソリューションの元となるサービスを連携できるようにすることで、これまでの例にあった相互接続に関する問題点などを解決していくことになりました。 SOAP は、インターネットの世界において標準化されているものであり、誰かの所有物ではありません。また、この規格自身は、プロトコルの仕様を定めているに過ぎません。あとは、さまざまなベンダーがこの規格に賛同し、それぞれのシステムへの実装を行っていくことで対応が進んでいくようになります。多くのプラットフォームにおいて、この標準をサポートし、オブジェクト技術が提供されるようになるのであれば、まさに、マルチプラットフォーム間での連携をインターネットという回線を介する形で実現していくことができるようになるわけです。 このようにして、アプリケーションに対して機能を提供している「サービス」を Web を利用し、提供する環境、すなわち、XML Web サービスが、ここに誕生することになりました。 では、インターネット標準の技術を応用した XML Web サービスの仕組みを紐解いていきましょう。まず、ソリューションの中で実現されているさまざまな機能は、サービスとしてコンポーネント単位で構成されている必要があります。これらが元となりアプリケーション間の連携が実現されていきます。 サービスを提供する側（XML Web サービスが実装される側になります）では、サービスの呼び出しに対応するためにSOAP メッセージの解釈ができるようになっている必要があります。.NET フレームワーク上では、最初からこのメッセージの解釈を行えるようライブラリが提供されています。（詳細は、後述します）SOAP メッセージを受け取ると、指定されたサービス（コンポーネントともいえます）とのマッピングを行い、処理の結果をふたたび XML フォーマットのメッセージとして送信側へ返信します。 サービスを利用する側（ここでは、Web サービスのクライアントということになります）では、サービスの呼び出しを行う際に、SOAP メッセージをジェネレートし、XML Web サービスの提供者へ送信します。結果は、XML フォーマットのデータとして送られてきますので、これを解釈し、アプリケーションの中で利用できるようになります。 これらの処理の流れは、下図：XML Web サービス適用前と適用後に示しましたので、あわせて参照してください。アプリケーションがどのサービスを利用するかがあらかじめ決まっているのであれば、これだけの仕様でも十分であると思えますが、実際のソリューションでは、そうとはいえません。 たとえば、何らかの商品調達を行うと想定します。その場合、同じ商品を調達するとしてもその調達元になる業者は、変化する可能性があります。また、業者がいくつか存在しているのかもしれません。このような場合はどうしたらいいのでしょうか。もちろん、それらの業者が提供する XML Web サービスがどこに存在しているかわかっているのであれば、そのための実装をしておけば済むかもしれません。しかし、動的に業者を探し、在庫を引き当てなければならないようなケースに対応していくことができません。 そこで、SOAP に関連し、サービス動的に発見する手法が必要となり、そのための仕様の策定も行われるようになりました。現段階で、このサービス発見のための使用は確定的なものではありません。マイクロソフトでは、XML Schema ベースとした DISCO といわれるサービス発見のための仕様を提案し、実装しているという状況です。また、サービス発見だけではなく、実際にどこにサービスが存在しているかを管理するための手法なども必要となってきます。さまざまな要求に対し、多くのベンダーが協力し合い、仕様を策定し、各々のプラットフォームへと実装しています。 先ほど例にあげたソリューションを Web サービス適用前と適用後で比較してみましょう。 下図：XML Web サービス適用前と適用後を比較するとよくわかるかと思いますが、いままでは、互いに直接関連することなくソリューションが存在し、実際の処理を行っていました。これが、Web サービスへ対応し、個々の業者がサービスを公開することによって、クライアントとなる企業のソリューションでは、システムが統合され、今まで手作業などで行っていた煩雑な処理が、一連の流れに沿ったワークフローのように構成されていくようになります。 これらの処理を .NET Framework で実現していくために ASP.NET は、"Services" としての機能を持つに至りました。拡張子 asmx というファイルを用意し、ここにコードを記述していくことで、実際に XML Web サービスを構築できるようにしたわけです。 XML Web サービス適用前 XML Web サービス適用後

■ Web アプリケーションを支えるインフラストラクチャサービス

ASP.NET は、Web アプリケーションや Web サービスを構築するための環境としてとても強力なものですが、さらにこれらに支援を与えるのが、インフラを支える技術としての ASP.NET の機能群です。これらは、いままで Web アプリケーションを開発し、提供していく中で問題となりがちだった現象を解決するための手段として有用なものです。

ASP.NET の提供するインフラ技術としては、以下に挙げるような機能があります。

• アプリケーションの設定情報をファイルで保持
• XCOPY ライクなアプリケーション配置機能
• 動的なコード更新
• キャッシング技術の提供
• デバッグ機能の強化

これまで、ASP をはじめとする Web アプリケーションを開発し、実際に本番環境へ移す場合や新しいモジュールに更新しようとした場合、多くの問題がありました。たとえば、ビジネスロジックとなる DLL ファイルがロックされて更新できなかったり、テスト環境とまったく同じ設定にするためにさまざまなプロパティウィンドを操作しなければならない、などといった問題です。しかし、インターネットという環境でアプリケーションを展開していくとなると、ビジネスの要求に応じ、短いスパンで更新作業や新しい機能の提供を行っていかなければなりません。このような局面でアプリケーション配置に困難な手順があると、ビジネスチャンスを逃しかねません。そこで、これらのインフラとしての技術が取り入れられることになりました。

完成したアプリケーションは、DOS のコマンドでおなじみの XCOPY と同じような方法でアプリケーション配置を行っていくことができます。つまり、あらかじめ用意された仮想ディレクトリなどにファイルのコピーを行うだけでアプリケーションの配置を完了させることができるのです。また、利用しているライブラリ（DLL など）はシステムにロックされることなく動作していますので、動的に DLL ファイルなどを更新していくことができます。このようにして、いままで、レジストリに登録したりプロパティウィンドの操作などによって行っていた作業を単純かつ明快に完了させることができるようになっています。これらは、設定情報においても同様の機能を提供しています。アプリケーション単位で web.config というファイルをもち、アプリケーションの設定情報を XML ベースのテキストファイルとして保持させることができます。これらの情報は、どの環境へ持ち込まれても、自動的にアプリケーションの実行時に読み込まれ反映されます。これにより、アプリケーションそのものの設定に関しても XCOPY ライクなアプリケーション配置を実現することができます。また、設定の変更も、サービスの再起動ナシに自動認識機能によりファイルの更新を行うだけで実現できるようになっています。

ASP.NET では、アプリケーション配置に関してだけではなく、アプリケーションを支える技術もいくつか提供しています。キャッシュ機能のサポートもそれにあたるでしょう。ASP.NET には、2 つのキャッシング技術が導入されています。

• Output cache
• Fragment cache

これらは、実行された ASP.NET ページをページ単位や部分ごとにメモリ上にキャッシュし、クライアントの要求に対するレスポンスパフォーマンスを向上させる機能をもっています。これによって、ある程度内容が固定化されているページなどは、リクエストに対してメモリ上から即時にレスポンスを返すことができ、無駄な実行時間を省くことができるようになっています。アプリケーションの配置や実行環境における改良は、実際にアプリケーションとして動作する上では重要ですが、開発者にとっては、実際の開発時における多くの問題を解決していくことが重要となってきます。たとえば、ASP におけるデバッグ機能は、決して十分なものであるとはいえず、開発作業においては、Response.Write() などの記述を使い、さまざまなプロセスでトレースを行うなどでデバッグ作業の代わりをしていたことでしょう。ASP.NET では、この Response.Write () だらけのデバッグコードから開放するために ASP.NET 自身のデバッグ機能を強化しています。トレースのためのコードを埋め込ませておき、web.config で有効/無効を切り替えることで、コードの変更を行わずにデバッグ環境と本番環境を切り替えることができるようになりました。また、実行途中に取得されたさまざまなデータもトレースデータとして出力できるようになっているため、どこに問題があるのかなどを発見するのに役立ちます。デバッグ作業を容易に、かつ、スマートに行えるようになったことで、ASP.NET での開発は、今後、作業効率が向上していくことでしょう。

このようにインフラとしての ASP.NET は、今までのアプリケーション配置や設定に関しての作業の常識を覆すまでの多くの機能をサポートすることによって新たな Web アプリケーションの世界、そして XML Web サービスの世界をサポートしています。

トレース情報の参照

このガイドの中で紹介しているサンプルアプリケーションは、Web アプリケーションの UI 生成、そしてこれらを支えるインフラ技術を活用して構築されています。

サンプルアプリケーションについて

当ガイドで提供している Multi UI Web アプリケーションは、OA サプライを扱う流通企業における営業支援アプリケーションを題材として実装されています。

シナリオとしては、以下のようなものを想定しています。

• 営業担当者は、営業活動として OA サプライ取扱店を訪問する
• 販売店からの要求情報を聞き、在庫の確認、場合によっては、受注業務を行う
• 営業担当者の内勤時においても、何らかの形での問い合わせに対して外勤営業活動時と同様の作業を行う
• 見積りの発行や納期の確認、配送依頼などを一連の業務フローの中で実施する

つまり、日常の業務において、営業担当者には在庫の確認業務や受注業務などが課せられています。これまで、このような業務を一連のアプリケーションによって実装することは容易なことではありませんでした。内勤時のソリューションは、Windows アプリケーションやイントラネット上の Web アプリケーションで実現できます。では、外勤時においては、どのように実現するのでしょうか。ノート PC などを営業活動時に持参して、内勤状態と同じアプリケーションを利用するのでしょうか。確かに現実的には可能な選択肢かもしれませんが、これでは、営業担当者に物理的な負担が大きいでしょう。

このようなシナリオにおいては、モバイルアプリケーションがひとつの解決策になるでしょう。現在のビジネス環境では、インターネットへアクセスできる携帯電話などを持ち歩いていることが多いでしょう。もしくは、一歩進んで Pocket PC のような PDA をスケジュール管理などのために持ち歩いているかもしれません。このようなデバイスを有効に活用していくことで一連のシナリオをひとつのアプリケーションの中に統合していくことができれば、非常に強力な営業支援ツールとなるでしょう。

これを実現する方法のひとつとして Multi UI Web アプリケーションというソリューションがあります。当サンプルアプリケーションは、この Multi UI Web アプリケーションを実現した実装がなされています。

ここでいう "Multi UI Web アプリケーション" とは、ひとつの Web アプリケーションを限定された Web ブラウザや環境をターゲットとするのではなく、デバイスに依存することのない Web アプリケーションのことです。これにより、Internet Explorer に代表されるリッチな Web ブラウザ環境のみをターゲットとするのではなく、携帯電話や PDA といったデバイスへも範囲を広げ、ビジネスにおけるアプリケーションニーズを満たすことができるのです。

一連の処理フロー

表 1: 作業番号とその詳細、取り扱われるデータ類

では、どのようなアプリケーション要求が存在するのか、そして、実際にソリューションを展開していくための方法を探っていくことにしましょう。

アプリケーションに対しての要求

Multi UI Web アプリケーションとはいったいどのようなアプリケーション要求によって発生していくのでしょうか。順を追ってこのアプリケーションの意味を考えてみます。

■ Web アプリケーションとして

昨今、さまざまな業務アプリケーションがありますが、その中で今日 Web アプリケーションとしての展開を検討しているものがいくつかあると思います。また、業務アプリケーションだけではなく、e-Commerce サイトのようにインターネット上でのビジネスの展開を考えていくのであれば、Web アプリケーションというのは重要な要素をもっています。

HTML などで作成された静的なコンテンツのみを公開したり共有するだけでなく、動的に編集される情報の提供やアプリケーション機能をもたせることが重要になってきたのです。

今日、このようなサイトに対しての情報取得動作は Internet Explorer などのブラウザだけではなく、i-Mode をはじめとする携帯電話や PDA などの情報端末などからアクセスし、アプリケーションの機能を呼び出し利用していくことができるようになってきました。このように Web アプリケーションに対してのクライアントデバイスが増加の一途をたどっている中、アプリケーションは、それらのデバイスへの対応を迅速に行うことができているのでしょうか。確かに、人員を動員し開発作業を行うことで対応できるかもしれませんが、総合的に見た場合、そこにかかるコストは大きく、また、投資に対しての効果を見極めるのも難しい状況であるのではないでしょうか。

サイトへアクセスしてくるユーザーのターゲットを広くもたせることは、容易ではありませんでした。しかし、現在では、これらの要求が高まってきていることも事実です。これらの要求を満たすことができれば、ターゲットを広げることでビジネスに対してのチャンスも広がりますし、業務アプリケーションなどに適用すれば、受注処理や在庫確認といった作業を Web アプリケーションから外出先で携帯端末などによって行うといったことも実現できるのです。

■ Mobile Internet Toolkit の利用

このようなアプリケーションの展開は夢物語ではありません。ミドルウェアなどの導入で実現することもできます。しかし、これでは、さまざまなデバイスへアプリケーションを対応させていくために多くのコストがかかってしまいます。また、アプリケーション開発に際し、新しい知識（HTML や言語だけではなく、CHTML や WML というようなモバイルのための技術など）を理解している必要が求められたりもするでしょう。

そこで、Microsoft Mobile Internet Toolkit（以下、MMIT）の利用を検討します。この MMIT は、ASP.NET のもつ UI 生成機能の拡張コンポーネントであると考えればよいでしょう。

Mobile Web フォームのクラスと ASP.NET Web フォームのクラスの関係

ASP.NET は、もともと Web フォームという機能も提供することで HTML や DHTML による UI の生成機能を実現していました。ここに MMIT で提供される Mobile Web フォームを追加することで、HTML、cHTML、DHTML、WML の生成をダイナミックに行うことができるようになります。また、これらのどの規格によって、UI を生成すればいいのかについては、システムがアクセスしてきたデバイスの情報を自動的に判断して決定します。

MMIT は、このように Web フォーム機能の拡張だけを行うものではありません。開発ツールとしてのサポートも行われています。MMIT を開発環境上へ導入することによって、Visual Studio .NETとの統合が行えます。この統合によって、Mobile Web アプリケーションを構築していくために必要な機能を Visual Studio .NET へアドオンできます。つまり、通常の Web アプリケーションの開発とまったく同じ方法で Mobile Web アプリケーションの構築が可能になったのです。Visual Studio .NET のツールボックスから必要なコントロールをデザイン画面へ配置し、必要なロジックを挿入するという Web フォームを利用した UI 作成と同じ方法で実装していくことができるのです。

また、これらの新しい機能が提供されたことにより新たな技術習得の必要性を軽減しています。前述のとおり UI のデザインや実装の作業方法についてはもちろんのこと、UI の生成に必要なロジックの実装などにおいては、統一されたプログラミングモデルの採用によって、Windows アプリケーションや Web アプリケーションでの Web フォームの実装との共通化が図られています。たとえば、文字列を表示したいのであれば Label コントロールの Text プロパティへアクセスすれば実現できますし、ボタンがクリックされた ときのイベントは Click イベントであるというように、新しいソリューションである Mobile Web アプリケーションのために新たな実装方法を学ぶことなく、今までの知識を活用していくことができるのです。

.NET Framework 上の Mobile Web フォームの位置

MMIT 動作の様子

このような機能が提供されることで、開発者は、「Web フォームによる Web アプリケーションの開発を行う」というひとつの知識によって、迅速にさまざまなデバイスに対応することのできる Web アプリケーションの開発を進めていくことができるようになるのです。

Multi UI Web アプリケーションの設計

では、ASP.NET Web フォームと MMIT の提供する Mobile Web フォームを組み合わせながら、Multi UI Web アプリケーションの構築とそのために必要となる設計手法を見ていくことにしましょう。

■ ASP.NET によるコードと UI の分離

ASP.NET を利用した Web アプリケーションを Visual Studio .NET によって開発していく場合、無意識のうちに UI 生成のためのロジックとイベントロジックが分離されていることに気づかれたでしょうか。たとえば、Visual Studio .NET において、default.aspx という UI を生成したとします。するとC# を利用するのであれば、default.aspx.cs、Visual Basic .NET を利用するのであれば、default.aspx.vb というファイルも同時に生成されます。この際、default.aspx には、UI 生成に必要なコントロールに関する情報などデザイン的な要素のみが実装され、ユーザーの操作によって発生するイベント処理などは、default.aspx.cs もしくは、default.aspx.vb というソースファイルに記述していくようになります。

ASP.NET によるコードと UI の分離

このような手法を用いると、UI の変更やロジックが変更されたときに、各々の変更が他方に対しての影響を軽減することができます。つまり、アプリケーション自身に柔軟性をもたせたことにより、変更に対しての耐性を強化することができるのです。ASP.NET においては、いままでの ASP における開発スタイルと同様にページの中にイベント処理や UI 生成のコードを混在させた実装を行うこともできますが、アプリケーションの設計上の観点から見ると、正しい実装方法ではありません。このような開発手法を用いることは、UI 設計・実装における疎結合を実現しているといえるでしょう。

ASP における実装例
特定の ASP ページ内において描画ロジックと処理ロジックが混在した実装が多い。手軽な実装手段であるが、その分、変更に対しての耐性を失うなどの障害を生じる。

ASP.NET における実装例
ASP での実装と異なり、レンダリングロジックと処理部分が明示的に 分割化して実装することができる。このようにすることでUI 部分における 実装上の構造が明確となり柔軟性を得ることができる。

■ 設計手法と開発指針

モバイルをターゲットとしたソリューションを構築していく際には、検討しなければならない事項があります。それは、アプリケーションの実装の前段階として、Web アプリケーション自身をどのように設計するのかという点です。確かに Visual Studio .NET と ASP.NET を活用すれば、いままでの Visual Basic と同じようにイベントドリブン型のサーバーサイドアプリケーションを構築していくことができます。しかし、同じアプリケーション機能に対していくつものデバイスをサポートし、また、日々変化していくビジネスニーズにアプリケーションを対応させていくには、それなりの設計が必要となってきます。

この項では、実際に Multi UI Web アプリケーションを提供していく段階においてどのように設計し、実装へ向かっていけばいいのかを紹介します。Multi UI Web アプリケーション、つまりモバイルもターゲットとした Web アプリケーションの構築を考えていく上で重要なのは、UI の設計における柔軟性の考慮です。UI の設計と考えると、ある範囲に閉じた世界であると考えられがちですが、実際はそうではありません。UI を形成するページ群をひとつのオブジェクトとして捕らえると、実は、このような部分にもオブジェクト指向的な設計概念が利用可能であることに気がつくでしょう。MVC（Model, View and Controller）は、UI をオブジェクト指向的観点から捕えた際に考案されたデザインパターンのひとつであることは、周知のとおりです。前述の UI とロジックの明示的な分離を行 うVisual Studio .NET の提供する実装機能は、このようなデザインパターンをツール自身がサポートしているということを意味しています。また、開発者が無意識のうちにこのような考えに基づいた実装を行うことができるということでもあります。

さて、Multi UI Web アプリケーションを構築していく場合、いくつかの制約があることにも気がついていなければなりません。たとえば、MMIT によって提供される Mobile Web フォームは、さまざまなデバイスに対応した UI を生成するための機能をもっていますが、モバイルなどの制限された環境へフォーカスされた実装であるため、よりリッチなクライアントとなる Internet Explorer などのブラウザへの UI のレンダリングには適していません。また、その逆に ASP.NET 自身で提供する Web フォームは、優れたデザイン機能と UI レンダリング機能を持ち合わせていますが、モバイルデバイスへのレンダリングには適していません。つまり、単一の Web アプリケーションにおけるシナリオにおいて双方をサポートするには、各々の技術を用いながら、クライアントに適した UI を用意する必要があるのです。

このような制約条件がある中で、どのように Multi UI Web アプリケーションを設計していけばいいのでしょうか。各々のデバイスのために特化した設計を行い、それぞれのアプリケーションを実装しなければならないのでしょうか。

たとえば、各々のデバイスのためにアプリケーションを実装していたとします。もちろん、これもひとつのアプローチであると考えられますが、あまり良い方法でないことは明らかです。アプリケーションに対して何らかの変更が行われた場合、それぞれのアプリケーションの修正を施し、それぞれのアプリケーションを配置しなければならないのです。設計手法が最善でなかったことによって、結果としてアプリケーション自身の柔軟性が損なわれてしまったわけです。では、このような状況を改善するにはどのようにしたらいいのでしょうか。

オブジェクト指向技術をベースとしたデザインパターンは、さまざまなものがあります。これらパターンといわれるものは、オブジェクト指向にのっとったアプリケーションの設計を行っていく中で生まれてきたノウハウのようなものです。これらから、今回の Multi UI Web アプリケーション構築のためのヒントを探してみましょう。

先に紹介した MVC というモデルは、UI とロジックの分離によって、アプリケーション自身の柔軟性を獲得するためのひとつの手段として適切な選択肢です。もちろん、この「パターン」を全面的に採用するというのもひとつの方法です。しかしこれだけでは十分ではありません。もうひとつ、BCE（Boundary Control Entity）の採用も検討してみます。こちらも、UI とロジックにかかわるパターンのひとつです。この 2 つのパターンでは、UI とアプリケーションのロジックとの関係、そして、UI とイベントロジックとの関係をすっきりさせることができます。単にひとつの手段だけを検討するのではなく、このようにいくつかの手法を検討し、新しいソリューションを展開していくことが大切なアプローチなのです。

では、MVC と BCE を組み合わせた形のデザインを紹介したいと思います。

UI の生成にかかわる部分においては、実装上の制約によってリッチな Web UI とモバイルのための Web UI をそれぞれ用意します。ここで用意されているオブジェクトに対してのイベント処理は、ページ内コードで実装します。しかし、このイベントロジックでは、直接的なアプリケーション処理を実装するわけではありません。実は、このバックエンドに Facade（ファサード）レイヤを用意しておきます。実際のアプリケーションの実装をこの部分でコントロールします。つまり、UI（View）から見た場合、この Facade レイヤによって動作を制御しているということができます。そして、各アプリケーションの機能に対しての実装は、この Facade レイヤの下位に配置することによって、隠蔽することができます。

このような設計手法を用いることにより、アプリケーションの柔軟性を向上させることができますし、また、スケーラビリティを拡大することができるのです。

たとえば、前述と同様にアプリケーションの実装において変更が行われたとしましょう。ここで紹介している設計手法を取り入れていることで、各々のビジネスロジックに変更が行われたとしても、UI のレイヤから明示的に分離しているため UI に影響をきたしません。また、逆の場合も同様に UI のデザインやページネーションを変更したからといってビジネスロジックに影響をきたすことはありません。また、変更に対しての耐性だけではなく、ロードバランシングサービスやクラスタ化などを検討していく中でも、このような配置になっていることでスケーラビリティを得ることができるのです。

下図のような形態で設計を施したものをベースとして実装していくということは、単に今あるアプリケーションに対してだけではなく、その先にある発展をも考慮した重要な作業であるということができるでしょう。

アプリケーションデザインにおける問題点と解決手段
ここで紹介しているデザインの手法は、.NET Framework および ASP.NET における実装上の問題を考慮した形態で検討されているものです。従って、MVC や BCE などのパターン自身に完全準拠しているモデルを提示しているわけではありません。アプリケーション設計上のエッセンスとしてこれらのパターンを検討し、結果として図のような手法を導き出しています。

おわりに

このように .NET Framework SDK で提供される ASP.NET そして、Microsoft Mobile Internet Toolkit を組み合わせ、適切に設計を行えば、Web アプリケーションを単に Internet Explorer などの Web ブラウザだけではなく、インターネットへアクセス可能なさまざまなデバイスへ展開していくことができます。また、このような Web アプリケーションは、.NET Framework 上で動作していることから、XML Web サービスとの連携を実現することもできます。つまり、Web アプリケーションが、真の Web ソリューションへと進化した証でもあります。

添付提供されているサンプルアプリケーションを通じ、新たな Web ソリューションの世界を体験され、ここから新たなビジネスが生まれてゆくことを願ってやみません。

参考資料

.NET Framework 上の ASP.NET、および Microsoft Mobile Internet Toolkit に関しての情報は、以下の URL などでも紹介されています。あわせてご参照いただき、アプリケーションの開発へお役立てください。

• MSDN Online（日本語）
  http://www.microsoft.com/japan/msdn/
• MSDN Online .NET 開発（日本語）
  http://www.microsoft.com/japan/msdn/net/
• Microsoft Mobile Internet Toolkit 情報サイト
  http://www.microsoft.com/japan/msdn/vstudio/device/mitdefault.aspx
• Microsoft Mobile Internet Toolkit（日本語版）ダウンロードサイト
  http://www.microsoft.com/japan/msdn/vstudio/device/mitdownload.aspx
• MSDN Online（英語）
  http://msdn.microsoft.com/en-us/default.aspx
• MSDN Online - .NET Development（英語）
  http://msdn.microsoft.com/en-us/netframework/default.aspx
• ASP.NET リソースサイト（英語）
  http://www.aspx.net/
• .NET Framework コミュニティー Web サイト（英語）
  http://gotdotnet.com/

また、アプリケーションの設計を行っていく中で利用されるパターン（当ガイド内では、アーキテクチャパターンやデザインパターンなどを総称し「パターン」と表記しています）などについては、紙面で紹介しただけではありません。オブジェクト指向技術が進化してきた過程の中で、経験と実績から導き出されたひとつの解として、多くのものが存在しています。これらの情報に関しては、インターネット上のサイトにおいて公開されているものもあります。また、多くの書籍も刊行されています。これらのリソースからアプリケーション設計に関してのエッセンスを吸収していくことでより理解が深まるでしょう。

※お使いのシステムの環境、および利用方法によっては、記載以外の制限が発生する場合もございますので、あらかじめご了承ください。