Migrasi aplikasi EJB 2.x ke EJB 3.0

Enterprise JavaBeans 3.0 menyederhanakan arsitektur kacang perusahaan dan menyediakan fitur yang ditingkatkan dan lebih kuat. Spesifikasi baru ini memanfaatkan fasilitas metadata anotasi yang diperkenalkan di Java 5, ketekunan dan praktik terbaik pemetaan relasional objek dari alat seperti Hibernate dan TopLink, dan pola Injeksi Ketergantungan yang dipopulerkan oleh kerangka kerja Java yang ringan seperti Spring.

Artikel ini membahas kemungkinan strategi migrasi untuk memindahkan aplikasi yang ditulis menggunakan EJB 2.1 atau spesifikasi sebelumnya ke arsitektur berbasis EJB 3.0. Jalur migrasi yang mungkin dievaluasi dari kedua perspektif desain dan implementasi. Artikel ini tidak bermaksud untuk memberikan gambaran lengkap tentang opsi migrasi. Setelah membaca artikel ini, Anda akan dapat memilih opsi terbaik, dalam konteks spesifik Anda sendiri, untuk memigrasi kode EJB lama ke spesifikasi baru.

Artikel ini mengasumsikan Anda sudah familiar dengan kacang perusahaan, Java 5, dan fitur dan konsep pemetaan relasional objek.

EJB 2.1 menjadi EJB 3.0: Apa yang berubah?

Untuk memberikan konteks untuk pembahasan artikel ini tentang kemungkinan jalur migrasi, saya mulai dengan membahas perubahan dalam spesifikasi baru dalam konteks masing-masing jenis kacang yang berbeda dan kemudian pada tingkat umum yang berkaitan dengan berbagai jenis kacang.

Kacang sesi

Dalam EJB 2.1 dan spesifikasi sebelumnya, dua antarmuka — rumah dan lokal, atau jarak jauh, antarmuka bisnis — dan kelas implementasi kacang diperlukan untuk setiap kacang sesi. Antarmuka beranda diperlukan untuk memperluas antarmuka EJBHomeatau EJBLocalHomedan mendeklarasikan metode siklus hidup, seperti create(). Antarmuka bisnis lokal, atau jarak jauh, diperlukan untuk memperluas antarmuka EJBObjectatau EJBLocalObjectdan menyatakan metode bisnis. Kelas implementasi kacang itu sendiri adalah sebuah EnterpriseBeantipe dan, dalam kasus kacang sesi, memperpanjangSessionBeansub-antarmuka. Implementasi metode callback dalam kelas kacang harus disediakan sehingga kontainer dapat memicunya saat kejadian siklus hidup yang sesuai. Selain itu, elemen penting dari bean, termasuk transaksi dan definisi keamanannya, dan apakah itu stateful atau stateless, didefinisikan dalam deskriptor penyebaran terkait.

Kode 1 mengilustrasikan contoh kacang sesi stateful yang didefinisikan menggunakan spesifikasi EJB 2.1.

Daftar 1. Sebuah layanan perbankan stateful kacang sesi berbasis EJB 2.1

public interface BankingService extends EJBObject { public void deposit(int accountId, float amount) throws RemoteException; public void withdraw(int accountId, float amount)throws RemoteException; public float getBalance(int accountId) throws RemoteException;

public void doServiceLogout() throws RemoteException; }

public interface BankingServiceHome extends EJBHome { public BankingService create() throws CreateException, RemoteException; }

