10 Replies Latest reply on Feb 20, 2007 8:13 AM by pmuir

    SFSB vs SLSBs for implementing actions in a conversation

    lawrieg

      Hi,

      One thing that is still confusing me with Seam is when you should implement your conversational action methods in one stateful session bean and when you should choose to implement them in one or more stateless session beans.

      What are the advantages / disadvantages of each approach?

      In what scenario would you choose SFSB over SLSBs, and vice versa?

      Thanks,

      Lawrie

        • 1. Re: SFSB vs SLSBs for implementing actions in a conversation
          pmuir

          Just to complicate it even further you can use Seam managed JavaBeans with methods marked @Transactional and an SMPC instead (these are by default conversational - e.g. EntityHome). I tend to use these instead of SLSB/SFSB

          • 2. Re: SFSB vs SLSBs for implementing actions in a conversation
            lawrieg

            Thanks for your reply Pete. Could I ask why you prefer this strategy over using SFSB or SLSBs?

            I can't seem to find anything in the docs or by searching the forums that gives an idea as to how to choose the most appropriate strategy for a particular app, so I'd be really grateful for any advice you can offer me as I'm feeling a bit lost... Or perhaps there is some helpful documentation / forum posts that I've missed to which you could point me?

            Many thanks,

            Lawrie

            • 3. Re: SFSB vs SLSBs for implementing actions in a conversation
              christian.bauer

              Well, since you need to keep conversational state somewhere, that would only be possible with a SFSB. I don't see how SLSBs can do the same? Sure, you can hold your conversation state in some other components and inject/outject them on your SLSB on every method call, but why would you when there are SFSBs?

              The EntityHome etc. components that come bundled with Seam are equivalent to conversational SFSBs, they are implemented as conversational Seam-managed JavaBeans because not everybody who wants to use them has an EJB 3.0 container.

              • 4. Re: SFSB vs SLSBs for implementing actions in a conversation
                lawrieg

                Thanks Christian - So if I understand you correctly, you are saying that your first choice would always be to use SFSBs unless you were not running in an EJB3 container, in which case you would be limited to using the built-in Seam components (EntityHome, etc) to hold conversational state?

                But there's no reason you shouldn't use EntityHome and the other Seam Application Framework components if you are running under an EJB3 container, right?

                Regards,

                Lawrie

                • 5. Re: SFSB vs SLSBs for implementing actions in a conversation
                  pmuir

                  Tbh I haven't found much difference between one strategy and the other - you don't have to write interfaces with Seam Java Beans (+1), its fewer annotations, and I generally have no need of anything a SF/SLSB gives me over a JavaBean ( + I use the EntityHome/EntityController stuff very extensively and the SF/SLSB's and they don't fit together very neatly atm).

                  • 6. Re: SFSB vs SLSBs for implementing actions in a conversation

                    SLSB's work pretty well when everything is passed through request parameters, because the resulting page is always bookmarkable. Search pages are great with SLSB's. SFSB's on the other hand are great for wizards and carts, and pretty much anything you would stick into the session.

                    There's a school of thought that believes you should do everything in stateless beans, but the same school tends to love shoving everything into the HTTP session to compensate. This always struck me as a giant leap backward ... thankfully Seam came around to make SFSB's cool again, and conversations are, well, the main reason I use Seam.

                    As for whether to use SFSB's or plain JavaBeans, I expect that when Seam is renamed to EJB4, the distinction between EJBs and POJOs will go away entirely ;)

                    • 7. Re: SFSB vs SLSBs for implementing actions in a conversation
                      lawrieg

                      I've been mulling over all the posts overnight and I have to say that I'm still a little bit confused...

                      If I understand correctly, what is being said is that there are three quite different approaches to take when writing Seam apps (but you might use 1 & 2 together):

                      1. Implement all your conversational code in Stateful Session Beans. Each SFSB will implement a number of related use-cases (conversations). You would use an EJB3 Extended Persistence Context which has the scope of the SFSBs lifetime.

                      2. Implement all your conversational code in SLSBs and hold your conversation state in some other components and inject/outject them on your SLSB on every method call. You would use the Seam-Managed Persistence Context as this has the scope of a conversation. (Although, like Christian says, this seems like making work for yourself unless you are passing very small amounts of state and want bookmark-ability)

                      3. Implement all your conversational code using Seam-managed Javabeans. You would use the Seam-Managed Persistence Context as this has the scope of a conversation.

                      Now where I'm getting bit lost (and I might be being a bit thick because I'm full of flu and didn't get much sleep last night) is how you would actually implement the Seam-managed Javabeans approach. How does Seam know to make a regular Javabean into a Seam-managed Javabean (and does this bean now basically mimic a SFSB but with Seam storing its state in the Session)? Have you got to extend EntityHome to get this functionality?

                      Also, if you were going the SFSB or the Seam-managed Javabean route, would you tend to implement all the related use-cases (/conversations) for a particular business area in the same one bean? Say you also had a requirement to display a list of Customers (and provide each row with view, edit, delete links), would you implement this functionality in the same bean as well?

                      Cheers,

                      Lawrie

                      • 8. Re: SFSB vs SLSBs for implementing actions in a conversation
                        pmuir

                         

                        "lawrieg" wrote:
                        Now where I'm getting bit lost (and I might be being a bit thick because I'm full of flu and didn't get much sleep last night) is how you would actually implement the Seam-managed Javabeans approach. How does Seam know to make a regular Javabean into a Seam-managed Javabean (and does this bean now basically mimic a SFSB but with Seam storing its state in the Session)? Have you got to extend EntityHome to get this functionality?



                        @Name("foo")
                        public class Foo {
                        
                         @In(create=true)
                         private EntityManager entityManager;
                        
                         @Transactional
                         public void bar() {
                         // Do some SMPC related operation
                         }
                        
                         ...
                        
                        }


                        Also, to make life easier, you could just extend EntityController.

                        • 9. Re: SFSB vs SLSBs for implementing actions in a conversation
                          lawrieg

                          Thanks again for your help Pete - I feel I'm getting close to that "A-ha!" moment...

                          Are you saying that all you have to do to make a Seam-managed Javabean component is inject EntityManager and mark all methods as @Transactional and it will then give you the same behaviour as a SFSB (i.e. the only difference is that Seam handles storing and fetching the component's state from the Http Session instead of SFSBs EJB container-managed state management)?

                          I suppose what I am really trying to grasp is whether you can use a Seam-managed Javabean component exactly like you would a SFSB? Or do you have to code your apps differently?

                          Cheers,

                          Lawrie

                          • 10. Re: SFSB vs SLSBs for implementing actions in a conversation
                            pmuir

                             

                            "lawrieg" wrote:
                            Are you saying that all you have to do to make a Seam-managed Javabean component is inject EntityManager and mark all methods as @Transactional and it will then give you the same behaviour as a SFSB (i.e. the only difference is that Seam handles storing and fetching the component's state from the Http Session instead of SFSBs EJB container-managed state management)?


                            From a user perspective, yes.

                            I suppose what I am really trying to grasp is whether you can use a Seam-managed Javabean component exactly like you would a SFSB? Or do you have to code your apps differently?

                            Basically yes, it works the same.