Category Archives: Web技術

Webサーバーの仕組み – メイドさんでも分かるプログラミングシリーズ vol.3

WWW(World Wide Web)は、世界中の論文をリンクする仕組みだった

昔々、と言っても1990年代なのですが、Timさん (Tim Berners-Lee)という人が、現在私達が「インターネット」だと思っている世界を考えました。

World Wide Webと名付けられたそれは、当時、できたてほやほやの「The Internet」を使って、論文を公開する仕組みとして設計されたものでした。

論文は他の論文を引用します。引用先はワンクリックでジャンプできたら便利です。そこで、引用先にリンクできる仕組みを「ハイパーリンク」を実現するテキスト文書「ハイパーテキスト」が誕生しました。「HTML」です。これは

<a href="リンク先">リンクテキスト</a>

のように書くと、他の文書にリンクできる画期的な書式でした！

Webとはくもの巣という意味です。文書と文書がリンクによってくもの巣のように世界中に張り巡らされている！それがワールドワイドなウェブの目指す世界だったのです。

この世界を実現するために、論文を読むためのソフト（Webブラウザー）と、論文を配信するホストコンピュータ（Webサーバー）が作られました。WebブラウザーとWebサーバーは互いに通信をします。通信をするための決まりごとを「プロトコル」と言います。Web専用のプロトコルとして、「HTTP (Hyper Text Transfer Protocol)」が作られました。

用語のおさらい

用語	意味
World Wide Web	Timさんが考えた「The Internet」上の論文配信ネットワーク
ハイパーリンク	論文から引用先論文にジャンプする画期的機能
ハイパーテキスト(HTML)	ハイパーリンクを実現するための文書形式
Webサーバー	論文を配信するサーバー
Webブラウザ	論文を閲覧するためのソフト
プロトコル	通信をするための決まりごと
HTTP	WebサーバーとWebブラウザの間で行われる通信のプロトコル

HTTPの仕組み

論文をサーバーから貰うには、次の情報が必要です。

論文のファイル名

論文を取得する命令をGETと名付けられました。

GET /folder/hogehoge.html

この命令（「HTTPリクエスト」と言います）を受け取ったWebサーバーは、folderの中にhogehoge.htmlがあれば次の情報を返します。

「あったよ！」という情報
hogehoge.html の内容

これらを合わせて「HTTPレスポンス」と言います。

そのうち、前者を「ステータスコード」と言います。これは数字3桁によって定められていて、例えば次のように決まっています。

200: OK (あったよ！)
400: BAD REQUEST（リクエストが間違ってるよ！）
404: NOT FOUND（そんなファイル無いよ！）
500: INTERNAL SERVER ERROR（ごめん、サーバーでエラーが起きちゃった（汗;）
503: Service Unavailable（ごめん、今混んでるみたいだ！後でもう一度来て！）

とてもシンプルな仕組みですね！

WebサーバーがHTMLを自動生成しても良い

Webサーバーは、Webブラウザーから、リクエストを受け取ったら、ステータスコードと、HTMLページを返せば良いのです。HTMLページは、サーバーのディスク上に、HTMLファイルとして置いておくことが最もシンプルですが、別に、ファイルがなくても、その場でプログラムで作ってしまっても良いのです！

Webリクエストを受け取ったWebサーバーが、プログラムを動かす仕組みとして、CGI (Common Gateway Interface) という物が作られました。

プログラムによって毎回違うページを作ることができるので便利です（例えば、現在時刻を出力！）このようなページのことを「動的ページ」と言います。反対に毎回変わらないページを「静的ページ」と言います。

Webリクエストにパラメータを渡したくなったら

CGIによって「動的ページ」が実現できると、プログラムにパラメータを与えたくなってきます。そこで、初め、ファイル名の後ろに?を付けてその後ろにパラメータをつけていく方法が考えられました。

GET xxx.html?id=1

この方法はとても便利です。現在でも、Googleの検索結果を

https://www.google.com/?q=Java

のように表すことができます。

しかし、問題がありました。

大量のデータを送ろうとすると長くなりすぎる

そこで、POSTという別の方法が考えられました。これは、ファイル名を指定した後、一行空行を開けてパラメータを送るという方法です。

POST /hello.cgi

name=taro&age=20&country=Japan&.......

これによって、非常に大量の情報が遅れるようになったので、Webを使って「ご注文フォーム」が作れるようになりました。Amazonのようなネット通販の始まりです。