public class BankingServiceEJB implements SessionBean {

public void deposit(int accountId, float amount) throws RemoteException { //Business logic to deposit the specified amount and update the balance }

public void withdraw(int accountId, float amount)throws RemoteException { //Business logic to withdraw the desired amount and update the balance }

public float getBalance(int accountId) throws RemoteException { //Business logic to get the current balance }

public void doServiceLogout() throws RemoteException { //Service completion and logout logic }

public void ejbCreate(){} public void ejbActivate(){} public void ejbPassivate(){} public void ejbRemove(){} public void setSessionContext(SessionContext context){}

}

Dalam spesifikasi EJB 3.0, kacang sesi hanya perlu mendefinisikan antarmuka bisnis dan kelas implementasi kacang. Antarmuka beranda telah dihapus. Antarmuka bisnis adalah antarmuka Java biasa, terkadang juga disebut POJI , atau antarmuka Java biasa. Antarmuka bisnis tidak perlu memperluas EJBObjectatau EJBLocalObjectantarmuka; sebaliknya, jika diperlukan, itu bisa didefinisikan dalam hierarki antarmuka yang mewakili model domain bisnis.

Kelas implementasi kacang adalah kelas Java biasa, kadang juga disebut POJO , atau objek Java biasa. Itu tidak mengimplementasikan EnterpriseBeantipe. Deklarasi dan konfigurasi dalam deskriptor penerapan dapat ditentukan dalam kode Java, menggunakan fasilitas metadata anotasi. Selain itu, nilai default disediakan untuk sebagian besar konfigurasi, sehingga meminimalkan persyaratan konfigurasi khusus kacang. Di bawah spesifikasi baru, seseorang dapat menerapkan kacang sesi tanpa deskriptor penerapan ejb-jar.xml, meskipun mereka masih ada dan dapat digunakan jika pengembang lebih memilihnya daripada model anotasi.

Dalam kasus kacang sesi EJB 3.0 yang mengimplementasikan layanan Web, metode yang diekspos sebagai operasi layanan Web dianotasi dengan WebMethoddeskriptor. Kacang sesi yang berfungsi sebagai titik akhir layanan Web dianotasi sebagai WebService.

Kode 2 mengilustrasikan contoh sebelumnya (dari Daftar 1) kacang sesi stateful menggunakan spesifikasi EJB 3.0.

Daftar 2. Sebuah layanan perbankan stateful kacang sesi berbasis EJB 3.0

@Remote public interface BankingService { public void deposit(int accountId, float amount); public void withdraw(int accountId, float amount); public float getBalance(int accountId); publlic void doServiceLogout();

}

@Stateful public class BankingServiceBean implements BankingService {

public void deposit(int accountId, float amount) { //Business logic to deposit the specified amount and update the balance }

public void withdraw(int accountId, float amount) { //Business logic to withdraw the desired amount and update the balance }

public float getBalance(int accountId) { //Business logic to get the current balance }

@Remove public void doServiceLogout () { //Service completion and logout logic }

}

Kacang berdasarkan pesan

Dalam EJB 2.1, kelas kacang berbasis pesan menerapkan MessageDrivenBeanantarmuka dan antarmuka pendengar pesan. Metode panggilan balik diimplementasikan di kelas kacang dan wadah, pada acara tertentu yang disebut metode terkait. Kacang berbasis pesan tidak pernah melibatkan konsep rumah dan antarmuka jarak jauh atau lokal.

Dalam EJB 3.0, MessageDrivenanotasi digunakan untuk menandai dan menentukan kacang berbasis pesan. Deskriptor penerapan juga dapat digunakan untuk menentukan kacang sebagai berbasis pesan. Jadi, kelas kacang tidak diperlukan untuk mengimplementasikan MessageDrivenBeanantarmuka. Antarmuka bisnis kacang yang digerakkan oleh pesan adalah antarmuka pendengar pesan yang sesuai dengan jenis pesan tempat kacang tersebut menjadi pendengar. Dalam kasus Java Message Service, javax.jms.MessageListeneradalah antarmuka pendengar pesan atau antarmuka bisnis. Kelas kacang perlu mengimplementasikan antarmuka pendengar pesan atau membuat anotasi antarmuka pendengar pesan menggunakan MessageDrivenanotasi.

Spesifikasi baru mendukung metode callback ( PostConstructdan PreDestroy), menyediakan pola Injeksi Ketergantungan untuk akses ke sumber daya, dan memungkinkan definisi metode interseptor untuk kacang yang digerakkan oleh pesan.

Kacang entitas

EJB 2.1 dan spesifikasi sebelumnya memerlukan definisi antarmuka rumah dan jarak jauh, dan implementasi kelas kacang untuk kacang entitas, mirip dengan jenis kacang sesi. Untuk skenario persistensi yang dikelola penampung (CMP) dan hubungan yang dikelola penampung (CMR), pemetaan dan definisi ditentukan di deskriptor penerapan.

Spesifikasi EJB 3.0 secara radikal mengubah konsep dan implementasi biji entitas sebelumnya dari objek kacang perusahaan kelas berat, dengan antarmuka rumah dan jarak jauh / lokal, menjadi objek domain persisten ringan yang sejalan dengan konsep pemetaan relasional objek. Diskusi selanjutnya tentang migrasi di artikel ini membahas dan merinci beberapa perubahan ini.

Lebih banyak perubahan — relevan dengan berbagai jenis kacang

Spesifikasi EJB 3.0 memperkenalkan perubahan penting dalam cara kacang perusahaan diakses dan dipanggil. Pola pencari lokasi layanan sebelumnya yang menggunakan pencarian JNDI (Java Naming and Directory Interface) sekarang diganti dengan pola Injeksi Ketergantungan. Dengan demikian, kompleksitas seputar penggunaan API JNDI dihapus dari sudut pandang pengembang kacang dan klien.

EJB 3.0 juga memperkenalkan konsep interseptor. Metode interseptor mencegat pemanggilan metode bisnis atau callback peristiwa siklus hidup. Metode interseptor dapat didefinisikan baik pada kelas kacang atau pada kelas interseptor yang terkait dengan kacang atau keduanya.

Kode 3 mengilustrasikan penggunaan AroundInvoke, penjelasan interseptor.

Daftar 3

@Stateful public class BankingServiceBean implements BankingService {

public void deposit(int accountId, float amount) { .... }

.... .... .... .... @Remove public void doServiceLogout () { .... }

@AroundInvoke public Object auditBankingService(InvocationContext inv) throws Exception { try { Object nextEntry = inv.proceed();

//Log the method name and parameters by using getMethod() on the InvocationContext instance. //The getMethod() returns the method of the bean class for which the interceptor was invoked. //The return type for getMethod() is a Method class, the reference to which can be used to get additional //method-related information. Target and context data can also be obtained using the InvocationContext instance.

return nextEntry; } catch (Exception ex) {

//Exception handling code goes here.

} }

}

Bermigrasi ke EJB 3.0

The EJB 3.0 (Java Specification Request 220) expert group specifically identified easy migration as an objective and hence provided for both backward compatibility and interoperability between enterprise bean components written in the old and the new specifications. This also makes it possible for EJB 2.x and earlier beans to be gradually and incrementally modified to utilize the EJB 3.0 specification. Interestingly enough, an entire chapter titled "Compatibility and Migration" is included in the EJB 3.0 simplified API specification document.

Some of the possible migration strategies are discussed below.

New functionality in EJB 3.0 with existing code in the old specification

An existing EJB application can be deployed in a container that supports EJB 3.0. The old bean components could be deployed and used without any modification.

EJB 2.x components could call EJB 3.0 components and vice-versa. Some scenarios where the client and server parts of the bean components are of different specifications are discussed below.

EJB 2.x and earlier clients of EJB 3.0 components

Enterprise bean components, which need to work with EJB 2.1 and earlier specifications, don't need to be written using old specifications any more. EJB 3.0 beans can utilize metadata annotations to make them work with older clients that expect to access them using the home and the remote interface. The methods required as per older specifications are mapped to corresponding methods in the enterprise bean written using the EJB 3.0 specification. As an example, the create() method as desired in the old specification could now map to a method that initializes the bean. This example was presented by Linda DeMichiel, one of the specification leads, as part of her Java One 2005 presentation on EJB 3.0.

EJB 3.0 clients of EJB 2.x components

Kacang EJB 3.0 dapat mengakses EJB 2.1 dan biji sebelumnya. Injeksi ketergantungan digunakan untuk menginjeksi referensi komponen EJB 2.1. Panggilan pencarian JNDI dihindari. Setelah pegangan diperoleh ke antarmuka beranda EJB yang diinjeksi, create()metode ini dipanggil untuk membuat instance dan selanjutnya menggunakan kacang.

Kode 4 menyajikan contoh di mana klien EJB 3.0 mengakses komponen EJB 2.1.

Daftar 4

.... ....

@EJB BankingServiceHome bsHome; BankingService bs = bsHome.create(); .... bs.deposit(....); .... bs.getBalance(....); .... bs.doServiceLogout(); .... ....