แอ็พพลิเคชันเซิร์ฟเวอร์และเว็บเซิร์ฟเวอร์ต่างกันอย่างไร

แอ็พพลิเคชันเซิร์ฟเวอร์และเว็บเซิร์ฟเวอร์ต่างกันอย่างไร

ส่วนใหญ่เวลาข้อกำหนดเหล่านี้เว็บเซิร์ฟเวอร์และเซิร์ฟเวอร์แอปพลิเคชันจะใช้แทนกันได้

ต่อไปนี้เป็นข้อแตกต่างที่สำคัญบางประการในคุณสมบัติของเว็บเซิร์ฟเวอร์และแอพพลิเคชันเซิร์ฟเวอร์:

• เว็บเซิร์ฟเวอร์ออกแบบมาเพื่อให้บริการเนื้อหา HTTP แอปเซิร์ฟเวอร์ยังสามารถให้บริการเนื้อหา HTTP แต่ไม่ จำกัด เพียง HTTP มันสามารถให้การสนับสนุนโปรโตคอลอื่น ๆ เช่น RMI / RPC
• เว็บเซิร์ฟเวอร์ส่วนใหญ่ได้รับการออกแบบมาเพื่อให้บริการเนื้อหาแบบคงที่ แต่เว็บเซิร์ฟเวอร์ส่วนใหญ่มีปลั๊กอินเพื่อรองรับภาษาสคริปต์เช่น Perl, PHP, ASP, JSP เป็นต้นซึ่งเซิร์ฟเวอร์เหล่านี้สามารถสร้างเนื้อหา HTTP แบบไดนามิก
• แอ็พพลิเคชันเซิร์ฟเวอร์ส่วนใหญ่มีเว็บเซิร์ฟเวอร์เป็นส่วนหนึ่งของพวกเขานั่นหมายความว่าแอพเซิร์ฟเวอร์สามารถทำสิ่งที่เว็บเซิร์ฟเวอร์สามารถทำได้ นอกจากนี้แอพเซิร์ฟเวอร์ยังมีส่วนประกอบและคุณสมบัติต่าง ๆ ที่รองรับบริการระดับแอพพลิเคชั่นเช่นการรวมการเชื่อมต่อการรวมวัตถุการสนับสนุนการทำธุรกรรมบริการส่งข้อความเป็นต้น
• เนื่องจากเว็บเซิร์ฟเวอร์เหมาะสำหรับเนื้อหาแบบคงที่และเซิร์ฟเวอร์แอพสำหรับเนื้อหาแบบไดนามิกสภาพแวดล้อมการผลิตส่วนใหญ่จึงมีเว็บเซิร์ฟเวอร์ที่ทำหน้าที่เป็นพร็อกซีย้อนกลับไปยังเซิร์ฟเวอร์แอป ซึ่งหมายความว่าในขณะที่ให้บริการคำขอหน้าเนื้อหาแบบสแตติก (เช่นอิมเมจ / HTML แบบ HTML) จะให้บริการโดยเว็บเซิร์ฟเวอร์ที่ตีความคำขอ การใช้เทคนิคการกรองบางประเภท (ส่วนใหญ่เป็นการขยายทรัพยากรที่ร้องขอ) เว็บเซิร์ฟเวอร์จะระบุคำขอเนื้อหาแบบไดนามิกและส่งต่อไปยังเซิร์ฟเวอร์แอปอย่างโปร่งใส

ตัวอย่างของการกำหนดค่าดังกล่าวคือ Apache Tomcat HTTP Server และ Oracle (เดิมชื่อ BEA) WebLogic Server Apache Tomcat HTTP Server เป็นเว็บเซิร์ฟเวอร์และ Oracle WebLogic เป็นเซิร์ฟเวอร์แอปพลิเคชัน

ในบางกรณีเซิร์ฟเวอร์จะรวมอย่างแน่นหนาเช่น IIS และ. NET Runtime IIS คือเว็บเซิร์ฟเวอร์ เมื่อติดตั้ง. NET runtime สิ่งแวดล้อม IIS มีความสามารถในการให้บริการแอปพลิเคชัน

นี่คือคำตอบโดยละเอียดกับบางสถานการณ์เพื่อให้เข้าใจอย่างชัดเจนถึงความแตกต่างความเหมือนและวิธีที่ทั้งสองสามารถทำงานร่วมกันและทั้งหมดได้

Application Serverเป็นคำที่บางครั้งมีการผสมกับเป็นเว็บเซิร์ฟเวอร์ ในขณะที่เว็บเซิร์ฟเวอร์ที่จับส่วนใหญ่HTTP โปรโตคอล , ข้อเสนอแอพพลิเคชันเซิร์ฟเวอร์กับโปรโตคอลที่แตกต่างกันหลายประการรวมถึง แต่ไม่ จำกัด เป็น HTTP

งานหลักของเว็บเซิร์ฟเวอร์คือการแสดงเนื้อหาของไซต์และแอปพลิเคชันเซิร์ฟเวอร์รับผิดชอบด้านตรรกะการโต้ตอบระหว่างผู้ใช้กับเนื้อหาที่แสดง แอ็พพลิเคชันเซิร์ฟเวอร์ทำงานร่วมกับเว็บเซิร์ฟเวอร์โดยที่หนึ่งจอแสดงผลและอีกอันหนึ่งโต้ตอบ

ข้อมูลที่เดินทางไปมาระหว่างเซิร์ฟเวอร์และไคลเอนต์ไม่ได้ จำกัด อยู่ที่มาร์กอัพแสดงผลแบบง่าย แต่เป็นการโต้ตอบระหว่างสองระบบ

ในกรณีส่วนใหญ่เซิร์ฟเวอร์จะสร้างการโต้ตอบนี้ผ่าน API ของคอมโพเนนต์เช่นJ2EE (แพลตฟอร์ม Java 2) , EJB (Enterprise JavaBean)และโมเดลแอปพลิเคชันซอฟต์แวร์อื่น ๆ

ตัวอย่าง:

วิธีที่ดีที่สุดในการทำความเข้าใจความแตกต่างระหว่างสถานการณ์ที่แอปพลิเคชันเซิร์ฟเวอร์ทำงานกับเว็บเซิร์ฟเวอร์กับสถานการณ์ที่ไม่มีแอปพลิเคชันเซิร์ฟเวอร์ผ่านร้านค้าออนไลน์