時代の流れとともに、いろんな情報を送りたくなってきた

時代は流れ、WWWは論文の配信だけにとどまらず、通販やゲームのようなあらゆる用途で使用されるようになってきました。しかも、文書だけでなく、画像、音声、映像、様々な種類のデータを配信するようになります。

そうすると、HTTPもどんどん複雑になります。現在はHTTP 1.1というバージョンが主流で、次のようにいろんな情報を送ります。

GET http://www.susumuis.info/
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:ja,en-US;q=0.8,en;q=0.6
Cache-Control:no-cache
Connection:keep-alive
Cookie:
Host:www.susumuis.info
Pragma:no-cache
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36

レスポンスは

200 OK
Cache-Control:no-cache, must-revalidate, max-age=0
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html; charset=UTF-8
Date:Mon, 04 Jan 2016 02:57:30 GMT
Expires:Wed, 11 Jan 1984 05:00:00 GMT
Pragma:no-cache
Server:nginx
Transfer-Encoding:chunked
Vary:Accept-Encoding

<!DOCTYPE html>
<html>
〜
（省略）
</html>

こんな風に、色々な情報が付与されてきます。Accept:のようにHTTPリクエストに付与される付加情報を「リクエストヘッダ」と呼びます。Cache-Control:のようにHTTPレスポンスに付与される付加情報を「レスポンスヘッダ」と呼びます。

Content-Typeヘッダについて

レスポンスヘッダに次の部分がありました。これは「コンテンツタイプ」といって、とても重要な情報です。

Content-Type:text/html; charset=UTF-8

text/htmlは、「MIME Type」と呼ばれる情報です。これは、レスポンスするデータの種類を表しています。MIME Typeには次のようなものがあります。

MIME Type	意味
text/plain	テキスト文書
text/html	HTMLページ
image/jpeg	JPEG画像
text/javascript	JavaScript
application/xml	XMLデータ
application/json	JSONデータ

アプリとWebサーバー

本来、Webサーバーは、WebブラウザーにWebページを配信することを目的としたサーバーでした。しかし、時代は流れ、Webブラウザだけでなく、HTTPプロトコルさえ使えれば、Webサーバーと通信ができる特性を利用して、スマートフォンアプリなどのプログラムがサーバーと通信をするために大変広く使われるようになりました。

HTTPがシンプル・高機能・有名で便利だったからです。

プログラム同士の通信では、もう、HTMLを使用する必要はありません。HTMLは人間に見た目を提供するためのフォーマットだからです。

プログラムで使う場合は、XMLまたはJSONというデータ形式が使われます。

XMLの例

<items>
  <item>
    <name>アイテム1</name>
    <price>1000</price>
    <image>xxxxxx.jpg</image>
  </item>
  <item>
    <name>アイテム2</name>
    <price>1240</price>
    <image>yyyyyy.jpg</image>
  </item>
</items>

JSONの例

{
    {
        "name": "アイテム1",
        "price": 1000,
        "image": "xxxxxx.jpg"
    },
    {
        "name": "アイテム2",
        "price": 1250,
        "image": "yyyyyy.jpg"
    }
}

サーバーはどうなっているの？

アプリ側から、サーバーの内部を意識する必要はありません。しかし、サーバーは通常次のように作られています。

Webサーバー

Apacheや、IIS、Nginxというようなサーバーソフトが使われます。

サーバープログラム

PHPや、Javaや、Rubyで書かれています。その間にアプリケーション・サーバーというソフトウェアが動いている場合もあります。

DBサーバー

Webサーバーは非常に大量のデータを扱うため、DBサーバーという専用のソフトウェアが使われることが大変多いです、MySQL、PostgreSQL、Oracleなどが有名です。

キャッシュサーバー

DBサーバーは非常に便利ですが、遅いという問題があります。そこで、高速化の目的で、別途キャッシュ用のサーバーが用意されていることがあります。Redis、Memcachedなどが有名です。

まとめ

このように、もともと論文を配信するためであったWebサーバーはとても便利なので、アプリのデータをやり取りするために使われるようになりました。

Webサーバーは今やとても複雑な仕組みですが、呼び出す側としては、HTTPプロトコルさえ分かればやり取りができるので、内部まで意識しなくても大丈夫です！

それでは、次回は実際にアプリから呼び出す方法を説明していきます。

テンプレートエンジンMayaaについて知りたいすべての人へ

ここまでを振り返って

Mayaaアドベントカレンダーを通じて、自分の持っているMayaaのノウハウを放出することで、世界で一番詳しいMayaaのノウハウ集をアウトプットしようと考えていました。

振り返ってみると、コーディングルールだったり、フレームワークとの連携だったり、拡張方法だったり、教育や、ソースコードの読み方など、本当にあらゆることを書けました。

そこで、今日はここまで書いたこと、及び、公式ドキュメントや、このブログの過去の記事、別の方の記事などをインデックス化することで、Mayaaについて調べる時のポータルページを作りたいと思います。

この、世界一詳しいMayaaのノウハウ集を、皆さんへの本当のクリスマスプレゼントとして捧げたいと思います。

Mayaaとは何か知りたい

公式サイト
- 大変素晴らしく整っているサイトです。ドキュメントの品質の良さがMayaaの良さと行っても過言ではありません。
- まずは、Mayaaの導入とチュートリアルを読んでみてください！
1日目:Mayaaとの出会い, 2日目:JSPで書かれたシステムをMayaaに移行する
- この2つを読めば、実案件での導入のイメージが掴めると思います
8日目:mayaaの向いてるサイト、向いていないサイト
- Mayaaは個性の強いテンプレートエンジンですので、苦手なサイトに適用しないように、ご注意ください。

プログラマー向け

Mayaaの使い方を覚えたい

3日目:MayaaでWebサイトのビューを実装するときに押さえておくべき基本テクニック1 – m:idの命名規則と実装方法
4日目:MayaaでWebサイトのビューを実装するときに押さえておくべき基本テクニック2 – m:idの実装における注意点
5日目:MayaaでWebサイトのビューを実装するときに押さえておくべき基本テクニック3 – m:idを減らすテクニック
6日目:MayaaでWebサイトのビューを実装するときに押さえておくべき基本テクニック4 – ヘッダー・フッター共通部分の扱い
7日目:MayaaでWebサイトのビューを実装するときに押さえておくべき基本テクニック5 – その他雑多なテクニック
- Mayaaをなるべく標準状態で、実用活用する方法論として、いしがみメソッドを提唱しています。Mayaaの使い方は一つではありませんが、実際に大規模サイトを構築できている方法論なので、一つの指針として参考に頂きたく思います。
- リーダー・アーキテクトの方は、もしいしがみメソッドを活用していただくならば、メンバーの方に一度見ていただくと良いかもしれません。
- （教育用に適さない表現などあったら訂正しますのでご指摘ください）

アーキテクト・上級プログラマー向け

ここから先は、Mayaaをどのように活用するかという話になります。

Mayaaを拡張・チューニングしたい、トラブルシューティングしたい

プロジェクトマネージャ、リーダー向け

Mayaaを使ったプロジェクト運営論

豆知識系

まとめ

25日間お疲れ様でした。
いかがでしたでしょうか？

ブログを毎日書くのは初めての体験で雑なところなどもあったと思います。半ば書ければいいやなどの投げやりな気持ちも1mmくらいはあったと思います。

しかし、今時派手ではない、テンプレートエンジンのノウハウはこうでもしないとアウトプットされないでしょうから、この機会があって良かったと思います。

今後僕は、あらゆる場面でこのアドベントカレンダーの一覧の記事を活用していこうと思います。その際にあらに気づいたら自ら直して行くことでしょう。

つまり、世界一詳しいMayaaノウハウ集づくりは、ここが起点なのです。Mayaaが続く限り、将来にわたってこれらの記事をメンテし続けることを約束します。

それではみなさん、メリークリスマス、そして良いお年を！

Mayaaソースコードの読み方

Mayaaのソースコードの読み方

MayaaのソースコードはGitHubにあります。

さて、git cloneで落としましたか？

今日はこいつの読み方を説明します。準備は良いでしょうか？

プロジェクト構成を眺める

プロジェクトフォルダをざっと見ると、

src-api
src-impl

2つのフォルダがあります。僕はこのようなフォルダ構成はMayaaしか知りません。試しにGoogleで「src-impl」と打ち込むと、Mayaaのソースが出てくるからMayaaの独特の構成かもしれません。

contect フォルダはライセンス情報や依存ライブラリ、Webアプリとして単体起動させるための設定情報などがあるだけで、ライブラリとしてあまり重要なものはありませんので、コードリーディング時は無視してよいです。

src-apiでAPI構成を知る

src-apiにはinterfaceが定義されています。つまり、src-apiに存在するインターフェースは何らかの方法で実装を交換可能になっているということです。

実装が交換可能ということは、独立した部品とみなされていると言って良いです。つまり、src-apiをざっと見れば、Mayaaがどんな部品によって構成されているかを知ることが出来ます。

パッケージ階層を見ると次のような構成であることが分かります。

builder
cycle
engine
provider
source

Mayaa内部の用語なので、これだけ見ても、最初は慣れないと思いますが、そこで、Mayaaの処理する流れをざっと説明します。

engineはMayaa中心で起点と考えてよいです。

engineの中は、processorと、specificationに分かれます。specificationはmayaaファイルやテンプレートの定義情報をモデル化したものです。processorは、テンプレートエンジンがそのノードをどのように処理するかをオブジェクト化したものです。つまり、specificationによって組み立てられたprocessorがあればMayaaエンジンはHTMLを出力することが出来ます。

providerはアプリケーションスコープのリソースです。エンジンの設定や、各インターフェースの実装クラスの選択はここが担当します。そのため、Mayaaの設定はorg.seasar.mayaa.provider.ServiceProviderなのです。

sourceは、mayaaファイルやhtmlテンプレートなどユーザーが作成するソースファイルを抽象化しています。他のインターフェースに依存しませんが、実装上は、ビルド時にほぼ必ず使用します。

cycleは、リクエスト処理のコンテキストを扱います。リクエスト・レスポンス、現在処理中のノードといったスレッドローカルなコンテキストはここに格納されていきます。

builderは（主にsourceを元にして）SpecificationNodeを組み立てます。

つまり、provider, cycleは事実上Engineを動かすのに必要ですが、何らかの方法でspecification/processorが構成できてしまえば、builder, sourceは切り離せるとも言えます。

継承の起点としてのインターフェースを理解する

次に、クラス階層から実装の作法を理解してみましょう。

こんなクラスが実装の起点に存在しています。

PositionAware
- NodeTreeWalker
- ParameterAware
ContextAware
UnifiedFactory

これらをざっと眺めておくと後々実装を追いやすくなります。

実装クラスの起点はMayaaServletから

なんだかんだ言っても実装はMayaaServletから追い始めるのがベターです。

MayaaServlet#doServiceで、Cycleを初期化し、ProviderからEngineを取得して実行しているのが分かります。

EngineImpl#doServiceを追って行くと、EngineImpl#doPageServiceという大きなメソッドに行き着きます。ここが、一リクエスト分のレンダリング処理の主要部分です。ここを起点に、テンプレートの情報を取得し、各部品を実行することで、結果としてのHTML文書が出力しされます。

大枠を理解できたら後は部品ごとの設計を理解する

例えば、SourceDescriptorは内部でCompositeパターンになっています。Processorを理解するには、TemplateProcessorSupportという巨大なクラスの機能を理解する必要があるでしょう。

また、Rhinoスクリプティング機能は、cycle.script.rhino内に収められています。したがって、これと同等の部品を実装して、独自のCompiledScriptが実装ができれば、スクリプトエンジンをRhino以外に切り替えることもできます。

まとめ

Mayaaのソースコードは、各部品の独立性と抽象度が高く設計されています。このため、全体を各部品に切り離して考えることが出来、一部分を拡張したり、変更することが行いやすくなっています。

FactoryFactoryがある時点で、DIコンテナが普及する以前の香りがしますね。Seasarプロジェクトと言いながらSeasarに依存しないのは、このように独自にフレームワークを作っているからなのです！また、今回は触れませんでしたが、内部には、GCの管理や、シリアライザーをガリガリいじったり、相当低レベルのこともしています。（それらを読んでいるととても勉強になります）

こういった低レベルな部分がソースを膨らませているとも言えます。何も知らないで読むと、溺れてしまいそうです。しかし、フレームワーク的なところ、低レベル過ぎるところは一旦置いておくと、読むべき範囲は限定されてきます。

ソースコードを読む動機というのは様々で、拡張したい時の他に、トラブルシューティングをするとき、パフォーマンスチューニングしたい時などいろいろあると思いますが、その時必要な範囲で読めるように、普段から慣れておけば、そんなに怖いものではありません。

susumuis Info

Webエンジニア susumuis の技術ブログ