Interceptor Dalam EJB

Bagaimana caranya jika sebelum atau dan sesudah satu method dapat menyiapkan atau melakukan sesuatu?
Bagaimana membuat class-class service yang kita lebih bersih dari hal2 diluar bisnis proses?

Jika rekan-rekan terbiasa dengan listener class dalam web aplikasi, seperti Session Listener, Request Listener atau Aplication Listener, maka cara kerja mereka sangat mirip jika tidak mau dikatakan sama. Method-method yang didefine sebagai callback akan diinvoke saat sesuatu terjadi, nah sesuatunnya ini tergantung callback yang mana atau apa dan siapa yang memanggilnya.

Dalam Statefull Session Bean (SFSB), Stateless Session (SLSB) , Message Driven Bean (MDB) atau bahkan Entity Bean, mereka semua memliki interceptor yang disebut callback.  Contoh callbak yang hanya dimiliki oleh SFSB adalag @PrePassivate dan @PostActivate. Kedua Callback ini terkait dengan daur hidup dari SFSB yang akan dipassivate saat instance nya, tidak digunakan dan time out agar dapat digunakan lagi nanti oleh clientnnya dan tidak perlu menginstantiate yang baru.

Setiap method yang didefinisikan @PrePassivate diatas methodnya, maka method tersebut akan dipanggil sesaatsebelum SFB tersebut di Passivete. Hal yang bisa dilakukan dalam method tersebut contohnya adalah menyimpan state dari SFSB tersebut. Dan setiap method yang didefine @PostActivate diatas method tersebut akan diinvoke sesaat setelah object SFSB tersebut di activate lagi container. Yang mentrigger SFSB tersebut di activate adalah adanya client yang membutuhkan SFSB tersebut. hal yang bisa dilakukan didalam method tersebut contohnya adalah meretrieve state yang disimpan saat sebelum di passivate. Dalam SFSB juga ada @Remove yang jika dipanggil maka akan memakas container untuk menghancurkan Object SFSB tersebut.

Jika @Prepassivate dan @PostPassivate digunakan oleh SLSB, maka tidak akan berpengaruh apa-apa, karena pada prinsipnya daur hidup SLSB yang mengatur adalah EJB container.

Semua component EJB memiliki callback @PostConstruct dan @PreDetroy. Dari nama annotation sudah kelihatan kapanm mereka diinvoke oleh container. Method yang diannotate @PostContruct dipanggil oleh container sesaat setelah object component EJB tersebut diinstantiate dan sebelum method-method yang lain dipanggil. Ia didedikasikan dan mendapat kehormatan untuk dipanggil oleh container pertama kali, sebelum yang lainnya. Dan setiap method yang diannotate @PostDestroy akan dipanggil sesaat sebelum component tersebut didestory. Ia disiapkan sebegai saksi dalam eksekusi penghancuran hisupnya component EJB.

Khusus untuk component Entity Bean, mereka memiliki callback tambahan yang terkait dengan data persistent milik mereka. Method @PostLoad akan dipanggil sesaat setelah data dari persistent diload kedalam object yang di intance. Hal yang bisa dilakukan dalam method ini contohnya adalah mengubah data type dan mengkonversinya sehingga dapat diassign pada member variable yang diannotate @Transient.

Selain  itu Entity Bean juga memiliki callback yang dapat ditebak kapan method tersebut akan dipanggil, yaitu;

@PrePersist, @PostPersist, @PreUpdate, @Postupdate , @PreRemove dan @PostRemove. Callback ini semua dapat digunakan untuk mencatat aktivitas yang terkait dengan table, misalnya mencatat siapa yang melakukan update satu data dan kapan terakhir diupdate, yang akan sangat penting untuk kepentingan audit.

Objective 3, Session Bean bagian 2

Bagi client, session object adalah non-persistent object yang mengimplement bisnis logic dalam server. Dengan kata lain sesion object logical extention bagi program client yang berjalan di dalam server. Session object tidak di share antara client satu dengan yang lain (jika clientnya lebih dari satu).

Sesuai namanya SFSB (Statefull Session Bean), mempertahan state-nya untuk sebuah session dan tidak akan di share yang berbeda dengan SLSB (Stateless Session Bean) yang disimpan dalam pool.

Setelah kita menyentuh bagaimana permukaan session bean dalam EJB pada bagian pertama, coba kita lebih dalam lagi pada bagian ini  mengenai Lifecyclenya.

SFSB  memiliki callback interceptor method PostConstruct, PreDestroy, PrePassivate,  dan PostActivate. Ketiga lifecycle callback interceptor methods dapat digunakan oleh SFSB, sedangkan untuk SLSB PostConstruct dan PreDestroy, dan jikalaupun ada kedua callbacak interceptor method (PoastActivate dan PrePassivate) di SLSB, maka callback ini akan diabaikan.

Sekali lagiPrepassivate dan PostActivate khusus hanya untuk SFSB.!

sesuai namanya, method-method callback tersebut akan digunakan (invoked)

PostConstruct akan dipanggil sesaat setelah di buat objectnya dan sebelum ada bisnis method yang dipanggil.

PreDestroy akan dipanggil sesaat sebelum object tersebut diclaim oleh GC atau dihancurkan

PrePassivate dipanggil sesaat sebelum SFSB memasuki phase passive (ingat, yang memanage lifecycle SFSB adalah bean container)

dan PostActivate dipanggil sesaat setelah diaktifkan kembali dan sebelum method yang lainnya dipanggil.

Kebutuhan data pendukung pengambillan keputusan bisnis

Penggunaan IT pada setiap organisasi untuk mendukung jalannya operasionalnya adalah suatu hal yang tidak bisa dipungkiri, terutama organisasi-organisasi bisnis. Dari mulai toko kecil alfamart/idomart/ceriamart di pasar hingga gerai besar semacam Giant, Carrefour menggunakan aplikasi POST (Poin Of Sale Transaction). Dibidang airline dengan aplikasi reservasi, hingga bisnis support semacam loyalty program tidak lepas dari software untuk menjalankan bisnisnya. Implikasi dari adanya software-software yang bersifat data centric (aplikasi tersebut menyimpan data dan biasanya dalam database) adalah tumpukan data transaksi yang tidak informatif dan tidak penting bagi stakeholder alasannya karena stakeholder memerlukan informasi yang agregate dan menggambarkan kondisi organisasi bisnis saat ini yang memerlukan data tidak hanya dari satu sumber (satu aplikasi operasional) tapi sebisa mungkin dari hampir setiap departement/bagian organisasinya sehingga bisa dijadikan dasar untuk pengambilan keputusan.

Banyak jalan menuju Mekah, banyak cara untuk memberikan informasi bagi stakeholder diantaranya dengan mengandalkan reporting dari setiap aplikasi. Hanya saja tidak feasible karena stakeholder perlu menggabungkannya setiap report yang digenerate dari setiap software yang dimiliki organisasi tersebut. Cara yang paling feasible menurut saya adalah dengan membangun data warehouse.

Data warehouse adalah salah satu tahapan dalam penggunaan data yang ekstensive untuk mendapatkan keunggualan kompetitif yang sukar ditiru oleh organisasi lain. Ingat, saat suatu keunggulan mudah ditiru, maka keunggulan tersebut akan cepat menjadi komoditas dan tidak bisa dijadikan kekuatan dalam persaingan bisnis. Tahap setelah data warehouse tentunya adalah data mining.