EJB คืออะไร? วิวัฒนาการของ Enterprise JavaBeans

Enterprise JavaBeans (EJB) เป็นข้อกำหนดสำหรับการพัฒนาแอปพลิเคชันทางธุรกิจขนาดใหญ่แบบกระจายบนแพลตฟอร์ม Java EJB 1.0 เปิดตัวในปี 1998 EJB 3.2.3 รุ่นล่าสุดได้ถูกนำมาใช้เพื่อรวมไว้ใน Jakarta EE โดยจะเปลี่ยนชื่อเป็น Jakarta Enterprise Beans

สถาปัตยกรรม EJB

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

EJB มีสองประเภท - ถั่วเซสชันและถั่วที่ขับเคลื่อนด้วยข้อความ:

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

เมื่อใช้เพื่อให้คงอยู่ในระบบ EJB เอนทิตี bean ถูกแทนที่ด้วย Java Persistence API อ่านต่อเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับถั่วเซสชันและถั่วที่ขับเคลื่อนด้วยข้อความ

EJB กับ JavaBeans

Enterprise JavaBeans เป็นโมเดลการพัฒนาที่ใช้องค์ประกอบแรกสำหรับ Java EE EJB คล้ายกับ JavaBeans ในการเป็นส่วนประกอบ แต่นั่นคือจุดสิ้นสุดของความคล้ายคลึงกัน:

  • JavaBeanเป็นชั้น Java ที่ห่อหุ้มวัตถุหลายและสอดคล้องกับการประชุมบางอย่าง JavaBeans ส่วนใหญ่ใช้สำหรับการพัฒนาฝั่งไคลเอ็นต์
  • ถั่วองค์กร (EJB)เป็นชั้น Java ตื้นตันใจกับความสามารถเฉพาะด้านเซิร์ฟเวอร์ Enterprise bean ใช้ในแอปพลิเคชันและระบบธุรกิจขนาดใหญ่

ถั่วเซสชั่น

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

คอนเทนเนอร์ EJB จัดการวงจรชีวิตของเซสชั่นบีนซึ่งกำหนดโดยสถานะของ bean:

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

ความปลอดภัยของด้ายด้วยถั่วเซสชั่น

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

ถั่วที่ขับเคลื่อนด้วยข้อความ

Message-driven beans (MDB) ถูกเรียกผ่านข้อความ JMS (Java Message Service) JMS ทำงานเหมือนรูปแบบคำสั่งแบบกระจายโดยที่ bean ที่ขับเคลื่อนด้วยข้อความทำหน้าที่เป็นผู้ฟังคำสั่ง เมื่อข้อความมาถึงหัวข้อหรือคิวระบบจะเรียกการฟัง bean ที่ขับเคลื่อนด้วยข้อความในหัวข้อนั้น

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

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

รูปที่ 1 แสดงสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์โดยทั่วไปด้วยถั่วที่ขับเคลื่อนด้วยข้อความ

Matthew Tyson

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

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

คำอธิบายประกอบ EJB

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

@Stateless: กำหนดถั่วเซสชั่นไร้สัญชาติ

In order to designate a class as a stateless session bean, you use the javax.ejb.Stateless annotation, as shown in Listing 1.

Listing 1. @Stateless annotation example

 import javax.ejb.Stateless; @Stateless public class MyStatelessBean { public String getGreeting() { return "Hello JavaWorld."; } } 

This stateless bean contains a simple signature that takes no arguments and returns a string. Don't let simplicity fool you, though: this bean can do anything you need it to, including interacting with other beans, services, or your application's data layer.

@EJB: Consume a stateless session bean

Once you've defined a session bean, using it is so simple:

Listing 2. @EJB annotation example

 public class MyServlet extends HttpServlet { @EJB MyStatelessBean myEjb; public void doGet(HttpServletRequest request, HttpServletResponse response) { response.getWriter().write("EJB Says " + testStatelessEjb.getGreeting()); } } 

Here, we inject the stateless bean into a servlet, and then it's available for use. Notice how the bean is identified under the @EJB annotation. The "stateless" designation tells us this bean will not track the client. Because it's stateless, we also know this bean is subject to threading if it does any work outside the invoked method.

@Remote: Define a remote EJB interface

In the above examples, I assumed the EJB and EJB client were running in the same JVM. If the enterprise bean and its client are running in separate JVMs, then the EJB must define a @Remote interface. In this case, it's up to you to define and implement the interface, as shown in Listing 3.

Listing 3. @Remote annotation example

 @Remote public interface MyStatelessEjbRemote { String sayHello(String name); } 

The remote interface is sent to the client to invoke. Calls to it will then be fulfilled by the EJB's server-side implementation. The MyStatelessBean example in Listing 4 implements the remote interface.

Listing 4. Implementing a remote interface

 public class MyStatelessBean implements MyStatelessEjbRemote{ ... } 

A remote interface is implemented just like a normal class implementing an interface. As the consumer of a remote EJB, the client application must be able to access the class definition for the remote interface. You can package the class definition for the remote interface as a dependency JAR.

Local vs remote interface

While it's important to know how to implement a remote interface, in practice it's more common to use a local interface. The local interface is used by default and works whenever the EJB is invoked within the same JVM context. Using the remote interface comes into play when the application is distributed across multiple JVMs.

Stateful sessions beans and singleton beans

The process for defining and consuming stateful @Session beans and @Singleton beans is the same as what you've seen for @Stateless beans. Remember the semantics:

  • Multiple session beans can be instantiated and used for the same client.
  • A singleton bean will exist only once for the entire application.

Thread safety and scheduling with singletons

Thread safety is built in when you're working with session beans, but both stateless and singleton beans can be accessed concurrently by multiple clients. Developers are responsible for thread safety when implementing these types of beans.

Singleton beans offer some support for thread safety via the @Lock annotation. You can use the @Lock annotation on singleton bean methods to set read/write privileges for each method. The two options are @Lock(LockType.READ) or @Lock(LockType.WRITE), which is the default.

Another useful feature of singleton beans is the ability to schedule tasks in a simple way, using the @Schedule annotation. Listing 5 shows how to schedule a task daily at noon.

Listing 5. @Schedule annotation example

 @Singleton public class MySchedulerBean { @Schedule(hour = "12") void doIt() { System.out.println("Hello at Noon!"); } } 

CDI vs EJB

CDI, or Context and Dependency Injection is a newer enterprise specification that some developers have proposed could replace EJB.

At a high level, CDI offers a general-purpose component framework, while EJB stands out for its richly featured, individual components. Whereas CDI uses dependency injection to define and reference any software component, EJB components are more formally defined, with each offering a specific set of capabilities out of the box. Both specs are planned for future development as part of Jakarta EE, where the question of whether CDI should replace EJB will eventually be resolved.

Conclusion

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

เรื่องนี้ "EJB คืออะไรวิวัฒนาการของ Enterprise JavaBeans" เผยแพร่ครั้งแรกโดย JavaWorld