[ANNOUCE:]New JSF Central Content - Dan Allen on Seam and Sp
Hello,
I'm pleased to announce podcast #6 in the JSFCentral podcast series: Dan Allen on Seam and Spring http://www.jsfcentral.com/articles/allen-08-08.html.
Dan Allen is the author of Seam in Action, and an independent software consultant, author, and open source advocate. He's also a speaker at the JSFOne conference http://www.jsfone.com , this September 4th-6th in the Washington, DC area. Here's an excerpt:
Kito:
I think that makes sense, but don't you think there are also things you can do with the full Spring container that maybe Seam doesn't do so well?
Dan:
Absolutely, Spring does things that - personally I don't think Seam will ever implement. It's a philosophy thing. Seam doesn't really believe in AspectJ. We don't necessarily believe that we need to implement it. That's not to say it's not useful, it just doesn't make sense for us to implement that now. Maybe we will change our mind sometime in the future but for now that's Spring's position and Seam has its position. Why should the developer not be able to take advantage of both? Why should the developer be caught in the middle? The developer doesn't have to get caught in the middle because it is possible to have a much broader technology choice by taking Seam and Spring, putting them together and saying "no matter what the two technologies decide they want to get involved with, I can take advantage of both sides." The reason that Seam doesn't get into AspectJ is because Seam is about trying to make the business components as simple and easy to understand as possible. Annotations... while some people might not think that annotations are elegant, they are very clear. When you put an annotation on a method, and you are a Java developer and you are looking at the method, it is very clear what is going on. In AspectJ because some of the configuration happens externally and is quite complex, you need an advanced or highly talented developer sometimes to understand how that actually gets applied. It is a difference in philosophy; if you are a shop that likes the elegance of Seam in the UI, but you want to use AspectJ for your advanced business components that you have separate developers working on, you can actually integrate the two, and that's a nice thing.
Kito:
I think another thing is all the different utility things that Spring provides. For instance, I have one client that uses stored procedures. Hibernate is not the best thing for stored procedures. Spring does have some stored procedure stuff -- it is okay but it does integrate with iBatus, which is better with stored procedures. For them, for me to say "well why don't you go ahead and use Hibernate?" Well they would say "it doesn't work." But they get more support from the Spring area for that type of development. I think there are some areas... Because Spring is coming more from the integration side of things where Seam is coming more from the application stack side of things, it seems like there are some things you can leverage in the Spring world that you probably won't see in the Seam world, like aspects or some other things.
Dan:
That's a great point. That expanded this discussion a little bit to things I wasn't thinking about right now. You are absolutely right. There are things that Spring has - it could be anything, as simple as a configuration Spring offers to expose a constant as a bean, which is a nice thing and Seam hasn't gotten to that yet. Maybe we will, but we haven't gotten to it yet, so if you want to use it today you can tap into Spring and take advantage of it - which is nice. You have Jasper report generation, and you have a couple other things that - again - Seam hasnt worked on, maybe we haven't gotten to, maybe we won't get to. You get a chance to use those. Seam is very focused on improving Java EE, it's very focused on the technologies that are in the stack, so if you want to use something like iBatus, or a simple JDBC template... Perhaps it's not that you're moving your whole application stack over, maybe you are running some reports in a section of your application and you have determined that for you the report would best be queried using straight JDBC. So hey, you can go over to Spring and do that one thing, and get the services from Spring to run that report. Again, the integration there is nice because you can expose the bean through the EL and then you can access it from JSF, or you can access it from a business process or any of the number of other things where in Seam you are allowed to use EL.
Catch the full interview here: http://www.jsfcentral.com/articles/allen-08-08.html.
Kito D. Mann -- Author, JavaServer Faces in Action
Join me at JSFOne http://www.jsfone.com! The One Conference for the JSF Ecosystem.