สถานการณ์ที่ 1: เว็บเซิร์ฟเวอร์ที่ไม่มีแอปพลิเคชันเซิร์ฟเวอร์

คุณมีร้านค้าออนไลน์ที่มีเพียงเว็บเซิร์ฟเวอร์และไม่มีเซิร์ฟเวอร์แอปพลิเคชัน เว็บไซต์จะให้การแสดงผลที่คุณสามารถเลือกผลิตภัณฑ์จาก เมื่อคุณส่งแบบสอบถามเว็บไซต์ทำการค้นหาและส่งคืนผลลัพธ์ HTML กลับไปยังลูกค้า เว็บเซิร์ฟเวอร์ส่งการสอบถามของคุณไปยังเซิร์ฟเวอร์ฐานข้อมูลโดยตรง (อดทนรอฉันจะอธิบายสิ่งนี้ใน nugget ถัดไปของเรา) และรอการตอบกลับ เมื่อได้รับแล้วเว็บเซิร์ฟเวอร์จะกำหนดคำตอบเป็นไฟล์ HTML และส่งไปยังเว็บเบราว์เซอร์ของคุณ การสื่อสารไปมาระหว่างเซิร์ฟเวอร์และเซิร์ฟเวอร์ฐานข้อมูลนี้เกิดขึ้นทุกครั้งที่มีการเรียกใช้แบบสอบถาม

สถานการณ์ที่ 2: เว็บเซิร์ฟเวอร์ที่มีแอพพลิเคชันเซิร์ฟเวอร์

หากแบบสอบถามที่คุณต้องการเรียกใช้ทำไปแล้วก่อนหน้านี้และไม่มีการเปลี่ยนแปลงข้อมูลตั้งแต่นั้นเซิร์ฟเวอร์จะสร้างผลลัพธ์โดยไม่ต้องส่งคำขอไปยังเซิร์ฟเวอร์ฐานข้อมูล ซึ่งช่วยให้แบบสอบถามแบบเรียลไทม์ซึ่งไคลเอนต์ที่สองสามารถเข้าถึงข้อมูลเดียวกันและรับข้อมูลที่เชื่อถือได้แบบเรียลไทม์โดยไม่ต้องส่งแบบสอบถามที่ซ้ำกันไปยังเซิร์ฟเวอร์ฐานข้อมูล เซิร์ฟเวอร์โดยทั่วไปจะทำหน้าที่เป็นสื่อกลางระหว่างเซิร์ฟเวอร์ฐานข้อมูลและเว็บเซิร์ฟเวอร์ สิ่งนี้ช่วยให้ข้อมูลที่ดึงมาสามารถนำมาใช้ซ้ำได้ในสถานการณ์แรกเนื่องจากข้อมูลนี้ฝังอยู่ในหน้าใดหน้าหนึ่งและ "กำหนดเอง" HTML นี่ไม่ใช่กระบวนการที่นำมาใช้ซ้ำได้ ลูกค้ารายที่สองจะต้องขอข้อมูลอีกครั้งและรับหน้า HTML ที่ฝังอีกหน้าหนึ่งพร้อมกับข้อมูลที่ร้องขอโดยไม่มีประสิทธิภาพสูง

เพื่อรองรับงานที่ซับซ้อนเช่นเซิร์ฟเวอร์นี้ต้องมีระบบสำรองในตัวกำลังการประมวลผลที่ยอดเยี่ยมและ RAM ที่มีปริมาณสูงเพื่อจัดการกับข้อมูลทั้งหมดที่ดึงมาแบบเรียลไทม์

หวังว่านี่จะช่วยได้

คำศัพท์ทั้งสองเป็นคำที่กว้างมากคำหนึ่งมีอีกคำหนึ่งและในทางกลับกันในบางกรณี

• เว็บเซิร์ฟเวอร์ : ให้บริการเนื้อหาไปยังเว็บโดยใช้โปรโตคอล http

• แอพพลิเคชันเซิร์ฟเวอร์ : โฮสต์และแสดงตรรกะทางธุรกิจและกระบวนการ

ฉันคิดว่าประเด็นหลักคือเว็บเซิร์ฟเวอร์จะเปิดเผยทุกอย่างผ่านโปรโตคอล http ในขณะที่แอปพลิเคชันเซิร์ฟเวอร์ไม่ได้ถูก จำกัด

ดังที่กล่าวไว้ในหลาย ๆ สถานการณ์คุณจะพบว่ามีการใช้เว็บเซิร์ฟเวอร์ในการสร้างส่วนหน้าของแอปพลิเคชันเซิร์ฟเวอร์นั่นคือจะแสดงชุดของหน้าเว็บที่อนุญาตให้ผู้ใช้โต้ตอบกับกฎทางธุรกิจที่พบใน แอ็พพลิเคชันเซิร์ฟเวอร์

เว็บเซิร์ฟเวอร์

เรียกใช้python -m 'SimpleHTTPServer'และไปที่http: // localhost: 8080 สิ่งที่คุณเห็นคือเว็บเซิร์ฟเวอร์ในที่ทำงาน เซิร์ฟเวอร์ให้บริการไฟล์ผ่าน 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()และฟังก์ชัน/aboutabout()

ในการเรียกใช้รหัสนี้เราต้องการแอปพลิเคชันเซิร์ฟเวอร์ (เช่น Gunicorn) - โปรแกรมหรือโมดูลที่สามารถรับฟังคำขอจากลูกค้าและใช้รหัสของเราคืนบางสิ่งได้แบบไดนามิก ในตัวอย่างเราเพียงแค่คืน HTML ที่แย่มาก ๆ

ตรรกะทางธุรกิจทั้งหมดที่คนอื่นพูดถึงคืออะไร? เนื่องจาก URL แผนที่ไปยังที่ใดที่หนึ่งโดยเฉพาะในโค้ดเบสของเราเราจึงแสดงเหตุผลบางอย่างเกี่ยวกับการทำงานของโปรแกรมของเรา

recapping

เว็บเซิร์ฟเวอร์ - ให้บริการไฟล์ที่เก็บไว้ที่ใดที่หนึ่ง (โดยทั่วไปคือ. css, .html, .js) เว็บเซิร์ฟเวอร์ทั่วไปคือ Apache, Nginx หรือ SimpleHTTPServer ของ Python

