アプリケーションサーバーとウェブサーバーの違いは何ですか?
28 に答える
ほとんどの場合、これらの用語 Web サーバーとアプリケーション サーバーは同じ意味で使用されます。
以下は、Web サーバーとアプリケーション サーバーの機能の主な違いの一部です。
- Web サーバーは、HTTP コンテンツを提供するように設計されています。App Server は HTTP コンテンツも提供できますが、HTTP だけに限定されません。RMI/RPC などの他のプロトコル サポートを提供できます。
- ほとんどの Web サーバーには、動的な HTTP コンテンツを生成できる Perl、PHP、ASP、JSP などのスクリプト言語をサポートするプラグインがありますが、Web サーバーは主に静的コンテンツを提供するように設計されています。
- ほとんどのアプリケーション サーバーには、Web サーバーが不可欠な部分として組み込まれています。つまり、アプリケーション サーバーは、Web サーバーでできることは何でも実行できます。さらに、App Server には、接続プーリング、オブジェクト プーリング、トランザクション サポート、メッセージング サービスなどのアプリケーション レベルのサービスをサポートするためのコンポーネントと機能があります。
- Web サーバーは静的コンテンツに、アプリ サーバーは動的コンテンツに適しているため、ほとんどの運用環境では、Web サーバーがアプリ サーバーへのリバース プロキシとして機能します。つまり、ページ要求を処理している間、静的コンテンツ (画像/静的 HTML など) は、要求を解釈する Web サーバーによって処理されます。ある種のフィルタリング技術 (主に要求されたリソースの拡張) を使用して、Web サーバーは動的コンテンツ要求を識別し、アプリ サーバーに透過的に転送します
このような構成の例は、Apache Tomcat HTTP Server および Oracle (以前の BEA) WebLogic Server です。Apache Tomcat HTTP サーバーは Web サーバーであり、Oracle WebLogic はアプリケーション サーバーです。
場合によっては、IIS や .NET ランタイムなど、サーバーが緊密に統合されています。IIS は Web サーバーです。.NET ランタイム環境を備えた IIS は、アプリケーション サービスを提供できます。
これは、相違点と類似点、および両方がどのように連携して機能するかを明確に理解するためのいくつかのシナリオを含む詳細な回答です。
アプリケーション サーバーは、 Web サーバーと混同されることがあります。Web サーバーは主にHTTP プロトコルを処理しますが、アプリケーション サーバーは HTTP を含むがこれに限定されないいくつかの異なるプロトコルを処理します。
Web サーバーの主な仕事はサイトのコンテンツを表示することであり、アプリケーション サーバーはロジック、つまりユーザーと表示されたコンテンツとの間の相互作用を担当します。アプリケーション サーバーはWeb サーバーと連動しており、一方が表示され、もう一方が対話します。
サーバーとそのクライアントの間を行き来する情報は、単純な表示マークアップに限定されず、2 つの間の相互作用に限定されます。
ほとんどの場合、サーバーは、J2EE (Java 2 プラットフォーム)、EJB (Enterprise JavaBean)、およびその他の異なるアプリケーション ソフトウェア モデルなどのコンポーネント API を介してこの対話を作成します。
例:
アプリケーション サーバーが Web サーバーと連動するシナリオと、アプリケーション サーバーが存在しないシナリオの違いを理解する最善の方法は、オンライン ストアを使用することです。
シナリオ 1: アプリケーション サーバーのない Web サーバー
Web サーバーのみがあり、アプリケーション サーバーがないオンライン ストアがあります。このサイトでは、製品を選択できるディスプレイが提供されます。クエリを送信すると、サイトはルックアップを実行し、HTML の結果をクライアントに返します。Web サーバーはクエリをデータベース サーバーに直接送信し (しばらくお待ちください。これについては次のナゲットで説明します)、応答を待ちます。受信すると、Web サーバーは応答を HTML ファイルにまとめ、Web ブラウザーに送信します。このサーバーとデータベース サーバー間のやり取りは、クエリが実行されるたびに発生します。
シナリオ 2: アプリケーション サーバーを備えた Web サーバー
実行したいクエリが以前に実行されていて、それ以降データが変更されていない場合、サーバーはデータベース サーバーにリクエストを送信しなくても結果を生成します。これにより、別の重複クエリをデータベース サーバーに送信することなく、2 番目のクライアントが同じ情報にアクセスし、リアルタイムで信頼できる情報を受信できるリアルタイム クエリが可能になります。サーバーは基本的に、データベース サーバーと Web サーバーの間の仲介者として機能します。これにより、最初のシナリオで取得した情報を再利用できるようになります。この情報は特定の「カスタマイズされた」HTML ページに埋め込まれているため、これは再利用可能なプロセスではありません。2 番目のクライアントは、再度情報を要求し、要求された情報を含む別の HTML 埋め込みページを受信する必要がありますが、これは非常に非効率的です。
このようなさまざまな複雑なタスクをサポートするために、このサーバーには冗長性、優れた処理能力、リアルタイムで取得するすべてのデータを処理するための大量の RAM が組み込まれている必要があります。
どちらの用語も非常に一般的であり、一方が他方を含み、場合によってはその逆もあります。
Webサーバー:httpプロトコルを使用してコンテンツをWebに提供します。
アプリケーションサーバー:ビジネスロジックとプロセスをホストおよび公開します。
重要な点は、アプリケーションサーバーがhttpプロトコルに制限されていないのに、Webサーバーがhttpプロトコルを介してすべてを公開していることだと思います。
とはいえ、多くのシナリオでは、Webサーバーを使用してアプリケーションサーバーのフロントエンドを作成していることがわかります。つまり、ユーザーがビジネスルールを操作できるようにする一連のWebページを公開しています。アプリケーション・サーバー。
Rutesh と jmservera が指摘したように、この区別はあいまいです。歴史的には、これらは異なっていましたが、90 年代を通じて、以前は別個だったこれら 2 つのカテゴリが機能をブレンドし、効果的に統合されました。この時点で、「アプリケーション サーバー」製品カテゴリが「Web サーバー」カテゴリの厳密なスーパーセットであると想像するのがおそらく最善です。
いくつかの歴史。Mosaic ブラウザーとハイパーリンク コンテンツの初期の頃、HTTP 経由で Web ページのコンテンツと画像を提供する "Web サーバー" と呼ばれるものが開発されました。コンテンツのほとんどは静的であり、HTTP 1.0 プロトコルはファイルを配布するための手段に過ぎませんでした。「Web サーバー」カテゴリはすぐに CGI 機能を含むように進化し、Web 要求ごとに効果的にプロセスを起動して動的コンテンツを生成しました。HTTP も成熟し、キャッシング、セキュリティ、および管理機能を備えた製品がより洗練されました。技術が成熟するにつれて、Kiva と NetDynamics から企業固有の Java ベースのサーバー側技術を取得し、最終的にすべて JSP に統合しました。Microsoft は、おそらく 1996 年に Windows NT 4.0 に ASP を追加しました。静的 Web サーバーはいくつかの新しいトリックを学習したため、効果的な"
並行するカテゴリでは、アプリ サーバーが進化し、長い間存在していました。多くの企業が、IMS や CICS などのメインフレーム アプリケーション管理および監視環境から哲学的に派生した、Tuxedo、TopEnd、Encina などの Unix 向け製品を提供しました。Microsoft が提供していたのは Microsoft Transaction Server (MTS) で、後に COM+ に発展しました。これらの製品のほとんどは、「ファットな」クライアントをサーバーに相互接続するために、「閉じた」製品固有の通信プロトコルを指定していました。(Encina の場合、通信プロトコルは DCE RPC で、MTS の場合は DCOM などでした。) 1995/96 年に、これらの従来のアプリ サーバー製品は、最初はゲートウェイ経由で、基本的な HTTP 通信機能を組み込み始めました。そして、線がぼやけ始めました。
Web サーバーは、より高い負荷、より多くの並行性、およびより優れた機能の処理に関して、ますます成熟してきました。アプリ サーバーは、ますます多くの HTTP ベースの通信機能を提供しました。
この時点で、「アプリ サーバー」と「Web サーバー」の間の線はあいまいです。しかし、強調の問題として、人々はこの用語を異なる方法で使用し続けています。誰かが「Web サーバー」と言うとき、多くの場合、HTTP 中心の Web UI 指向のアプリを思い浮かべます。誰かが「アプリケーション サーバー」と言うと、「より重い負荷、エンタープライズ機能、トランザクションとキューイング、マルチチャネル通信 (HTTP など)」と考えるかもしれません。しかし、多くの場合、両方のワークロード要件を満たす同じ製品です。
- IBM の「アプリ サーバー」である WebSphere には、独自のバンドルされた Web サーバーがあります。
- 同様に、もう 1 つの従来のアプリ サーバーである WebLogic。
- Microsoft の App Server である Windows (File&Print Server、Media Server などであることに加えて) には、IIS がバンドルされています。
多くの人が以前に言ったように、Web サーバーは HTTP 請願を処理し、アプリケーション サーバーは分散コンポーネントの請願を処理します。したがって、違いを理解する最も簡単な方法は、提供されるプログラミング環境に関して 2 つの製品を比較することです。
Web サーバー -> プログラミング環境
IIS : ASP (.NET)
Tomcat : サーブレット
Jetty : サーブレット
アパッチ:PHP、CGI
アプリケーション サーバー -> プログラミング環境
MTS : COM +
だった: EJB
JBoss : EJB
WebLogic アプリケーション サーバー : EJB
決定的な違いは、アプリケーション サーバーが一部の分散コンポーネントテクノロジをサポートし、リモート呼び出しや分散トランザクション ( JavaのEJBやMicrosoft プラットフォームのCOM+など) などの機能を提供することです。多くの場合、HTTP サーバーは、Microsoft の場合は ASP (.NET)、Java や PHP の場合は JSP、Apache の場合は CGI など、サーブレット ベースの ASP (.NET) など、より単純なプログラミング環境をサポートします。
ロード バランシング、クラスタリング、セッション フェイルオーバー、接続プーリングなど、以前はアプリケーション サーバーの領域にあったその他の機能は、Web サーバーでも直接または一部のサード パーティ製品を通じて利用できるようになっています。
最後に、Spring Framework のような「軽量コンテナー」では、アプリケーション サーバー インフラストラクチャを使用せずに、より単純な方法でアプリケーション サーバーの目的を補完することが多いため、全体像がさらに歪められていることに注意してください。また、アプリケーションの分散の側面が分散コンポーネントからサービス パラダイムおよび SOA アーキテクチャに移行しているため、従来のアプリケーション サーバーに残されたスペースはますます少なくなっています。
つまり、
Web サーバーは、HTTP 要求を介してユーザーに静的な Web ページを提供するサーバーです。
アプリケーション サーバーは、システムのビジネス ロジックをホストするサーバーです。
多くの場合、長時間実行/バッチ プロセスおよび/または人間が使用するためのものではない相互運用サービス (REST/JSON サービス、SOAP、RPC など) の両方をホストします。
Web サーバーは、HTTP/HTTPS 要求のみを処理します。HTTP/HTTPS プロトコルを使用して Web にコンテンツを提供します。
アプリケーション サーバーは、HTTP など、さまざまなプロトコルを介してアプリケーション プログラムにビジネス ロジックを提供します。アプリケーション プログラムは、オブジェクトのメソッドを呼び出すのと同じように、このロジックを使用できます。ほとんどの場合、サーバーは、Java EE (Java Platform、Enterprise Edition) アプリケーション サーバーにある EJB (Enterprise JavaBean) コンポーネント モデルなどのコンポーネント API を介してこのビジネス ロジックを公開します。要点は、Web サーバーは http プロトコルを介してすべてを公開しますが、アプリケーション サーバーはそれに制限されないということです。したがって、アプリケーション サーバーは、通常、次のような Web サーバーよりもはるかに多くのサービスを提供します。
- (独自または非公開) API
- 負荷分散、フェイルオーバー...
- オブジェクトのライフサイクル管理
- 状態管理 (セッション)
- リソース管理 (データベースへの接続プールなど)
ほとんどのアプリケーション サーバーには、Web サーバーが不可欠な部分として組み込まれています。つまり、アプリケーション サーバーは、Web サーバーでできることは何でも実行できます。さらに、App Server には、接続プーリング、オブジェクト プーリング、トランザクション サポート、メッセージング サービスなどのアプリケーション レベルのサービスをサポートするためのコンポーネントと機能があります。
アプリケーション サーバーは、Web サーバー上で実行してプログラム ロジックを実行することができます (常に実行できるわけではありません)。その結果は、Web サーバーによって配信されます。これは、Web サーバー/アプリケーション サーバーのシナリオの一例です。Microsoft の世界での良い例は、Internet Information Server と SharePoint Server の関係です。IIS は Web サーバーです。SharePoint はアプリケーション サーバーです。SharePoint は IIS の "上" に位置し、特定のロジックを実行し、IIS を介して結果を提供します。Java の世界では、たとえば Apache と Tomcat で同様のシナリオがあります。
Web サーバーは静的コンテンツに、アプリ サーバーは動的コンテンツに適しているため、ほとんどの運用環境では、Web サーバーがアプリ サーバーへのリバース プロキシとして機能します。つまり、ページ要求を処理している間、画像/静的 html などの静的コンテンツは、要求を解釈する Web サーバーによって処理されます。ある種のフィルタリング技術 (主に要求されたリソースの拡張) を使用して、Web サーバーは動的コンテンツ要求を識別し、アプリ サーバーに透過的に転送します。
このような構成の例は、Apache HTTP Server および BEA WebLogic Server です。Apache HTTP サーバーは Web サーバーであり、BEA WebLogic はアプリケーション サーバーです。場合によっては、IIS や .NET ランタイムなど、サーバーが緊密に統合されています。IIS は Web サーバーです。.NET ランタイム環境 IIS を搭載すると、アプリケーション サービスを提供できます。
Web Server Programming Environment
Apache PHP, CGI
IIS (Internet Information Server) ASP (.NET)
Tomcat Servlet
Jetty Servlet
Application Server Programming Environment
WAS (IBM's WebSphere Application Server) EJB
WebLogic Application Server (Oracle's) EJB
JBoss AS EJB
MTS COM+
The border between these two are getting ever so thinner.
Application servers expose business logic to clients. That means application servers comprise of a set of methods (not exclusively though, can even be a networked computer allowing many to run software on it) to perform business logic. So it will simply output the desired results, not HTML content. (similar to a method call). So it is not strictly HTTP based.
But web servers pass HTML content to web browsers (Strictly HTTP based). Web servers were capable of handling only the static web resources, but the emergence of server side scripting allowed web servers to handle dynamic contents as well. Where a web server takes in the request and directs it to relevant scripts (PHP, JSP, CGI scripts, etc.) to CREATE HTML content to be sent to the client. Once the content is received, web server will send the HTML page to the client.
However, nowadays both these servers are used together. Where web server takes the request and then calls a script to create the HTML content. Then, the script will again call an application server LOGIC (e.g. Retrieve transaction details) to fill the HTML content.
So both the servers are used effectively.
Therefore .... We can safely say that nowadays, in most of the cases, web servers are used as a subset of application servers. BUT theatrically it is NOT the case.
I have read many articles about this topic and found this article quite handy.
Java 用語では、もう 1 つWeb コンテナー(より厳密にはサーブレット コンテナー) があります。たとえば、Web サーバーとアプリケーション サーバーの間にあります。
Java 用語での Web コンテナーは、基本的に Java EE の JSP/サーブレット部分のみを実装し、EJB サポートなどの Java EE のいくつかのコア部分を欠いているアプリケーション サーバーです。例として、Apache Tomcat があります。
通常、アプリケーション サーバーは、リソースを集中的に使用する長時間実行プロセスを容易にするように設計および展開されます。
Web サーバーは、通常、リソースを集中的に使用しない短いバーストに使用されます。これは主に、Web ベースのトラフィックの提供を容易にするためのものです。
Web サーバーは、HTTP プロトコルを実行して Web ページを提供します。アプリケーション サーバーは、Web サーバー上で実行してプログラム ロジックを実行することができます (常にではありません)。その結果は、Web サーバーによって配信されます。これは、Web サーバー/アプリケーション サーバーのシナリオの一例です。
Microsoft の世界での良い例は、Internet Information Server と SharePoint Server の関係です。IIS は Web サーバーです。SharePoint はアプリケーション サーバーです。SharePoint は IIS の "上" に位置し、特定のロジックを実行し、IIS を介して結果を提供します。
Java の世界では、たとえば Apache と Tomcat で同様のシナリオがあります。
まず、Web サーバーは HTTP プロトコルを介して Web コンテンツ (HTML および静的コンテンツ) を提供します。一方、アプリケーション サーバーは、n 層アーキテクチャの HTTP を含むさまざまなプロトコルを介して、ビジネス ロジックとプロセスを構築し、クライアント アプリケーションに公開できるコンテナです。
したがって、アプリケーション サーバーは、通常、次のような Web サーバーよりもはるかに多くのサービスを提供します。
- (独自または非公開) API
- オブジェクトのライフサイクル管理、
- 状態管理(セッション)、
- リソース管理 (データベースへの接続プールなど)、
- 負荷分散、フェイルオーバー...
私の知る限り、ATG Dynamoは 90 年代後半の最初のアプリケーション サーバーの 1 つでした (上記の定義によると)。2000 年初頭には、ColdFusion (CFML AS)、BroadVision (サーバーサイド JavaScript AS) などのいくつかのプロプライエタリ アプリケーション サーバーが支配していました。
アプリケーションサーバーは、提供するサービスのクライアントからの要求を「リッスン」(任意のチャネルで、任意のプロトコルを使用) し、それらの要求に基づいて何かを実行するマシン (実際には、あるマシン上で実行される実行可能なプロセス) です。(クライアントへの応答を伴う場合と伴わない場合があります)
Web サーバーは、「インターネット」プロトコル (http、https、ftp など) の 1 つを使用して特に TCP/IP チャネルを「リッスン」し、着信要求に基づいて実行するマシン上で実行されるプロセスです。 .. 一般に、(元の定義によると)、サーバー上の静的な html ファイルからフェッチされるか、受信したクライアント要求のパラメーターに基づいて動的に構築された html Web ページをフェッチ/生成し、クライアントに返します。
最大の違いは、Web サーバーが HTTP 要求を処理するのに対し、アプリケーション サーバーは任意の数のプロトコルでビジネス ロジックを実行することです。
基本的な理解:
クライアント サーバー アーキテクチャの場合
サーバー:> リクエストを処理します。
クライアント :> サービスを消費するもの。
Web サーバーとアプリケーション サーバーはどちらも、クライアントに対してサーバーとして機能するソフトウェア アプリケーションです。
それらは、使用場所に基づいて名前が付けられました。
Web server :> serve web content
:> Like Html components
:> Like Javascript components
:> Other web components like images,resource files
:> Supports mainly web protocols like http,https.
:> Supports web Request & Response formats.
使用法 -
we require low processing rates, regular processing practices involves.
例: Web ベースのコンテンツのみを提供する既製のすべてのフラット サーバーが一般に利用可能です。
Application server :> Serve application content/component data(Business data).
:> These are special kind which are custom written
designed/engineered for specific
purpose.some times fully unique in
their way and stands out of the crowd.
:> As these serves different types of data/response contents
:> So we can utilize these services for mobile client,web
clients,intranet clients.
:> Usually application servers are services offered on different
protocols.
:> Supports different Request& Response formats.
使用法 -
we require multi point processing, specialized processing techniques involves like for AI.
例: Google マップ サーバー、Google 検索サーバー、Google ドキュメント サーバー、Microsoft 365 サーバー、AI 用 Microsoft コンピュータ ビジョン サーバー。
それらを 4 層/n 層アーキテクチャの層/階層として想定できます。
So they can provide
load balancing,
multiple security levels,
multiple active points,
even they can provide different request processing environments.
標準アーキテクチャの類推については、次のリンクをたどってください。
https://docs.microsoft.com/en-us/previous-versions/msp-np/ee658120(v%3dpandp.10)
実際、Apache は Web サーバーで、Tomcat はアプリケーション サーバーです。HTTP リクエストが Web サーバーに到達したとき。次に、静的コンテンツが Web サーバーによってブラウザーに送り返されます。そこにあり、ロジックが行われている場合、そのリクエストはアプリケーションサーバーに送信されます。ロジックを処理した後、応答を Web サーバーに送信し、クライアントに送信します。
上記のすべては、非常に単純なものを過度に複雑にしています。アプリケーション サーバーには Web サーバーが含まれています。アプリケーション サーバーには、標準の Web サーバーよりもいくつかの追加/拡張機能があります。例として TomEE を見ると、次のようになります。
CDI - Apache OpenWebBeans
EJB - Apache OpenEJB
JPA - Apache OpenJPA
JSF - Apache MyFaces
JSP - Apache Tomcat
JSTL - Apache Tomcat
JTA - Apache Geronimo Transaction
Servlet - Apache Tomcat
Javamail - Apache Geronimo JavaMail
Bean Validation - Apache BVal
Tomcat (Web コンテナー/サーバー) は、アプリ サーバーのツールの 1 つに過ぎないことがわかります。必要に応じて、Web サーバーで JPA やその他の技術を取得することもできますが、アプリケーション サーバーは、便宜上、これらすべてをパッケージ化するだけです。アプリサーバーとして完全に分類されるには、基本的に、何らかの標準によって定められたツールのリストに準拠する必要があります。
必ずしも明確な境界線があるとは限りません。現在、多くのプログラムは、http リクエストの処理 (Web サーバー) とビジネス ロジックの処理 (アプリ サーバー) の両方の要素を組み合わせています。
- Web サーバー: すべての URL に対して、ファイルを返します。それだけです。ファイルは静的コンテンツです。つまり、リクエストを行う前に、サーバーのどこかに保存されます。最も一般的な Web サーバーはapache httpとnginxです。
- アプリケーション サーバー: すべての URL に対して、何らかの言語で記述されたコードを実行し、応答を生成して返します。応答は事前に存在しません。特定の要求に対して生成されます。つまり、動的コンテンツです。アプリケーション サーバーは言語ごとに異なります。一般的な例としては、Java のtomcat/jetty 、python のuwsgi/gunicornがあります。
アクセスするほぼすべてのページで、両方が使用されています。静的コンテンツ (画像、ビデオなど) は Web サーバーによって提供され、残り (自分と他のユーザーの間で異なる部分) はアプリケーション サーバーによって生成されます。
2 つの間に重複があるかもしれませんが (一部の Web サーバーはアプリケーション サーバーとして使用される場合もあります)、最大の違いは処理モデルとセッション管理にあります。
Web サーバー処理モデルでは、要求の処理に重点が置かれます。「セッション」の概念はほとんど仮想です。つまり、「セッション」は、クライアントとサーバーの間で状態の表現を転送する (したがって REST) および/またはそれを外部の永続ストレージ (SQL Server、Memcached など) にシリアル化することによってシミュレートされます。
アプリケーション サーバーでは、通常、セッションはより明示的であり、多くの場合、「セッション」の全期間にわたってアプリケーション サーバーのメモリに存在するオブジェクトの形式をとります。
厳密な定義では、Web サーバーはアプリケーション サーバーの一般的なサブセットです。
Web サーバーは、主に Web ブラウザーからのハイパーテキスト転送プロトコル (HTTP) 要求に応答して、静的な Web コンテンツ (HTML ページ、ファイル、画像、ビデオなど) を配信します。
通常、アプリケーション サーバーは Web コンテンツも配信できますが、その主な役割は、エンド ユーザー クライアントとサーバー側アプリケーション コード (ビジネス ロジックと呼ばれることが多いコード) との間の対話を可能にして、トランザクションなどの動的コンテンツを生成および配信することです。結果、意思決定支援、またはリアルタイム分析。アプリケーション サーバーのクライアントは、アプリケーション自体のエンド ユーザー UI、Web ブラウザー、またはモバイル アプリである可能性があり、クライアントとサーバーの対話は、任意の数の通信プロトコルを介して発生する可能性があります。
ただし、実際には、Web サーバーとアプリケーション サーバーの間の線引きはあいまいになりました。特に、Web ブラウザがアプリケーション クライアントの選択肢として台頭し、Web アプリケーションと Web アプリケーションのパフォーマンスに対するユーザーの期待が高まるにつれてです。
ほとんどの Web サーバーは、スクリプト言語 (ASP、JSP、PHP、Perl など) のプラグインをサポートしており、Web サーバーがサーバー側のロジックに基づいて動的コンテンツを生成できるようにします。また、Web サーバー機能を組み込むだけでなく、HTTP をプライマリ プロトコルとして使用し、Web サーバーとのインターフェイス用に他のプロトコル (CGI および CGI バリアントなど) をサポートするアプリケーション サーバーの数が増えています。また、Web アプリケーションは、リバース プロキシ、クラスタリング、冗長性、負荷分散などのサービスを利用できます。これらのサービスにより、パフォーマンスと信頼性が向上し、開発者はインフラストラクチャよりもコーディングに集中できるようになります。
さらに紛らわしいことに、多くの Web サーバーと一部のアプリケーション サーバーは Web アプリケーション サーバー と呼ばれているか、またはそれ自体を参照しています。
要するに、今日最も普及している Web サーバーとアプリケーション サーバーは、両方のハイブリッドです。現在使用されているますますリッチなアプリケーションのほとんどは、静的な Web コンテンツと動的なアプリケーション コンテンツの組み合わせを特徴としており、Web サーバーとアプリケーション サーバーのテクノロジの組み合わせによって配信されます。
それは特定のアーキテクチャに依存します。一部のアプリケーション サーバーは Web プロトコル (XML/RPC/SOAP over HTTP) をネイティブに使用する場合があるため、技術的な違いはほとんどありません。通常、Web サーバーはユーザー向けであり、HTTP/HTTPS を介してさまざまなコンテンツを提供しますが、アプリケーション サーバーはユーザー向けではなく、非標準またはルーティング不可能なプロトコルを使用する場合があります。もちろん、RIA/AJAX を使用すると、特定のリモート アクセス サービスをポンピングするクライアントに非 HTML コンテンツ (JSON/XML) のみを提供して、違いがさらに曖昧になる可能性があります。