Singkatnya EJB 3.0

Terlepas dari beberapa hal positif, kompleksitas arsitektur Enterprise JavaBeans menghalangi adopsi J2EE. Arsitektur EJB mungkin satu-satunya komponen J2EE yang telah gagal total dalam memenuhi janji J2EE untuk meningkatkan produktivitas pengembang melalui kemudahan pengembangan. EJB 3.0 membuat upaya lain untuk memenuhi janji itu dengan mengurangi kompleksitas EJB untuk pengembang. EJB 3.0 mengurangi jumlah artefak pemrograman bagi pengembang untuk menyediakan, menghilangkan atau meminimalkan metode panggilan balik yang diperlukan untuk diimplementasikan, dan mengurangi kompleksitas model pemrograman kacang entitas dan model pemetaan O / R.

Dalam artikel ini, saya pertama kali membahas perubahan paling signifikan di EJB 3.0. Penting untuk memiliki dasar-dasarnya sebelum menyelam ke pool EJB 3.0. Selanjutnya, saya memberikan pandangan tingkat tinggi dari draf EJB 3.0 dan kemudian membahas spesifikasi yang diusulkan secara spesifik, memperhatikan semua perubahan satu per satu: dampak pada jenis biji perusahaan, model pemetaan O / R, entitas- model hubungan, EJB QL (Bahasa Kueri EJB), dll.

Latar Belakang

Dua perubahan paling signifikan dalam spesifikasi EJB 3.0 yang diusulkan adalah penggunaan fasilitas anotasi program yang diperkenalkan di Java 5 dan model pemetaan O / R baru berdasarkan Hibernate.

Fasilitas Metadata di Java 5

Java 5 (sebelumnya disebut J2SE 1.5, atau Tiger) telah memperkenalkan fasilitas anotasi program baru ke bahasa tersebut. Dengan fasilitas ini, Anda dapat menentukan anotasi khusus dan kemudian menganotasi bidang, metode, kelas, dll., Dengan anotasi ini. Anotasi tidak secara langsung memengaruhi semantik program, tetapi alat (waktu kompilasi atau waktu proses) dapat memeriksa anotasi ini untuk menghasilkan konstruksi tambahan (seperti deskriptor penerapan) atau menerapkan perilaku waktu proses yang diinginkan (seperti sifat stateful komponen EJB). Anotasi dapat diperiksa melalui penguraian sumber (mis., Kompiler atau alat IDE) atau dengan menggunakan API refleksi tambahan yang ditambahkan di Java 5. Anotasi dapat didefinisikan agar hanya tersedia di tingkat kode sumber, di tingkat kelas yang dikompilasi, atau saat runtime . Semua penjelasan yang diusulkan dalam EJB 3.0 rancangan awal memiliki RetentionPolicydariRUNTIME. Ini meningkatkan footprint memori kelas secara marginal, tetapi membuat kehidupan penyedia container dan penyedia alat menjadi jauh lebih mudah.

Lihat Sumberdaya untuk membaca lebih lanjut tentang topik ini.

Hibernasi

Hibernate adalah kerangka kerja pemetaan O / R open source yang populer untuk lingkungan Java, yang dimaksudkan untuk melindungi pengembang dari sebagian besar tugas pemrograman terkait persistensi data. Ia juga memiliki Hibernate Query Language (HQL) tertentu, yang jejaknya dapat dilihat di EJB QL baru. Hibernate menawarkan fasilitas untuk pengambilan dan pembaruan data, penggabungan koneksi, manajemen transaksi, manajemen hubungan entitas deklaratif, dan kueri deklaratif dan terprogram.

Pandangan mata burung

Perubahan dalam spesifikasi EJB 3.0 yang diusulkan dapat dibagi menjadi dua kategori:

  • Model pemrograman EJB berbasis anotasi, selain model EJB 2.1 untuk menentukan perilaku aplikasi melalui deskriptor penyebaran dan beberapa antarmuka.
  • Model persistensi baru untuk biji entitas. EJB QL juga telah berubah secara signifikan.

