Dasar-dasar EJB dan kacang sesi

Java Enterprise Edition (Java EE) memiliki fasilitas canggih yang didedikasikan untuk mengekspresikan logika bisnis aplikasi dan untuk mengakses database menggunakan konsep mirip JavaBeans. Fasilitas itu adalah Enterprise JavaBeans , yang disingkat EJB.

Pada artikel ini, kita akan mulai menjelajahi dunia EJB, yang merupakan kapabilitas yang sangat penting dari platform Java EE. EJB menyediakan infrastruktur untuk mengembangkan dan menyebarkan aplikasi perusahaan yang sangat penting. Pertama-tama kita akan melihat beberapa dasar EJB, dan kemudian fokus pada satu jenis EJB: kacang sesi.

Dalam artikel ini, Anda akan mempelajari hal-hal berikut:

  • Manfaat menggunakan EJB
  • Tiga jenis EJB: sesi, entitas, dan kacang berbasis pesan
  • Riasan kacang sesi
  • Bagaimana mengembangkan kacang sesi
  • Perbedaan antara kacang sesi stateful dan stateless

Memahami EJB

Arsitektur aplikasi sering kali terdiri dari beberapa tingkatan yang masing-masing memiliki tanggung jawabnya sendiri. Salah satu arsitektur yang terdiri dari tiga tingkatan diilustrasikan dalam diagram Unified Modeling Language (UML) yang ditunjukkan pada Gambar 1.

Dua elemen di sisi kiri diagram pada Gambar 1 disebut komponen dalam notasi UML. Komponen mewakili modul perangkat lunak. Diagram menggambarkan apa yang disebut arsitektur bertingkat , atau berlapis . Arsitektur bertingkat memiliki banyak keuntungan, tidak sedikit di antaranya adalah kemampuan untuk mengubah salah satu lapisan tanpa mempengaruhi semua lapisan lainnya. Ini berbeda dengan arsitektur single-tier , di mana semua aspek desain program hidup berdampingan dalam satu elemen. Perubahan atau tindakan yang memengaruhi satu bagian dari elemen tingkat tunggal juga berpotensi memengaruhi anggota lain dari elemen itu.

Pertimbangkan arsitektur tiga lapisan yang ditunjukkan pada Gambar 1, yang terdiri dari antarmuka pengguna, logika aplikasi, dan lapisan database. Jika lapisan database diubah, hanya lapisan logika aplikasi yang terpengaruh. Lapisan logika aplikasi melindungi lapisan antarmuka pengguna dari perubahan pada lapisan database. Ini memfasilitasi pemeliharaan aplikasi yang berkelanjutan dan juga meningkatkan kemampuan aplikasi untuk memasukkan teknologi baru ke dalam lapisannya.

Lapisan ini memberikan model yang sangat baik tentang bagaimana EJB cocok dengan desain program Anda secara keseluruhan. EJB menyediakan lapisan logika aplikasi dan abstraksi mirip JavaBeans dari lapisan database. Lapisan logika aplikasi juga dikenal sebagai tingkat menengah .

Catatan
JavaBeans dan Enterprise JavaBeans adalah dua hal yang berbeda, tetapi karena kesamaannya (dan untuk alasan pemasaran), keduanya memiliki nama yang sama. JavaBeans adalah komponen bawaan Java yang dapat digunakan di tingkat mana pun dalam aplikasi. Mereka sering dianggap dalam hubungannya dengan servlet dan sebagai komponen GUI. Enterprise JavaBeans adalah komponen khusus berbasis server, yang digunakan untuk membangun logika bisnis dan fungsionalitas akses data dari suatu aplikasi.

Mengapa menggunakan EJB?

