> 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.
