Java EE คืออะไรจริงๆ? [ปิด]

Java EE มี "ผ้าห่อศพลึกลับ" สำหรับนักพัฒนา Java รุ่นน้องซึ่งเป็นสิ่งที่ฉันพยายามยกระดับตัวเองมาระยะหนึ่งแล้วและประสบความสำเร็จเพียงเล็กน้อย

ความสับสนเกิดจาก:

• Java EE ดูเหมือนจะเป็นทั้งไลบรารีและแพลตฟอร์มมีหลายวิธีในการ "รับ" ไลบรารี Java EE โดยทั่วไปจะมาจากการดาวน์โหลด Java EE SDK ของ Oracle อย่างไรก็ตามไลบรารี Java EE จะไม่ทำงานหรือคอมไพล์เว้นแต่ว่าโค้ดของคุณกำลังรันหรือมีการเข้าถึงแอ็พพลิเคชันเซิร์ฟเวอร์ Java EE (เช่น JBoss, GlassFish, Tomcat เป็นต้น) ทำไม? ไลบรารีไม่สามารถทำงานนอกสภาพแวดล้อมแอ็พพลิเคชันเซิร์ฟเวอร์ได้หรือไม่? ทำไมฉันต้องมีอะไรที่ใหญ่โตเหมือน JBoss เพื่อรวบรวมโค้ดง่ายๆเพื่อส่งอีเมล

• เหตุใดไลบรารี Java EE จึงไม่เป็น "มาตรฐาน" และรวมอยู่ในการดาวน์โหลด JVM ปกติและ / หรือ SDK

• เหตุใดจึงมีข้อเสนอ Java EE มากมายในเมื่อ Java มาตรฐานมีเพียงสองรสชาติหลัก (Oracle JVM / SDK | OpenJDK JVM / JDK)

• Java EE ทำอะไรกับ Java มาตรฐานไม่ได้

• Java มาตรฐานทำอะไรกับ Java EE ไม่ได้บ้าง

• นักพัฒนาตัดสินใจว่า "ต้องการ" Java EE เมื่อใด

• เมื่อใดที่นักพัฒนาตัดสินใจว่าไม่ต้องการ Java EE

• เหตุใดเวอร์ชันไลบรารี Java EE จึงไม่ซิงค์กับไลบรารี Java มาตรฐาน (Java EE 6 เทียบกับ Java 7)

ขอบคุณที่ช่วยฉันล้างโบย!

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

จริงๆแล้วพวกเขาทำได้ ไลบรารีส่วนใหญ่สามารถใช้งานได้โดยตรงแบบสแตนด์อโลน (ใน Java SE) หรือรวมอยู่ใน. war (ซึ่งแทบจะเป็น Tomcat เสมอ) บางส่วนของ Java EE เช่น JPA มีส่วนที่ชัดเจนในข้อกำหนดเฉพาะที่บอกวิธีการทำงานและใช้ใน Java SE

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

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

ทำไมฉันต้องมีอะไรที่ใหญ่โตเหมือน JBoss เพื่อรวบรวมโค้ดง่ายๆเพื่อส่งอีเมล

คำถามนี้มีบางอย่างผิดปกติ:

1. สำหรับการคอมไพล์คุณต้องใช้เฉพาะโถ API ซึ่งมีขนาดต่ำกว่า 1MB สำหรับโปรไฟล์เว็บและมากกว่า 1MB เล็กน้อยสำหรับโปรไฟล์แบบเต็ม
2. เห็นได้ชัดว่าสำหรับการใช้งานคุณจำเป็นต้องมีการใช้งาน แต่ "จำนวนมาก" เป็นการพูดเกินจริง ตัวอย่างเช่น OpenJDK มีขนาดประมาณ 75MB และ TomEE (การใช้งานโปรไฟล์เว็บที่มีการรองรับเมล) เพียง 25MB แม้แต่ GlassFish (การใช้งานแบบ Full Profile) ก็มีขนาดเพียง 53MB
3. Mail ทำงานสมบูรณ์ดีจาก Java SE (และ Tomcat) เช่นเดียวกับการใช้แบบสแตนด์อโลนmail.jar และ activation.jar

