Apa itu EJB? Evolusi Enterprise JavaBeans

Enterprise JavaBeans (EJB) adalah spesifikasi untuk mengembangkan aplikasi bisnis terdistribusi berskala besar pada platform Java. EJB 1.0 dirilis pada tahun 1998. Rilis terbaru, EJB 3.2.3, telah diadopsi untuk dimasukkan dalam EE Jakarta, di mana ia akan berganti nama menjadi Jakarta Enterprise Beans.

Arsitektur EJB

Arsitektur EJB terdiri dari tiga komponen utama: kacang perusahaan (EJB), kontainer EJB, dan server aplikasi Java. EJB dijalankan di dalam container EJB, dan container EJB dijalankan di dalam server aplikasi Java.

Ada dua jenis EJB - kacang sesi dan kacang berbasis pesan:

  • Kacang sesi dipanggil oleh klien dan membuat fungsionalitas perusahaan seperti transaksi dan manajemen sumber daya tersedia untuk klien secara terprogram.
  • Kacang berbasis pesan juga merangkum dan memberikan fungsionalitas perusahaan, tetapi mereka asynchronous dan event driven. Kacang berbasis pesan mendengarkan dan menanggapi peristiwa, dan tidak dapat dipanggil oleh klien.

Setelah digunakan untuk menyediakan persistensi dalam sistem EJB, biji entitas telah digantikan oleh Java Persistence API. Teruslah membaca untuk mempelajari lebih lanjut tentang kacang sesi dan kacang berbasis pesan.

EJB vs JavaBeans

Enterprise JavaBeans adalah model pengembangan berbasis komponen pertama untuk Java EE. EJB mirip dengan JavaBeans karena berbasis komponen, tetapi di situlah kesamaan berakhir:

  • Sebuah JavaBean adalah kelas Java yang merangkum beberapa objek dan sesuai dengan konvensi tertentu. JavaBeans digunakan terutama untuk pengembangan sisi klien.
  • Sebuah perusahaan kacang (EJB) adalah kelas Java dijiwai dengan kemampuan server-side tertentu. Biji perusahaan digunakan dalam aplikasi dan sistem bisnis skala besar.

Kacang sesi

Sebuah kacang sesi adalah jenis generik sebagian besar perusahaan kacang, mewakili sepotong fungsionalitas bisnis yang dapat dipanggil oleh klien. Klien dalam hal ini bisa jadi kelas lain di JVM lokal atau panggilan jarak jauh.

Kontainer EJB mengelola siklus hidup kacang sesi, yang ditentukan oleh status kacang:

  • Kacang sesi tanpa status mirip dengan cakupan permintaan di Java Servlet API. Kacang sesi tanpa status berisi sejumlah fungsionalitas yang dapat dipanggil tetapi sebaliknya tanpa status.
  • Kacang sesi berstatus diasosiasikan dengan satu klien saja, dan dilampirkan ke sesi klien yang sedang berlangsung. Kacang sesi stateful berfungsi mirip dengan cakupan sesi di Servlet API.
  • Kacang tunggal mirip dengan cakupan aplikasi di Servlet API. Kacang sesi tunggal hanya ada sekali untuk setiap klien.

Keamanan benang dengan kacang sesi

Kacang sesi berstatus hanya dapat diakses oleh satu klien pada satu waktu, jadi keamanan utas dijamin ketika Anda bekerja dengan kacang jenis ini. Kacang sesi tanpa status dan kacang tunggal lebih fleksibel, memungkinkan koneksi serentak, yang harus dikelola oleh pengembang. Anda bertanggung jawab atas keamanan benang saat menangani jenis kacang ini.

Kacang berdasarkan pesan

Kacang berbasis pesan (MDB) dipanggil melalui pesan JMS (Java Message Service). JMS bekerja seperti pola Perintah terdistribusi, di mana kacang berbasis pesan bertindak sebagai pendengar untuk perintah tersebut. Ketika sebuah pesan tiba di topik atau antrian, kacang berbasis pesan yang mendengarkan pada topik itu dipanggil.

Kacang berbasis pesan tidak umum digunakan sebagai kacang sesi, tetapi mereka kuat. Menjadi asynchronous dan event-driven, mereka sangat berguna untuk pekerjaan yang berjalan lama di mana penting untuk menghemat resource.

Arsitektur paling sederhana akan terdiri dari aplikasi EJB dan container serta servernya, yang berkoordinasi dengan layanan pesan yang memproses MDB. Dalam produksi, arsitektur Anda kemungkinan akan menyertakan komponen ketiga yang didedikasikan untuk mengonsumsi biji. Dalam pengembangan, semua komponen ini dapat berjalan di mesin lokal yang sama.

