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

差WEBサーバ、アプリケーションサーバ、HTTPサーバとは何ですか？それぞれIIS、Apacheのは、Tomcatのは、WebLogic、WebSphereサーバーはに属していますか？長い時間のために困惑これらの質問は、最終的には明確に整理します：

Webサーバーの基本的な機能は、Webブラウジングサービス情報を提供します。これは、HTTPプロトコルのみ、HTML文書形式とURLをサポートしています。クライアントのWebブラウザと組み合わせて使用します。通常の状況下では、HTTPサーバーとWebサーバーが同じであるように、Webサーバプロトコルは、HTTPの主なサポートであるので（HTTP Webサーバ以外のプロトコルがサポートされていない、作者が確認されていなかった）、同じことは述べています。

アプリケーションサーバー（アプリケーション・サーバーと呼ばれる）、私たちはその定義にマイクロソフトを見て:.の多くをユーザーに提供するために、ファイルサーバとして」システムの基礎となるビジネスアプリケーションソフトウェアを実行するために、共有サーバー「我々は、アプリケーション・サーバーは次のように定義されて置きます」ファイルと同様、アプリケーションサーバー」とは、複数のユーザーが（通常はクライアントアプリケーションによって作成された）、同時にアプリケーションを使用することができます許可します

人気話すには、Webサーバーが提供するブラウザがページを表示することができるように（機能）が、アプリケーション・サーバーは、クライアントアプリケーションが（呼び出し）メソッド（メソッド）を呼び出すことができます提供します。正確なポイントは、あなたが言うことができます：HTTPリクエスト（要求）を処理する専用のWebサーバが、アプリケーション・サーバは、多くのプロトコルによって、アプリケーション（機能）ビジネスロジック（ビジネスロジック）を提供することです。

例えばJavaのEE、Webサーバ、と主に静的なページとし、サーブレット/ JSPのサーブレットコンテナ処理、解釈および実装として扱う、およびアプリケーション・サーバー等、EJB、JNDIとのJMX APIの主にJ2EE APIの用語をビジネスロジックを実行している、だけでなく、これは、トランザクション処理、データベース接続、および他の機能を含んでいるので、エンタープライズ・アプリケーションにおいて、アプリケーションサーバは、ウェブサーバより強力提供します。

このような定義では、IIS、Apacheは、Tomcat Webサーバーは、WebLogicの所属することができ、WebSphereアプリケーション・サーバーが属します。

アパッチ

Webサーバーでは、Apache Webサーバは、多くの場合、Tomcatのと対になって、純粋です。それは、強力なHTMLページ説明力を持っていますが、ページ内に埋め込まれたサーバー側のスクリプトコード（JSP /サーブレット）を説明することはできません。

Tomcatの

早期のApache Tomcatは、JSP /サーブレットエンジンに埋め込まれている+ Apache Tomcatの等価IIS + ASPを説明しました。その後、TomcatはTomcatプロセスは、Apacheのプロセスの実行とは独立して、もはやApacheの中に埋め込まれていません。さらに、Tomcatのサーブレットは、独立したJSPコンテナを有するビジネス・ロジック・コード、及びコード・インタフェース対話層を分離しました。したがって、誰かが軽量Tomcatアプリケーションサーバーと呼ばれます。

IIS

初期のMicrosoft IISのは、純粋なWebサーバーです。後でそれは埋め込みASPエンジンは、VBScriptとJScriptのサーバ側コードを解釈することができ、その後、それはアプリケーションサーバを兼ねることができます。もちろん、それは単にそれがかろうじてアプリケーションサーバと呼ばれることができるという原則から、機能的にはJ2EEアプリケーション・サーバーと比較して、しかしすることはできません。むしろ、それは両方のアプリケーションサーバ機能Webサーバーの少しです。

要約すると：