Belum lama berselang, ketika pengembang sistem ingin membuat aplikasi perusahaan, mereka sering kali memulai dengan "menggulirkan sendiri" (atau membeli server aplikasi berpemilik) untuk mendukung fungsionalitas lapisan logika aplikasi. Beberapa fitur server aplikasi meliputi yang berikut ini:

  • Komunikasi klien: Klien, yang seringkali berupa antarmuka pengguna, harus dapat memanggil metode objek pada server aplikasi melalui protokol yang disepakati.
  • Manajemen status sesi: Anda akan mengingat diskusi kami tentang topik ini dalam konteks JSP (Halaman JavaServer) dan pengembangan servlet di Bab 6.
  • Manajemen transaksi: Beberapa operasi, misalnya, saat memperbarui data, harus terjadi sebagai satu unit kerja. Jika satu pembaruan gagal, semuanya harus gagal.
  • Manajemen koneksi database: Server aplikasi harus terhubung ke database, sering kali menggunakan kumpulan koneksi database untuk mengoptimalkan sumber daya.
  • Otentikasi pengguna dan otorisasi berbasis peran: Pengguna aplikasi harus sering masuk untuk tujuan keamanan. Fungsionalitas aplikasi yang mengizinkan akses pengguna sering kali didasarkan pada peran yang terkait dengan ID pengguna.
  • Perpesanan asinkron: Aplikasi sering kali perlu berkomunikasi dengan sistem lain secara asinkron; yaitu, tanpa menunggu sistem lain merespons. Ini membutuhkan sistem pesan yang mendasari yang memberikan jaminan pengiriman pesan asinkron ini.
  • Administrasi server aplikasi: Server aplikasi harus dikelola. Misalnya, mereka perlu dipantau dan disetel.

Spesifikasi EJB

Spesifikasi EJB mendefinisikan arsitektur umum, yang telah mendorong beberapa vendor untuk membangun server aplikasi yang sesuai dengan spesifikasi ini. Sekarang pengembang bisa mendapatkan server aplikasi off-the-shelf yang sesuai dengan standar umum, mendapatkan keuntungan dari persaingan (di area seperti harga, fitur, dan kinerja) di antara vendor tersebut.

Beberapa server aplikasi EJB komersial yang lebih umum adalah WebLogic (BEA), Java Enterprise System (Sun), wadah OC4J untuk Oracle Database 10g, dan WebSphere (IBM). Ada juga beberapa entri open source yang sangat bagus di pasar ini seperti JBoss dan JOnAS. Sun juga menyediakan implementasi referensi sumber terbuka (Java EE SDK) dari spesifikasi Java EE 5 dan EJB 3.0 yang dapat digunakan pengembang untuk mengembangkan dan menguji aplikasi agar sesuai dengan spesifikasi tersebut. (Implementasi referensi tidak boleh, bagaimanapun, digunakan untuk menyebarkan sistem produksi.) Saat ini dalam pengembangan, implementasi referensi diberi nama kode "Glassfish." Platform ini menyediakan platform pengujian EJB 3.0 dasar; detail lebih lanjut dapat ditemukan di Website dan di forum diskusi terkait. Server aplikasi ini,sehubungan dengan kemampuan yang ditentukan dalam spesifikasi EJB, mendukung semua fitur yang tercantum di sini dan banyak lagi.

Spesifikasi EJB dibuat oleh anggota komunitas pengembangan yang berpengalaman; badan seperti itu disebut kelompok ahli. Dalam kelompok ahli spesifikasi EJB adalah anggota dari organisasi seperti JBoss, Oracle, dan Google. Berkat mereka, kami sekarang memiliki cara standar berbasis spesifikasi untuk mengembangkan dan menerapkan sistem kelas perusahaan. Kami mendekati impian Java untuk mengembangkan aplikasi yang dapat berjalan di platform vendor apa pun apa adanya. Ini berbeda dengan cara khusus vendor yang biasa kami kembangkan, di mana setiap server memiliki caranya sendiri dalam melakukan sesuatu, dan di mana pengembang dikunci ke dalam platform yang dipilih setelah baris pertama kode ditulis!