Ada juga beberapa efek samping proposal ini, seperti model pemrograman klien baru, penggunaan antarmuka bisnis, dan siklus hidup kacang entitas. Harap dicatat bahwa model pemrograman EJB 2.1 (dengan deskriptor penyebaran dan antarmuka rumah / jarak jauh) masih valid. Model baru yang disederhanakan tidak sepenuhnya menggantikan model EJB 2.1.

Anotasi EJB

Salah satu tujuan penting kelompok ahli adalah untuk mengurangi jumlah artefak yang harus disediakan oleh penyedia kacang, dan kelompok tersebut telah melakukan pekerjaan yang cukup rapi dalam mencapai tujuan tersebut. Di dunia EJB 3.0, semua jenis kacang perusahaan hanyalah objek Java lama (POJO) biasa dengan penjelasan yang sesuai. Anotasi dapat digunakan untuk menentukan antarmuka bisnis kacang, informasi pemetaan O / R, referensi sumber daya, dan apa saja yang didefinisikan melalui pendeskripsi atau antarmuka penerapan di EJB 2.1. Deskriptor penerapan tidak lagi diperlukan; antarmuka beranda hilang, dan Anda tidak perlu menerapkan antarmuka bisnis (penampung dapat membuatnya untuk Anda).

Misalnya, Anda mendeklarasikan kacang sesi stateless dengan menggunakan @Statelessanotasi pada kelas Java. Untuk kacang stateful, @Removeanotasi ditandai pada metode tertentu untuk menunjukkan bahwa instance kacang harus dihapus setelah panggilan ke metode yang ditandai selesai.

Untuk mengurangi jumlah informasi yang harus Anda tentukan untuk sebuah komponen, grup pakar telah mengadopsi pendekatan konfigurasi-dengan-pengecualian , yang berarti Anda memberikan default intuitif untuk semua anotasi sehingga sebagian besar informasi umum dapat disimpulkan.

Model persistensi baru

Kacang entitas baru juga hanya POJO dengan sedikit penjelasan dan bukan entitas persisten sejak lahir. Instance entitas menjadi persisten setelah dikaitkan dengan EntityManagerdan menjadi bagian dari konteks persistensi . Konteks ketekunan secara longgar identik dengan konteks transaksi; dengan kata tegas, itu secara implisit berdampingan dengan ruang lingkup transaksi.

Hubungan entitas juga ditentukan melalui penjelasan. Selain itu, pemetaan O / R juga dilakukan melalui anotasi, dan dukungan untuk beberapa operasi khusus database disediakan. Dengan EJB 2.1, pengembang menggunakan pola desain mereka sendiri atau menggunakan teknik nonportable (misalnya, strategi pembuatan kunci otomatis).

Menggali lebih dalam

Sekarang saatnya untuk membahas secara spesifik proposal yang dibuat dalam draf awal EJB 3.0. Mari kita mulai dengan keempat jenis kacang perusahaan dan kemudian beralih ke proposal umum ke seluruh model pemrograman EJB.

Kacang sesi tanpa negara:

Kacang sesi stateless (SLSB), ditulis dengan cara EJB 3.0, hanyalah file Java biasa dengan penjelasan tingkat kelas @Stateless. Kelas kacang dapat mengimplementasikan javax.ejb.SessionBeanantarmuka, tetapi tidak diharuskan (dan biasanya tidak).

SLSB tidak lagi memiliki antarmuka beranda — pada kenyataannya, tidak ada tipe EJB yang memerlukannya. Kelas kacang mungkin atau mungkin tidak mengimplementasikan antarmuka bisnis. Jika tidak menerapkan antarmuka bisnis apa pun, antarmuka bisnis akan dibuat menggunakan semua metode publik. Jika hanya metode tertentu yang harus diekspos di antarmuka bisnis, semua metode tersebut dapat ditandai dengan @BusinessMethodanotasi. Secara default, semua antarmuka yang dihasilkan bersifat lokal, tetapi @Remoteanotasi dapat digunakan untuk menunjukkan bahwa antarmuka jarak jauh harus dibuat.