Apacheは、Tomcatの純粋なWebサーバであり、サーバ機能を備えた軽量なWebサーバーやアプリケーションサーバーとして呼び出すことができますサーバー側のコードの説明を行う能力を有するものとIIS。WebLogicのは、WebSphere J2EEそれは強力な機能を提供することができますので、それは絶対にアプリケーションサーバのは間違いないです。Tomcatのセカンダリアプリケーションサーバとアプリケーションサーバと展開することができるように、純粋とApacheウェブサーバで使用することができる中間位置、で：

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

これまでのところ、Tomcatは、サーブレットコンテナと呼ばれ、サーブレット/ JSPのAPIアクチュエータと考えられてきました。しかし、Tomcatはそれはまた、JNDIとJMX APIの実装メカニズムを提供し、それだけではありません。それはほとんどのJ2EE APIのためのサポートを提供しないためにもかかわらず、Tomcatはまだ、アプリケーションサーバとみなすことはできません。

興味深いことに、通常はそのサーブレットコンテナとJSP APIのように、Tomcatアプリケーションサーバーの多く。Tomcatが彼のおかげを追加することによって、単に開発者に可能にするので、そのTomcatアプリケーションに埋め込むことができます。残念ながら、多くの商用アプリケーション・サーバは、この規則に準拠していません。

開発者にとって、それはサーブレット、JSPの使用を見つけることであれば、JavaのWebアプリケーションを生成するためのJNDIとJMX技術、そしてTomcatは優れたソリューションで選択します。しかし、サポート、他のJ2EE APIを追求するためには、アプリケーション・サーバーを探したりTomcatアプリケーションサーバーがセカンダリとして、良い解決策になる;第三の方法は、達成するための独立したJ2EEのAPIを見つけ、その後、Tomcatのに使用するためにそれらを一緒に結合することです。統合は、関連する問題をもたらすでしょうが、このアプローチが最も効果的であるが。。

二、Tomcat Webサーバー

Tomcatは、サーブレットとJSPコンテナ支持操作です。サーブレットとJSPは、動的なWebコンテンツを生成し、実際のニーズに基づいてすることができます。Webサーバは、Apacheは静的なページ、無力になります動的ページのサポートをサポートしています。また、静的なページのためのサポートを提供しながらTomcatが、両方の動的なWebサービスです。それはいつもの速いWebサーバを持っていませんが、Webサーバ機能はリッチではありませんが、Tomcatのサポート静的コンテンツは徐々に拡大しています。ほとんどのWebサーバーでは、このように純粋なJavaのTomcatの実行速度で書かれた、それぞれのプラットフォームの機能を利用し、Cのような基本的な言語で書かれているそれらと比較することはできません。

一般的には、大規模なサイトは、TomcatとApache、クライアントからのすべての要求を受け入れる責任のApache HTTPの組み合わせであり、その後に対処するためのJSPサーブレットとTomcatに要求を転送します。治療終了後のTomcat、Apacheのバック、バッククライアントにApacheの最終応答に対する応答。

そして、性能を向上させるためには、Apache Tomcatの負荷分散の複数に接続することができます。

WEBサーバ、アプリケーションサーバについて、より詳細に違いは次の資料を参照することができます：

慎重に道を私達にするにはしてみましょう：

Webサーバ（Webサーバ）

Webサーバは、（ハンドル）HTTPプロトコルを解決することができます。WebサーバーがHTTPリクエスト（要求）を受信すると、それは、例えば、バックのHTMLページをHTTPレスポンス（応答）を返します。リクエスト（要求）を処理するために、Webサーバの応答（レスポンス）は、静的ページや画像、ページジャンプ（リダイレクト）、またはデリゲートを生成する（デリゲート）動的応答（動的応答）は、CGIなどのいくつかの他のプログラムにサーバ側（サーバ側）のJavaScript、またはいくつかの他のサーバー（サーバー側）技術上のスクリプト、JSP（JavaServer Pagesの）スクリプト、サーブレット、ASP（Active Server Pagesの）スクリプト。彼らはあるかどうか：どのように（翻訳者注スクリプト）目的で、これらのサーバ側（サーバ側）のプログラムは、通常はブラウザが閲覧できるようにHTMLレスポンス（応答）を生成します。

あなたが知っている、Webサーバー（委任モデル）のプロキシモデルは非常に単純です。（：サーバー側のスクリプト翻訳者注）要求（リクエスト）をWebは、単純な要求（リクエスト）がアプリケーションの処理要求に伝達され、サーバーに送信された場合の（要求）非常に良いことができます。ウェブサーバは、サーバ（サーバ側）を実行することができ、プログラムは、機能の範囲を超えることなく、環境応答（レスポンス）（プログラムが生成される）を返し。サーバ（サーバ側）は、典型的には、トランザクション処理プログラム（トランザクション処理）、データベース接続（データベース接続）とメッセージ（メッセージング）機能を有しています。

このような負荷分散（ロードバランシング）、バッファとして、フォールトトレランス（耐障害性）とスケーラビリティ（拡張性）を達成するために（採用）、様々な戦略（ストラテジー）をWebサーバは、トランザクションやデータベース接続プールをサポートしていませんが、設定することができますが、（キャッシュ）。クラスタ機能（クラスタリング-機能）は、多くの場合、単にアプリケーションサーバ固有の機能と間違えです。

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

私たちの定義によれば、アプリケーションサーバとして、ビジネスロジックにさらさHTTPなど、様々な通信プロトコル、を介してクライアントアプリケーションを（EXPOSE）。Webサーバは、主に閲覧するためのブラウザにHTMLを送信して対処、およびアプリケーション・サーバーは、クライアントアプリケーションで使用するために、ビジネスロジックにアクセスするための方法を提供します。このアプリケーションは、（関数またはプロセス言語）を使用すると、同じオブジェクトを呼び出す方法として、ビジネス・ロジックを使用しています。

（グラフィカル・ユーザー・インターフェース（GUI）を含む）、クライアント・アプリケーション・サーバーは、PC、Webサーバー、あるいは他のアプリケーションサーバー上で実行されている可能性があります。簡単な情報の表示マークを超えて（旅行）前後に、アプリケーション・サーバーとクライアント間。むしろ、そのような情報は、プログラムロジック（プログラムロジック）です。それは作られたこのロジック（とり）のデータとメソッド呼び出し（呼び出し）の形ではなく、静的なHTMLであるので、クライアントは、任意のビジネスロジックにさらされるためにこれを使用することができます。

ほとんどの場合、アプリケーションコンポーネント（コンポーネント）インタフェース（API）を介してアプリケーション・サーバは、例えばJ2EE（Java 2プラットフォーム、エンタープライズ版）に基づいてビジネスロジック（EXPOSE）（クライアントアプリケーション）を、露光したアプリケーションEJB（エンタープライズJavaBean）コンポーネントモデルのアプリケーションサーバ。また、アプリケーションサーバは、セキュリティ（安全保障）を含む用務員の仕事（ゲートキーピング業務）、トランザクション処理（トランザクション処理）、リソースプール（リソースプール）、およびメッセージ（メッセージング）など、独自のリソースを管理することができます。ただ、Webサーバーのように、アプリケーションサーバは、スケーラビリティ（拡張性）とフォールトトレランス（耐障害性）技術の様々な設定されています。

例

たとえば、想像オンラインストア（ウェブサイト）は、リアルタイムの価格設定（リアルタイムプライシング）と有効性（可用性）情報を提供します。このサイトは（サイト）の形（フォーム）を提供する可能性がありますが、製品を選択することができます。クエリ（クエリ）を送信すると、サイトが見つけること（ルックアップ）とHTMLページに埋め込まれた結果を返します。ウェブサイトには、この機能を実現するためのさまざまな方法を持つことができます。私は、サーバーのシナリオとアプリケーションサーバを使用してシナリオを使用するアプリケーションを紹介したいと思います。あなたは、アプリケーション・サーバーの機能を理解するのに役立ちます2つの異なるシナリオに見えます。

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