เหตุใดไลบรารี Java EE จึงไม่เป็น "มาตรฐาน" และรวมอยู่ในการดาวน์โหลด JVM ปกติและ / หรือ SDK

Java EE เป็นหนึ่งในความพยายามครั้งแรกในการแยก JDK ขนาดใหญ่ที่มีอยู่แล้วออกเป็นชิ้นส่วนที่ง่ายต่อการจัดการและดาวน์โหลด ผู้คนบ่นกันอยู่แล้วว่าคลาสกราฟิก (AWT, Swing) และ Applets อยู่ใน JRE เมื่อสิ่งที่พวกเขาทำคือเรียกใช้คำสั่งบางอย่างบนเซิร์ฟเวอร์ที่ไม่มีหัว แล้วคุณต้องการรวมไลบรารี Java EE ทั้งหมดใน JDK มาตรฐานหรือไม่?

ด้วยการเปิดตัวการสนับสนุนแบบแยกส่วนในที่สุดเราจะมี JRE พื้นฐานขนาดเล็กพร้อมด้วยหลายสิ่งที่สามารถติดตั้งแยกต่างหากเป็นแพ็คเกจ บางทีวันหนึ่งหลาย ๆ คลาสหรือแม้แต่คลาสทั้งหมดที่ประกอบเป็น Java EE ก็จะเป็นแพ็คเกจเช่นกัน เวลาจะบอกเอง.

เหตุใดจึงมีข้อเสนอ Java EE มากมายในเมื่อ Java มาตรฐานมีเพียงสองรสชาติหลัก (Oracle JVM / SDK | OpenJDK JVM / JDK)

Java SE มีมากกว่าสองรสชาติ อย่างน้อยก็มี IBM JDK ซึ่งเป็น BEA รุ่นก่อนหน้า (JRocket ซึ่งถูกรวมเข้ากับ Oracle / Sun one เนื่องจากการซื้อกิจการ) การใช้งานโอเพนซอร์สอื่น ๆ อีกมากมายและการนำไปใช้งานสำหรับการใช้งานแบบฝัง

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

มันไม่แตกต่างจากคอมไพเลอร์ C และ C ++ ซึ่งคุณมีข้อเสนอที่แข่งขันกันมากมายและทั้งหมดก็ปฏิบัติตามมาตรฐาน C ++

เหตุใดเวอร์ชันไลบรารี Java EE จึงไม่ซิงค์กับไลบรารี Java มาตรฐาน (Java EE 6 เทียบกับ Java 7)

Java EE สร้างบน Java SE ดังนั้นจึงเดินตามหลัง เวอร์ชันจะสอดคล้องกัน Java EE 5 ต้องการ Java SE 5. Java EE 6 ต้องการ Java SE 6 เป็นต้น ส่วนใหญ่เมื่อ Java SE X เป็นปัจจุบัน Java EE X-1 จะเป็นปัจจุบัน

ต่อไปนี้เป็นคำตอบสำหรับคำถามของคุณอย่างรวดเร็ว ...

• เหตุใดไลบรารี JavaEE จึงไม่สามารถทำงานได้หากไม่มีแอ็พพลิเคชันเซิร์ฟเวอร์ บริการที่จัดหาให้โดย JavaEE (ธุรกรรมที่มีการจัดการคอนเทนเนอร์, การฉีดการพึ่งพาที่มีการจัดการคอนเทนเนอร์, บริการจับเวลา ฯลฯ ) โดยเนื้อแท้จะเกี่ยวข้องกับ Application Servers ที่เข้ากันได้กับ JavaEE (ตัวอย่างเช่น GlassFish, JBoss, WebSphere ฯลฯ ... ) ดังนั้นไลบรารี JavaEE จึงไม่มีจุดประสงค์ใด ๆ หากไม่มีคอนเทนเนอร์ดังกล่าว " ทำไมฉันต้องมีอะไรที่ใหญ่พอ ๆ กับ JBoss เพื่อรวบรวมโค้ดง่ายๆเพื่อส่งอีเมล " คุณไม่ทำ มีหลายวิธีในการส่งอีเมลโดยไม่ใช้ JavaEE ... แต่ถ้าคุณต้องการทำด้วยวิธี JavaEE คุณต้องมีคอนเทนเนอร์ JavaEE

