Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Moving a mature application to EJB  RSS feed

 
eric moon
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My company decided against a move to EJBs, because "we didn't want to support an API". Does this make sense? In what way might we be having to support an API by moving to EJB? We do catalog services for eProcurement, and have a product with a search engine that runs against a database, with a shopping cart feature and an interface that can be customized using JSP. I'm just wondering how EJBs would impact that kind of a setup, and what would be involved in switching. What advantages would we gain, if any? (Given that it's already functioning!) Thanks!
 
David Weitzman
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If it ain't broken, don't fix it.
First of all, I haven't ever used EJB's in a real project, I just read a book on them once, so don't trust me. EJB would allows you to make more types of interfaces (any java application could access them with the necessary libraries, as opposed to a JSP-only interface). Depending on what the code is like currently and any plans to add features to it in the future, EJB might prove to be a more extensible and easy to maintain system once it's setup. EJBs can make handling buisness logic and data consistancy much easier. It also has cool security and transaction support, but it doesn't sound like you have a problem with that.
But unless you have plans to change the features in the future, I refer you to the first sentance of this reply.
 
Matts Smith
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by David Garland:
If it ain't broken, don't fix it.

The guy's got a point. I totally agree. EJB projects are more prone to fail than any other projects because not many programmers went through the 300 pages spec and understood. Unless you have more senior staff on your team used to EJB development, forget it.
 
Tim Holloway
Bartender
Posts: 18705
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"If it ain't broken, don't fix it".
Uh-oh. I thought Fred Brooks shot that one down years ago. If you wait for a system to break down in the software world, you're likely to be spending a frantic time being yelled at 2 in the morning when it finally DOES break. Software's never as isolated from its environment as we like to think.
Mind, I DON'T recommend doing a massive system rewrite just because your APIs are "out of date". If you did that in the Microsoft world, where they went through ODBC, RDO, DAO, ADO, OLE DB and .NET in a blur so fast they didn't even get the Developer Studio to keep up, you'd have wasted a lot of time for no good purpose.
On the other hand, it certainly doesn't hurt to rethink a system in terms of newer technology. Some day you may HAVE to fix it, and the advance knowledge might come in handy. If nothing else, by thinking about a system you are familiar with in new-technology terms, you'll be more comfortable when it comes time to create or upgrade other systems.
Let's not over-mysticise EJBs, though. A significant part of that spec is detailed nitpicking over the responsibilities of EJB containers, not EJBs themselves. EJBs are designed to make it easier to work in a complex environment, and a lot of that ease of use comes in having had someone ELSE having done the design and debugging of your container.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!