web-dev-qa-db-ja.com

アプリケーションサーバーとWebサーバーの違いは何ですか？

アプリケーションサーバーとWebサーバーの違いは何ですか？

webserverterminologyapplication-server
624
TwiggedToday

ほとんどの場合、Webサーバーとアプリケーションサーバーという用語は同じ意味で使用されています。

Webサーバーとアプリケーションサーバーの機能の主な違いは次のとおりです。

  • WebサーバーはHTTPコンテンツを提供するように設計されています。 App ServerはHTTPコンテンツも提供できますが、HTTPだけに限定されません。 RMI/RPCなどの他のプロトコルサポートを提供できます。
  • Webサーバーはほとんど静的コンテンツを提供するように設計されていますが、ほとんどのWebサーバーはPerl、PHP、ASP、JSPなどのスクリプト言語をサポートするプラグインを持っていて、これらのサーバーを通して動的HTTPコンテンツを生成できます。
  • ほとんどのアプリケーションサーバーは、Webサーバーをその一部として備えています。つまり、App Serverは、Webサーバーができることなら何でもできるということです。さらに、App Serverには、コネクションプーリング、オブジェクトプーリング、トランザクションサポート、メッセージングサービスなどのアプリケーションレベルのサービスをサポートするためのコンポーネントと機能があります。
  • Webサーバーは静的コンテンツや動的コンテンツ用のアプリケーションサーバーに適しているため、ほとんどの実稼働環境ではWebサーバーがアプリケーションサーバーへのリバースプロキシとして機能しています。つまり、ページリクエストを処理している間は、リクエストを解釈するWebサーバーによって静的コンテンツ（images/Static HTMLなど）が配信されます。ある種のフィルタリング技術（主に要求されたリソースの拡張）を使用してWebサーバーは動的コンテンツ要求を識別し、透過的にアプリケーションサーバーに転送します

そのような構成の例は、Apache Tomcat HTTP ServerおよびOracle（以前のBEA）WebLogic Serverです。 Apache Tomcat HTTPサーバーはWebサーバーであり、Oracle WebLogicはアプリケーションサーバーです。

場合によっては、IISや.NET Runtimeなど、サーバーが緊密に統合されています。 IISはWebサーバーです。 .NETランタイム環境を備えている場合、IISはアプリケーションサービスを提供できます。

538
Rutesh Makhijani

これは、違い、類似性、および両方がどのように連携して機能するかを明確に理解するためのいくつかのシナリオに関する詳細な回答です。

Application Serverは、web serverと混同されることもある用語です。 Webサーバーは主にHTTPプロトコルを処理しますが、アプリケーションサーバーはHTTPに限定されないなど、いくつかの異なるプロトコルを処理します。

Webサーバーの主な仕事はサイトのコンテンツを表示するであり、アプリケーションサーバーはロジックを担当するであり、ユーザーと表示されたコンテンツの間のやり取りです。アプリケーションサーバーは、Webサーバーと連携して動作しますであり、一方が表示され、もう一方が対話します。

サーバーとそのクライアントの間を行き来する情報は、単純な表示マークアップに限定されず、2つの間の相互作用に限定されます。

ほとんどの場合、サーバーはこのコンポーネントAPIを介した対話を作成します。たとえば、J2EE （Java 2 Platform）、EJB （Enterprise JavaBean）およびその他の異なるアプリケーションソフトウェアモデル。

enter image description here

例：

アプリケーションサーバーがWebサーバーと連携するシナリオと、アプリケーションサーバーがないシナリオとの違いを理解する最良の方法は、オンラインストアを使用することです

シナリオ1：アプリケーションサーバーのないWebサーバー

