+1, jarang2 nih dukun tulisannya bisa dimengerti kekekekkeke :D 2009/5/11 sm96 <syaiful.mukh...@gmail.com>: > > > Bedanya, kalo pake SFSB, state bisa diakses langsung dari komponen EJB > manapun. > kalo state disimpan di HttpSession, state mesti dikirimkan berulang > kali ke EJB instance > mana saja yg membutuhkannya, sesering pemanggilan ke EJB instance yg > dilakukan. > kalo dipandang dari sisi client, benefit penggunaan SFSB atau > HttpSession tidak begitu > kelihatan perbedaannya. Tetapi SFSB sendiri akan kelihatan benefitnya jika > diperlukan oleh komponen EJB yang lain jika mau menyimpan state2 > tertentu yg diperlukan. > Adakalanya state ini tidak seharusnya disimpan di database, walaupun > sebenarnya > bisa aja kita bilang, statenya bisa disimpan di database saja. > Selama, webapp dan EJB deployment dilakukan di satu server yg sama, > maka penggunaan > HttpSession atau EJB SFSB tidak begitu kelihatan bedanya. Akan benar2 > terasa, jika ternyata > deployment webapp dan EJB komponen dilakukan di beberapa server yg > terpisah (distributed). > Sehingga tidak bisa dihindari jika diperlukan bagi EJB untuk menyimpan > state2 tertentu > yg diperlukan, maka harus disediakan EJB khusus untuk itu, tidak lain > tidak bukan salah satunya > adalah dengan SFSB. kalo udah bener2 distributed seperti ini, akan ada > overhead di sisi network > traffic kalo masih dipaksakan state disimpan di HttpSession jika > ternyata state2 tertentu > diperlukan antar EJB instance saja. > Singkat kata, mau pake HttpSession atau SFSB, tergantung kebutuhan. > Kadangkala kalo pake single deployment satu paket web + ejb dalam satu > server yg non distributed > penggunaan SFSB keliatan overkill. silahkan saja kalo mo pake HttpSession > mungkin untuk kasus Endy ternyata lebih cocok pake HttpSession. > Dan karena keseringan kita develop aplikasi adalah web based dan gak > selalu bener2 enterprise-grade > jadinya fitur2 enterprise yg rada-rada high-end sering dihujat habis2an > sesekali lirik ke enterprise level development yg beneran. kalo emang > gak butuh, gak ngelirik > juga gak papa. > > 2009/5/10 Achmad Arif Rachim <a...@rach.im>: > >> >> >>> Uummm.. kalo gini ujung2nya sama kayak yang di bilang Pak Endy dong.. >>> Ujung2nya pake HttpSession juga.. Jadi "kegunaan" dari SFSB sendiri jadi >>> hampir ga ada??? Ujung2nya memanage dan memantain Http Session juga... >> >> Menggunakan HttpSession untuk webapp agar reference object terhadap >> SFSB tidak hilang. Balik ke cerita awal, penggunaan SFSB, IMO lebih >> efisien ketimbang menggunakan VO yg di simpan di HttpSession. (Kasus >> session replication). >> >> Kalau objective kamu hanya menyimpan state, ya ga perlu SFSB. Tapi >> kalau sudah mempertimbangkan faktor2 seperti penggunaan JPA juga >> Transaction, nah SFSB comes in handy. >> >>> >>>> 2. Alternatifnya, kamu menggunakan Controller yg memiliki Scope >>>> Conversation, seperti kebanyakan framework jaman sekarang. >>> >>> Kalo ini mah ya sudah jelas.. >>> >>> Berarti kalo gitu, design awal (Java EE 1.2, 1.3) Stateful Session Bean >>> itu >>> dibuat dan diciptakan bukan untuk dipake sebagai native web app component >>> ya? Tapi untuk desktop app? >> >> Engga juga, SFSB kan awalnya diciptakan agar kita bisa menempatkan >> business logic terpisah dari clientnya. Client disini bisa webtier, >> atau desktop application. Kalau kamu inget J2EE core pattern jaman >> dulu, ada istilah SessionFacade. >> >> Stateful Session Facade Strategy >> A business process that needs multiple method calls to complete the >> service is a conversational business process. The conversational state >> must be saved between each client method invocation. In this scenario, >> a stateful session bean may be a more suitable approach for >> implementing the Session Facade. >> >> Nah kata kuncinya ada disini "A business process that needs multiple >> method calls to complete the service is a conversational business >> process." Jadi kalau kamu butuh aplikasi seperti wizard page, >> penggunaan SFSB sangat bermanfaat. >> > > -- > syaiful.mukhlis > gtalk:syaiful.mukh...@gmail.com >
-- Warm Regards, Arif Rachim