• เหตุใดไลบรารี JavaEE จึงไม่รวมอยู่ในการดาวน์โหลด JavaSE เหตุผลเดียวกับที่ไม่รวมไลบรารีจำนวนมาก: มันจะมากเกินไป เนื่องจากคุณไม่สามารถใช้ไลบรารี JavaEE โดยไม่มีแอปพลิเคชันเซิร์ฟเวอร์ได้ทำไมต้องรวมไว้ด้วย? ควรดาวน์โหลด JavaEE หากนักพัฒนาติดตั้งแอปพลิเคชันเซิร์ฟเวอร์และตัดสินใจใช้ JavaEE

• เหตุใดจึงมีข้อเสนอ JavaEE จำนวนมาก มีข้อเสนอ JavaEE " มากมาย " จริงๆหรือไม่? ถ้าเป็นเช่นนั้นโปรดระบุรายการบางส่วน ถูกต้องมากขึ้นผมเชื่อว่ามีหลายการใช้งานของAPIs เดียวกัน

• คุณสามารถทำอะไรกับ JavaEE ที่ไม่สามารถทำได้หากไม่มี Java มาตรฐาน? มากมาย คุณไม่สามารถพึ่งพาแอ็พพลิเคชันเซิร์ฟเวอร์เพื่อจัดการธุรกรรมหรือบริบทการคงอยู่ได้หากไม่มี JavaEE คุณไม่สามารถอนุญาตให้แอ็พพลิเคชันเซิร์ฟเวอร์จัดการ EJB dependency injection โดยไม่มี JavaEE คุณไม่สามารถใช้บริการตัวจับเวลาที่มีการจัดการแอปพลิเคชันโดยไม่มี JavaEE คำตอบสำหรับคำถามนี้ควรให้คำตอบสำหรับคำถามแรกค่อนข้างชัดเจน ... บริการส่วนใหญ่ที่จัดหาโดย JavaEE ต้องใช้คอนเทนเนอร์ JavaEE

• คุณสามารถทำอะไรกับ JavaSE ที่คุณไม่สามารถทำได้ด้วย JavaEE? อืม ... ไม่รู้สิ

• นักพัฒนาตัดสินใจว่าต้องการ JavaEE เมื่อใด คำถามนี้เป็นเรื่องส่วนตัวโดยสิ้นเชิง ... แต่ถ้าคุณต้องการบริการใด ๆ ที่ JavaEE จัดหาให้คุณก็เริ่มคิดถึงมัน ถ้าคุณไม่รู้ว่า JavaEE คืออะไร ... คุณอาจไม่ต้องการมัน

• เมื่อใดที่นักพัฒนาตัดสินใจว่าไม่ต้องการ JavaEE ดูคำตอบก่อนหน้า

• เหตุใดเวอร์ชันไลบรารี JavaEE จึงไม่ซิงค์กับเวอร์ชัน JavaSE คำถามที่ดี. ฉันจะไม่แสร้งทำเป็นว่าไม่รู้จะตอบยังไง ... แต่ฉันเดาว่าคำตอบคือ "เพราะมันไม่ตรงกัน"

ในมุมมองจากมุมสูง Java EE เป็นแพลตฟอร์มซึ่งเป็นสิ่งที่เราสามารถสร้างขึ้นได้

ด้วยมุมมองทางเทคนิคที่มากขึ้นมาตรฐาน Java Enterprise Edition กำหนดชุดของ API ที่ใช้กันทั่วไปสำหรับการสร้างแอปพลิเคชันระดับองค์กร API เหล่านี้ใช้งานโดยแอ็พพลิเคชันเซิร์ฟเวอร์และใช่แอ็พพลิเคชันเซิร์ฟเวอร์ที่แตกต่างกันมีอิสระในการใช้งาน Java EE API ที่แตกต่างกัน