Beberapa baris kode berikut sudah cukup untuk mendefinisikan HelloWorldkacang. Dengan EJB 2.1, kacang yang sama akan membutuhkan setidaknya dua antarmuka, satu kelas implementasi dengan beberapa implementasi metode kosong, dan deskriptor penyebaran.

import javax.ejb. *; / ** * Kacang sesi stateless yang meminta agar antarmuka bisnis * jarak jauh dibuat untuknya. * / @Stateless @Remote public class HelloWorldBean {public String sayHello () {return "Hello World !!!"; }}

Lihat Sumberdaya untuk kode sumber lengkap yang menyertai artikel ini.

Kacang sesi stateful

Cerita dengan stateful session beans (SFSB) hampir sama untuk SLSB, kecuali untuk beberapa poin khusus SFSB:

  • SFSB harus memiliki cara untuk menginisialisasi dirinya sendiri (disediakan melalui ejbCreate()metode di EJB 2.1 dan sebelumnya). Spesifikasi EJB 3.0 menunjukkan bahwa metode inisialisasi tersebut disediakan sebagai metode kustom dan diekspos melalui antarmuka bisnis kacang. Tanggung jawab sekarang terletak pada klien untuk memanggil metode inisialisasi yang sesuai sebelum menggunakan kacang. Kelompok ahli masih memperdebatkan perlunya memberikan anotasi yang menandai metode tertentu untuk inisialisasi.
  • Penyedia kacang dapat menandai metode SFSB apa pun dengan @Removepenjelasan untuk menunjukkan bahwa instance kacang harus dihapus setelah metode yang dianotasi dipanggil. Sekali lagi, kelompok ahli masih mendiskusikan apakah suatu fasilitas diperlukan untuk menunjukkan bahwa biji kopi tidak boleh dibuang jika metode tersebut tidak selesai secara normal.

Inilah pendapat saya tentang dua masalah terbuka:

  • Haruskah ada anotasi untuk metode inisialisasi? Pilihan saya adalah ya — dengan asumsi bahwa penampung akan memastikan bahwa setidaknya satu dari metode inisialisasi dipanggil sebelum metode bisnis lain dipanggil. Hal ini tidak hanya melindungi dari kesalahan pemrograman yang tidak disengaja, tetapi juga membuat container lebih percaya diri untuk menggunakan kembali instance SFSB. Untuk kejelasan, izinkan saya menyebutkan di sini bahwa tidak ada metode inisialisasi yang ditentukan (seperti ejbCreate) sedang dipertimbangkan; kelompok ahli hanya mempertimbangkan untuk memiliki tanda anotasi sebagai metode sebagai metode inisialisasi.
  • Haruskah dapat dikonfigurasi bahwa penghentian abnormal @Removemetode tidak menghapus instance kacang? Sekali lagi, suara saya adalah ya. Ini hanya akan memberikan kontrol yang lebih baik kepada penyedia kacang dan pemrogram klien. Hanya satu pertanyaan tersisa: apa yang terjadi pada kacang yang ditandai untuk tidak dihapus pada panggilan yang gagal ke metode penghapusan dan metode penghapusan contoh tertentu tidak pernah berhasil diselesaikan? Tidak ada cara untuk menghapus instance tersebut secara terprogram, tetapi akan dihapus pada sesi timeout.

Lihat kode sumber untuk contoh SFSB.

Kacang berdasarkan pesan

Kacang yang digerakkan oleh pesan (MDB) adalah satu-satunya jenis kacang yang harus mengimplementasikan antarmuka bisnis. Jenis antarmuka ini menunjukkan jenis sistem pesan yang didukung kacang. Untuk MDB berbasis JMS (Java Message Service), antarmuka ini adalah javax.jms.MessageListener. Perhatikan bahwa antarmuka bisnis MDB bukanlah antarmuka bisnis yang sebenarnya , itu hanya antarmuka pengiriman pesan.

