File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Other Application Frameworks and the fly likes Prefer Seam over Spring Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Prefer Seam over Spring" Watch "Prefer Seam over Spring" New topic
Author

Prefer Seam over Spring

Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
Do you think we should prefer Seam over Spring? If yes then when and why?
Dan Allen
Author
Ranch Hand

Joined: Mar 05, 2003
Posts: 164
In the spirit of bipartisanship, I'd like to start off by saying that Seam and Spring are both excellent and proven frameworks. With the advent of Spring WebFlow, Spring has entered itself as a serious contender in the stateful web framework space. You really can't go wrong with either one. So how do you decide then?

Personally, my feeling is that your choice of Spring vs Seam is going to come down to two factors: style of development and architecture. Seam espouses very thin layering, while Spring has always promoted the idea of having a data layer, a business layer, and a view layer. I was an adamant believer in separating out all of my logic the way that Rod Johnson recommended in export one-on-one J2EE Design and Development and subsequent books...until I tried to use it in the real world. Our application grew monolithic extremely quickly, the very type of system that Spring had intended to demolish. It has been said, and I agree with it, that Spring looks frighteningly similar to an EJB container. I was torn over an idea that appeared sound and the reality of my application being very stagnant. That was, until I discovered Seam.

What Seam did was turn the current thinking on its head by encouraging you to stop thinking in terms of view->business->data for every problem and start thinking about the object, its behavior and its state. What type of object, or in Seam terms, component, are you dealing with? What type of state does it hold and what actions can it perform on that state or calculate from it?

Take that idea for a moment and realize that layers will grow organically (meaning they will happen naturally). Now you can take that component and bind it to a user-interface control...a button, a link, a select menu, or a tree. Taking this thinking allows you to get to your application's requirements very quickly. You can develop a component that is accessible from the UI, perform the least amount of work possible (as the agile developers would say) and then mature it as time goes on.

Let's assume that you buy into all of what I just said. What does Seam provide you, perhaps that Spring doesn't? First and foremost, Seam is a contextual container. What does that mean really? It means that first and foremost, Seam understands that the context of a component, its lifetime, is just as important as what the component does. In Spring, you primarily have a stateless container, where objects live for the entire lifetime of the container, and you have to bolt onto the side of that container the idea of shorter-term scopes. It just wasn't designed to accommodate the types of scopes you need in an enterprise application. Seam, on the other hand, has a wide range of scopes built right into its core: event, page, session, conversation, business, and application. This is all a natural part of using Seam.

But to give credit to Spring, WebFlow layers this type of stateful container on top of Spring, so more or less you can get away from Spring's legacy as a stateless container. The main downside of WebFlow in this regard is that it is tightly coupled with navigation (i.e., the flow), so you can't have stateful components and not have the stateful flow. Seam, on the other hands, lets you use stateful components in an ad-hoc manner (i.e., ad-hoc conversations), meaning you create the component on one page and perhaps destroy it later down the road based on a business case.

Putting aside that Spring WebFlow requires you to use a stateful pageflow, and comparing it with Seam on other bases, both solve the most fundamental problem in enterprise applications, management of the persistence context. The persistence context (e.g., the JPA EntityManager or Hibernate Session) is a stateful component. It was intended to remain open for the lifetime of the use case in which you are modifying the entities that it retrieves.

Case in point. You select a record for editing. You modify that record. Then you save it. The persistence context should remain open for that entire use case. Then, the ORM tool (e.g., JPA or Hibernate) can automatically detect changes and push them to the database. Better yet, it can detect when the database has been altered in the interim and prevent those changes from overwriting someone else's changes. There are a whole host of other features, such as persistence by reachability, that simply make the task of database saves and updates completely automated.