Gambar 1 menunjukkan arsitektur berbasis peristiwa yang khas dengan kacang berbasis pesan.

Matthew Tyson

Bekerja dengan kacang berbasis pesan lebih melibatkan daripada menggunakan kacang sesi. Dalam lingkungan yang digerakkan oleh peristiwa, Anda biasanya memerlukan broker pesan seperti ActiveMQ.

Sementara kacang sesi lebih sederhana, dan dengan demikian lebih umum digunakan di EJB, arsitektur yang digerakkan oleh peristiwa telah menjadi populer, terutama dengan ledakan layanan mikro. 

Anotasi EJB

Mendefinisikan dan mengonsumsi kacang perusahaan adalah titik penting bagi banyak pengembang hingga EJB 3.0, yang memperkenalkan anotasi ke spesifikasi EJB. Anotasi membuatnya sangat mudah untuk mengonfigurasi kacang perusahaan untuk berbagai fungsi yang ditemukan di Java EE. Teruskan membaca untuk memulai dengan anotasi EJB.

@Stateless: Tentukan kacang sesi stateless

Untuk menunjuk kelas sebagai kacang sesi stateless, Anda menggunakan javax.ejb.Statelesspenjelasan, seperti yang ditunjukkan pada Kode 1.

Kode 1. Contoh anotasi @Stateless

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

Kacang tanpa status ini berisi tanda tangan sederhana yang tidak membutuhkan argumen dan mengembalikan string. Namun, jangan biarkan kesederhanaan membodohi Anda: kacang ini dapat melakukan apa pun yang Anda perlukan, termasuk berinteraksi dengan kacang lain, layanan, atau lapisan data aplikasi Anda.

@EJB: Konsumsi kacang sesi tanpa kewarganegaraan

Setelah Anda mendefinisikan kacang sesi, menggunakannya sangat sederhana:

Kode 2. Contoh penjelasan @EJB

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

Di sini, kami menyuntikkan kacang tanpa kewarganegaraan ke dalam servlet, dan kemudian tersedia untuk digunakan. Perhatikan bagaimana kacang diidentifikasi di bawah @EJBanotasi. Penunjukan "stateless" memberi tahu kita bahwa kacang ini tidak akan melacak klien. Karena tidak memiliki kewarganegaraan, kami juga tahu bahwa kacang ini tunduk pada penguliran jika bekerja di luar metode yang dipanggil.

@Remote: Tentukan antarmuka EJB jarak jauh

Dalam contoh di atas, saya berasumsi bahwa klien EJB dan EJB berjalan di JVM yang sama. Jika kacang perusahaan dan kliennya berjalan di JVM terpisah, maka EJB harus menentukan @Remoteantarmuka. Dalam hal ini, terserah Anda untuk menentukan dan mengimplementasikan antarmuka, seperti yang ditunjukkan pada Daftar 3.

Kode 3. Contoh anotasi @Remote

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

Antarmuka jarak jauh dikirim ke klien untuk dipanggil. Panggilan ke sana kemudian akan dipenuhi oleh implementasi sisi server EJB. The MyStatelessBeancontoh pada Listing 4 mengimplementasikan remote interface.

Kode 4. Menerapkan antarmuka jarak jauh

 public class MyStatelessBean implements MyStatelessEjbRemote{ ... } 

Antarmuka jarak jauh diimplementasikan seperti kelas normal yang mengimplementasikan antarmuka. Sebagai pengguna EJB jarak jauh, aplikasi klien harus dapat mengakses definisi kelas untuk antarmuka jarak jauh. Anda dapat mengemas definisi kelas untuk antarmuka jarak jauh sebagai JAR ketergantungan.

Antarmuka lokal vs jarak jauh

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 adalah spesifikasi pertama yang menawarkan cara mudah merangkum dan menggunakan kembali logika bisnis dalam aplikasi Java perusahaan. Jauh dari raksasa kelas berat di masa lalu, EJB hari ini adalah kerangka kerja berbasis anotasi yang ramping yang memungkinkan Anda mengakses berbagai fungsi perusahaan, langsung dari kotak. Pertimbangkan EJB saat Anda diminta untuk segera meningkatkan aplikasi bisnis yang terdistribusi dan dapat diskalakan. Anda mungkin akan terkejut.

Artikel ini, "Apa itu EJB? Evolusi Enterprise JavaBeans" awalnya diterbitkan oleh JavaWorld.