นักพัฒนาทุกคนที่ใช้เซิร์ฟเล็ตในปัจจุบันรู้จัก JSP ซึ่งเป็นเทคโนโลยีเว็บที่คิดค้นโดย Sun Microsystems และใช้ความพยายามอย่างมากในการส่งเสริมและสร้างเทคโนโลยีเซิร์ฟเล็ต JSP แยกโค้ด HTML ออกจากเซิร์ฟเล็ต ซึ่งจะช่วยเร่งการพัฒนาเว็บแอปพลิเคชันและการบำรุงรักษาเพจให้เร็วขึ้น ในความเป็นจริง เอกสาร "Application Development Model" อย่างเป็นทางการที่เผยแพร่โดย Sun มีรายละเอียดเพิ่มเติมอีกว่า "เทคโนโลยี JSP ควรถือเป็นมาตรฐาน และเซิร์ฟเล็ตสามารถถือเป็นส่วนเสริมในกรณีส่วนใหญ่" (มาตรา 1.9, 1999/12 /15) ฉบับรับฟังความคิดเห็น)
วัตถุประสงค์ของบทความนี้คือเพื่อรับฟังการประเมินความน่าเชื่อถือของข้อความนี้ - โดยการเปรียบเทียบ JSP กับเทคโนโลยีที่ใช้เซิร์ฟเล็ตอื่น: เอ็นจิ้นเทมเพลต
ปัญหาในการใช้ Servlets โดยตรง
ในตอนแรก servlets ถูกประดิษฐ์ขึ้นและคนทั้งโลกเห็นความเหนือกว่าของมัน หน้าเว็บแบบไดนามิกที่ใช้เซิร์ฟเล็ตสามารถดำเนินการได้อย่างรวดเร็ว สามารถถ่ายโอนระหว่างเซิร์ฟเวอร์หลายเครื่องได้อย่างง่ายดาย และสามารถรวมเข้ากับฐานข้อมูลแบ็คเอนด์ได้อย่างสมบูรณ์แบบ Servlets ได้รับการยอมรับอย่างกว้างขวางว่าเป็นแพลตฟอร์มที่ต้องการสำหรับเว็บเซิร์ฟเวอร์
อย่างไรก็ตาม โค้ด html ที่ปกติใช้งานด้วยวิธีง่ายๆ ตอนนี้ต้องการให้โปรแกรมเมอร์เรียก out.println() สำหรับแต่ละบรรทัดของ HTML ซึ่งกลายเป็นปัญหาร้ายแรงในแอปพลิเคชันเซิร์ฟเล็ตจริง เนื้อหา HTML จะต้องถูกนำมาใช้ผ่านโค้ด ซึ่งเป็นงานที่น่าเบื่อและใช้เวลานานสำหรับหน้า HTML ขนาดใหญ่ นอกจากนี้ ผู้รับผิดชอบเนื้อหาเว็บยังต้องจ้างนักพัฒนาให้ทำการอัปเดตทั้งหมดอีกด้วย ด้วยเหตุนี้ ผู้คนจึงมองหาวิธีแก้ปัญหาที่ดีกว่า
เจเอสพี มาแล้ว!
JSP 0.90 ปรากฏขึ้น ในเทคนิคนี้ คุณจะฝังโค้ด Java ลงในไฟล์ HTML และเซิร์ฟเวอร์จะสร้างเซิร์ฟเล็ตสำหรับเพจโดยอัตโนมัติ JSP ถือเป็นวิธีง่ายๆ ในการเขียนเซิร์ฟเล็ต สามารถรับ HTML ทั้งหมดได้โดยตรงโดยไม่ต้องเรียก out.println() และผู้รับผิดชอบเนื้อหาของหน้าสามารถแก้ไข HTML ได้โดยตรงโดยไม่เสี่ยงต่อการทำลายโค้ด Java
อย่างไรก็ตาม การให้เพจศิลปินและนักพัฒนาทำงานในไฟล์เดียวกันนั้นไม่เหมาะ และการฝัง Java ลงใน HTML พิสูจน์แล้วว่าเป็นเรื่องที่น่าอายพอๆ กับการฝัง HTML ลงใน Java การอ่านโค้ดที่ยุ่งเหยิงยังคงเป็นเรื่องยาก
เป็นผลให้ผู้คนมีความเป็นผู้ใหญ่ในการใช้ jsp และใช้ JavaBeans มากขึ้น Beans มีโค้ดตรรกะทางธุรกิจที่ jsp ต้องการ โค้ดส่วนใหญ่ใน JSP สามารถนำออกมาและใส่ลงใน bean ได้ โดยเหลือเพียงมาร์กอัปจำนวนเล็กน้อยสำหรับการเรียก bean
ช่วงนี้คนเริ่มคิดว่าเพจ JSP ในลักษณะนี้เหมือนยอดวิวจริงๆ พวกมันกลายเป็นองค์ประกอบที่ใช้เพื่อแสดงผลลัพธ์คำขอของลูกค้า คนก็จะคิดว่าทำไมไม่ส่งคำขอตรงไปดูล่ะ? จะเกิดอะไรขึ้นหากมุมมองเป้าหมายไม่เหมาะกับคำขอ ท้ายที่สุดแล้ว คำขอจำนวนมากมีความเป็นไปได้หลายประการในการรับมุมมองผลลัพธ์ ตัวอย่างเช่น คำขอเดียวกันอาจสร้างเพจที่ประสบความสำเร็จ รายงานข้อผิดพลาดข้อยกเว้นของฐานข้อมูล หรือรายงานข้อผิดพลาดของพารามิเตอร์ที่หายไป คำขอเดียวกันอาจสร้างหน้าภาษาอังกฤษหรือหน้าภาษาสเปน ขึ้นอยู่กับสถานที่ของลูกค้า เหตุใดไคลเอนต์จึงต้องส่งคำขอโดยตรงไปยังมุมมอง เหตุใดจึงไม่ควรส่งคำขอไปยังส่วนประกอบเซิร์ฟเวอร์ทั่วไปและปล่อยให้เซิร์ฟเวอร์ตัดสินใจว่ามุมมอง JSP จะส่งกลับอะไร
สิ่งนี้ทำให้หลายคนยอมรับสิ่งที่กลายเป็นที่รู้จักในชื่อ " การออกแบบโมเดล 2" นี่คือโมเดลที่ใช้โมเดลวิวคอนโทรลเลอร์ที่กำหนดใน JSP 0.92 ในการออกแบบนี้ คำขอจะถูกส่งไปยังตัวควบคุมเซิร์ฟเล็ต ซึ่งดำเนินการตรรกะทางธุรกิจ และสร้าง "โมเดล" ข้อมูลที่คล้ายกันสำหรับการแสดงผล จากนั้นข้อมูลนี้จะถูกส่งภายในไปยัง "มุมมอง" ของ JSP เพื่อแสดงผล ทำให้เพจ JSP ดูเหมือน JavaBean ที่ฝังอยู่ทั่วไป สามารถเลือกเพจ JSP ที่เหมาะสมสำหรับการแสดงผลตามตรรกะภายในของเซิร์ฟเล็ตที่รับผิดชอบในการควบคุม ด้วยวิธีนี้ ไฟล์ JSP จะกลายเป็นมุมมองเทมเพลตที่สวยงาม นี่เป็นการพัฒนาอีกอย่างหนึ่งและได้รับการยกย่องจากนักพัฒนารายอื่นมาจนถึงทุกวันนี้
เข้าสู่ Template Engines
และใช้ Template Engine เพื่อแทนที่ JSP สำหรับวัตถุประสงค์ทั่วไป การออกแบบที่ตามมาจะง่ายขึ้น ไวยากรณ์จะง่ายขึ้น ข้อความแสดงข้อผิดพลาดจะอ่านง่ายขึ้น และเครื่องมือต่างๆ จะดีขึ้น บริษัทหลายแห่งได้สร้างเอ็นจิ้นดังกล่าวขึ้นมา โดยที่มีชื่อเสียงที่สุดน่าจะเป็น WebMacro ( http://webmacro.org จาก Semiotek) และเอ็นจิ้นของพวกเขานั้นฟรี
นักพัฒนาควรเข้าใจว่าการเลือกเอ็นจิ้นเทมเพลตเพื่อแทนที่ JSP นั้นให้ข้อได้เปรียบทางเทคนิคดังกล่าว ซึ่งเป็นข้อบกพร่องบางประการของ jsp:
ปัญหา #1: โค้ด Java มีเทมเพลตมากเกินไป
แม้ว่าจะถือว่าเป็นการออกแบบที่ไม่ดี แต่ JSP ยังคงพยายามเพิ่ม Java รหัสไปยังหน้าเว็บ นี่ค่อนข้างเหมือนกับสิ่งที่ Java เคยทำ ซึ่งเป็นการปรับเปลี่ยนเอ็นจิ้นเทมเพลต C++ อย่างง่าย และยังทำให้มันง่ายขึ้นด้วยการลบซอร์สโค้ดระดับล่างใน jsp เอ็นจิ้นเทมเพลตใช้การออกแบบที่ดีกว่า
คำถาม #2: การต้องการโค้ด Java
จำเป็นต้องเขียนโค้ด Java บางส่วนในหน้า JSP ตัวอย่างเช่น สมมติว่าเพจกำหนดบริบทรูทของเว็บแอปพลิเคชันปัจจุบันและนำไปสู่โฮมเพจ
วิธีที่ดีที่สุดคือใช้โค้ด Java ต่อไปนี้ใน JSP:
＜a href="＜%= request.getContextPath() %><หน้าแรก
คุณสามารถลองหลีกเลี่ยงโค้ด Java และใช้แท็ก
property="contextPath"/>/index.html">
การใช้เครื่องมือเทมเพลต ทำให้ไม่มีโค้ด Java และไวยากรณ์ที่น่าเกลียด นี่คือวิธีการเขียนใน WebMacro ภายใต้ข้อกำหนดเดียวกัน:
＜a href="$ Request.ContextPath ;/index.html">หน้าแรก
ใน WebMacro นั้น ContextPath จะถูกใช้เป็นแอตทริบิวต์ของตัวแปร $Request โดยใช้ไวยากรณ์ที่คล้ายกับ Perl ส่วนกลไกเทมเพลตอื่นๆ ใช้ไวยากรณ์ประเภทอื่น
ดูตัวอย่างอื่น สมมติว่า "มุมมอง" ขั้นสูงจำเป็นต้องตั้งค่าคุกกี้เพื่อบันทึกการกำหนดค่าสีเริ่มต้นของผู้ใช้ - ดูเหมือนว่างานนี้มีแนวโน้มที่จะเสร็จสมบูรณ์โดยมุมมองแทนที่จะเป็นตัวควบคุมเซิร์ฟเล็ต จะต้องมีโค้ด Java ดังกล่าวใน JSP:
<% Cookie c = new Cookie("colorscheme", "blue"); response.addCookie(c); %>
ไม่มีโค้ด Java ใน WebMacro:
#set $Cookie.colorscheme = "สีน้ำเงิน"
เป็นอิออนสุดท้าย หากคุณต้องการดึงการกำหนดค่าสีในคุกกี้ดั้งเดิม สำหรับ JSP เราสามารถนึกถึงคลาสเครื่องมือที่เกี่ยวข้องเพื่อช่วยได้ เพราะมันจะกลายเป็นเรื่องไร้สาระและยากที่จะทำสิ่งระดับต่ำโดยตรงกับ getCookies() ใน JSP:
<% String colourscheme = ServletUtils.getCookie(request, "colorscheme"); %>
ไม่จำเป็นต้องมีคลาสเครื่องมือใน WebMacro โดยปกติแล้ว: $Cookie.colorscheme.Value สำหรับศิลปินกราฟิกที่เขียน JSP ไวยากรณ์ใดเรียนรู้ได้ง่ายกว่า
JSP 1.1 เปิดตัวแท็กแบบกำหนดเองที่อนุญาตให้แท็กที่มีลักษณะคล้าย HTML เรียกใช้โค้ด Java ในพื้นหลังในหน้า JSP ซึ่งจะมีค่าบางอย่าง แต่เฉพาะในกรณีที่มีไลบรารีแท็กมาตรฐานที่เป็นที่รู้จักอย่างกว้างขวาง มีคุณสมบัติครบถ้วน และใช้งานได้ฟรี ขณะนี้ไม่มีไลบรารีแท็กดังกล่าว
ปัญหา #3: งานง่ายๆ ยังคงน่าเบื่อ
แม้แต่งานง่ายๆ เช่น การรวมส่วนหัวและส่วนท้าย ยังคงเป็นเรื่องยากมากใน JSP สมมติว่ามีเทมเพลต "ส่วนหัว" และ "ส่วนท้าย" ที่จะรวมไว้ในทุกหน้า และแต่ละเทมเพลตควรมีชื่อหน้าปัจจุบันในเนื้อหา
วิธีที่ดีที่สุดใน JSP คือ:
＜% ชื่อสตริง = "ชื่อหน้า"; %><
＜%@ รวม file="/header.jsp" %><
...เนื้อหาเพจของคุณ...
＜%@ include file="/footer.jsp" %＞
ผู้ออกแบบเพจควรจำไว้ว่าอย่าละเครื่องหมายอัฒภาคในบรรทัดแรก และกำหนดชื่อเรื่องเป็นสตริง นอกจากนี้ /header.jsp และ /footer.jsp ต้องอยู่ในไดเร็กทอรีรากและต้องเป็นไฟล์ที่สามารถเข้าถึงได้โดยสมบูรณ์
การรวมส่วนหัวและส่วนท้ายใน WebMacro นั้นค่อนข้างง่าย:
#set $title = "The Page Title"
#แยกวิเคราะห์ "header.wm"
เนื้อหาของคุณที่นี่
#parse "footer.wm"
ไม่มีเครื่องหมายอัฒภาคหรือคำจำกัดความของชื่อเรื่องให้นักออกแบบจดจำ และสามารถวางไฟล์ .wm ในพาธการค้นหาที่ปรับแต่งได้
ปัญหา #4: ลูปที่หนามาก
การวนซ้ำใน JSP เป็นเรื่องยาก ในที่นี้ JSP ใช้เพื่อพิมพ์ชื่อของอ็อบเจ็กต์ ISP แต่ละรายการซ้ำๆ
-
การแจงนับ e = list.elements();
ในขณะที่ (e.hasMoreElements()) {
out.print("ชื่อถัดไปคือ");
out.println(((ISP)e.nextElement()).getName());
out.print("
");
-
%>
บางทีอาจมีแท็กที่ผู้ใช้กำหนดเพื่อทำการวนซ้ำเหล่านี้ในบางครั้ง เช่นเดียวกับ "ถ้า" หน้า JSP อาจดูเหมือนโค้ด Java แปลกๆ และในเวลาเดียวกัน webmacro loop ก็สวยงาม:
#foreach $isp ใน $isps {
ชื่อถัดไปคือ $isp.Name
}
หากจำเป็น คุณสามารถแทนที่คำสั่ง #foreach ได้อย่างง่ายดายด้วยคำสั่ง #foreach-backwards ที่กำหนดเอง
หากคุณใช้ jsp มันอาจเป็นเช่นนี้: (นี่คือแท็ก
ชื่อต่อไปคือ ＜jsp:getProperty name="isp" property="name"/> ＜br><
นักออกแบบจะเลือกแบบแรกโดยธรรมชาติ
ปัญหา #5: ข้อความแสดงข้อผิดพลาดที่ไร้ประโยชน์
JSP มักจะมีข้อความแสดงข้อผิดพลาดที่น่าประหลาดใจ นี่เป็นเพราะว่าเพจถูกแปลงเป็นเซิร์ฟเล็ตก่อนแล้วจึงคอมไพล์ เครื่องมือ JSP ที่ดีสามารถเพิ่มโอกาสในการค้นหาตำแหน่งของข้อผิดพลาดได้ค่อนข้างมาก แต่แม้แต่เครื่องมือที่ดีที่สุดก็ไม่สามารถทำให้ข้อความแสดงข้อผิดพลาดทั้งหมดสามารถอ่านได้ง่าย เนื่องจากกระบวนการแปลง ข้อผิดพลาดบางอย่างอาจเป็นไปไม่ได้ที่เครื่องมือจะระบุได้
ตัวอย่างเช่น สมมติว่าเพจ JSP จำเป็นต้องสร้างหัวเรื่องที่ใช้ร่วมกันกับทุกเพจ โค้ดต่อไปนี้ไม่มีอะไรผิดปกติ:
＜% static String title = "Global title"; %>
แต่ Tomcat จะให้ข้อความแสดงข้อผิดพลาดต่อไปนี้:
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: คำสั่งที่คาดหวัง
จำนวน int แบบคงที่ = 0;
↑
ข้อมูลนี้คิดว่าสคริปต์ด้านบนถูกใส่ไว้ในเมธอด _jspService() และไม่อนุญาตให้ใส่ตัวแปรสแตติกลงในเมธอด ไวยากรณ์ควรเป็น <%! %> เป็นเรื่องยากสำหรับผู้ออกแบบเพจเพื่ออ่านข้อความแสดงข้อผิดพลาดเหล่านี้ แม้แต่แพลตฟอร์มที่ดีที่สุดก็ยังขาดในเรื่องนี้ แม้แต่การย้ายโค้ด Java ทั้งหมดออกจากเพจก็ไม่สามารถแก้ปัญหาได้ นอกจากนี้ เกิดอะไรขึ้นกับนิพจน์ต่อไปนี้
<% จำนวน %>
แมวตัวผู้ให้:
work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: ไม่พบจำนวนคลาสใน
ประกาศประเภท
นับ
-
work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: การประกาศไม่ถูกต้อง
out.write("rn");
↑
กล่าวอีกนัยหนึ่ง มันเป็นเพียงเครื่องหมายที่หายไป มันควรจะเป็น <%= นับ %>
เนื่องจากกลไกเทมเพลตสามารถสร้างขึ้นได้โดยตรงจากไฟล์เทมเพลตโดยไม่ต้องแปลเป็นโค้ดมากนัก การรายงานข้อผิดพลาดที่เหมาะสมจึงเป็นเรื่องง่ายมาก ในการเปรียบเทียบ เมื่อพิมพ์คำสั่งภาษา C ลงในบรรทัดคำสั่งของ Unix เชลล์ คุณไม่ต้องการให้เชลล์สร้างโปรแกรม C เพื่อรันคำสั่ง แต่คุณเพียงแค่ต้องใช้เชลล์เพื่อตีความคำสั่งและดำเนินการเท่านั้น และรายงานข้อผิดพลาดโดยตรง
ปัญหา #6: ความต้องการคอมไพเลอร์
JSP จำเป็นต้องมีคอมไพเลอร์ที่อยู่ในเว็บเซิร์ฟเวอร์ สิ่งนี้กลายเป็นปัญหาเนื่องจาก Sun ปฏิเสธที่จะละทิ้งไลบรารี tools.jar ที่มีคอมไพเลอร์ javac เว็บเซิร์ฟเวอร์สามารถรวมคอมไพเลอร์ของบริษัทอื่น เช่น Jikes ของ IBM แต่คอมไพเลอร์ดังกล่าวไม่ได้ทำงานได้อย่างราบรื่นบนทุกแพลตฟอร์ม (เขียนด้วยภาษา C++) และไม่เอื้อต่อการสร้างเว็บเซิร์ฟเวอร์ Java ล้วนๆ JSP มีตัวเลือกการคอมไพล์ล่วงหน้าที่ช่วยได้ แม้ว่ามันจะไม่สมบูรณ์แบบก็ตาม
ปัญหา #7: การสิ้นเปลืองพื้นที่
JSP ใช้หน่วยความจำเพิ่มเติมและพื้นที่ฮาร์ดดิสก์ สำหรับไฟล์ JSP ขนาด 30K ทุกไฟล์บนเซิร์ฟเวอร์ จะต้องสร้างไฟล์คลาสที่สอดคล้องกันที่มีขนาดใหญ่กว่า 30K เพิ่มพื้นที่ฮาร์ดไดรฟ์เป็นสองเท่าอย่างมีประสิทธิภาพ เมื่อพิจารณาว่าไฟล์ JSP สามารถรวมไฟล์ข้อมูลขนาดใหญ่ได้อย่างง่ายดายผ่าน <%@ include> ได้ตลอดเวลา ข้อกังวลนี้มีความสำคัญในทางปฏิบัติมาก ในเวลาเดียวกัน ข้อมูลไฟล์คลาสของแต่ละ JSP จะต้องโหลดลงในหน่วยความจำของเซิร์ฟเวอร์ ซึ่งหมายความว่าหน่วยความจำของเซิร์ฟเวอร์จะต้องบันทึกแผนผังเอกสาร JSP ทั้งหมดตลอดไป JVM บางตัวมีความสามารถในการย้ายข้อมูลไฟล์คลาสจากหน่วยความจำ อย่างไรก็ตาม โปรแกรมเมอร์มักจะไม่สามารถควบคุมกฎสำหรับการประกาศซ้ำได้ และการประกาศซ้ำอาจไม่มีประสิทธิภาพมากนักสำหรับไซต์ขนาดใหญ่ สำหรับเอ็นจิ้นเทมเพลต พื้นที่จะถูกประหยัดเนื่องจากไม่มีการสร้างไฟล์ที่สอง เอ็นจิ้นเทมเพลตยังช่วยให้โปรแกรมเมอร์สามารถควบคุมวิธีการแคชเทมเพลตในหน่วยความจำได้อย่างสมบูรณ์
นอกจากนี้ยังมีปัญหาบางประการในการใช้กลไกจัดการเทมเพลต:
ปัญหาเทมเพลต #1: ไม่ได้กำหนดไว้อย่างเคร่งครัด
วิธีการทำงานของกลไกจัดการเทมเพลตไม่ได้กำหนดไว้อย่างเคร่งครัด อย่างไรก็ตาม เมื่อเปรียบเทียบกับ JSP แล้ว สิ่งนี้ไม่สำคัญมากนัก ต่างจาก JSP ตรงที่เทมเพลทเอ็นจิ้นไม่มีข้อกำหนดพิเศษสำหรับเว็บเซิร์ฟเวอร์ - เซิร์ฟเวอร์ใดๆ ที่รองรับเซิร์ฟเล็ตสามารถรองรับเอ็นจิ้นเทมเพลตได้ (รวมถึงเซิร์ฟเวอร์ API 2.0 เช่น Apache/ JServ ด้วย) ไม่สนับสนุน JSP อย่างเต็มที่)! หากการแข่งขันที่ดีเพื่อการออกแบบเครื่องมือเทมเพลตที่ดีที่สุดอาจทำให้เกิดนวัตกรรมที่น่าทึ่ง โดยเฉพาะอย่างยิ่งกับการส่งเสริมโอเพ่นซอร์ส (อนุญาตให้แนวคิดต่างๆ ผลักดันและส่งเสริมซึ่งกันและกัน) WebMacro ของวันนี้ก็จะเหมือนกับ Perl ไม่ได้กำหนดไว้อย่างเคร่งครัด แต่การส่งเสริมองค์กรโอเพ่นซอร์สถือเป็นมาตรฐาน
ปัญหาเทมเพลต #2: ไม่รู้จัก
เอ็นจิ้นเทมเพลตไม่เป็นที่รู้จักอย่างกว้างขวาง JSP ครอบครองตลาดการค้าขนาดใหญ่และหยั่งรากลึกในหัวใจของผู้คน การใช้เอ็นจิ้นเทมเพลต g สามารถเป็นเทคโนโลยีทางเลือกที่ไม่เข้าใจเท่านั้น
ปัญหาเทมเพลต #3: ยังไม่ได้ปรับใช้
เอ็นจิ้นเทมเพลตยังไม่มีการกำหนดค่าสูง ไม่มีการทดสอบและการเปรียบเทียบประสิทธิภาพระหว่างเครื่องมือเทมเพลตและ JSP ตามทฤษฎีแล้ว การใช้งานกลไกเทมเพลตที่ปรับใช้อย่างดีควรตรงกับ JSP ที่ถูกปรับใช้อย่างดี อย่างไรก็ตาม เมื่อพิจารณาว่าบุคคลที่สามได้ผลักดันอย่างลึกซึ้งสำหรับ jsp มีเพียง jsp เท่านั้นที่ถูกปรับใช้อย่างดี
บทบาทของ JSP
แน่นอนว่า JSP จะมีตำแหน่งในอนาคตอย่างแน่นอน ความคล้ายคลึงกันระหว่าง JSP และ ASP สามารถเห็นได้จากชื่อ แต่จะแตกต่างกันเพียงตัวอักษรเดียวเท่านั้น ดังนั้น หากผู้ที่ใช้ ASP จะเปลี่ยนไปใช้ Java สภาพแวดล้อม JSP ที่คล้ายกันมากจะมีบทบาทอย่างมากในการส่งเสริมสิ่งนี้ บทบาทของการรักษาความสัมพันธ์ที่สอดคล้องกันนี้กับ ASP ก็ควรเป็นข้อพิจารณาสำคัญสำหรับนักออกแบบที่เปิดตัว JSP
อย่างไรก็ตาม ประเด็นก็คือ มีความแตกต่างอย่างมากระหว่างสิ่งที่เป็นประโยชน์ต่อพนักงานที่ย้ายเข้าสู่สภาพแวดล้อมใหม่ และไม่ว่าจะเป็นวิธีที่ดีที่สุดในการใช้สภาพแวดล้อมนั้นหรือไม่
JSP แสดงให้เห็นมากขึ้นเรื่อยๆ ว่ากำลังกลายเป็นหนึ่งในเทคโนโลยี Java ที่สำคัญที่สุด และช่วยให้ผู้คนออกจากโลกของ ASP ได้ ดังนั้น Sun จะสนับสนุนกรณีธุรกิจที่แข็งแกร่งนี้ และผู้สนับสนุนเทคโนโลยีที่เกี่ยวข้องกับ Java จะให้การสนับสนุนมากขึ้นเช่นกัน
อย่างไรก็ตาม นี่ไม่ใช่ทางออกที่ดีที่สุดสำหรับแพลตฟอร์ม Java สิ่งนี้จะทำให้โซลูชัน Java ดูเหมือนเป็นโซลูชันที่ไม่มี Java