แอพพลิเคชันเซิร์ฟเวอร์ - ให้บริการไฟล์ที่สร้างขึ้นได้ทันที โดยพื้นฐานแล้วเว็บเซิร์ฟเวอร์ส่วนใหญ่มีปลั๊กอินบางประเภทหรือแม้กระทั่งมีฟังก์ชันการทำงานในตัวเพื่อทำเช่นนั้น มีแอพพลิเคชันเซิร์ฟเวอร์ที่เข้มงวดเช่น Gunicorn (Python), Unicorn (Ruby), uWSGI (Python) เป็นต้น

โปรดสังเกตว่าคุณสามารถสร้างเว็บเซิร์ฟเวอร์ได้ด้วยรหัสของแอปพลิเคชันเซิร์ฟเวอร์ ในบางกรณีในระหว่างการพัฒนาที่คุณไม่ต้องการให้เซิร์ฟเวอร์ต่าง ๆ ทำงานบนคอมพิวเตอร์ของคุณ

ดังที่ Rutesh และ jmservera ได้ชี้ให้เห็นความแตกต่างเป็นสิ่งที่คลุมเครือ ในอดีตมีความแตกต่างกัน แต่ผ่าน 90's ทั้งสองหมวดหมู่ที่แตกต่างกันก่อนหน้านี้มีคุณสมบัติการผสมผสานและผสานอย่างมีประสิทธิภาพ ณ จุดนี้น่าจะเป็นการดีที่สุดที่จะจินตนาการว่าหมวดหมู่ผลิตภัณฑ์ "เซิร์ฟเวอร์แอพ" เป็นชุดที่เข้มงวดของหมวดหมู่ "เว็บเซิร์ฟเวอร์"

ประวัติบ้าง ในวันแรก ๆ ของเบราว์เซอร์ Mosaic และเนื้อหาไฮเปอร์ลิงก์มีการพัฒนาสิ่งนี้เรียกว่า "เว็บเซิร์ฟเวอร์" ที่ให้บริการเนื้อหาของหน้าเว็บและรูปภาพผ่าน HTTP เนื้อหาส่วนใหญ่เป็นแบบสแตติกและโปรโตคอล HTTP 1.0 เป็นเพียงวิธีการจัดส่งไฟล์ หมวดหมู่ "เว็บเซิร์ฟเวอร์" อย่างรวดเร็วพัฒนาขึ้นเพื่อรวมความสามารถของ CGI - เปิดตัวกระบวนการในแต่ละคำขอของเว็บเพื่อสร้างเนื้อหาแบบไดนามิกได้อย่างมีประสิทธิภาพ HTTP ยังครบกำหนดและผลิตภัณฑ์มีความซับซ้อนมากขึ้นด้วยการแคชการรักษาความปลอดภัยและคุณสมบัติการจัดการ เมื่อเทคโนโลยีครบกำหนดเราได้รับเทคโนโลยีฝั่งเซิร์ฟเวอร์เฉพาะ Java จาก Kiva และ NetDynamics ซึ่งในที่สุดก็รวมเข้ากับ JSP Microsoft ได้เพิ่ม ASP ฉันคิดว่าในปี 1996 กับ Windows NT 4.0 เว็บเซิร์ฟเวอร์แบบสแตติกได้เรียนรู้เทคนิคใหม่บางอย่างเพื่อให้มีประสิทธิภาพ "

ในประเภทคู่ขนานเซิร์ฟเวอร์แอปมีการพัฒนาและมีอยู่เป็นเวลานาน บริษัท ต่างๆส่งมอบผลิตภัณฑ์ให้กับ Unix อย่าง Tuxedo, TopEnd, Encina ซึ่งได้มาจากการจัดการแอพพลิเคชั่นเมนเฟรมและการตรวจสอบสภาพแวดล้อมเช่น IMS และ CICS ข้อเสนอของ Microsoft คือ Microsoft Transaction Server (MTS) ซึ่งต่อมาพัฒนาเป็น COM + ส่วนใหญ่ของผลิตภัณฑ์เหล่านี้ระบุโปรโตคอลการสื่อสารเฉพาะผลิตภัณฑ์ "ปิด" เพื่อเชื่อมต่อระหว่างลูกค้า "อ้วน" กับเซิร์ฟเวอร์ (สำหรับ Encina โปรโตคอล comms คือ DCE RPC สำหรับ MTS เป็น DCOM และอื่น ๆ ) ในปี 1995/96 ผลิตภัณฑ์เซิร์ฟเวอร์แอพแบบดั้งเดิมเหล่านี้เริ่มฝังความสามารถในการสื่อสาร HTTP พื้นฐานในตอนแรกผ่านเกตเวย์ และเส้นเริ่มเบลอ

เว็บเซิร์ฟเวอร์มีความเป็นผู้ใหญ่มากขึ้นเมื่อเทียบกับการจัดการโหลดที่สูงขึ้นการทำงานพร้อมกันและคุณสมบัติที่ดีขึ้น เซิร์ฟเวอร์แอปมอบขีดความสามารถในการสื่อสารผ่าน HTTP ที่มากขึ้นเรื่อย ๆ

ณ จุดนี้เส้นระหว่าง "เซิร์ฟเวอร์แอป" และ "เว็บเซิร์ฟเวอร์" เป็นสิ่งที่คลุมเครือ แต่ผู้คนยังคงใช้คำศัพท์ต่างกันอย่างต่อเนื่องเนื่องจากเป็นเรื่องที่เน้นย้ำ เมื่อมีคนพูดว่า "เว็บเซิร์ฟเวอร์" คุณมักจะคิดว่า HTTP เป็นศูนย์กลางเว็บ UI แอปที่มุ่งเน้น เมื่อมีคนพูดว่า "เซิร์ฟเวอร์แอป" คุณอาจคิดว่า "การโหลดที่หนักกว่าคุณสมบัติขององค์กรธุรกรรมและการเข้าคิวการสื่อสารหลายช่องทาง (HTTP + มากกว่า) แต่บ่อยครั้งที่มันเป็นผลิตภัณฑ์เดียวกันที่ตอบสนองความต้องการปริมาณงานทั้งสองชุด