Versi spesifikasi EJB yang disertakan dengan rekomendasi Java EE 5.0 adalah 3.0, dan ini adalah versi yang kami rujuk saat membahas EJB. Spesifikasi EJB 3.0 telah menambahkan banyak perbaikan pada pendahulunya (versi 2.1, yang merupakan bagian dari rekomendasi J2EE 1.4), termasuk anotasi metadata untuk menyederhanakan masalah penyebaran, tingkat kontrol yang lebih tinggi atas ketekunan kacang, dan yang jauh lebih disederhanakan (tetapi model pemrograman yang tidak kalah kuatnya untuk mengembangkan EJB.

Tiga jenis EJB

Sebenarnya ada tiga jenis EJB: kacang sesi, kacang entitas, dan kacang berbasis pesan. Di sini, kami akan menyajikan pengantar singkat untuk setiap jenis kacang. Keseimbangan artikel ini kemudian akan fokus pada kacang sesi.

Catatan
Saat mengacu pada EJB dalam pengertian umum, kita akan menggunakan istilah EJB , biji perusahaan , atau hanya kacang .

Kacang sesi

Salah satu cara untuk berpikir tentang lapisan logika aplikasi (middle tier) dalam contoh arsitektur yang ditunjukkan pada Gambar 1 adalah sebagai sekumpulan objek yang, bersama-sama, mengimplementasikan logika bisnis dari suatu aplikasi. Kacang sesi adalah konstruksi dalam EJB yang dirancang untuk tujuan ini. Seperti yang ditunjukkan pada Gambar 2, mungkin ada beberapa sesi kacang dalam sebuah aplikasi. Masing-masing menangani subset dari logika bisnis aplikasi.

Kacang sesi cenderung bertanggung jawab atas sekelompok fungsionalitas terkait. Misalnya, aplikasi untuk lembaga pendidikan mungkin memiliki kacang sesi yang metodenya berisi logika untuk menangani catatan siswa. Kacang sesi lain mungkin berisi logika yang memelihara daftar kursus dan program yang tersedia di lembaga itu.

Ada dua jenis kacang sesi, yang ditentukan oleh penggunaannya dalam interaksi klien:

  • Stateless: Kacang ini tidak mendeklarasikan variabel instance (tingkat kelas), sehingga metode yang terkandung di dalamnya hanya dapat bertindak pada parameter lokal apa pun. Tidak ada cara untuk mempertahankan status di seluruh panggilan metode.
  • Stateful: Kacang ini dapat menyimpan status klien di seluruh pemanggilan metode. Ini dimungkinkan dengan penggunaan variabel instan yang dideklarasikan dalam definisi kelas. Klien kemudian akan menetapkan nilai untuk variabel ini dan menggunakan nilai ini dalam panggilan metode lain.

Mungkin ada lebih banyak pekerjaan yang terlibat untuk server untuk berbagi kacang sesi stateful daripada yang dibutuhkan untuk berbagi kacang stateless. Menyimpan status EJB adalah proses yang sangat boros sumber daya, sehingga aplikasi yang menggunakan kacang stateful mungkin tidak mudah diskalakan. Kacang sesi tanpa status memberikan skalabilitas yang sangat baik, karena container EJB tidak perlu melacak statusnya di seluruh pemanggilan metode. Anda akan melihat bagaimana mengembangkan kacang sesi stateless dan stateful nanti di artikel ini.

Semua EJB, termasuk session beans, beroperasi dalam konteks server EJB, seperti yang ditunjukkan pada Gambar 2. Server EJB berisi konstruksi yang dikenal sebagai kontainer EJB, yang bertanggung jawab untuk menyediakan lingkungan operasi untuk mengelola dan menyediakan layanan ke EJB yang berjalan di dalamnya.

Dalam skenario umum, antarmuka pengguna (UI) aplikasi memanggil metode kacang sesi karena memerlukan fungsionalitas yang mereka sediakan. Kacang sesi dapat memanggil kacang sesi dan kacang entitas lainnya. Gambar 2 mengilustrasikan interaksi khas antara antarmuka pengguna, kacang sesi, kacang entitas, dan database.

Kacang entitas

Sebelum orientasi objek menjadi populer, program biasanya ditulis dalam bahasa prosedural dan sering menggunakan database relasional untuk menyimpan data. Karena kekuatan dan kematangan teknologi database relasional, sekarang sering kali menguntungkan untuk mengembangkan aplikasi berorientasi objek yang menggunakan database relasional. Masalah dengan pendekatan ini adalah bahwa ada perbedaan yang melekat antara teknologi database berorientasi objek dan relasional, membuatnya kurang alami bagi mereka untuk hidup berdampingan dalam satu aplikasi. Penggunaan biji entitas adalah salah satu cara untuk mendapatkan yang terbaik dari kedua dunia ini, karena alasan berikut:

  • Kacang entitas adalah objek, dan dapat dirancang menggunakan prinsip berorientasi objek dan digunakan dalam aplikasi sebagai objek.
  • Data dalam objek kacang entitas ini disimpan di beberapa penyimpanan data, biasanya database relasional. Semua manfaat teknologi relasional — termasuk kematangan produk, kecepatan, keandalan, kemampuan untuk memulihkan, dan kemudahan kueri — dapat dimanfaatkan.

Dalam skenario EJB tipikal, ketika kacang sesi perlu mengakses data, ia memanggil metode kacang entitas. Kacang entitas mewakili data persisten dalam aplikasi EJB. Misalnya, aplikasi untuk institusi pendidikan mungkin memiliki entitas bean bernama Studentyang memiliki satu contoh untuk setiap siswa yang terdaftar di institusi. Kacang entitas, sering kali didukung oleh database relasional, membaca dan menulis ke tabel dalam database. Karena itu, mereka menyediakan abstraksi berorientasi objek ke beberapa penyimpanan informasi.

Seperti yang ditunjukkan pada Gambar 2, ini adalah praktik yang baik untuk memanggil hanya kacang sesi langsung dari klien, dan membiarkan kacang sesi memanggil kacang entitas. Berikut beberapa alasannya:

  • Praktik ini tidak menghindari logika bisnis yang terkandung dalam kacang sesi. Memanggil kacang entitas secara langsung cenderung mendorong logika bisnis ke logika UI, yang biasanya merupakan hal yang buruk.
  • UI tidak perlu bergantung pada perubahan pada kacang entitas. UI dilindungi dari perubahan ini oleh kacang sesi.
  • Agar klien dapat berinteraksi dengan kacang di server EJB, harus ada referensi jarak jauh ke kacang tersebut, yang membutuhkan sumber daya. Ada cenderung lebih banyak (urutan besarnya) instance kacang entitas dalam aplikasi daripada instance kacang sesi. Membatasi akses klien ke kacang sesi sangat menghemat sumber daya server dan jaringan.
Catatan
Mengembangkan biji entitas tidak memerlukan antarmuka bisnis; Faktanya, kacang berbasis pesan adalah satu-satunya EJB yang harus mengimplementasikan beberapa antarmuka bisnis.

Kacang berdasarkan pesan

Ketika aplikasi berbasis EJB perlu menerima pesan asinkron dari sistem lain, itu dapat memanfaatkan kekuatan dan kenyamanan kacang berbasis pesan. Pesan asinkron antar sistem dapat dianalogikan dengan peristiwa yang diaktifkan dari komponen UI ke pengendali peristiwa di JVM yang sama. Misalnya, dalam domain bisnis-ke-bisnis (B2B), pedagang grosir dapat memiliki aplikasi EJB yang menggunakan biji berbasis pesan untuk mendengarkan pesanan pembelian yang dikeluarkan secara elektronik dari pengecer.

Jenis EJB apa yang harus Anda gunakan?

Jadi, bagaimana Anda memutuskan apakah EJB tertentu harus kacang sesi, kacang entitas, atau kacang berbasis pesan? Berikut beberapa pedoman untuk memutuskan: