Ringkasnya EJB 3.0

Walaupun terdapat beberapa hal positif, kerumitan seni bina Enterprise JavaBeans menghalangi penerapan J2EE. Senibina EJB mungkin satu-satunya komponen J2EE yang telah gagal dengan begitu teruk dalam menunaikan janji J2EE untuk meningkatkan produktiviti pemaju dengan mudahnya pembangunan. EJB 3.0 membuat usaha lain untuk menunaikan janji itu dengan mengurangkan kerumitan EJB untuk pemaju. EJB 3.0 mengurangkan jumlah artifak pengaturcaraan untuk disediakan oleh pembangun, menghilangkan atau meminimumkan kaedah panggilan balik yang diperlukan untuk dilaksanakan, dan mengurangkan kerumitan model pengaturcaraan kacang kacang dan model pemetaan O / R.

Dalam artikel ini, saya pertama kali membahas perubahan yang paling ketara dalam EJB 3.0. Penting untuk menerapkan asas sebelum menyelam ke kolam EJB 3.0. Seterusnya, saya memberikan pandangan tingkat tinggi draf EJB 3.0 dan kemudian masuk ke dalam spesifikasi yang dicadangkan, dengan memperhatikan semua perubahan satu persatu: kesan pada jenis kacang perusahaan, model pemetaan O / R, entiti- model hubungan, EJB QL (EJB Query Language), dll.

Latar belakang

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

Kemudahan metadata di Java 5

Java 5 (sebelumnya disebut J2SE 1.5, atau Tiger) telah memperkenalkan kemudahan anotasi program baru untuk bahasa tersebut. Dengan kemudahan ini, anda boleh menentukan anotasi tersuai dan kemudian memberi anotasi medan, kaedah, kelas, dan lain-lain, dengan anotasi ini. Anotasi tidak secara langsung mempengaruhi semantik program, tetapi alat (menyusun masa atau waktu berjalan) dapat memeriksa anotasi ini untuk menghasilkan konstruksi tambahan (seperti penerangan penerapan) atau menguatkuasakan tingkah laku runtime yang diinginkan (seperti sifat EJB komponen yang jelas). Anotasi dapat diperiksa melalui penghuraian sumber (misalnya, penyusun atau alat IDE) atau dengan menggunakan API refleksi tambahan yang ditambahkan di Java 5. Anotasi dapat didefinisikan hanya tersedia pada tingkat kod sumber, pada tingkat kelas yang dikompilasi, atau pada waktu proses . Semua anotasi dicadangkan dalam EJB 3.0 awal draf mempunyai RetentionPolicydaripadaRUNTIME. Ini meningkatkan jejak memori kelas sedikit, tetapi menjadikan kehidupan penyedia kontena dan penyedia alat menjadi lebih mudah.

Rujuk Sumber untuk membaca lebih lanjut mengenai topik ini.

Hibernate

Hibernate adalah kerangka pemetaan O / R sumber terbuka yang popular untuk lingkungan Java, yang dimaksudkan untuk melindungi pemaju dari kebanyakan tugas pengaturcaraan yang berkaitan dengan ketekunan data. Ia juga mempunyai Hibernate Query Language (HQL) tertentu, yang dapat dilihat pada EJB QL baru. Hibernate menawarkan kemudahan untuk pengambilan dan kemas kini data, penyatuan sambungan, pengurusan transaksi, pengurusan hubungan entiti deklaratif, dan pertanyaan deklaratif dan terprogram.

Pandangan burung

Perubahan dalam spesifikasi EJB 3.0 yang dicadangkan dapat dibahagikan kepada dua kategori:

  • Model pengaturcaraan EJB berasaskan anotasi, selain model EJB 2.1 untuk menentukan tingkah laku aplikasi melalui penerangan penerapan dan beberapa antaramuka.
  • Model ketekunan baru untuk kacang entiti. EJB QL juga telah berubah dengan ketara.

Terdapat juga beberapa kesan sampingan terhadap cadangan ini, seperti model pengaturcaraan pelanggan baru, penggunaan antara muka perniagaan, dan kitaran hidup kacang entiti. Harap maklum bahawa model pengaturcaraan EJB 2.1 (dengan penerangan penyebaran dan antara muka rumah / jarak jauh) masih berlaku. Model ringkas yang baru tidak sepenuhnya menggantikan model EJB 2.1.

Anotasi EJB

