[1] [[Webアプリケーション]]の本体[[サーバー]]のことを、
[DFN[[RUBYB[[[アプリケーションサーバー]]]@en[application server]]]]や[DFN[[RUBYB[[[バックエンド]]]@en[backend]]]]などと呼びます。

* 意味

[2] 
ふつう、 [[Webアプリケーション]]を構成する[[サーバー]]を[[データベース]]サーバー、
[[プロキシ]]サーバー、
その他の[[ストレージ]]サーバーといった役割によって分けるときに、
[[アプリケーション]]本体を指すために使う言葉です。

[5] 
[[プロキシサーバー]]や[[キャッシュサーバー]]を前面に置く構成のとき、
[[クライアント]]は[[アプリケーションサーバー]]に直接アクセスせず、
前面のサーバーを通して間接的にアクセスすることになります。
この場合は前面のサーバーと[[アプリケーションサーバー]]
(やその他の構成[[サーバー]])
の全体が1つの
[[Webサーバー]]として機能するといえます。

[3] 
ほとんどの場合、
[[アプリケーションサーバー]]は
[[HTTP]]
によって[[要求]]を受け取り、
[[応答]]を返す形で実装されます。
この場合[[アプリケーションサーバー]]は
[[HTTPサーバー]]であり、
これ単体でも
[[Webサーバー]]といえます。


[4] 理論上は[[アプリケーションサーバー]]を [[HTTP]]
以外で実装することもできます。
[[パフォーマンス]]向上や、
旧来システムとの互換性など、
相応の理由があるときは採用され得ますが、
反面、
単体でのデバッグが難しくなるなどデメリットも多いので、
通常はそうしません。

[6] 
前面にサーバーを置かない構成のとき、
[[アプリケーションサーバー]]は[[クライアント]]の[[要求]]を直接受け取り、
[[応答]]を直接返すことになります。
この場合は当然、[[アプリケーションサーバー]]が
[[HTTP]] (や [[TLS]])
のすべての要件に従う義務が生じることになります。

[7] 
前面に他のサーバーを置く構成を前提とする[[アプリケーションサーバー]]は、
[[HTTP]] の一部の機能に限って実装したり、
パフォーマンスやセキュリティーに一定の制限を置く形の実装になっていたりすることがありますので、
注意が必要です。

[EG[
[8] 
[[Webアプリケーションフレームワーク]]の [[HTTPサーバー]]ライブラリーは、
前面にサーバーを配した[[アプリケーションサーバー]]としての利用を前提に、
[[HTTPS]] 対応を省いたり、
[[HTTP/1.1]] 対応を省いたり、
[[HTTP/2]] 対応を省いたり、
[[応答]]に必要な [[HTTPヘッダー]]を出力しなかったりすることがあります。

]EG]

[11] 
[[Webアプリケーション]]の運用技法として発達したものですが、
[[HTTP]] を使う[[ネイティブアプリケーション]]にも流用されています。
歴史をたどれば [[Web]] で完全に新規に発達したものでもなく、
従来の[[分散システム]]技術から派生した部分もあります。

* アプリケーションサーバー (プッシュ)

[10] 
[[Web Push]]
における[DFN[[RUBYB[アプリケーションサーバー][application server]]]]は、
[[アプリケーション][アプリケーション (プッシュ)]]の[RUBYB[[[部品]]][component]]であって、
通常[[サーバー]]上で動作し、
[[プッシュメッセージ]]の[[配送]]を要求するものです。
[SRC[>>9]]

[13] 
[[Push API]]
における[DFN[[RUBYB[アプリケーションサーバー][application server]]]]は、
[[Webアプリケーション]]の[[サーバー]]側[[部品]]です。
[SRC[>>12]]


[REFS[
- [9] [CITE@en[RFC 8030 - Generic Event Delivery Using HTTP Push]], [TIME[2020-03-09 00:13:33 +09:00]] <https://tools.ietf.org/html/rfc8030#section-1.1>
- [12] [CITE@en-US[Push API]], [TIME[2020-02-04 16:21:34 +09:00]] <https://w3c.github.io/push-api/#application-server>
]REFS]

* メモ