7 Replies Latest reply on Sep 4, 2008 3:07 PM by gjeudy

    No more tiers and layers with Seam?

      Hi,
      my project is building a web app with seam. We often run into problems with Injection/Outjection and performance (especially when using conversation scope).
      It rose the question, if seam completely gives up architectural concepts as layers and tiers. For me it seems, that Seam advices to access entities and EJB SessionBeans from wherever you are.


      I suspect the combination of EJB mechanisms and Seam to be the cause of some of our problems.


      Did anyone think about having an old fashioned presentation tier consisting of pojos that are handled with seam and leaving the SessionBeans to the EJB container? Or am I misunderstanding the core principles of Seam?


      CU,
      Thomas

        • 1. Re: No more tiers and layers with Seam?
          gjeudy

          It should technically be possible to have an old fashioned presentation tier.


          Your session beans can be EJBs or both EJB/seam components. If you dont want your EJBs to be seam components then integration is going to be a little harder. You will have to deal with the following constraints



          • You can only use injection mechanisms supported by the EJB container. i.e.
            @EJB, @Resource, @PersistenceContext





          • You cannot inject session beans in your presentation layer POJOs using Seam, you will have to resort to regular JNDI lookups or if you are using Spring you can probably DI inject with that.




          • And this is where it hurts the most for me. You will find Persistence Context management/propagation alot harder using the regular EJB3 rules and more prone to LIE, detached object problems.



          If you are willing to live with these constraints you can do it but I would recommend using SMPC as it simplifies dealing with the persistence context propagation alot. Unfortunately to use SMPC you will have to make your EJB a Seam component.


          Conclusion: Either way you can still have a separate presentation layer and EJB layer but the later option will make the EJB layer unusable in a non-seam context.

          • 2. Re: No more tiers and layers with Seam?
            benmoore

            Perhaps the problem is conversation scope, not the removal of layers. Adding layers almost certainly never helps performance.

            • 3. Re: No more tiers and layers with Seam?
              gjeudy

              Thats true having layers might not help performance but it can help design and promote the re-use of components.


              I suggest you checkout this excellent post to help monitor bijection performance.


              http://www.seamframework.org/Community/SeamPerformanceProblemRewardingWorkaround


              There is a knowledge gap in the recommended usage of Seam in regards to performance. I think the Seam team had plans to give more documentation in the next major release on how to address typical performance issues.

              • 4. Re: No more tiers and layers with Seam?
                benmoore

                Yes, adding layers enables encapsulation, abstraction, better design and reuse, and lots of other modern software engineering concepts.


                It does not, however, usually help with performance...in fact, it is often detrimental to performance. The original poster asked about performance, not the benefits of layers, hence my reply.


                • 5. Re: No more tiers and layers with Seam?
                  gjeudy

                  Thanks for bringing me back on the right track Ben. :-)


                  ok having layers is often detrimental to performance but I dont think one should forego such a design unless it indeed creates performance issues.


                  So to begin with, the original poster should start by profiling and measuring application performance to find out what precisely is the bottleneck before even thinking about redesigning his architecture.

                  • 6. Re: No more tiers and layers with Seam?

                    Hi!


                    Thanks at first for your posts.


                    I am far from being an EJB specialist, I am more common with the client side.


                    (1) I can't remember having used JNDI on client side, yet. But maybe it was only encapsulated by someone else in my project who knew it better. Before Seam I worked with BusinessFacades and Factories - little Work, so I would not miss Seam for this on client side. My impression is, that Seam is most helpful transporting states between controllers and between views and controllers.


                    (2) If I want to split client and server tier, is there a way to separate the Seam sea of objects into these two parts? Maybe then, one could use Seam separately in both tiers.


                    (3) Guillaumes hint to Tobias' learned lesson just confirms me in my suspect, that its's problematic accessing SBs from the view. Having proper layers would have avoid the problems (so layering would have improved performance).


                    Hoping to learn more from your posts.


                    CU,
                    Thomas


                    • 7. Re: No more tiers and layers with Seam?
                      gjeudy

                      Thomas Nordmeyer wrote on Sep 04, 2008 14:19:


                      Hi!

                      Thanks at first for your posts.

                      I am far from being an EJB specialist, I am more common with the client side.

                      (1) I can't remember having used JNDI on client side, yet. But maybe it was only encapsulated by someone else in my project who knew it better. Before Seam I worked with BusinessFacades and Factories - little Work, so I would not miss Seam for this on client side. My impression is, that Seam is most helpful transporting states between controllers and between views and controllers.


                      You have to use JNDI for lookup only if you are not making your EJBs Seam components, otherwise Seam bijection takes care of it.



                      (2) If I want to split client and server tier, is there a way to separate the Seam sea of objects into these two parts? Maybe then, one could use Seam separately in both tiers.


                      Yes if your client and server tier are colocated in the same Seam application you can certainly do that and use Seam bijection to inject EJBs into your client tier.



                      (3) Guillaumes hint to Tobias' learned lesson just confirms me in my suspect, that its's problematic accessing SBs from the view. Having proper layers would have avoid the problems (so layering would have improved performance).


                      I don't think the issue is with having layering or not. It's just that Seam opens the door for bad usage patterns when referencing Seam components from your view. Once you understand the way these components are resolved in the view you can create non-Seam DTOs or use

                      @BypassInterceptors

                      Seam annotation on your Seam component that hold the data so you don't incur bijection performance overhead when looping in a dataTable for example.



                      Hoping to learn more from your posts.

                      CU,
                      Thomas