9 Replies Latest reply on Feb 7, 2007 2:28 PM by Vinicius Carvalho

    Seam and granularity

    Vinicius Carvalho Apprentice

      Hello there! Just started here, yesterday some folks gave me some help on my first question. Now I have another architectural question: I know I'm free to not use each managed bean as a SLSB, I could use my managed bean as a facade to a remote object and have the SLSB injected inside my managed bean, which would lead me to a coarse grained SLSB. Using each managed bean as a SLSB turns in a very fine grained SLSB. Normally the rule of thumb we use in projects here is to have 1 SLSB per requirement, which groups 3-5 use cases (we have fine grained use cases, we are at sea level according to Cockburn). Now, having so many SLSB wouldn't be a burden for my AS? JBoss has an MBean for each SLSB conteiner right? So in a typical app where I would have some actions/managed beans and few SLSB, I'd change it to a lot of SLSB (maybe not that much) inside my conteiner.

      I'm pretty sure, Seam designers worry about performance. I'm just a pretty concerned about this issue. Am I being paranoid?

      Best regards

        • 1. Re: Seam and granularity
          Hung Tang Apprentice

          I don't know if you are more concerned about architecture or performance here but I assume the latter. When it comes to performance, you need to be more specific (scalability, response time, etc.) and set realistic goals/targets that can be "testable."

          Now I am no EJB expert, but you'll find a better response in the EJB/JBoss forums with this question concerning EJB3 performance. Seam just helps to integrate the technology as you already know. Now it would help make discussions more interesting if you can tell me why you think "having many SLSBs would be a burden for the AS?"

          • 2. Re: Seam and granularity
            Vinicius Carvalho Apprentice

             

            "hstang" wrote:
            (...) Now it would help make discussions more interesting if you can tell me why you think "having many SLSBs would be a burden for the AS?"


            Ok, sorry for the vague question :P

            Ok, regarding performance. Its just a guess, but a SLSB with all the interceptors it has (tx,security etc...) is a bit heavy in terms of processing time and memory usage than a simple managed bean.

            Regarding architecture, its just a question about the granularity of our apps, we use the approach I was talking before, may not be the best, may not be right, and of course I'm willing to change, it was just a question about how could this shift in terms of granularity would impact on our apps.

            Not trying to create any problems, just seeking some orientation.

            Regards


            • 3. Re: Seam and granularity
              Christian Bauer Master

               

              Its just a guess
              \

              Exactly. Without numbers, it's a guess and any attempt to "improve" the situation falls under premature optimization. Especially once you consider how costly data access to a remote DBMS is. If you have numbers that show that a few method calls and some interception is a performance, or even a scalability problem, there is something to talk.



              • 4. Re: Seam and granularity
                Vladimir Kovalyuk Apprentice

                A little bit more ...
                http://jcp.org/en/jsr/detail?id=299


                ...JBoss has submitted JSR 299 - Web Beans to the JCP for review. "The goal of this work is to enable EJB 3.0 components to be used as JSF managed beans, unifying the two component models and enabling a considerable simplification to the programming model for web-based applications in Java. In particular, this work will provide a programming model suitable for rapid development of simple data-driven applications without sacrificing the full power of the Java EE 5 platform. This is a domain where Java EE has been perceived as overly complex." ...


                So, I believe it's the right place for the question. Seam implements JSR 299 that inspires developers to create more enterprise beans. (is it correct?)

                What to do if simple application based on Seam eventually ceases to be simple? Does it become out of the Seam scope?


                • 5. Re: Seam and granularity
                  Christian Bauer Master

                   

                  So, I believe it's the right place for the question. Seam implements JSR 299 that inspires developers to create more enterprise beans. (is it correct?)

                  What to do if simple application based on Seam eventually ceases to be simple? Does it become out of the Seam scope?


                  http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/07/29#simple


                  • 6. Re: Seam and granularity
                    Christian Bauer Master

                     

                    Seam implements JSR 299 that inspires developers to create more enterprise beans. (is it correct?)


                    JSR 299 has not yet released any work, so nobody implements it (because there is so far no specification to implement). Sure, Seam encourages you to write more Enterprise Java Beans. Now that these are plain Java classes in EJB 3.0, why not?


                    • 7. Re: Seam and granularity
                      Hung Tang Apprentice

                       

                      "viniciuscarvalho" wrote:

                      Ok, regarding performance. Its just a guess, but a SLSB with all the interceptors it has (tx,security etc...) is a bit heavy in terms of processing time and memory usage than a simple managed bean.

                      There is no doubt there will be additional overhead when you use EJBs, but this is the cost incurred for the additional services your application requires. If you don't need tx, security, pooling, etc., then managed beans would suffice. I would concur with you that processing time will increase, but the burning question: is it real-world noticeable? Could you afford a few more extra clock cycles for the added benefit of services afforded to you by EJB? It really depends on your requirements and your available resources.

                      As for memory usage, SLSB don't carry any state so they are easier to "scale," at least in theory.

                      "viniciuscarvalho" wrote:
                      Not trying to create any problems,

                      There are no problems caused=)



                      • 8. Re: Seam and granularity
                        Vladimir Kovalyuk Apprentice

                        Christian, the problem is in the fact that Seam provides me with a lot of possibilities of designing JSF<->EJB interchanging. Now I have to try out several approaches on my own and work out my best practices. And someone have to do the same on his/her own.
                        I don't know whether Seam book have a chapter "best practices".
                        What about creating a Wiki page for "JSF Managed EJB best practices"?

                        • 9. Re: Seam and granularity
                          Vinicius Carvalho Apprentice

                           

                          "hstang" wrote:

                          (...) but the burning question: is it real-world noticeable? Could you afford a few more extra clock cycles for the added benefit of services afforded to you by EJB?


                          good point :)