• WebSphere, "เซิร์ฟเวอร์แอป" ของ IBM มีเว็บเซิร์ฟเวอร์รวมของตัวเอง
• WebLogic ซึ่งเป็นเซิร์ฟเวอร์แอปดั้งเดิมอีกเครื่องเช่นเดียวกัน
• Windows ซึ่งเป็น App Server ของ Microsoft (นอกเหนือจากการเป็น File & Print Server, Media Server และอื่น ๆ ) รวม IIS

ดังที่หลายคนเคยกล่าวไว้ก่อนหน้านี้เว็บเซิร์ฟเวอร์จัดการคำร้อง HTTP ในขณะที่แอ็พพลิเคชันเซิร์ฟเวอร์จัดการคำร้องสำหรับส่วนประกอบแบบกระจาย ดังนั้นวิธีที่ง่ายที่สุดที่จะเข้าใจความแตกต่างคือการเปรียบเทียบผลิตภัณฑ์ทั้งสองเกี่ยวกับสภาพแวดล้อมการเขียนโปรแกรมที่เสนอ

เว็บเซิร์ฟเวอร์ -> สภาพแวดล้อมการเขียนโปรแกรม

IIS: ASP (.NET)

Tomcat: Servlet

Jetty: Servlet

Apache: Php, CGI

แอพพลิเคชันเซิร์ฟเวอร์ -> สภาพแวดล้อมการเขียนโปรแกรม

MTS: COM +

WAS: EJB

JBoss: EJB

แอปพลิเคชันเซิร์ฟเวอร์ WebLogic: EJB

ความแตกต่างที่สำคัญคือแอพพลิเคชั่นเซิร์ฟเวอร์รองรับเทคโนโลยีส่วนประกอบที่มีการกระจายการให้บริการคุณสมบัติเช่นการร้องขอจากระยะไกลและการทำธุรกรรมแบบกระจายเช่นEJBในโลก Java หรือCOM +บนแพลตฟอร์ม Microsoft เซิร์ฟเวอร์ Http มักจะรองรับสภาพแวดล้อมการเขียนโปรแกรมที่ง่ายขึ้นเช่นการเขียนสคริปต์เช่น ASP (.NET) ในกรณีของ Microsoft หรือ Servlet - based รวมถึง JSP และอื่น ๆ อีกมากมายในกรณีของ Java หรือ PHP และ CGI ในกรณีของ Apache

ความสามารถอื่น ๆ เช่นการทำโหลดบาลานซ์การทำคลัสเตอร์เซสชั่นการเฟลโอเวอร์การรวมการเชื่อมต่อเป็นต้นซึ่งเคยอยู่ในขอบเขตของแอปพลิเคชันเซิร์ฟเวอร์กำลังมีอยู่บนเว็บเซิร์ฟเวอร์เช่นกันโดยตรงหรือผ่านผลิตภัณฑ์ของบุคคลที่สาม

ในที่สุดมันก็เป็นที่น่าสังเกตว่าภาพที่บิดเบี้ยวต่อไปด้วย "ภาชนะบรรจุที่มีน้ำหนักเบา" เช่น Spring Framework ที่มักจะเสริมวัตถุประสงค์ของแอปพลิเคชันเซิร์ฟเวอร์ในลักษณะที่ง่ายขึ้นและไม่มีโครงสร้างพื้นฐานเซิร์ฟเวอร์แอปพลิเคชัน และเนื่องจากลักษณะการกระจายในแอปพลิเคชันเคลื่อนจากส่วนประกอบที่กระจายไปสู่กระบวนทัศน์การบริการและสถาปัตยกรรม SOA จึงมีพื้นที่เหลือน้อยลงสำหรับแอปพลิเคชันเซิร์ฟเวอร์แบบดั้งเดิม

ข้อแตกต่างที่สำคัญระหว่างเว็บเซิร์ฟเวอร์และแอปพลิเคชันเซิร์ฟเวอร์คือเว็บเซิร์ฟเวอร์นั้นมีไว้เพื่อให้บริการหน้าคงที่เช่น HTML และ CSS ในขณะที่ Application Server มีหน้าที่สร้างเนื้อหาแบบไดนามิกโดยรันโค้ดด้านเซิร์ฟเวอร์เช่น JSP, Servlet หรือ EJB

ฉันควรใช้อันไหนดี?
เมื่อคุณทราบถึงความแตกต่างระหว่างเว็บและเซิร์ฟเวอร์แอปพลิเคชันและเว็บคอนเทนเนอร์มันเป็นเรื่องง่ายที่จะทราบว่าจะใช้เมื่อไร คุณต้องมีweb serverApache HTTPD เหมือนกันหากคุณให้บริการหน้าเว็บแบบคงที่ หากคุณมีแอปพลิเคชัน Java ที่มีเพียง JSP และ Servlet เพื่อสร้างเนื้อหาแบบไดนามิกคุณต้องมีweb containersTomcat หรือ Jetty ในขณะที่ถ้าคุณมีแอปพลิเคชัน Java EE ที่ใช้ EJB ธุรกรรมแบบกระจายการส่งข้อความและคุณสมบัติแฟนซีอื่น ๆกว่าที่คุณต้องใช้อย่างเต็มรูปแบบapplication serverเช่น JBoss, WebSphere หรือ WebLogic ของ Oracle

เว็บคอนเทนเนอร์เป็นส่วนหนึ่งของเว็บเซิร์ฟเวอร์และเว็บเซิร์ฟเวอร์เป็นส่วนหนึ่งของแอพพลิเคชันเซิร์ฟเวอร์

เว็บเซิร์ฟเวอร์ประกอบด้วยเว็บคอนเทนเนอร์ในขณะที่แอพพลิเคชันเซิร์ฟเวอร์ประกอบด้วยเว็บคอนเทนเนอร์เช่นเดียวกับคอนเทนเนอร์ EJB

กล่าวโดยย่อคือเว็บเซิร์ฟเวอร์คือเซิร์ฟเวอร์ที่ให้บริการหน้าเว็บแก่ผู้ใช้ผ่าน http แอพพลิเคชันเซิร์ฟเวอร์เป็นเซิร์ฟเวอร์ที่โฮสต์ตรรกะทางธุรกิจสำหรับระบบที่ มันมักจะเป็นเจ้าภาพทั้งกระบวนการทำงานนาน / ชุดและ / หรือบริการ interop ไม่ได้หมายถึงการบริโภคของมนุษย์ (บริการ REST / JSON, SOAP, RPC, ฯลฯ )

เว็บเซิร์ฟเวอร์จัดการการร้องขอ HTTP / HTTPS โดยเฉพาะ มันให้บริการเนื้อหาไปยังเว็บโดยใช้โปรโตคอล HTTP / HTTPS

แอ็พพลิเคชันเซิร์ฟเวอร์ให้บริการตรรกะทางธุรกิจแก่แอ็พพลิเคชันโปรแกรมผ่านโปรโตคอลจำนวนเท่าใดก็ได้รวมถึง HTTP แอปพลิเคชันโปรแกรมสามารถใช้ตรรกะนี้เหมือนกับที่จะเรียกใช้เมธอดบนวัตถุ ในกรณีส่วนใหญ่เซิร์ฟเวอร์จะเปิดเผยตรรกะทางธุรกิจนี้ผ่านส่วนประกอบ API เช่นโมเดลส่วนประกอบ EJB (Enterprise JavaBean) ที่พบในเซิร์ฟเวอร์แอปพลิเคชัน Java EE (Java Platform, Enterprise Edition) ประเด็นหลักคือเว็บเซิร์ฟเวอร์จะเปิดเผยทุกอย่างผ่านโปรโตคอล http ในขณะที่แอปพลิเคชันเซิร์ฟเวอร์ไม่ได้ถูก จำกัด แอปพลิเคชันเซิร์ฟเวอร์จึงเสนอบริการมากกว่าเว็บเซิร์ฟเวอร์ซึ่งโดยทั่วไปจะรวมถึง:

• API (เป็นกรรมสิทธิ์หรือไม่)
• โหลดบาลานซ์ล้มเหลว ...
• การจัดการวัฏจักรวัตถุ
• การจัดการของรัฐ (เซสชัน)
• การจัดการทรัพยากร (เช่นกลุ่มการเชื่อมต่อกับฐานข้อมูล)

แอ็พพลิเคชันเซิร์ฟเวอร์ส่วนใหญ่มีเว็บเซิร์ฟเวอร์เป็นส่วนหนึ่งของพวกเขานั่นหมายความว่าแอพเซิร์ฟเวอร์สามารถทำสิ่งที่เว็บเซิร์ฟเวอร์สามารถทำได้ นอกจากนี้แอพเซิร์ฟเวอร์ยังมีส่วนประกอบและคุณสมบัติต่าง ๆ ที่รองรับบริการระดับแอพพลิเคชั่นเช่นการรวมการเชื่อมต่อการรวมวัตถุการสนับสนุนการทำธุรกรรมบริการส่งข้อความเป็นต้น

แอ็พพลิเคชันเซิร์ฟเวอร์สามารถ (แต่ไม่เสมอไป) บนเว็บเซิร์ฟเวอร์เพื่อรันโปรแกรมตรรกะผลลัพธ์ที่เว็บเซิร์ฟเวอร์สามารถส่งมอบได้ นั่นเป็นตัวอย่างหนึ่งของสถานการณ์สมมติของเว็บเซิร์ฟเวอร์ / แอปพลิเคชันเซิร์ฟเวอร์ ตัวอย่างที่ดีในโลกของ Microsoft คือความสัมพันธ์ของ Internet Information Server / SharePoint Server IIS เป็นเว็บเซิร์ฟเวอร์ SharePoint เป็นเซิร์ฟเวอร์แอปพลิเคชัน SharePoint ตั้งอยู่ "บนสุด" ของ IIS ดำเนินการตรรกะเฉพาะและให้บริการผลลัพธ์ผ่าน IIS ในโลกของ Java มีสถานการณ์คล้ายกับ Apache และ Tomcat เป็นต้น

เนื่องจากเว็บเซิร์ฟเวอร์เหมาะสำหรับเนื้อหาแบบคงที่และเซิร์ฟเวอร์แอพสำหรับเนื้อหาแบบไดนามิกสภาพแวดล้อมการผลิตส่วนใหญ่จึงมีเว็บเซิร์ฟเวอร์ที่ทำหน้าที่เป็นพร็อกซีย้อนกลับไปยังเซิร์ฟเวอร์แอป ซึ่งหมายความว่าในขณะที่ให้บริการคำขอหน้าเนื้อหาแบบคงที่เช่น images / Static html จะถูกให้บริการโดยเว็บเซิร์ฟเวอร์ที่ตีความคำขอ การใช้เทคนิคการกรองบางประเภท (ส่วนใหญ่เป็นการขยายทรัพยากรที่ร้องขอ) เว็บเซิร์ฟเวอร์จะระบุคำขอเนื้อหาแบบไดนามิกและส่งต่อไปยังเซิร์ฟเวอร์แอปอย่างโปร่งใส

ตัวอย่างของการกำหนดค่าเช่น Apache HTTP Server และ BEA WebLogic Server Apache HTTP Server เป็นเว็บเซิร์ฟเวอร์และ BEA WebLogic เป็น Application Server ในบางกรณีเซิร์ฟเวอร์รวมอย่างแน่นหนาเช่น IIS และ. NET Runtime IIS คือเว็บเซิร์ฟเวอร์ เมื่อติดตั้ง. NET runtime environment 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+

เส้นแบ่งระหว่างสองสิ่งนี้กำลังผอมลงเรื่อย ๆ

แอ็พพลิเคชันเซิร์ฟเวอร์เปิดเผยตรรกะทางธุรกิจแก่ลูกค้า นั่นหมายความว่าแอปพลิเคชันเซิร์ฟเวอร์ประกอบด้วยชุดของวิธีการ (ไม่เพียง แต่สามารถเป็นคอมพิวเตอร์เครือข่ายที่อนุญาตให้หลายคนรันซอฟต์แวร์บน) เพื่อดำเนินการตรรกะทางธุรกิจ ดังนั้นมันจะแสดงผลลัพธ์ที่ต้องการไม่ใช่เนื้อหา HTML (คล้ายกับการเรียกเมธอด) ดังนั้นจึงไม่ได้ยึดตาม HTTP อย่างเคร่งครัด