But where Seam really steps ahead is in its support for rich rendering. It embraces Facelets and the Unified EL (extended with extra Seam goodies) to give you an XHTML-based approach to creating all of the following:

  • PDF
  • Excel
  • RSS
  • Charts
  • Graphics
  • Email (with attachments that include any of the above)


  • On top of all that, Seam embraces Java EE so that you can take those certifications that you have an apply them in a more effective manner. Seam is not asking you to abandon Java EE, but rather looking for ways to take it to the next level. There are very tight integrations with many of the Java EE services, such as EJB, Timers, and JMS, that work just like any other Seam component. It even has strong integration with Spring, so that you can treat Spring as though it were a consumable service.

    I'll close by saying that we are lucky to have both frameworks as choices. If you talk to the Spring developers, you might end up using Spring & Spring WebFlow. If you talk to me, you might end up using Seam. Personally, I can tell you that I have used both and my most successful projects were those that I developed in Seam. Maybe it suits me better, or maybe it is just a better approach. That's really for you to decide.


    Dan Allen | http://mojavelinux.com | Author of Seam in Action - http://mojavelinux.com/seaminaction
    Raymond Van Eperen
    Greenhorn

    Joined: Oct 07, 2008
    Posts: 17

    I know I can't really add anything to Dan's comments (I've read his book - trust me). But let me reiterate a few points.

    1. Dijection versus Injection is very powerful.
    2. I think there is a tighter integration with the web/presentation tier technologies (JSF, Facelets, Rich/ICEfaces and with the back end technologies (JPA/Hibernate).
    3. I think it's a bit easier to get your arms around and get productive.
    4. Better alignment with JEE - which may be considered a negative since many Spring folks I've talked to want to stay away from EE.
    5. Less code in not having the layer-thing going. I must admit I was a fan of that until recently, but am beginning to see how nice it is not to do it. Maybe because you can do it better with Seam (sounds like an catch phrase). And you can still have sell architected code and separation of concerns.
    6. Not everyone thinks Java standards are all that big a deal, but being the RI for Web Beans is pretty significant to me.

    I'm sure I haven't converted anyone, but those are a few of my thoughts.
    Raymond Van Eperen
    Greenhorn

    Joined: Oct 07, 2008
    Posts: 17

    Oh, and don't forget extended persistence context. Way powerful!!!
    Mark Spritzler
    ranger
    Sheriff

    Joined: Feb 05, 2001
    Posts: 17249
        
        6

    I'd like to add that sometimes it might not be an either/or question. How about using both. Seam created integration with Spring. So you can make a Spring bean into a Seam component, and you can make a Seam component into a Spring bean. And guess what, it is extremely easy to do, the docs in the Seam documentation is like just one page long.

    So you could have Seam handling the UI and conversation state, but the backing beans and back end code be Spring beans. Why not have both worlds.

    Just another perspective to add to the discussion.

    Mark


    Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
    How to Ask Questions the Smart Way FAQ
    Adeel Ansari
    Ranch Hand

    Joined: Aug 15, 2004
    Posts: 2874
    Dan and Raymond,
    Thanks. The responses really provided me some insight.

    Mark,
    Would it be any need there to use both in any case? save, suppose, we are doing an app using Seam and we need to provide things to some other apps already running on Spring.

    With Spring we usually, replace their web part with some other smaller specialized frameworks like stripes and all. That makes perfect sense, though. Or integrating data layer using iBatis/Hibernate/Toplink is another sound case. But why Seam?
    Kuladip Yadav
    Ranch Hand

    Joined: Jul 30, 2008
    Posts: 162

    Originally posted by Mark Spritzler:
    I'd like to add that sometimes it might not be an either/or question. How about using both. Seam created integration with Spring. So you can make a Spring bean into a Seam component, and you can make a Seam component into a Spring bean. And guess what, it is extremely easy to do, the docs in the Seam documentation is like just one page long.

    So you could have Seam handling the UI and conversation state, but the backing beans and back end code be Spring beans. Why not have both worlds.

    Just another perspective to add to the discussion.

    Mark


    Hi Mark,

    Thats excellent idea.
    That will be great if it is possible so we can take advantages of both seam and Spring.
    But is it possible to use both framework in single appliction ?
    Dan Allen
    Author
    Ranch Hand

    Joined: Mar 05, 2003
    Posts: 164
    That will be great if it is possible so we can take advantages of both seam and Spring.
    But is it possible to use both framework in single application?


    Absolutely, that's precisely what I explain in chapter 15 of Seam in Action, which is available online for free (currently a Word document but soon to be PDF).

    http://manning.com/dallen
    Adeel Ansari
    Ranch Hand

    Joined: Aug 15, 2004
    Posts: 2874
    Originally posted by Kuldeep Yadav:
    But is it possible to use both framework in single appliction ?


    Its already there in Mark's response, before your asking.

    Highlighting Mark's response:
    I'd like to add that sometimes it might not be an either/or question. How about using both. Seam created integration with Spring. So you can make a Spring bean into a Seam component, and you can make a Seam component into a Spring bean. And guess what, it is extremely easy to do, the docs in the Seam documentation is like just one page long.
    Adeel Ansari
    Ranch Hand

    Joined: Aug 15, 2004
    Posts: 2874
    Originally posted by Dan Allen:
    Absolutely, that's precisely what I explain in chapter 15 of Seam in Action, which is available online for free (currently a Word document but soon to be PDF).


    Just after start reading it I got my answer. It says,


    Spring offers up a plethora of features that you won't find in Seam. It�s likely that these features�such as lightweight remoting, advanced aspect-oriented programming (AOP) declarations, template classes, and emulated container resource injections, to mention a few�simply aren�t the passion of Seam.


    Thanks, Dan.
    Mark Spritzler
    ranger
    Sheriff

    Joined: Feb 05, 2001
    Posts: 17249
        
        6

    Yes, definitely could use both. Seam for the Web UI layer, to create the JSF pages and Bijection, and have the backing beans call into/ or be Spring beans, so on the Spring side, you have the Application layer with Service and Repository/DAOs.

    Or write the Seam app with Seam backing beans, configure the Seam bean to be your Spring "service" classes that can get Repositories/Daos injected into the Seam component for data access.

    Mark
    Adeel Ansari
    Ranch Hand

    Joined: Aug 15, 2004
    Posts: 2874
    Originally posted by Mark Spritzler:
    Yes, definitely could use both. Seam for the Web UI layer, to create the JSF pages and Bijection, and have the backing beans call into/ or be Spring beans, so on the Spring side, you have the Application layer with Service and Repository/DAOs.

    Or write the Seam app with Seam backing beans, configure the Seam bean to be your Spring "service" classes that can get Repositories/Daos injected into the Seam component for data access.


    Mark, I don't know. But I am not seeing any reason here to use Spring, especially when I chose JSF to go. For application layer, should I look into Spring? Becuase I believe Seam offers, as good as Spring, for that too. Except those already mentioned, in chapter 15, like lightweight remoting, AOP declaration with AspectJ or etc..

    Thanks.

    Thats fair enough.
    Dan Allen
    Author
    Ranch Hand

    Joined: Mar 05, 2003
    Posts: 164
    Adeel, when you arrive at the question you are asking, "Why would I use Spring?" then you have crossed the bridge to Seam and outgrown the need to integrate. Unless there is something in Spring that entices you, you are correct in saying that you don't really need to use it anymore. The integration is most useful for teams that have invested $$$ in a service layer and need to find some way to reuse it if they are going to move to JSF, Seam/JSF, or even Seam/Wicket. If that isn't the case, just stick with Seam.
    Adeel Ansari
    Ranch Hand

    Joined: Aug 15, 2004
    Posts: 2874
    Exactly.
    Thanks Dan for being here and good luck with your book.
    Mark Spritzler
    ranger
    Sheriff

    Joined: Feb 05, 2001
    Posts: 17249
        
        6

    Originally posted by Adeel Ansari:


    Mark, I don't know. But I am not seeing any reason here to use Spring, especially when I chose JSF to go. For application layer, should I look into Spring? Becuase I believe Seam offers, as good as Spring, for that too. Except those already mentioned, in chapter 15, like lightweight remoting, AOP declaration with AspectJ or etc..

    Thanks.

    Thats fair enough.


    While I completely created a Seam app that just used POJOs as backing beans, we didn't need things like a database or transactions, and that whole service and services integration that really is where Seam with Spring on the business logic layer really makes sense, if you don't want to use say an App Server, you can deploy your app in Tomcat standalone. configuring TransactionManager and DataSources are easy in Spring. There is still a huge compelling reason to use both Seam with Spring.

    Mark
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Prefer Seam over Spring
     
    Similar Threads
    Seam Vs Spring
    Is Seam Framework better framework than struts and Spring?
    Seam and persistence context management
    Seam or Spring
    Seam in OSGi Framework