webサーバーのみがあり、アプリケーションサーバーがないオンラインストアがあります。このサイトでは、製品を選択できるディスプレイが提供されます。クエリを送信すると、サイトはルックアップを実行し、HTML結果をクライアントに返します。 Webサーバーはクエリをデータベースサーバーに直接送信し（辛抱強く、次のナゲットでこれについて説明します）、応答を待ちます。受信すると、Webサーバーは応答をHTMLファイルに定式化し、Webブラウザーに送信します。サーバーとデータベースサーバー間のこの往復通信は、クエリが実行されるたびに発生します。

シナリオ2：アプリケーションサーバーを備えたWebサーバー

実行するクエリが既に実行されており、それ以降データが変更されていない場合、サーバーは要求をデータベースサーバーに送信せずに結果を生成します。これにより、2番目のクライアントがデータベースサーバーに別の重複クエリを送信することなく、同じ情報にアクセスし、リアルタイムで信頼できる情報を受信できるリアルタイムクエリが可能になります。サーバーは基本的に、データベースサーバーとWebサーバーの中間として機能します。これにより、最初のシナリオで取得した情報を再利用可能にすることができます。この情報は特定の「カスタマイズされた」HTMLページに埋め込まれているため、再利用可能なプロセスではありません。 2番目のクライアントは、情報を再度要求し、情報が要求された別のHTML埋め込みページを受信する必要があります-非常に非効率的です。このタイプのサーバーは、セキュリティ、トランザクション処理、メッセージング、リソースプーリングなどの独自のリソースを管理できるため、非常に柔軟であることは言うまでもありません。

このようなさまざまな複雑なタスクをサポートするには、このサーバーに組み込みの冗長性、優れた処理能力、大量のRAMが搭載され、リアルタイムで取得するすべてのデータを処理する必要があります。

お役に立てれば。

136
Durai Amuthan.H

両方の用語は非常に一般的で、一方が他方を含み、場合によってはその逆もあります。

  • Webサーバ ：httpプロトコルを使用してコンテンツをWebに配信します。

  • アプリケーションサーバー ：ビジネスロジックとプロセスをホストして公開します。

主な点は、Webサーバーはhttpプロトコルを介してすべてを公開するのに対し、アプリケーションサーバーはそれに限定されないことです。

とはいえ、多くのシナリオでは、Webサーバーがアプリケーションサーバーのフロントエンドの作成に使用されていることがわかります。アプリケーション・サーバー。

124
jmservera

Ruteshとjmserveraが指摘したように、この区別はあいまいなものです。歴史的に、それらは異なっていました、しかし90年代を通してこれら二つの以前は異なったカテゴリーは特徴を混ぜ合わせて効果的にマージしました。現時点では、 "App Server"製品カテゴリは "Webサーバー"カテゴリの厳密なスーパーセットであると考えるのがおそらく最善です。

いくつかの歴史Mosaicブラウザとハイパーリンクコンテンツの初期の頃には、HTTPを介してWebページのコンテンツと画像を提供する「Webサーバー」と呼ばれるものが進化しました。コンテンツの大部分は静的であり、HTTP 1.0プロトコルはファイルを配布するための単なる方法です。すぐに「Webサーバー」カテゴリは、動的コンテンツを生成するために各Web要求で効果的にプロセスを起動するCGI機能を含むように進化しました。 HTTPも成熟し、キャッシング、セキュリティ、および管理機能を備えた製品はより洗練されたものになりました。技術が成熟するにつれて、私たちはKivaとNetDynamicsから会社固有のJavaベースのサーバーサイド技術を得ました。そして、それらは最終的にすべてJSPに統合されました。 Microsoftは、1996年にASPをWindows NT 4.0に追加しました。静的Webサーバーはいくつかの新しいトリックを習得していたので、多くのシナリオで効果的な「アプリケーションサーバー」でした。

並列カテゴリでは、アプリサーバーは長い間進化していました。 Tuxedo、TopEnd、EncinaなどのUNIX向け製品は、メインフレームのアプリケーション管理やIMS、CIC​​Sなどの監視環境から哲学的に派生した製品で提供されていました。 Microsoftが提供する製品はMicrosoft Transaction Server（MTS）で、後でCOM +に進化しました。これらの製品のほとんどは、「太った」クライアントをサーバーに相互接続するための「クローズド」製品固有の通信プロトコルを指定していました。 （Encinaではcommsプロトコルは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をバンドルしています。
57
Cheeso

