perlukah EJB ?

Ini adalah ulasan dari seorang java developer tentang kefanatikan terhadap EJB dan realitasnya.

Saya tidak mengerti mengapa masih ada orang terobsesi dengan teknologi EJB ???

In my humble opinion, kecuali kita adalah aplha geek programmer, atau kita tergantung IDE yang canggih, percayalah ..... membangun EJB adalah painfull. Dan sebagai J2EE programmer (kecuali kita orang marketing) pastilah kita merasakan betapa complexnya metadata EJB, kita harus menyentuh 4 file untuk membangun satu component ejb (Remote:Local:Bean:Metadata). Lalu apakah yang akan kita dapatkan ? EJB menjanjikan tradeoff yang sebanding ?

EJB adalah teknologi yang powerfull kita mengakuinya dan juga semua orang yang terlibat.Saya termasuk salah seorang (kalau boleh dibilang) dulunya EJB Fanatik. Bahkan untuk membangun aplikasi J2EE yang sederhana saya gunakan EJB. Tetapi seiring dengan berjalannya waktu, applikasi yang dibangun sangatlah sulit diimplementasikan menggunakan EJB. Kita tahu betapa terlalu sederhananya CMP-QL, betapa borosnya BMP, betapa tidak bermanfaatnya SFSB (10 Fallacies Of Distributed Computing) dan hanya SLSB yang umumnya sering kita manfaatkan. Sehingga tidak jarang orang mengorbankan WORA karena keterbatasan EJB dengan spesifikasi dan teknologi supplement dari Vendor.

Contoh sederhananya, bagaimana kita bisa melakukan mekanisme paging 1000000 row jika menggunakan CMP ? kecuali kita menggunakan DesignPattern ValueListHandler yang notabene tanpa menyentuh EJB CMP sama sekali. (Jika ada programmer yang membuat program untuk melakukan MASS CREATE /READE /UPDATE /DELETE menggunakan EJB CMP/BMP maka salahkanlah kebodohan Architectnya yang sudah termakan orang marketing). EJB adalah salah satu alasan yang membuat J2EE tercoreng ,... sama seperti Applet menghancurkan nama besar Java.

Lalu bagaimana solusinya, ... tiap vendor memiliki spesifikasi yang berbeda2. JBoss-QL tidak dapat dimanfaatkan dalam web logic. Fitur web logic tidak dapat di implementasikan kedalam Web Sphere. Apa yang dijanjikan java WORA ... tidak dapat diimplementasikan dalam dunia nyata. Sehingga J2EE developer sangat tergantung pada vendor, ada yang sangat tergantung web logic, web sphere, sun appServer,oracle appServer bahkan JBoss.

EJB Sangat powerfull apakah seperti demikian ?.... sebagian orang menganggapnya steik diantara burger. Seperti roket dibandingkan pesawat, seperti limo daripada sedan.

Anggapan orang yang fanatik dengan EJB mengatakan distributed object adalah dasar Distributed Computing. Jika kita memang membutuhkan scalable serta distributed application yang vendor denpendent, java oriented, dan performance neglected EJB adalah solusi yang tepat. Apa yang saya maksud adalah infamous sun example Java PetStore. Kalau boleh dibilang PetStore adalah over engineered technology yang gagal.

Lalu apakah EJB Memang begitu powerfull sebagai distributed object. Apakah dengan meng-clustering EJB maka performansi meningkat ? Jika anda adalah programmer dan tidak termakan marketing sesungguhnya dengan mengcluster EJB dan berharap banyak pada remote interface hanyalah hitungan2 dalam teori.

Jika kita berharap terlalu banyak pada EJB sebagai distributed object dengan harapan scalable .... sebenarnya dapat saja terjadi SEANDAINYA 10 Fallacies Of Distributed Computing sudah tidak berlaku. Poin dari 10 fallacies of distributed computing (Effective Enterprise Java:Ted Neward)

1. The network is reliable

2. Latency is zero

3. Bandwidth is infinite

4. The network is secure

5. Topology doesn't change

6. There is one administrator

7. Transport cost is zero

8. The network is homogeneous

9. The system is monolithic

10.The system is finished

Berharap banyak pada remote EJB sebagai distributed object akan berhadapan dengan enterprise Fallacies. Tradeoffnya,.. performansi, resource, effective dan efficiensi menjadi terbengkalai. Padahal tujuan utamanya EJB adalah memudahkan mengembangkan Enterprise Scale System. Ternyata semuanya itu adalah keliru.

Bahkan Sun Microsystem secara tidak langsung memohon maaf kepada EJB Developer dengan mengeluarkan spesifikasi Local Interface pada EJB. Dimana distributed object yang sangat diagung2kan oleh EJB seandainya mereka harus mengeluarkan spesifikasi Local Object EJB,... dimana lagi distributed object sebagai dasar Enterprise jika harus menggunakan Local Object.

Untuk apa "SessionFacade" jika memang distributed object dengan mengexpose entity secara remote memudahkan jika alasannya sekedar memindahkan business logic di ejb container.

Untuk apa "TransferObject" seandainya attributenya sama seperti Entity Beans

Untuk apa "ValueListHandler" diciptakan seandainya Entity Beans memang Enterprise Entity.

.......... tidakkah kita sadari ini ? Teknologi dan DesignPattern yang ditawarkan sun secara tidak langsung menyarankan kita untuk meminimalisir penggunaan remote ejb,.. kemampuan sesungguhnya EJB dengan remote interface.

Hemat saya, sebagai sesama developer, ilmu selalu berkembang ... dan jangan sampai kita tidak mengikutinya. Buka mata, telinga dan hati. Jangan takut menghadapi perubahan, ... jika pernah mengikuti seminar "Who moved my cheese" kita sebagai programmer bagaikan tikus yang harus siap menghadapi perubahan, ejb 2 adalah masa lalu. Sekarang kita berharap pada EJB 3. Tetapi selagi menunggu tidak ada salahnya mempelajari teknologi yang lain, yang menjanjikan.

Semoga email ini tidak memacu flame. Dan saya tidak tertarik untuk diskusi berkepanjangan, mohon maaf jika ada reply tidak akan saya "entertain". Tetapi saya bertanggung jawab atas setiap kalimat yang saya tuliskan. Ini sekedar bahan renungan saja.

Penulis:
Ahmad Arif Rachim