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