Salah satu tujuan penting kumpulan pakar adalah untuk mengurangkan jumlah artifak yang mesti disediakan oleh penyedia kacang, dan kumpulan itu telah melakukan pekerjaan yang cukup rapi dalam mencapai tujuan tersebut. Di dunia EJB 3.0, semua jenis kacang perusahaan hanyalah objek Java lama (POJO) dengan anotasi yang sesuai. Anotasi dapat digunakan untuk menentukan antara muka perniagaan kacang, informasi pemetaan O / R, rujukan sumber, dan apa sahaja yang ditakrifkan melalui deskriptor penyebaran atau antara muka di EJB 2.1. Penerangan penerapan tidak lagi diperlukan; antara muka rumah sudah tiada, dan anda tidak semestinya harus melaksanakan antara muka perniagaan (wadah boleh menghasilkannya untuk anda).

Sebagai contoh, anda mengisytiharkan kacang sesi tanpa status dengan menggunakan @Statelessanotasi pada kelas Java. Untuk kacang polong, @Removeanotasi ditandakan pada kaedah tertentu untuk menunjukkan bahawa contoh kacang harus dikeluarkan setelah panggilan ke kaedah yang ditandai selesai.

Untuk mengurangkan jumlah maklumat yang mesti anda tentukan untuk komponen, kumpulan pakar telah menggunakan pendekatan konfigurasi-dengan-pengecualian , yang bermaksud anda memberikan lalai intuitif untuk semua anotasi sehingga kebanyakan maklumat umum dapat disimpulkan.

Model kegigihan baru

Kacang entiti baru juga hanya POJO dengan beberapa anotasi dan bukan entiti berterusan sejak lahir. Contoh entiti menjadi berterusan setelah dikaitkan dengan EntityManagerdan menjadi sebahagian daripada konteks kegigihan . Konteks kegigihan sangat sinonim dengan konteks transaksi; dengan kata-kata yang tegas, secara tidak langsung ia wujud bersama dengan skop transaksi.

Hubungan entiti juga ditentukan melalui anotasi. Selain itu, pemetaan O / R juga dilakukan melalui anotasi, dan dukungan untuk beberapa operasi khusus pangkalan data disediakan. Dengan EJB 2.1, pembangun menggunakan corak reka bentuk mereka sendiri atau menggunakan teknik yang tidak boleh dibawa (misalnya, strategi penjanaan kunci automatik).

Menggali jauh

Kini tiba masanya untuk mengetahui spesifik cadangan yang dibuat dalam draf awal EJB 3.0. Mari kita mulakan dengan keempat-empat jenis kacang perusahaan dan kemudian beralih ke cadangan generik ke keseluruhan model pengaturcaraan EJB.

Kacang sesi tanpa stat:

Bean sesi tanpa stat (SLSB), ditulis dengan cara EJB 3.0, hanyalah fail Java biasa dengan anotasi peringkat kelas @Stateless. Kelas kacang boleh melaksanakan javax.ejb.SessionBeanantara muka, tetapi tidak diperlukan (dan biasanya tidak).

SLSB tidak mempunyai antara muka rumah lagi - sebenarnya, tidak ada jenis EJB yang memerlukannya. Kelas kacang mungkin atau mungkin tidak melaksanakan antara muka perniagaan. Sekiranya tidak melaksanakan antara muka perniagaan, antara muka perniagaan akan dihasilkan menggunakan semua kaedah awam. Sekiranya hanya kaedah-kaedah tertentu yang harus didedahkan di antara muka perniagaan, semua kaedah tersebut dapat ditandai dengan @BusinessMethodpenjelasan. Secara lalai, semua antara muka yang dihasilkan adalah tempatan, tetapi @Remoteanotasi dapat digunakan untuk menunjukkan bahawa antara muka jarak jauh harus dihasilkan.

Beberapa baris kod berikut cukup untuk menentukan HelloWorldkacang. Dengan EJB 2.1, kacang yang sama memerlukan sekurang-kurangnya dua antara muka, satu kelas pelaksanaan dengan beberapa pelaksanaan kaedah kosong, dan penerangan penerapan.

import javax.ejb. *; / ** * Kacang sesi tanpa status yang meminta agar antara muka perniagaan jauh * dihasilkan untuknya. * / @Stateless @Remote kelas awam HelloWorldBean {public String sayHello () {kembali "Hello World !!!"; }}

Rujuk Sumber untuk kod sumber lengkap yang menyertai artikel ini.

Kacang sesi bernegara

