[ajug-members] Opinions on a project re-write - To EJB3 or Not

[Charlie Walker]

Ok, I'm gonna weigh in on the ejb3 side.  Our company's been using standard
JEE components for the last 7 years and until ejb3 was released I would have
probably agreed with an investigation of spring.
Over the past couple of years, we have been early adopters of jee5 solutions
such as ejb3 and jpa and have found them easy to program, configure and
scale.  With the modularity of appservers like jboss and glassfish,
a JEE appserver no longer has to be a heavyweight solution. While Les feels
comfortable know that spring "has his back", I have that same feeling using
JEE standards.

Just my 2 cents,
Charlie

On Fri, May 23, 2008 at 2:56 PM, Les Hazlewood <les at hazlewood.com> wrote:

> I'm a huge fan of Spring as well.  Spring is essentially a superset of
> JEE 5, giving you more options if you ever need them.  For messaging,
> I also use message-driven POJOs and that is my preferred approach.
>
> Spring also supports annotations, just like in JEE, so there's no
> reason to not use Spring if you prefer that mechanism of
> configuration.  Also with all the 3rd party integration and simplified
> APIs provided by Spring out of the box (remoting, JDBC, Hibernate,
> JPA, etc, etc, etc), there is a massively comforting feeling as an
> architect knowing that Spring 'has my back' should I ever need to
> approach a scenario or use a tool that I may not have encountered
> before.  You can't underestimate this value since system resiliency
> over time is an extremely difficult thing to achieve, but desired by
> everyone.  I feel Spring gives me this piece of mind like nothing
> else.
>
> The Spring API is beautifully documented, inherently intuitive and
> extremely capable of enabling hooks for any custom behavior you might
> ever need.  I've developed every single app I've done in the last 4
> years on Spring/Hibernate and I've never looked back nor ever
> questioned my decision.  My focus nowadays is finding new frameworks
> and tools that make existing tasks even easier (Wicket, Click,
> Grails).  Almost all of these work in Spring or already have Spring
> integration, so my programming life just keeps getting better.
>
> There is a learning curve with Spring, as it is a 'kitchen sink'
> framework - it supports almost anything you need, but you must pick
> and choose what you use and when.  In my experience however, the
> learning curve is gradual and you're able to accumulate knowledge over
> time, instead of feeling like you'll need to spend 2 weeks reading
> books before you ever write a line of code.  I promise that if you go
> with it, you'll be quite satisfied.
>
> Finally if you need a vote of confidence for production applications,
> many extremely mission critical banking, airline, and educational
> applications run on of top of just Spring and Hibernate inside Tomcat.
>  I've written many of these exact systems for my clients and they're
> able to handle massive transactional or data volume as capably as
> you'd hope for.
>
> Good luck!
>
> Les
>
> On Fri, May 23, 2008 at 1:56 PM, Rob Worsnop <rworsnop at gmail.com> wrote:
> > If it's a rewrite, using Spring is a no-brainer in my opinion.
> >
> > Don't forget that you can use Spring in a full JEE container if you
> > want to. There's no problem with integrating the container's
> > transaction manager with Spring. And, of course, you can use Spring's
> > JmsTemplate with any JMS implementation. If you use JBoss, you can
> > even inject its transaction-scoped EntityManager into your Spring
> > beans. (I assume this is also possible with other containers.)
> >
> > I'd also look into Spring's "message-driven POJOs" as an alternative to
> MDBs.
> >
> > On Fri, May 23, 2008 at 12:31 PM, Rick <rickcr at gmail.com> wrote:
> >>
> >> We have older EJB2/JBoss3.2.6/Hibernate(2?) application that
> >> needs to updated.  We have the opportunity to rewrite the
> >> application and I'm having some trouble deciding what technology
> >> stack I want to go with. (GUI front end is already in Flex and
> >> that's staying.)
> >>
> >> The system will rely heavily on JMS (for communications with
> >> another server that handles a lot of workflow stuff) and will also have
> to
> >> support some external calls into the system (from within the
> >> company) which are currently remote EJB calls, but there isn't a
> >> problem changing to some other contract.
> >>
> >> I'm basically debating about an EJB3 vs a
> >> Spring(Hibernate/or iBATIS)/SpingJMS/webservice solution.
> >> I've messed around with EJB3 some and find it quite easy to use,
> >> but haven't used it for a production application. I won't have
> >> transactions that cross databases either. I haven't used
> >> SpringJMS so not sure how robust and configurable it is? One
> >> thing for sure, is this application will have to be easy to
> >> scale. I could also do a combination approach where I use Spring
> >> managed transactions in pojos but leverage the EJB3 MDB stuff.
> >> That sort of seems like a waste though. Coding EJB3 stateless
> >> session beans is so easy now, that if I'm already using their
> >> MDBs, I might as well go in for the whole ball of wax?
> >>
> >> Just curious on any opinions. on-list or off-list is fine. Thanks.
> >>
> >> --
> >> Rick
> >>
> >> _______________________________________________
> >> ajug-members mailing list
> >> ajug-members at ajug.org
> >> http://www.ajug.org/mailman/listinfo/ajug-members
> >
> > _______________________________________________
> > ajug-members mailing list
> > ajug-members at ajug.org
> > http://www.ajug.org/mailman/listinfo/ajug-members
> >
>
> _______________________________________________
> ajug-members mailing list
> ajug-members at ajug.org
> http://www.ajug.org/mailman/listinfo/ajug-members
>



-- 
Charlie Walker - Registered Linux User #62358

"Now and then we had a hope that if we lived and were good, God would permit
us to be pirates." - Mark Twain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ajug.org/pipermail/ajug-members/attachments/20080525/fe16580e/attachment.html