Webサーバー

python -m 'SimpleHTTPServer'を実行して http：// localhost：8080 にアクセスしてください。あなたが目にしているのは、その働きの中のWebサーバーです。サーバーは単にあなたのコンピューターに保存されているHTTP経由でファイルを提供します。重要な点は、これらすべてがHTTPプロトコルの上で行われることです。例えば全く同じこと（保存されたファイルを提供する）をするが、異なるプロトコルの上にあるFTPサーバーも存在します。

アプリケーションサーバー

以下のような小さなアプリケーションがあるとします（ Flask からの抜粋）。

@app.route('/')
def homepage():
    return '<html>My homepage</html>'

@app.route('/about')
def about():
    return '<html>My name is John</html>'

小さなサンプルプログラムは、URL /を関数homepage()に、/aboutを関数about()にマッピングします。

このコードを実行するには、アプリケーションサーバー（Gunicornなど）、つまりクライアントからの要求を待機してコードを使用して何かを動的に返すことができるプログラムまたはモジュールが必要です。例では、非常に悪いHTMLを返すだけです。

他のすべての人が話しているビジネスロジックは何ですか？ URLはコードベース内のどこかにマッピングされているので、プログラムがどのように機能するかについての論理を仮定的に示しています。

再キャッピング

Webサーバー - どこかに保存されているファイルを処理します（最も一般的には.css、.html、.js）。一般的なWebサーバーは、Apache、Nginx、さらにはPythonのSimpleHTTPServerです。

アプリケーションサーバー - その場で生成されたファイルを処理します。基本的にほとんどのWebサーバーはある種のプラグインを持っているか、あるいはそれをするための組込み機能さえ持っています。 Gunicorn（Python）、Unicorn（Ruby）、uWSGI（Python）などの厳密なアプリケーションサーバーもあります。

実際には、アプリケーションサーバーのコードを使ってWebサーバーを構築することができます。これは開発中に、コンピュータ上でさまざまなサーバーを実行したくない場合があります。

46
Pithikos

これまで多くの人が言ってきたように、WebサーバーはHTTP請願を処理しますが、アプリケーションサーバーは分散コンポーネントの請願を処理します。したがって、違いを理解するための最も簡単な方法は、2つの製品を、それらが提供するプログラミング環境に関して比較することです。

Webサーバ - >プログラミング環境

IIS：ASP（.NET）

Tomcat：サーブレット

桟橋：サーブレット

アパッチ：Php、CGI

アプリケーションサーバー - >プログラミング環境

MTS：COM +

WAS：EJB

JBoss：EJB

WebLogicアプリケーションサーバー：EJB

重要な違いは、アプリケーションサーバーが一部の distributed component technologyをサポートし、リモート呼び出しや分散トランザクション（Javaの場合は _ ejb _ 、Microsoftプラットフォームの場合は COM + など）のような機能を提供することです。 HTTPサーバは、Microsoftやサーブレットベースの場合はASP（.NET）、Javaの場合は[JSP]やPHPやCGIなどの他の多くのスクリプトをサポートします。 Apacheの場合.

ロードバランシング、クラスタリング、セッションフェイルオーバー、接続プーリングなど、アプリケーションサーバーの分野で使用されていたその他の機能は、直接または一部のサードパーティ製品を通じてWebサーバーで使用できるようになりました。

最後に、Spring Frameworkのような "軽量コンテナー"を使用すると、アプリケーションサーバーのインフラストラクチャを使用せずに、より単純な方法でアプリケーションサーバーの目的を補完することができ、画像がさらに歪められます。そして、アプリケーションにおける分散の側面は分散型コンポーネントからサービスパラダイムとSOAアーキテクチャに向かって動いているので、伝統的なアプリケーションサーバーのために残されるスペースがますます少なくなります。