แต่เว็บเซิร์ฟเวอร์จะส่งเนื้อหา HTML ไปยังเว็บเบราว์เซอร์ (ใช้ HTTP อย่างเคร่งครัด) เว็บเซิร์ฟเวอร์มีความสามารถในการจัดการทรัพยากรเว็บแบบคงที่เท่านั้น แต่การเกิดขึ้นของสคริปต์ฝั่งเซิร์ฟเวอร์ทำให้เว็บเซิร์ฟเวอร์สามารถจัดการเนื้อหาแบบไดนามิกได้เช่นกัน ที่ซึ่งเว็บเซิร์ฟเวอร์ใช้ในการร้องขอและนำไปยังสคริปต์ที่เกี่ยวข้อง (สคริปต์ PHP, JSP, CGI, ฯลฯ ) เพื่อสร้างเนื้อหา HTML เพื่อส่งไปยังไคลเอนต์ เมื่อได้รับเนื้อหาเว็บเซิร์ฟเวอร์จะส่งหน้า HTML ไปยังลูกค้า

อย่างไรก็ตามในปัจจุบันเซิร์ฟเวอร์ทั้งสองนี้ใช้ร่วมกัน ที่ซึ่งเว็บเซิร์ฟเวอร์รับการร้องขอจากนั้นเรียกสคริปต์เพื่อสร้างเนื้อหา HTML จากนั้นสคริปต์จะเรียกแอปพลิเคชันเซิร์ฟเวอร์ LOGIC อีกครั้ง (เช่นดึงรายละเอียดธุรกรรม) เพื่อเติมเนื้อหา HTML

ดังนั้นเซิร์ฟเวอร์ทั้งสองจึงใช้งานได้อย่างมีประสิทธิภาพ

ดังนั้น .... เราสามารถพูดได้อย่างปลอดภัยว่าทุกวันนี้ในกรณีส่วนใหญ่เว็บเซิร์ฟเวอร์ถูกใช้เป็นส่วนหนึ่งของแอพพลิเคชันเซิร์ฟเวอร์ แต่ในทางทฤษฎีมันไม่ใช่กรณี

ฉันได้อ่านหลายบทความเกี่ยวกับหัวข้อนี้และพบนี้บทความมีประโยชน์มาก

โดยทั่วไปแล้วแอปพลิเคชันเซิร์ฟเวอร์ได้รับการออกแบบและปรับใช้เพื่ออำนวยความสะดวกในกระบวนการที่ใช้งานนานกว่าซึ่งจะต้องใช้ทรัพยากรมากขึ้น

เว็บเซิร์ฟเวอร์ใช้สำหรับการปะทุระยะสั้นที่ไม่ได้ใช้ทรัพยากรอย่างมาก นี่คือส่วนใหญ่เพื่ออำนวยความสะดวกในการแสดงผลปริมาณการใช้เว็บ

ในแง่ของจาวามีมากกว่าหนึ่งอย่าง: เว็บคอนเทนเนอร์ (หรือมากกว่านั้นคือ servlet container) ในระหว่างเว็บเซิร์ฟเวอร์และแอพพลิเคชันเซิร์ฟเวอร์

เว็บคอนเทนเนอร์ในแง่ของจาวาคือแอปพลิเคชั่นเซิร์ฟเวอร์ที่โดยพื้นฐานแล้วจะใช้เฉพาะส่วนของ JSP / Servlet ของ Java EE เท่านั้นและขาดองค์ประกอบหลักหลายส่วนของ Java EE เช่น EJB รองรับ ตัวอย่างคือ Apache Tomcat

แอ็พพลิเคชันเซิร์ฟเวอร์คือเครื่อง (กระบวนการที่เรียกใช้บนเครื่องบางเครื่อง) ที่จริง "ฟัง" (ในทุกช่องทางใช้โปรโตคอลใด ๆ ) สำหรับคำขอจากไคลเอนต์สำหรับบริการใดก็ตามที่มีให้และจากนั้นทำบางสิ่งตามคำขอเหล่านั้น (อาจมีหรือไม่มีส่วนร่วมกับลูกค้า)

เว็บเซิร์ฟเวอร์กำลังดำเนินการบนเครื่องที่ "รับฟัง" โดยเฉพาะในช่อง TCP / IP โดยใช้หนึ่งใน "อินเทอร์เน็ต" โปรโตคอล (http, https, ftp, etc .. ) และทำสิ่งที่มันทำตามคำขอขาเข้าเหล่านั้น .. โดยทั่วไป (ตามที่กำหนดไว้เดิม) จะดึง / สร้างและส่งคืนหน้าเว็บ html ไปยังลูกค้าไม่ว่าจะดึงมาจากไฟล์ html แบบคงที่บนเซิร์ฟเวอร์หรือสร้างแบบไดนามิกขึ้นอยู่กับพารามิเตอร์ในคำขอของลูกค้าที่เข้ามา

เว็บเซิร์ฟเวอร์เรียกใช้โปรโตคอล HTTP เพื่อให้บริการหน้าเว็บ แอ็พพลิเคชันเซิร์ฟเวอร์สามารถ (แต่ไม่เสมอไป) บนเว็บเซิร์ฟเวอร์เพื่อรันโปรแกรมตรรกะผลลัพธ์ที่เว็บเซิร์ฟเวอร์สามารถส่งมอบได้ นั่นเป็นตัวอย่างหนึ่งของสถานการณ์สมมติของเว็บเซิร์ฟเวอร์ / แอปพลิเคชันเซิร์ฟเวอร์

ตัวอย่างที่ดีในโลกของ Microsoft คือความสัมพันธ์ของ Internet Information Server / SharePoint Server IIS เป็นเว็บเซิร์ฟเวอร์ SharePoint เป็นเซิร์ฟเวอร์แอปพลิเคชัน SharePoint ตั้งอยู่ "บนสุด" ของ IIS ดำเนินการตรรกะเฉพาะและให้บริการผลลัพธ์ผ่าน IIS

ในโลกของ Java มีสถานการณ์คล้ายกันกับ Apache และ Tomcat

ในมือแรกเว็บเซิร์ฟเวอร์ให้บริการเนื้อหาเว็บ (HTML และเนื้อหาคงที่) ผ่านโปรโตคอล HTTP ในอีกทางหนึ่งแอ็พพลิเคชันเซิร์ฟเวอร์เป็นคอนเทนเนอร์ที่คุณสามารถสร้างและเปิดเผยตรรกะทางธุรกิจและกระบวนการไปยังแอปพลิเคชันไคลเอนต์ผ่านโปรโตคอลต่างๆรวมถึง HTTP ในสถาปัตยกรรมระดับ n

แอปพลิเคชันเซิร์ฟเวอร์จึงเสนอบริการมากกว่าเว็บเซิร์ฟเวอร์ซึ่งโดยทั่วไปจะรวมถึง:

• API (เป็นกรรมสิทธิ์หรือไม่)
• การจัดการวงจรชีวิตของวัตถุ
• การจัดการของรัฐ (เซสชัน)
• การจัดการทรัพยากร (เช่นพูลการเชื่อมต่อกับฐานข้อมูล)
• โหลดบาลานซ์ล้มเหลว ...

AFAIK, ATG Dynamoเป็นหนึ่งในแอพพลิเคชั่นเซิร์ฟเวอร์ตัวแรกในช่วงปลายยุค 90 (ตามคำนิยามข้างต้น) ในต้นปี 2000 มันเป็นรัชสมัยของแอพพลิเคชันเซิร์ฟเวอร์ที่เป็นกรรมสิทธิ์เช่นColdFusion (CFML AS), BroadVision (ฝั่งเซิร์ฟเวอร์ JavaScript AS) เป็นต้น แต่ไม่มีใครรอดชีวิตมาได้ในยุคของแอพพลิเคชันเซิร์ฟเวอร์ Java

ความเข้าใจพื้นฐาน:

ในสถาปัตยกรรมเซิร์ฟเวอร์ลูกค้า

เซิร์ฟเวอร์:> ซึ่งทำหน้าที่ร้องขอ

ลูกค้า:> ใช้บริการใด

เว็บเซิร์ฟเวอร์และแอปพลิเคชันเซิร์ฟเวอร์เป็นทั้งแอปพลิเคชันซอฟต์แวร์ที่ทำหน้าที่เป็นเซิร์ฟเวอร์ให้กับลูกค้า

พวกเขาได้รับชื่อตามสถานที่ใช้งาน

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.

เช่นโดยทั่วไปแล้วเซิร์ฟเวอร์แบนทั้งหมดพร้อมใช้งานซึ่งให้บริการเฉพาะเนื้อหาบนเว็บ

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 เซิร์ฟเวอร์ Microsoft Computer Vision สำหรับ AI

เราสามารถสันนิษฐานได้ว่าเป็นเทียร์ / ลำดับชั้นในสถาปัตยกรรม 4-tier / n-tier

 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)

ความแตกต่างที่ใหญ่ที่สุดคือเว็บเซิร์ฟเวอร์จัดการคำขอ HTTP ในขณะที่แอปพลิเคชันเซิร์ฟเวอร์จะดำเนินการตามตรรกะทางธุรกิจกับโปรโตคอลจำนวนเท่าใดก็ได้

จริงๆแล้ว Apache เป็นเว็บเซิร์ฟเวอร์และ Tomcat เป็นแอพพลิเคชันเซิร์ฟเวอร์ เมื่อคำขอ HTTP มาถึงเว็บเซิร์ฟเวอร์ จากนั้นเนื้อหาแบบคงที่ส่งกลับไปยังเบราว์เซอร์โดยเว็บเซิร์ฟเวอร์ มีและตรรกะที่ต้องทำจากนั้นส่งคำขอไปยังเซิร์ฟเวอร์แอปพลิเคชัน หลังจากประมวลผลลอจิกแล้วการตอบสนองส่งไปยังเว็บเซิร์ฟเวอร์และส่งไปยังลูกค้า

จากทั้งหมดที่กล่าวมาเป็นเพียงเรื่องยุ่งยากซับซ้อน แอ็พพลิเคชันเซิร์ฟเวอร์มีเว็บเซิร์ฟเวอร์แอปพลิเคชันเซิร์ฟเวอร์มีส่วนเพิ่มเติม / ส่วนขยายเพิ่มเติมสองรายการมากกว่าเว็บเซิร์ฟเวอร์มาตรฐาน หากคุณดู 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 (เว็บคอนเทนเนอร์ / เซิร์ฟเวอร์) เป็นเพียงเครื่องมือในคลังแอพ คุณสามารถรับ JPA และเทคโนโลยีอื่น ๆ ในเว็บเซิร์ฟเวอร์ได้เช่นกันหากคุณต้องการ แต่แอปพลิเคชันเซิร์ฟเวอร์เพียงทำแพ็คเกจสิ่งเหล่านี้ทั้งหมดเพื่อความสะดวกของคุณ ในการจัดประเภทเป็นเซิร์ฟเวอร์แอปคุณจำเป็นต้องปฏิบัติตามรายการเครื่องมือที่กำหนดโดยมาตรฐานบางอย่าง

ไม่จำเป็นต้องมีเส้นแบ่งที่ชัดเจน ทุกวันนี้มีหลายโปรแกรมที่รวมองค์ประกอบต่าง ๆ ของทั้งการให้บริการการร้องขอ http (เว็บเซิร์ฟเวอร์) และการจัดการตรรกะทางธุรกิจ

จากhttps://en.wikipedia.org/wiki/Web_server

เว็บเซิร์ฟเวอร์เป็นระบบคอมพิวเตอร์ที่ร้องขอกระบวนการผ่านทาง HTTP, โปรโตคอลเครือข่ายพื้นฐานที่ใช้ในการเผยแพร่ข้อมูลเกี่ยวกับเวิลด์ไวด์เว็บ คำที่สามารถดูได้ทั้งระบบหรือเฉพาะซอฟต์แวร์ที่ยอมรับและกำกับดูแลหน้า HTTP

จากhttps://en.wikipedia.org/wiki/Application_server#Application_Server_definition

แอปพลิเคชันเซิร์ฟเวอร์ทำงานอยู่หลังเว็บเซิร์ฟเวอร์ (เช่น Apache หรือ Microsoft Internet Information Services (IIS)) และ (เกือบทุกครั้ง) หน้าฐานข้อมูล SQL (เช่น PostgreSQL, MySQL หรือ Oracle)

การใช้งานเว็บที่มีรหัสคอมพิวเตอร์ที่ทำงานบนเซิร์ฟเวอร์แอพลิเคชันและมีการเขียนในภาษา (s) เคชันเซิร์ฟเวอร์สนับสนุนและเรียกห้องสมุดรันไทม์และส่วนประกอบข้อเสนอแอพพลิเคชันเซิร์ฟเวอร์

