• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Prefer Seam over Spring

 
Ranch Hand
Posts: 2874
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Do you think we should prefer Seam over Spring? If yes then when and why?
 
Author
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
     
    Greenhorn
    Posts: 17
    Mac Postgres Database Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Posts: 17
    Mac Postgres Database Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Oh, and don't forget extended persistence context. Way powerful!!!
     
    ranger
    Posts: 17347
    11
    Mac IntelliJ IDE Spring
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
     
    Adeel Ansari
    Ranch Hand
    Posts: 2874
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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?
     
    Ranch Hand
    Posts: 162
    Hibernate Spring Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Posts: 164
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Posts: 2874
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Posts: 2874
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Posts: 17347
    11
    Mac IntelliJ IDE Spring
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Posts: 2874
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Posts: 164
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Posts: 2874
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Exactly.
    Thanks Dan for being here and good luck with your book.
     
    Mark Spritzler
    ranger
    Posts: 17347
    11
    Mac IntelliJ IDE Spring
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
     
    reply
      Bookmark Topic Watch Topic
    • New Topic