อย่างไรก็ตามไลบรารี java ee จะไม่ทำงานหรือคอมไพล์เว้นแต่ว่าโค้ดของคุณกำลังรันหรือมีการเข้าถึงแอ็พพลิเคชันเซิร์ฟเวอร์ Java EE (เช่น JBoss, GlassFish, Tomcat ฯลฯ )

คุณคอมไพล์กับ Java EE API ดังนั้นคุณต้องใช้ API เหล่านั้นในเวลาคอมไพล์เท่านั้น ในรันไทม์คุณจะต้องใช้ API เหล่านี้เช่นแอปพลิเคชันเซิร์ฟเวอร์

ทำไมฉันต้องมีอะไรที่ใหญ่โตเหมือน JBoss เพื่อรวบรวมโค้ดง่ายๆเพื่อส่งอีเมล

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

เหตุใดไลบรารี Java EE จึงไม่เป็น "มาตรฐาน" และรวมอยู่ในการดาวน์โหลด JVM ปกติและ / หรือ SDK

เนื่องจากเฉพาะ API เท่านั้นที่เป็นมาตรฐานไม่ใช่การนำไปใช้งาน

เหตุใดจึงมีข้อเสนอ Java EE จำนวนมาก

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

Java EE ทำอะไรกับ Java มาตรฐานไม่ได้

เนื่องจากการใช้งาน Java EE สร้างขึ้นด้วย "Java มาตรฐาน": ไม่มีอะไร อย่างไรก็ตามการใช้ประโยชน์จากไลบรารีที่มีอยู่สามารถช่วยประหยัดความพยายามได้มากหากคุณกำลังแก้ปัญหาระดับองค์กรโดยทั่วไปและการใช้ API ที่เป็นมาตรฐานสามารถป้องกันการล็อกผู้ขายได้

Java มาตรฐานทำอะไรกับ Java EE ไม่ได้บ้าง

ไม่มีอะไรเลยเนื่องจาก Java EE มี Java SE

นักพัฒนาตัดสินใจว่า "ต้องการ" Java EE เมื่อใด เมื่อใดที่นักพัฒนาตัดสินใจว่าไม่ต้องการ Java EE

โดยทั่วไป Java EE API ช่วยแก้ปัญหาทั่วไปที่เกิดขึ้นประจำในการประมวลผลระดับองค์กร หากคุณมีปัญหาดังกล่าวคุณควรใช้วิธีแก้ไขปัญหามาตรฐาน แต่ถ้าคุณมีปัญหาที่แตกต่างกันอาจมีการเรียกใช้วิธีแก้ปัญหาที่แตกต่าง ตัวอย่างเช่นหากคุณต้องการพูดคุยกับฐานข้อมูลเชิงสัมพันธ์คุณควรพิจารณาใช้ JPA แต่ถ้าคุณไม่ต้องการฐานข้อมูลเชิงสัมพันธ์ JPA จะไม่ช่วยคุณ

Java EE คืออะไร?

เริ่มจากนิยาม canonicity ที่ wiki:

Java Platform, Enterprise Edition หรือ Java EE คือแพลตฟอร์มคอมพิวเตอร์ Java ระดับองค์กรของ Oracle แพลตฟอร์มนี้มี API และสภาพแวดล้อมรันไทม์สำหรับการพัฒนาและใช้งานซอฟต์แวร์ระดับองค์กรรวมถึงบริการเครือข่ายและเว็บและแอปพลิเคชันเครือข่ายขนาดใหญ่หลายชั้นปรับขนาดได้เชื่อถือได้และปลอดภัย

ประเด็นหลักคือ Java EE เป็นแพลตฟอร์มที่ให้ API ไม่ใช่ไลบรารีที่เป็นรูปธรรม

Java EE ต้องการอะไร?

ขอบเขตหลักของ Java EE คือแอปพลิเคชันบนเครือข่ายซึ่งแตกต่างจาก Java SE ที่มุ่งเน้นไปที่การพัฒนาแอปพลิเคชันเดสก์ท็อปด้วยการสนับสนุนเครือข่ายอย่างง่าย นี่คือความแตกต่างหลักระหว่างพวกเขา ความสามารถในการปรับขนาดการส่งข้อความการทำธุรกรรมรองรับ DB สำหรับทุกแอปพลิเคชัน ... ความต้องการทั้งหมดนี้เพิ่มขึ้นตามวิวัฒนาการของเครือข่าย แน่นอนว่าโซลูชันสำเร็จรูปจำนวนมากซึ่ง Java SE มีให้นั้นมีประโยชน์สำหรับการพัฒนาเครือข่ายดังนั้น Java EE จึงขยาย Java SE