35
Dan

WebサーバーはHTTP/HTTPS要求を排他的に処理します。 HTTP/HTTPSプロトコルを使用してコンテンツをWebに配信します。

アプリケーションサーバーは、HTTPなどのプロトコルを使用して、アプリケーションプログラムにビジネスロジックを提供します。アプリケーションプログラムは、オブジェクトのメソッドを呼び出すのと同じようにこのロジックを使用できます。ほとんどの場合、サーバーはJava EE（Java Platform、Enterprise Edition）アプリケーションサーバーにあるEJB（Enterprise JavaBean）コンポーネントモデルなどのコンポーネントAPIを介してこのビジネスロジックを公開します。重要な点は、Webサーバーはhttpプロトコルを介してすべてを公開するのに対し、アプリケーションサーバーはそれに制限されていないということです。したがって、アプリケーションサーバーは、通常次のようなWebサーバーよりもはるかに多くのサービスを提供します。

  • （独自かどうかにかかわらず）API
  • 負荷分散、フェイルオーバー...
  • オブジェクトライフサイクル管理
  • 状態管理（セッション）
  • リソース管理（例：データベースへの接続プール）

ほとんどのアプリケーションサーバーは、Webサーバーをその一部として備えています。つまり、App Serverは、Webサーバーができることなら何でもできるということです。さらに、App Serverには、コネクションプーリング、オブジェクトプーリング、トランザクションサポート、メッセージングサービスなどのアプリケーションレベルのサービスをサポートするためのコンポーネントと機能があります。

アプリケーションサーバーは（常にではありませんが）プログラムロジックを実行するためにWebサーバー上で実行でき、その結果はWebサーバーによって配信されます。これは、Webサーバー/アプリケーションサーバーのシナリオの一例です。マイクロソフトの世界における良い例は、インターネットインフォメーションサービス/ SharePoint Serverの関係です。 IISはWebサーバーです。 SharePointはアプリケーションサーバーです。 SharePointはIISの最上位に位置し、特定のロジックを実行し、IISを介して結果を提供します。 Javaの世界では、たとえば、ApacheとTomcatの場合と似たようなシナリオがあります。

Webサーバーは静的コンテンツや動的コンテンツ用のアプリケーションサーバーに適しているため、ほとんどの実稼働環境ではWebサーバーがアプリケーションサーバーへのリバースプロキシとして機能しています。つまり、ページ要求を処理している間、images/Static htmlなどの静的コンテンツは、要求を解釈するWebサーバーによって処理されます。ある種のフィルタリング技術（主に要求されたリソースの拡張）を使用して、Webサーバーは動的コンテンツ要求を識別し、透過的にアプリケーションサーバーに転送します。

そのような構成の例は、Apache HTTP ServerとBEA WebLogic Serverです。 Apache HTTPサーバーはWebサーバー、BEA WebLogicはアプリケーションサーバーです。場合によっては、IISや.NET Runtimeなど、サーバーが緊密に統合されています。 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+
17
Parv

Webサーバーとアプリケーションサーバーの主な違いは、Webサーバーが静的なページを提供することを意図していることです。 HTMLとCSS。ApplicationServerは、サーバー側のコードを実行して動的コンテンツを生成します。 JSP、サーブレットまたはEJB。

どちらを使用すべきですか？
。静的Webページを提供している場合、Apache HTTPDのようなweb serverが必要です。動的コンテンツを生成するためのJSPとサーブレットだけを備えたJavaアプリケーションがある場合、TomcatやJettyのようなweb containersが必要です。一方、EJB、分散トランザクション、メッセージング、およびその他の豪華な機能を使用するJava EEアプリケーションがある場合、本格的なapplication server JBoss、WebSphere、またはOracleのWebLogicなど。

WebコンテナはWebサーバーの一部であり、WebサーバーはApplication Serverの一部です。

Application Server

Web ServerはWebコンテナで構成され、Application ServerはWebコンテナとEJBコンテナで構成されます。

17
Arun Raaj

手短に言うと、 Webサーバー は、httpを介してユーザーにWebページを提供するサーバーです。 アプリケーションサーバー は、システムのビジネスロジックをホストするサーバーです。多くの場合、長時間実行/バッチプロセス、および/または人が消費することを意図していない相互運用サービス（REST/JSONサービス、SOAP、RPCなど）の両方をホストします。

15
C. Ross

Javaの用語ではもう1つあります。 Webコンテナ （厳密にはサーブレットコンテナ）。たとえば、Webサーバーとアプリケーションサーバーの間です。 Java用語のWebコンテナは、基本的に only はJava EEのJSP /サーブレット部分を実装し、EJBサポートなどのJava EEのいくつかのコア部分を欠いているアプリケーションサーバーです。例はApache Tomcatです。

8
BalusC

通常、アプリケーションサーバーは、実行時間が長くなるプロセスを容易にするように設計され、展開されます。これにより、リソースの使用量も増えます。

Webサーバーは、一般的にリソースを消費しない短いバーストに使用されます。これは主にWebベースのトラフィックの処理を容易にするためのものです。

8
Joseph

WebサーバーはWebページを提供するためにHTTPプロトコルを実行します。アプリケーションサーバーは（常にではありませんが）プログラムロジックを実行するためにWebサーバー上で実行でき、その結果はWebサーバーによって配信されます。これは、Webサーバー/アプリケーションサーバーのシナリオの一例です。

マイクロソフトの世界における良い例は、インターネットインフォメーションサービス/ SharePoint Serverの関係です。 IISはWebサーバーです。 SharePointはアプリケーションサーバーです。 SharePointはIISの最上位に位置し、特定のロジックを実行し、IISを介して結果を提供します。

Javaの世界では、たとえば、ApacheとTomcatの場合と似たようなシナリオがあります。

8
Robert S.

一方、WebサーバーはHTTPプロトコルを介してWebコンテンツ（HTMLおよび静的コンテンツ）を提供します。一方、アプリケーションサーバーは、n層アーキテクチャのHTTPを含むさまざまなプロトコルを通じて、ビジネスロジックとプロセスを構築してクライアントアプリケーションに公開するためのコンテナです。

したがって、アプリケーションサーバーは、通常次のようなWebサーバーよりもはるかに多くのサービスを提供します。

  • （独自かどうかにかかわらず）API
  • オブジェクトライフサイクル管理
  • 状態管理（セッション）
  • リソース管理（例：データベースへの接続プール）
  • 負荷分散、フェイルオーバー...

私の知る限りでは、 ATG Dynamo は90年代後半の最初のアプリケーションサーバーの1つでした（上記の定義による）。 2000年の初め頃は、 ColdFusion （CFML AS）、 BroadVision （サーバーサイドJavaScript AS）など、一部のプロプライエタリなアプリケーションサーバーが登場しました。

7
Pascal Thivent

これら2つの間の境界はこれまでになく薄くなっています。

アプリケーションサーバーは、ビジネスロジックをクライアントに公開します。そのため、そのようなアプリケーションサーバーは、ビジネスロジックを実行するための一連のメソッドで構成されています（必ずしもそうとは限りません）。そのため、HTMLコンテンツではなく、単に目的の結果が出力されます。 （メソッド呼び出しに似ています）。そのため、厳密にはHTTPベースではありません。

しかし、WebサーバーはHTMLコンテンツをWebブラウザに渡します（厳密にはHTTPベース）。 Webサーバーは静的Webリソースしか処理できませんでしたが、サーバーサイドスクリプティングの出現により、Webサーバーは動的コンテンツも処理できました。 Webサーバーが要求を受け取り、それをスクリプト（PHP、JSP、CGIスクリプトなど）に送信して、クライアントに送信するHTMLコンテンツを作成する場所。それからウェブサーバはそれらをクライアントに送り返す方法を知っています。 Webサーバが本当に知っているのはそのためです。

とは言っても、今日では開発者はこれらの両方を一緒に使用しています。 Webサーバーが要求を受けてからHTMLを作成するためのスクリプトを呼び出す場合、BUTスクリプトは再びHTMLコンテンツを埋めるためにアプリケーションサーバーLOGIC（例：トランザクション詳細の取得）を呼び出します。

そのため、この場合は両方のサーバーが効果的に使用されました。

したがって....今日では、ほとんどの場合、Webサーバーはアプリケーションサーバーのサブセットとして使用されています。しかし、演劇的にはそうではありません。

私はこのトピックに関する多くの記事を読んでいて、 this の記事はとても便利です。

7
Dilruk

アプリケーションサーバーは、クライアントが提供するサービスを問わず、クライアントからの要求を（任意のチャネルで、任意のプロトコルを使用して）「リッスン」し、それらの要求に基づいて何かを実行するマシン（実際には何らかのマシンで実行される実行可能プロセス）です。 （クライアントに責任を負うかどうかにかかわらず）

Webサーバーは、「インターネット」プロトコル（http、https、ftpなど）の1つを使用してTCP/IPチャネルで特に「待機」し、それらの着信要求に基づいて行うことをすべて実行するマシン上で実行されているプロセスです。 ..（元々定義されているように）通常、サーバー上の静的HTMLファイルから取得するか、着信クライアント要求内のパラメーターに基づいて動的に構築されたHTML Webページを取得/生成してクライアントに返しました。

4
Charles Bretana

上記のすべては、非常に単純なものを過度に複雑にしているだけです。アプリケーションサーバーにはWebサーバーが含まれていますが、アプリケーションサーバーには標準のWebサーバーよりも2、3の追加/拡張があります。例として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コンテナ/サーバー）は、アプリサーバーの別のツールにすぎません。必要に応じて、JPAやその他の技術をWebサーバーに取り込むこともできますが、アプリケーションサーバーはこれらすべてをパッケージ化したものです。アプリケーションサーバーとして完全に分類されるためには、基本的に何らかの標準によって定められたツールのリストに従う必要があります。

4
Gerrit Brink

実際にはApacheはWebサーバーであり、Tomcatはアプリケーションサーバーです。 HTTPリクエストがWebサーバーに届いたとき。その後、静的コンテンツはWebサーバーによってブラウザに返送されます。そこにありそして論理はするべきであり、そしてその要求はアプリケーションサーバーに送られる。ロジックを処理した後、Webサーバーに送信してクライアントに送信します。

3
Amila

最大の違いは、WebサーバーがHTTP要求を処理するのに対し、アプリケーションサーバーは任意の数のプロトコルでビジネスロジックを実行することです。

3
MarkPowell

アプリケーションサーバーとWebサーバーの両方を使用してWebアプリケーションをホストします。 Web ServerはWebコンテナを処理しますが、Application ServerはWebコンテナおよびEJB（Enterprise JavaBean）コンテナまたはMicrosoft dot NetのCOM +コンテナを処理します。

Web Serverは、HTML、画像などのHTTP静的コンテンツを提供するように設計されています。動的コンテンツには、Perl、PHP、ASP、JSPなどのスクリプト言語をサポートするプラグインがあり、HTTPプロトコルに限定されます。以下のサーバーは動的HTTPコンテンツを生成できます。

Webサーバーのプログラミング環境：

IIS：ASP（.NET）

Apache Tomcat：サーブレット

桟橋：サーブレット

アパッチ：Php、CGI

Application Serverは、接続プーリング、オブジェクトプーリング、トランザクションサポート、メッセージングサービスなどのアプリケーションレベルのサービスをサポートするためのコンポーネントと機能を備えているだけでなく、Webサーバーが対応し、あらゆるプロトコルを使用して待機します。

