Ifnu bima wrote: > HI all, > > tadi malem sambil nonton sepanyol membabat rusia 3-0 gw selingi dengan > percakapan seru sama temen lama yang lagi implement middleware untuk > messaging. > > So far prototype aplikasi-nya sudah jalan okay dan bagus (bisa sampe > 100 transaksi per second, dibanding implementasi delphi yang cuma > 20tps). Ada satu titik dimana kita sama-sama blank tentang mana yang > lebih baik. > > Aplikasi ini handle banyak payment device dengan beberapa protokol > messaging, ada yang iso8583 ada yang simple XML dll, oleh karena itu > setiap device dibuatin handlernya, kemudian setiap handler ini akan > mengirim message ke JMS, so far dya pake Active MQ, performa sangat > bagus dan memuaskan, kemudian untuk consumer messagenya dya bikin pake > aplikasi socket multithreading biasa. Sampe sini kita berdebat seru > dan bertanya-tanya juga nih, gimana kalau JMS servernya pake punya > glassfish dan consumernya pake MDB, apakah lebih bagus arsitekturnya?
Arsitektur sama tapi yang akan didapat adalah kemampuan monitoring GlassFish. Dari kemampuan monitoring ini kita bisa tahu: apakah thread yang kita alokasi sudah cukup? apakah memori yang kita alokasi cukup? Berapa rata-rata waktu response listener kita? Hal ini yang akhirnya menyebabkan saya pindah dari ActiveMQ+Tomcat ke GlassFish. > kalau activeMQ + aplikasi console biasa pasti berjalan di JVM yang > berbeda sehingga memerlukan mekanisme serializable untuk mengirim > data, apa perpindahan ke arsitektur glassfish (MDB) menghasilkan > tuning yang signifikan? Inter JVM dengan intra JVM jelas beda performancenya. > sebenernya aplikasi ini bottlenecknya bukan di bagian messaging, tapi > bagian database processingnya sih, nah so far sih mau implement JDBC > murni dengan memanggil Storedprocedure Oracle, nah kalau koneksi ke > databasenya ini diganti pake EJB3, apa lebih efisien? Supaya bisa lebih efisien kuncinya adalah strategi caching yang tepat untuk pembacaan data dan pemakaian arsitektur async pada saat menulis ke database. Bukan isu stored procedure vs ejb3. > > adakah yang pernah manage aplikasi asychronous yang terdiri dari > beberapa layer aplikasi jalan terpisah di beberapa JVM? kemudian kalau > kita bandingkan dengan environtment EJB3 gimana yah? lebih gampang > dimanagenya atau nggaj yah? > Di tahun 2006 saya membangun aplikasi enterprise berbasis messaging. Ini dibangun dengan messaging listener yang berkomunikasi dengan layer web. Messaging listenernya bisa dijalankan dalam beberapa JVM dan bisa juga dalam 1 VM. Aplikasi ini stateful penuh dan state dimanage aplikasi karena meniru behaviour aplikasi terminal mainframe. Di tahun 2008 saya membangun aplikasi web service yang merupakan interface ke aplikasi mainframe Galileo GDS. Aplikasi ini dibangun dengan fondasi EJB3 stateful session bean. Stateful session bean karena aplikasi ini ada sedikit kebutuhan untuk stateful juga tapi tidak banyak. Aplikasi yang pertama lebih manageable dalam hal resource. Kenapa? Karena jumlah listener bisa dikendalikan secara penuh. Makin banyak transaksi yang perlu di proses paralel maka tinggal menaikkan jumlah listener. Akan tetapi jumlah codenya jauh lebih banyak dari aplikasi yang kedua. Aplikasi yang kedua lebih boros dalam hal resource tapi masalah beres begitu dikasih memori yang berlimpah. Yah Java memang memory monster :-) Kenapa boros? Karena resource management dihandle container EJB3. Dan dia akan alokasi banyak instance pada saat peak load. Baru pada saat idle instance akan dihapus dan di GC. Masalahnya aplikasi ini juga menjalankan banyak proses latar belakang untuk monitoring booking queue sehinggga walaupun tidak ada request dari luar akan tetap ada instance yang dikeep untuk melayani proses latar belakang. Aplikasi yang kedua tadinya jalan dalam environment yang kekurangan memori akibatnya setiap 2-3 minggu down tanpa log apapun. Yang jebol JVM nya. He he he. Sekarang aplikasi yang kedua jalan dalam environment yang berlimpah memori dan bisa jalan berbulan-bulan tanpa restart. Jadi kesimpulannya? Pakai messaging maka resource lebih manageable tapi ada harga yang harus dibayar. Code jadi bengkak. Berapa banyak jika dibandingkan aplikasi EJB3? Yah sekitar 5 kali lipat jumlah code. Kalau ada yang berminat mengakses GDS Galileo lewat web service untuk bisa bikin aplikasi reservasi pesawat khusus bisa lihat-lihat WSDL nya di sini. http://im.galileoindonesia.com:8086/giws/ Dalam waktu dekat aplikasi ini bakal selesai di integrasikan ke sistem reservasi Navitaire Mandala. Jadi lewat 1 web service bisa booking ke Galileo GDS dan juga ke Mandala. Di masa depan besar kemungkinan akan ada integrasi dengan airline lokal pemakai Navitaire dan sistem reservasi lainnya.