แอ็พพลิเคชันเซิร์ฟเวอร์และเว็บเซิร์ฟเวอร์ทั้งคู่ใช้เพื่อโฮสต์เว็บ เว็บเซิร์ฟเวอร์จะจัดการกับเว็บคอนเทนเนอร์ในอีกทางหนึ่งแอปพลิเคชันเซิร์ฟเวอร์จะจัดการกับเว็บคอนเทนเนอร์เช่นเดียวกับคอนเทนเนอร์ EJB (Enterprise JavaBean) หรือคอนเทนเนอร์ COM + สำหรับ Microsoft dot Net

เว็บเซิร์ฟเวอร์ได้รับการออกแบบมาเพื่อให้บริการเนื้อหาแบบคงที่ HTTP เช่น HTML, รูปภาพและอื่น ๆ สำหรับเนื้อหาแบบไดนามิกมีปลั๊กอินเพื่อรองรับภาษาสคริปต์เช่น Perl, PHP, ASP, JSP และอื่น ๆ ซึ่ง จำกัด เฉพาะโปรโตคอล HTTP เซิร์ฟเวอร์ด้านล่างสามารถสร้างเนื้อหา HTTP แบบไดนามิก

สภาพแวดล้อมการเขียนโปรแกรมของเว็บเซิร์ฟเวอร์:

IIS: ASP (.NET)

Apache Tomcat: Servlet

Jetty: Servlet

Apache: Php, CGI

แอปพลิเคชันเซิร์ฟเวอร์สามารถทำสิ่งที่เว็บเซิร์ฟเวอร์มีความสามารถและรับฟังโดยใช้โปรโตคอลใด ๆ รวมทั้งแอพเซิร์ฟเวอร์มีส่วนประกอบและคุณสมบัติเพื่อรองรับบริการระดับแอพพลิเคชั่นเช่นการเชื่อมต่อรวมกันการรวบรวมวัตถุการสนับสนุนการทำธุรกรรม

สภาพแวดล้อมการเขียนโปรแกรมของ Application Server:

MTS: COM +

WAS: EJB

JBoss: EJB

แอปพลิเคชันเซิร์ฟเวอร์ WebLogic: EJB

แม้ว่าอาจจะมีการซ้อนทับกันระหว่างสองรายการ (บางเว็บเซิร์ฟเวอร์อาจใช้เป็นเซิร์ฟเวอร์แอปพลิเคชัน) ความแตกต่างที่ใหญ่ที่สุดคือ IMHO ในรูปแบบการประมวลผลและการจัดการเซสชัน:

ในโมเดลการประมวลผลของเว็บเซิร์ฟเวอร์โฟกัสอยู่ที่การจัดการคำร้องขอ ความคิดของ "เซสชั่น" เป็นเสมือนจริงมาก กล่าวคือ "เซสชัน" ถูกจำลองด้วยการถ่ายโอนการแสดงสถานะระหว่างไคลเอนต์และเซิร์ฟเวอร์ (ด้วยเหตุนี้ REST) ​​และ / หรือทำให้เป็นอนุกรมไปยังที่เก็บข้อมูลถาวรภายนอก (SQL Server, Memcached เป็นต้น)

ในแอปพลิเคชันเซิร์ฟเวอร์เซสชันมักจะชัดเจนกว่าและมักจะอยู่ในรูปแบบของวัตถุที่อยู่ในหน่วยความจำของแอปพลิเคชันเซิร์ฟเวอร์ตลอดช่วงเวลาของ "เซสชัน"

ขึ้นอยู่กับสถาปัตยกรรมเฉพาะ แอ็พพลิเคชันเซิร์ฟเวอร์บางตัวอาจใช้เว็บโปรโตคอลโดยพื้นฐาน (XML / RPC / SOAP ผ่าน HTTP) ดังนั้นจึงมีความแตกต่างทางเทคนิคเล็กน้อย โดยทั่วไปแล้วเว็บเซิร์ฟเวอร์จะเข้าหาผู้ใช้โดยให้บริการเนื้อหาที่หลากหลายผ่าน HTTP / HTTPS ในขณะที่แอปพลิเคชันเซิร์ฟเวอร์ไม่ได้หันหน้าเข้าหาผู้ใช้และอาจใช้โปรโตคอลที่ไม่ได้มาตรฐานหรือไม่สามารถกำหนดเส้นทางได้ แน่นอนกับ RIA / AJAX ความแตกต่างอาจถูกทำให้ขุ่นมัวมากขึ้นโดยให้บริการเฉพาะเนื้อหาที่ไม่ใช่ HTML (JSON / XML) ให้กับลูกค้าที่สูบฉีดบริการการเข้าถึงระยะไกลโดยเฉพาะ

IMO ส่วนใหญ่เกี่ยวกับการแยกข้อกังวล

จากมุมมองทางเทคนิคล้วนๆคุณสามารถทำทุกอย่าง (เนื้อหาเว็บ + ตรรกะทางธุรกิจ) ในเว็บเซิร์ฟเวอร์เดียว หากคุณทำเช่นนั้นข้อมูลจะถูกฝังอยู่ภายในร้องขอเนื้อหา HTML สิ่งที่จะได้รับผลกระทบ?

ตัวอย่างเช่นสมมติว่าคุณมี 2 แอพที่แตกต่างกันซึ่งแสดงเนื้อหา HTML ที่แตกต่างกันอย่างสิ้นเชิงในเบราว์เซอร์ หากคุณจะแยกตรรกะทางธุรกิจลงในเซิร์ฟเวอร์แอปกว่าที่คุณสามารถให้เว็บเซิร์ฟเวอร์ต่างๆค้นหาข้อมูลเดียวกันในแอปเซิร์ฟเวอร์ผ่านสคริปต์ อย่างไรก็ตามหากคุณไม่แยกตรรกะและเก็บไว้ในเว็บเซิร์ฟเวอร์เมื่อใดก็ตามที่คุณเปลี่ยนรูปแบบธุรกิจของคุณคุณจะต้องเปลี่ยนมันในทุกเว็บเซิร์ฟเวอร์เดียวที่คุณมีซึ่งจะใช้เวลามากกว่าเชื่อถือได้น้อยลงและ ข้อผิดพลาดง่าย.