この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方)
出典検索?: "Webアプリケーションフレームワーク"
Web アプリケーションフレームワーク(英: Web Application Framework)は、動的なWebサイト、Webアプリケーション、Webサービスの開発をサポートするために設計されたフレームワークである。
Webアプリケーションフレームワークの目的は、Web開発で用いられる共通した作業に伴う労力の軽減である。たとえば、多数のフレームワークがデータベースへのアクセスのためのライブラリやテンプレートエンジン(Webテンプレートも参照)、セッション管理を提供し、コードの再利用を促進させるものもある。 World Wide Webの設計は元々ダイナミックなものではなく、初期のハイパーテキストは Webサーバ上で公開されたハードコードのHTMLでできていた。 公開されたページについての変更はページの作者が行う必要があった。ユーザーからの入力を反映したコンテンツを提供するため、Webサーバが外部のアプリケーションとやり取りするためのCommon Gateway Interface (CGI) 標準が導入された。[1]CGIでは各リクエストが別々のプロセスを開始しなければならないため、サーバの負荷に悪い影響を与えることがある。 高いトラフィックに対応したWebアプリケーションを実現するため、プログラマはWebサーバとの密な結合を望んだ。Apache HTTP Serverは、例えば、Webサーバが任意のコードを実行したり(mod pythonなど)、特定のリクエストを動的なコンテンツを扱えるWebサーバに転送するような(mod_jk 同じころWeb用途に特化してPHPやActive Server Pagesなどの新しい言語が開発された。 Webページの動的な生成に用いられる大半のプログラミング言語が、共通した作業を行うためのライブラリを持っているが、Webアプリケーションは HTMLの生成(たとえば JavaServer Faces)などWebアプリケーションで有用なライブラリを必要とすることが多い。 成熟した「フルスタック」フレームワークが登場した。これは、複数のWeb開発に有用なライブラリを一つに結合したWeb開発者向けの ソフトウェアスタック 従来のフレームワークは基本的に横型に分割されているため、ユーザ機能を追加 / 変更 / 削除する場合は、アプリケーションを入れ替える必要があった。ポータルフレームワークはユーザ機能を縦型に分割し、ユーザ機能毎にホット・デプロイ / アンデプロイできる。デプロイされたポートレットをドラッグ・アンド・ドロップ操作でWebページに配置することができるのが特徴である。 なお、ポートレット毎にエンティティインターフェース(モデル)、表示(ビュー)、業務ロジックが含まれているため、ポートレット毎に異なるスタック技術を利用することもできる。例えばJSFで作成したポートレットとSpring Frameworkで作成したポートレットを1つのWebページに配置することができる。また、異なった言語でポートレットを記述することもできる。例えばJava、Ruby、PHPで記述したポートレットを一つのWebページに配置できる。 ユーザ機能を随時に追加/置き換え/削除することができるため、ポートレットフレームワークはアジャイル開発のように継続的に開発を行う場合に適している。例えばScrumの各ユーザストリーをプラグインにすることができる。 ポートレットフレームワークを利用したWebシステムの例として、liferay、Alfrescoなどがある。その中でliferayは開発者向けのツールが揃っている。 多数のフレームワークが、データモデル、ビジネスロジック、ユーザーインターフェイスを分割するためにMVCモデルに従っている。 ほとんどのMVCフレームワークは、プッシュ型のアーキテクチャにしたがっている。このようなフレームワークは、処理を要求するアクションを実行し、次に結果を出力するためにデータを表示のレイヤにプッシュする。[2] Struts、Django、Ruby on Rails、Spring Frameworkの一部であるSpring MVCなどがこのアーキテクチャの良い例である。 これに対するものとしてプル型のアーキテクチャがあり、「コンポーネント型」とも呼ばれている。こうしたフレームワークは表示レイヤから処理を開始し、必要に応じて複数のコントローラからの処理の結果を「プル」する。このアーキテクチャでは、複数のコントローラーが一つのビューに関連付けられる。Tapestry、Velocity などがプル型アーキテクチャの一例である。 自己記述的なコンテンツ管理システムが、高位のレイヤーのWebアプリケーションフレームワークに進出し始めている。例えば、Drupalの構造は Webアプリケーションフレームワークに関連した機能を提供するモジュールにより機能を拡張できる最小限のコアを提供している。WordPress、JoomlaとPloneも同様な機能を持っている。Liferay(オープンソース)のような高度な汎用コンテンツ管理システムでは、更にコンテンツのバージョン管理、公開開始日/終了日、公開する前の承認ワークフロー、プレビュー機能、マルチメディアコンテンツの対応など従来ではWebSphereやMicrosoft SharePointなどでしか提供されていない機能にも対応している。伝統的にこれらは コンテンツ管理システムとも呼ばれる。 しかし、コンテンツの管理がこれらのシステムの上で最重要の機能であるかについては議論の余地がある。Liferayのようなフレームワークは関数API、機能のフレームワークやコーディング標準、伝統的にWebアプリケーションフレームワークに関連する機能も提供している。 Webアプリケーションフレームワークにはアクセス制御機能(ユーザ認証とアクセス認可)を備えたものもある。Djangoはその一例で、ロールに基づいてページに対するアクセスを管理する機能と、ユーザーの作成やロールの割り当てのためのWebベースのインターフェイスを提供する。 多数のWebアプリケーションフレームワークはバックエンドのデータベースに対する統一されたAPIを提供し、コードの変更なく多数のデータベースとやりとりすることを可能にし、プログラマーがより高位の概念を扱うことができるようにしている。また高いパフォーマンスを得るため、AOLserver さらに、オブジェクト指向フレームワークはオブジェクトと関係モデルとの対応づけを行うオブジェクト関係マッピングの機能を提供するマッピングツールを備えている。
Webアプリケーションフレームワークの発展の歴史
Common Gateway Interface (CGI)
密結合
Web言語
Webライブラリ
フルスタック
ポートレット
アーキテクチャ
Model view controller
プッシュ型とプル型の比較
コンテンツ管理システム
機能
セキュリティ
データベースへのアクセスおよびマッピング
Size:33 KB
出典: フリー百科事典『ウィキペディア(Wikipedia)』
担当:undef