ทำไมเราต้องมีแอพพลิเคชั่นเซิร์ฟเวอร์เพื่อรันโค้ดของเรา?

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

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

อีกตัวอย่างหนึ่งที่นี่อาจเป็น JVM สำหรับ Java

เหตุใด Java EE จึงไม่มีเซิร์ฟเวอร์แอปออนบอร์ด

ยากที่จะพูดสำหรับฉัน ฉันคิดว่ามันทำเพื่อความยืดหยุ่นมากขึ้น Java EE บอกว่าพวกเขาควรทำอะไรพวกเขาตัดสินใจว่าจะทำอย่างไร

ทำไม JVM ไม่รวม Java EE

เนื่องจากมุ่งไปยังภาคการตลาดที่แตกต่างกัน Java EE มีฟังก์ชันมากมายที่ไม่จำเป็นสำหรับเดสก์ท็อปทั่วไป

เหตุใดจึงมีข้อเสนอ Java EE จำนวนมาก

เนื่องจาก Java EE อธิบายเฉพาะพฤติกรรมเท่านั้น ทุกคนสามารถนำไปใช้ได้

Java EE ทำอะไรกับ Java SE ไม่ได้บ้าง

เพื่อพิชิตอินเทอร์เน็ต มันยากมากที่จะทำกับแอพเพล็ตและซ็อกเก็ต Java SE :)

Java SE ทำอะไรกับ Java EE ไม่ได้

ดังที่กล่าวไว้ข้างต้น Java EE ขยาย Java SE ดังนั้นด้วย Java EE คุณควรจะสามารถทำทุกอย่างที่มีให้สำหรับ Java SE

นักพัฒนาตัดสินใจว่า "ต้องการ" Java EE เมื่อใด

เมื่อพวกเขาต้องการพลังของ Java EE สิ่งที่กล่าวมาทั้งหมด

เมื่อใดที่นักพัฒนาตัดสินใจว่าไม่ต้องการ Java EE

เมื่อพวกเขาเขียนโปรแกรมคอนโซลหรือเดสก์ท็อปตามปกติ

เหตุใดเวอร์ชันของ Java SE และ Java EE จึงไม่ได้ซิงค์

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

Java EE เป็นแนวคิดเกี่ยวกับคอนเทนเนอร์
คอนเทนเนอร์คือบริบทการดำเนินการซึ่งจะเรียกใช้แอปพลิเคชันของคุณและจะให้บริการชุดสุดท้ายนี้ บริการแต่ละประเภทถูกกำหนดโดยข้อกำหนดที่ชื่อว่า JSR ตัวอย่างเช่น JSR 907, JTA (java transaction Api) ซึ่งเป็นวิธีมาตรฐานในการจัดการธุรกรรมแบบกระจายกับทรัพยากรต่างๆ
โดยทั่วไปจะมีการใช้งานที่แตกต่างกันมากมายสำหรับ JSR ที่กำหนดการใช้งานที่คุณจะใช้นั้นขึ้นอยู่กับผู้ให้บริการคอนเทนเนอร์ แต่คุณไม่ได้ใส่ใจเรื่องนี้มากนักเนื่องจากคุณแน่ใจว่าพฤติกรรมนั้นเป็นไปตามสัญญาที่กำหนดไว้ล่วงหน้านั่นคือ JSR API
ดังนั้นเพื่อใช้ประโยชน์จาก Java EE คุณต้องเรียกใช้แอปพลิเคชันของคุณภายในคอนเทนเนอร์ สองตัวหลักคือ EJB และ servlet container ซึ่งมีอยู่ในแอ็พพลิเคชันเซิร์ฟเวอร์ที่ได้รับการรับรอง Java EE

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