このシナリオでは、ウェブサーバ機能の独立したオンラインストア。処理プログラム（リクエスト）Aを要求することができ、あなたのWebサーバーの要求（リクエスト）を取得し、サーバー（サーバー側）に送られます。データベースやテキストファイルからこのプログラム：価格情報を見つけるために（フラットファイル、翻訳者注フラットファイルには、特別なフォーマットがなどの特性やXMLファイルなどの非バイナリファイル、を意味していないです）。見つかったら、サーバー（サーバー側）の番組情報結果は、HTMLフォーム（策定）のように表現され、最終的にWebサーバーは、Webブラウザに送信します。

単にHTTPリクエストを処理するために（レスポンス）HTMLページ（リクエスト）を応答することによって簡単に言えば、Webサーバ。

シナリオ2：アプリケーションサーバーとWebサーバー

シナリオ2とシナリオ同じWebサーバ1は、生成またはスクリプト（翻訳者注：サーバー（サーバー側）のプログラム）へのデリゲート（委譲）レスポンス（応答）されます。ただし、アプリケーションサーバーへのビジネス・ロジック（ビジネスロジック）の価格設定を見つけることができます。この変更のため、スクリプトは単にアプリケーション・サーバーの検索サービス（検索サービス）を呼び出して、すでにデータを見つける方法を知っているし、その後（策定）レスポンス（応答）として発現していません。その後、スクリプトはHTMLレスポンス（応答）を生成するときの結果を返すためにサービスを使用することができます。

このシナリオでは、アプリケーションサーバは、製品情報の照会の価格設定のためのビジネス・ロジックを提供する（働きます）。（サーバー）この関数（機能）は、ディスプレイとクライアントの詳細は、この情報を使用する方法を示すものではありませんが、むしろ、クライアントとアプリケーション・サーバは、ちょうど前後にデータを転送します。クライアントは、アプリケーション・サーバーの検索サービス（検索サービス）を呼び出すと、このサービスは、単純に検索し、結果をクライアントに戻します。

強い（検索）ロジックの再利用価格設定アプリケーションに応答から（レスポンス生成）HTMLコードを生成することによって、単離されました。こうしたキャッシュレジスタなどの他のクライアントは、あなたはまた、チェックアウトの店員と顧客に同じサービス（サービス）を呼び出すことができます。情報は、HTMLページに埋め込まれているのでこれとは対照的に、シナリオ1で価格検索サービスは再利用可能ではありません。

すべてのすべてで、シナリオ2、HTMLページに応答することにより、HTTPリクエスト（要求）を処理するために、Webサーバー、およびアプリケーション・サーバーでのモデルは、価格と可用性の要求（可用性）（要求）を処理することによって、アプリケーション・ロジックを提供することです。

警告（警告）

さて、XML Webサービスは混乱し、アプリケーション・サーバーとWebサーバーの境界を作っています。サーバにXMLペイロード（ペイロード）を送信することにより容量が、ウェブ・サーバは、現在のデータと以前のアプリケーションサーバ同量の応答（レスポンス）を扱うことができます。

また、ほとんどのアプリケーションサーバは現在もWebサーバーがサブセット（サブセット）アプリケーション・サーバであるとして、あなたが置くことができることを意味し、Webサーバーが含まれています。アプリケーションサーバは、Webサーバーの機能が含まれていますが、開発者はめったにアプリケーションサーバの展開（展開）この関数に（容量）（翻訳者注が：この機能がアプリケーションサーバの両方の関数でありますWebサーバ機能）。逆に、必要であれば、彼らは通常、Webサーバーの構成を分離して、以前のアプリケーション・サーバの後になります。機能のこの分離は、（簡単なWeb要求（リクエスト）、アプリケーション・サーバーには影響しません）、分離の構成（専用のWebサーバー、クラスター（クラスタリング）、など）、そして最高の製品にパフォーマンスを向上させることができます余裕を選択します。