アプリケーションサーバのプログラミング環境：

MTS：COM +

WAS：EJB

JBoss：EJB

WebLogicアプリケーションサーバー：EJB

2
Bablu Ahmed

明確な境界線は必ずしもありません。今日では、多くのプログラムが両方の要素を組み合わせています。http要求を処理する（Webサーバー）とビジネスロジックを処理する（アプリケーションサーバー）

2
Peter Recore

から https://en.wikipedia.org/wiki/Web_server

Webサーバーは、World Wide Webで情報を配信するために使用される基本的なネットワークプロトコルであるHTTPを介して要求を処理するコンピューターシステムです。この用語は、システム全体、または具体的にはHTTP要求を受け入れて監視するソフトウェアを指すことができます。

から https://en.wikipedia.org/wiki/Application_server#Application_Server_definition

アプリケーションサーバーは、Webサーバーの背後（ApacheまたはMicrosoftインターネットインフォメーションサービス（IIS）など）および（ほとんどの場合）SQLデータベースの前で実行されます（たとえば、PostgreSQL、MySQL、またはOracle）。

Webアプリケーションは、アプリケーションサーバー上で実行されるコンピューターコードであり、アプリケーションサーバーがサポートする言語で記述され、ランタイムライブラリとコンポーネントを呼び出しますアプリケーションサーバーが提供しています。

2
Manohar Reddy Poreddy

両者の間にはオーバーラップがあるかもしれませんが（いくつかのWebサーバーはアプリケーションサーバーとしても使用されるかもしれません）、最大の違いは、処理モデルとセッション管理にあります。

Webサーバー処理モデルでは、焦点は要求の処理にあります。 「セッション」の概念はほとんど仮想的です。つまり、「セッション」は、クライアントとサーバー間の状態の表現（つまりREST）を転送したり、外部の永続的な記憶域（SQL Server、Memcachedなど）にシリアル化したりすることによってシミュレートされます。

アプリケーションサーバでは、セッションは通常、より明示的で、「セッション」の全期間にわたってアプリケーションサーバのメモリ内に存在するオブジェクトの形をとることがよくあります。

1
zvolkov

それは特定のアーキテクチャに依存します。一部のアプリケーションサーバーは、Webプロトコル（HTTP上のXML/RPC/SOAP）をネイティブに使用するため、技術的な違いはほとんどありません。通常、Webサーバーはユーザー向けで、HTTP/HTTPS経由でさまざまなコンテンツを提供しますが、アプリケーションサーバーはユーザー向けではなく、非標準またはルーティング不可能なプロトコルを使用することがあります。もちろんRIA/AJAXでは、その違いはさらに曇り、特定のリモートアクセスサービスを提供しているクライアントには非HTMLコンテンツ（JSON/XML）しか提供されません。

0
Cade Roux

IMO、それは主に懸念を切り離すことについてです。

純粋に技術的な観点からは、すべて（Webコンテンツ+ビジネスロジック）を単一のWebサーバーで実行できます。あなたがそうするならば、情報は要求されたHTMLコンテンツの中に埋め込まれるでしょう。影響は何ですか？

たとえば、ブラウザにまったく異なるHTMLコンテンツをレンダリングする2つの異なるアプリケーションがあるとします。ビジネスロジックをアプリケーションサーバーに分離するのであれば、スクリプトを介してアプリケーションサーバー内の同じデータを検索する別のWebサーバーを提供することができます。ただし、ロジックを分離してWebサーバーに保存しないと、ビジネスモデルを変更するたびに、変更する時間がかかり、信頼性が低下してしまいます。エラーを起こしやすい。

0
stdout

基本的な理解：

クライアントサーバーアーキテクチャでは

サーバー：>リクエストを処理します。

クライアント：>これはサービスを消費します。

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/ja-jp/previous-versions/msp-n-p/ee658120(v%3dpandp.10）

0
chandra rv