Kacang entitas

Kacang entitas ditandai dengan @Entityanotasi, dan semua properti / bidang dalam kelas kacang entitas yang tidak ditandai dengan @Transientanotasi dianggap tetap. Bidang persisten kacang entitas diekspos melalui properti gaya JavaBean atau hanya sebagai bidang kelas Java publik / dilindungi.

Kacang entitas dapat menggunakan kelas pembantu untuk mewakili status kacang entitas, tetapi instance dari kelas ini tidak memiliki identitas yang persisten. Sebaliknya, keberadaan mereka terikat kuat pada instance kacang entitas pemilik; juga objek ini tidak dapat dibagikan di seluruh entitas.

Lihat kode sumber untuk beberapa contoh kacang entitas.

Hubungan entitas

EJB 3.0 mendukung hubungan searah dan dua arah antara biji entitas, yang dapat berupa hubungan satu-ke-satu, satu-ke-banyak, banyak-ke-satu, atau banyak-ke-banyak. Namun, dua sisi hubungan dua arah dibedakan sebagai sisi pemilik dan sisi terbalik. Sisi pemilik bertanggung jawab untuk menyebarkan perubahan hubungan ke database. Untuk pengaitan banyak ke banyak, sisi pemilik harus ditentukan secara eksplisit. Sebenarnya itu adalah sisi kebalikan yang ditentukan oleh isInverse=trueanggota anotasi pada anotasi sisi sebaliknya ManyToMany; dari situ, sisi yang memiliki disimpulkan. Sekarang, bukankah kelompok ahli mengatakan itu membuat EJB lebih mudah?

Pemetaan O / R

The O/R mapping model has also significantly changed from the abstract-persistence-schema-based approach to a Hibernate-inspired one. Though the expert group is still discussing the model, and a clear picture will emerge only with the next draft, this draft features clear indications of the overall approach.

For one, the O/R mapping will be specified in the entity bean class itself by annotations. Also, the approach is to refer to concrete tables and columns instead of the abstract persistence schema. The O/R mapping model has intrinsic support for native SQL; that is, support at a deeper level, not just the ability to run native SQL queries. For example, the column definitions annotation (@Column) has a member columnDefinition that can be something like columnDefinition="BLOB NOT NULL".

Client programming model

An EJB client can acquire a reference to the bean's business interface using the injection mechanism (@Inject annotation). Using the newly introduced @javax.ejb.EJBContext.lookup() method is another approach. But the specification is not clear as to how a standalone Java client acquires reference to a bean instance since the standalone Java clients run in a J2EE client container and lack access to the @javax.ejb.EJBContext object. There is yet another mechanism—a newly introduced universal context object: @javax.ejb.Context(). But, again, the spec does not say how this object can be used in a client container.

EJB QL

Queries can be defined through the @NamedQuery annotation. Two members of this annotation are name and queryString. Once defined, this query can be accessed using the EntityManager.createNamedQuery(name) method. You can also create a regular JDBC-style (Java Database Connectivity) query by calling EntityManager.createQuery(ejbqlString) or a native query using EntityManager.createNativeQuery(nativeSqlString).

EJB QL queries can have both positional as well as named parameters. The javax.ejb.Query interface provides methods for setting these parameters, executing updates, listing results, etc.

Here is one example of how an EJB QL query can be created and executed:

.. .. @NamedQuery (name = "findAllCustomersWithName", queryString = "PILIH c DARI Pelanggan c DI MANA c.name LIKE: custName") .. .. @Inject public EntityManager em; pelanggan = em.createNamedQuery ("findAllCustomersWithName") .setParameter ("custName", "Smith") .listResults ();

Berikut daftar beberapa dari beberapa penyempurnaan yang dilakukan pada QL itu sendiri: