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

[SilverAnvil]

I'm not an expert and I don't play one on TV, but here's my opinion. this is
an interesting discussion, and I think both sides make good points. I also
think we're way off track.

In getting back to the original question - and side-stepping some of the
controversy - I'd say Rick should go with JEE5 unless there's some
business-based reason for digging into Spring and here's the reasoning
behind my (possibly inflammatory) statement:
  1) Based on what he's said, there are external systems making calls to
EJBs. Even though there "isn't a problem changing to some other contract" -
his words - doing so will require someone to write new code. That code has
to be tested, fixed, and deployed to production - but the deployment has to
be synchronized with the release of the new system. All that costs extra
money to do.
  2) If you rewrite the system using Spring, it probably means a redesign as
well. Otherwise you're not going to take advantage of the goodies Spring can
offer. That's more time and a greater risk - because the team isn't already
familiar with Spring.
  3) It should take less time to rewrite the system using JEE5 because most
of it can stay the same. If that's the case then Production Support and QC
will also have an easier time because the new system will work in much the
same manner as the existing one.
  4) Using Spring ties you to a single vendor - though it is open source and
(as I understand it) there are lots of companies offering support.
  5) JEE5 is a standard and you're not tied to a specific vendor. You can
use an open source offering like JBoss or GlassFish and change to some other
implementation if you wish. With JEE 5 you can change some of the underlying
pieces (like switching out Open JPA for Hibernate or OracleLink) if you wish
so you have some of the flexibility Spring offers you in that area as well.

In short, I don't see anything in Rick's original message that indicated a
good business reason for switching from J2EE to Spring. If there's a
compelling business reason for using Spring then go with it; otherwise
upgrade to JEE 5.



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
>



-- 
"The only rules that really matter are these: what a man can do and what a
man can't do." Captain Jack Sparrow
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ajug.org/pipermail/ajug-members/attachments/20080529/ed7b4417/attachment.html