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

[Rick]

Thanks for the continued comments... some inline below...

On Thu, May 29, 2008 at 4:47 PM, SilverAnvil <silveranvil at gmail.com> wrote:

>   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.

After analyzing it a bit further (I'm new to the project) the calling
code is so extremely minimal. The system is called externally from
only one app with one remote ejb call. It's also not a critical piece
in the overall scheme and can easily be replaced. Just stating that up
front since I don't want it to influence the discussion too much.

Now, the messaging pieces, those will be important to remain. Another
system that is tightly integrated with the app relies on jms (as well
as notifications back) so that can't go anywhere. From that standpoint
of integration it's a must (at least for right now.)

>   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.

True to an extent, but JBoss4 will also be a new beast compared to
JBoss3 (all new config files from what I gather, etc.) I've worked
with Spring some but only in a fairly light sense (simple injection of
daos into pojos and for help with my ibatis layer.) Only point I'm
getting at here is that I'd assume an equal level (or lack-there-of)
knowledge about a Spring solution and/or a pure EJB solution.

>   3) It should take less time to rewrite the system using JEE5 because most
> of it can stay the same.

Well, truthfully, I plan to fix a lot of it - including having the
whole thing in a maven structure as well. The only pieces that will
probably remain are the business logic pieces. Even if I stick with
hibernate or JPA, the persistence layer has to be revisited since it
was written during the early stages of hibernate and the crew that
worked on it was new to using Hibernate. (I'm actually not a hibernate
expert or particular fan myself, having always felt more comfortable
with iBATIS - but I'll probably bite the bullet and give the
ubiquitous hibernate a a full-blown try  - not 100% positive though.)

>   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.

Ha don't we wish:) that's actually my biggest beef about Sun and the
jee stuff coming out. You are still always tied to a vendor. Even look
at the quote by Bauer on amazon in regard to some comments people had
about the Java Persistence with Hibernate book with a complaint about
the book blending too much JPA with Hibernate:

"So, the trick is to find the right balance between mixing and
separating Java Persistence and Hibernate. I still think that,
especially from a practical point of view, I made the right decisions.
In practice, it is really not possible to write a sophisticated
application without using a vendor-specific feature. You need extra
options of the implementation you picked, be it Hibernate or some
other provider."

So how does the JPA spec help us that much? We still end up tied to a
vendor whether it's hibernate or toplink, etc. How easy is it to drop
an ear created for weblogic into JBoss or Glassfish? Fortunately I
don't care that much in this case about being tied to a vendor, but
the concept that JEE5 doesn't tie you to a vendor I don't find that
true.

> 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.

(see comment above.)

> 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.

I probably should have  stated my initial question better. For the
sake of this discussion, let's assume this is a brand new application,
that had to scale well, handle some requests from a flash front end
while at the same time it had to interact using JMS with another
system. (Of course typical database layer thrown into the mix as
well.)

I've appreciated all the comments so far. Thanks.