Cerita dengan kacang sesi yang bernas (SFSB) hampir sama untuk SLSB, kecuali beberapa perkara khusus SFSB:

  • SFSB harus mempunyai cara untuk menginisialisasi dirinya (disediakan melalui ejbCreate()kaedah dalam EJB 2.1 dan sebelumnya). Spesifikasi EJB 3.0 menunjukkan bahawa kaedah inisialisasi seperti itu disediakan sebagai kaedah khusus dan didedahkan melalui antara muka perniagaan kacang. Tanggungjawab kini terletak pada pelanggan untuk memanggil kaedah permulaan yang sesuai sebelum menggunakan kacang. Kumpulan pakar masih membahaskan perlunya memberikan anotasi yang menandakan kaedah tertentu untuk permulaan.
  • Penyedia kacang boleh menandakan sebarang kaedah SFSB dengan @Removeanotasi untuk menunjukkan bahawa contoh kacang mesti dikeluarkan setelah kaedah anotasi dipanggil. Sekali lagi, kumpulan pakar masih membincangkan apakah kemudahan diperlukan untuk menunjukkan bahawa kacang tidak boleh dikeluarkan jika kaedahnya tidak selesai secara normal.

Inilah pendapat saya mengenai dua isu terbuka:

  • Sekiranya ada anotasi untuk kaedah inisialisasi? Undian saya adalah ya — dengan anggapan bahawa wadah akan memastikan bahawa sekurang-kurangnya satu kaedah permulaan dipanggil sebelum kaedah perniagaan lain dipanggil. Ini bukan sahaja melindungi dari kesalahan pengaturcaraan yang tidak disengajakan, tetapi juga membuat wadah lebih yakin untuk menggunakan semula contoh SFSB. Untuk penjelasan, izinkan saya menyebutkan di sini bahawa tidak ada kaedah inisialisasi (seperti ejbCreate) yang dipertimbangkan; kumpulan pakar hanya mempertimbangkan untuk menggunakan kaedah anotasi sebagai kaedah inisialisasi.
  • Perlukah dikonfigurasi bahawa penghentian @Removekaedah yang tidak normal tidak menghilangkan contoh kacang? Sekali lagi, suara saya adalah ya. Ini hanya akan memberikan kawalan yang lebih baik kepada penyedia kacang dan pengaturcara pelanggan. Tinggal satu soalan lagi: apa yang terjadi pada kacang yang ditandai sebagai tidak dikeluarkan pada panggilan yang tidak berjaya untuk kaedah penghapusan dan kaedah penghapusan contoh tertentu tidak pernah selesai dengan jayanya? Tidak ada cara untuk membuang kejadian tersebut secara terprogram, tetapi akan dihapus pada waktu tamat sesi.

Rujuk kod sumber untuk contoh SFSB.

Kacang berdasarkan pesanan

Kacang berasaskan pesanan (MDB) adalah satu-satunya jenis kacang yang mesti melaksanakan antara muka perniagaan. Jenis antara muka ini menunjukkan jenis sistem pesanan yang disokong oleh kacang. Untuk MDB berasaskan JMS (Java Message Service), antara muka ini adalah javax.jms.MessageListener. Perhatikan bahawa antara muka perniagaan MDB sebenarnya bukan antara muka perniagaan , tetapi hanya antara muka pesanan.

Kacang entiti

Biji entiti ditandai dengan @Entityanotasi, dan semua sifat / medan dalam kelas kacang entiti yang tidak ditandai dengan @Transientanotasi dianggap berterusan. Medan persisten kacang entiti didedahkan melalui sifat gaya JavaBean atau sama seperti medan kelas Java yang dilindungi umum / dilindungi.

Entity kacang boleh menggunakan kelas pembantu untuk mewakili keadaan kacang entiti, tetapi contoh kelas ini tidak mempunyai identiti berterusan. Sebaliknya, keberadaan mereka sangat terkait dengan contoh kacang entiti yang memiliki; juga objek ini tidak boleh dikongsi di antara entiti.

Rujuk kod sumber untuk beberapa contoh kacang entiti.

Hubungan entiti

EJB 3.0 menyokong hubungan dua arah dan dua arah antara kacang entiti, yang boleh menjadi hubungan satu-ke-satu, satu-ke-banyak, banyak-ke-satu, atau banyak-ke-banyak. Walau bagaimanapun, dua sisi hubungan dua arah dibezakan sebagai sisi pemilik dan sisi terbalik. Sisi yang dimiliki bertanggungjawab untuk menyebarkan perubahan hubungan ke pangkalan data. Bagi banyak persatuan, bahagian yang dimiliki mesti dinyatakan dengan jelas. Sebenarnya ia adalah sisi belakang yang ditentukan oleh isInverse=trueanggota anotasi pada anotasi sisi belakang ManyToMany; dari itu, pihak yang memiliki kesimpulan. Sekarang, tidakkah kumpulan pakar mengatakan bahawa ia menjadikan 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 SEPERTI: custName") .. .. @Masukkan entiti awam Manajer em; pelanggan = em.createNamedQuery ("findAllCustomersWithName") .setParameter ("custName", "Smith") .listResults ();

Berikut ini disenaraikan beberapa peningkatan yang dibuat untuk QL itu sendiri: