Announcement Announcement Module
Collapse
No announcement yet.
Opinions on JBoss Seam vs Spring Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Opinions on JBoss Seam vs Spring

    I just watched Rod Johnson's presentation in Denmark "Are We There Yet?", and I read some technical reviews of JBoss's Seam functionality. It seems there are several areas of competing technology:
    - Seam's heavy use of annotation vs. Rod's 'perceived' concerns about them
    - Seam's notion of bijection vs dependency injection
    - Rod's preference for moving business logic into the domain layer vs the notion of jBPM (I admit these may be approaches that are more complimentary than competing)
    - Seam's use of EJB (Entity and Session Bean) vs POJO's

    What is the Spring team's take on Seam?

  • #2
    Hello,

    I'm not in the Spring team, and just a newbie in this framework and this forum.

    I'll just give my 0.2 cents (all I have ).

    We're going to use Jsf / Seam / Spring in our company. So perhaps, it can give you some hints.

    The reason why we're going to use Seam is because we want to use Jsf (and this is the only reason).

    To explain the reason in detail :
    Our first purpose was to use Jsf (sandard framework in JEE 5) and Spring (standard de facto integration framework).
    After making several attemtps on experimenting Jsf, it appeared to be (to us) unusable without some add-on framework (i.e missing center functionnalities such as exception handling, poor security handling, conversation or page scope, templating, ...).
    Seam was the only framework we saw which targeted all those points (or perhaps the most of these).

    So the last question was :
    - are we going to keep Spring or just gonna use Seam ?

    We kept Spring because :
    - there's no really wide experience about using Ejb3 as controllers for the moment - but there's a lot of experience using classical (and procedural - not DDD) service pojo layer.
    - we're not only using Jpa in our company - but also jca accessing mainframe (50%/50% each) (so Extended Persistence Context and the new development model for it isn't really usefull for us).
    - it's really wider in scope thanSeam (i.e. scheduling, available templates, security system, ....).

    So we're actually have some pain integrating the 2 frameworks but so far so good... Sure it would be good if Spring provided the same functionnalities than Seam for Jsf but there isn't.

    I hope this helps you

    Comment


    • #3
      there's no really wide experience about using EjB3 as controllers for the moment - but there's a lot of experience using classical (and procedural - not DDD) service pojo layer.
      You can create the same "pojo" (anotated pojos are not pojos?, aren't ejb3 components also pojos? nevermind...) layer with Seam, you don't have to use EjB3 if you don't want to...

      I don't see a huge difference between using "classic" spring service pojo layers or SFSB/SLSB in EJB3 in terms of using them as procedural controllers. The only pain with EJB3 is that you *have* to implement an interface everytime (you should not need to if you don't want to). The big advantage is that you get replication "out of the box" in case you need it. Seam also provides replication for "pojos" but it's a bit invasive, the recommendation is to use EJB3 if you need this. Another huge advantage of SFSB/Seam components is that you can use them as conversational caches in Ajax, wizards or in combination with extended persistence contexts. The integrated ORM support is a killer, super-easy to use. This is great stuff that most applications need out of the box.

      Seam has nowadays support for asynch strategies like java.util.concurrent and Quartz in addition to EJB3 timer service. It also comes with a security framework and extension points for integration with non-JTA transaction environments.


      The best thing about Seam/JSF is that you can build feature rich apps with a fraction of the effort that it would take with other popular MVC frameworks
      Last edited by Manuel Palacio; Jun 13th, 2007, 05:07 PM.

      Comment


      • #4
        Sorry,

        My point was only : if you're goign for Jsf Seam appears an excellent choice.
        If you go for another web framework, stay out of Seam for the moment.

        For Manuel Palacio
        I didn't explained very well my concern about lack of real experience of Ejb 3 :
        - I was not talking about JPA.
        - I was only talking about the statefull session bean and the extended persistence context. With those two components (the SFSB acting as a controller), you can create long running conversation between various user interactions, and you change is commited only when you call the controller method annotatd with @End.
        All changes made to your domain model are kept in persistence context and only commited when the conversation is ended.
        If you go for a Jpa based application, great solution. If not you won't use Extended Persistence Context, and so SFSB will be of lesser use.

        Another point : my container isn't Ejb3 ready. Don't know how many containers are production ready for Ejb3 and how many persons are using it...

        Comment


        • #5
          All changes made to your domain model are kept in persistence context and only commited when the conversation is ended.
          If you go for a Jpa based application, great solution. If not you won't use Extended Persistence Context, and so SFSB will be of lesser use
          Yeah, if you are after fully atomic conversations and no LIEs in views with Seam then you need JPA.
          Last edited by Manuel Palacio; Jun 14th, 2007, 03:56 AM.

          Comment


          • #6
            You should try to compare Seam with Spring Web Flow. It has JSF support and gives an experience closer to Seam than straight Spring can.

            Comment


            • #7
              Speaking of Seam...

              Does anyone know if it possible to do something like @configurable in Seam (e.g. injecting a stateless EJB into an entity bean)?

              Does anyone know (or have theories on) how close the Web Beans (JSR 299) specs are going to be to the current Seam implementation?

              Comment


              • #8
                Does anyone know if it possible to do something like @configurable in Seam (e.g. injecting a stateless EJB into an entity bean)?
                It seems that right now this is not possible. Entity bean components do not support bijection or context demarcation.

                Does anyone know (or have theories on) how close the Web Beans (JSR 299) specs are going to be to the current Seam implementation?
                Seam will be the reference implementation for Web Beans, and is one of the inspirations and sources of ideas for Web Beans.

                So a future version of Seam will implement Web Beans (I imagine it will be the first implementation of Web beans).

                According to Gavin King,
                Guice is another source of inspiration and ideas and, indeed, some features of the current Web Beans draft look more like Guice than Seam. The current design of Web Beans is very much superior to both Guice and Seam, since it draws ideas from both and mixes them together in a very elegant way.

                Comment


                • #9
                  Originally posted by Manuel Palacio View Post
                  It seems that right now this is not possible. Entity bean components do not support bijection or context demarcation.
                  That's a shame. Well, you can always pass in a repository or look it up before using it.

                  Originally posted by Manuel Palacio View Post
                  Seam will be the reference implementation for Web Beans, and is one of the inspirations and sources of ideas for Web Beans.
                  I am sure Spring will have its place but I'm also sure WebBeans + JSF + JPA + EJB + (Facelets, IceFaces and others) will have a significant impact. In a year or so, that is.

                  Comment


                  • #10
                    That's a shame. Well, you can always pass in a repository or look it up before using it.
                    Actually, there's a way to work with rich domain models in Seam. The way to do it is by using the jBPM support provided by Drools, the rules engine. Using this approach services can be declared in .drl (drools) files globally so they can be used whenever entities need them.

                    Still, it would be very convenient to be able to use @In within entities as well.
                    Last edited by Manuel Palacio; Jul 23rd, 2007, 03:12 PM.

                    Comment


                    • #11
                      Originally posted by Manuel Palacio View Post
                      Actually, there's a way to work with rich domain models in Seam. The way to do it is by using the jBPM support provided by Drools, the rules engine. Using this approach services can be declared in .drl (drools) files globally so they can be used whenever entities need them.
                      OK. Good to know. Although quite a heavy price to get rid of some oneliners

                      Originally posted by Manuel Palacio View Post
                      Still, it would be very convenient to be able to use @In within entities as well
                      Yep, it would make the dependencies more clearly visible. Perhaps WebBeans will allow for this, being non-EJB also...

                      Comment

                      Working...
                      X