Justify use of EJB
Payam Fard
Ranch Hand
Posts: 77
posted 13 years ago
The existing application is working as expected, but to foresee the future you as a developer would like to introduce EJB into the picture to handle potentially large future transaction handling, but your manager due to the cost of adding the EJB to your project disagrees and asks for justifications.
Basically, the question is how do you justify to your non-technical managers that taking the EJB route is the correct way to go?
Basically, the question is how do you justify to your non-technical managers that taking the EJB route is the correct way to go?
Morgan Bath
Ranch Hand
Posts: 196
posted 13 years ago
Sorry I agree with your manager 
If its working don't try to fix it.
IF (big IF) you need to change it at a later date thats the time to think about changing the architecture imho.
But for the sake of argument lets assume I agree with you that it needs to be changed. Justifications I would use are:
1) EJBs are simple to add now with modern IDEs and EJB 2.0 local interfaces. If you use JDeveloper 10g you can have a basic Entity bean collection for a simple DB up in about 5 minutes, the session bean structure (without business logic) in another 5. It will be fine grained and some purists will go mental, but there ya go. **nontech talk :SIMPLE, LOW DEVELPMENT TIME
2) They produce an elegant OO interface on top of the database, with a nice session facade and good use of resource locator pattern any programmer with a basic java knowledge can use. He can forget JDBC, prepared statements, SQL etc etc. **nontech talk :EASY TO UNDERSTAND, IMPROVE MAINTAINANCE COSTS / TIME
3) EJBs are not PL/SQL stored procedures. PL/SQL is ugly. It is not sexy and we hate it lots. We don't care if its efficient and powerful. Its not Java and therefore we hate it. **nontech talk : PLEAAAAASEEEEE LET US DO IT!
4) Even oracle are getting Java barmy so perhaps we need to get ahead of the rest and get comfortable with the new thing **nontech talk :ADVANCED, J2EE, MODERN
Thats what id try, but ill lay odds your boss will go: Anyone paying us to change it? Anyone (and by anyone I mean anyone paying us cash) complained about the existing system? Anyone except you give a rats ass about elegant code? Ok, go bring me coffee!
morgan
[ July 20, 2004: Message edited by: Morgan Bath ]
If its working don't try to fix it.IF (big IF) you need to change it at a later date thats the time to think about changing the architecture imho.
But for the sake of argument lets assume I agree with you that it needs to be changed. Justifications I would use are:
1) EJBs are simple to add now with modern IDEs and EJB 2.0 local interfaces. If you use JDeveloper 10g you can have a basic Entity bean collection for a simple DB up in about 5 minutes, the session bean structure (without business logic) in another 5. It will be fine grained and some purists will go mental, but there ya go. **nontech talk :SIMPLE, LOW DEVELPMENT TIME
2) They produce an elegant OO interface on top of the database, with a nice session facade and good use of resource locator pattern any programmer with a basic java knowledge can use. He can forget JDBC, prepared statements, SQL etc etc. **nontech talk :EASY TO UNDERSTAND, IMPROVE MAINTAINANCE COSTS / TIME
3) EJBs are not PL/SQL stored procedures. PL/SQL is ugly. It is not sexy and we hate it lots. We don't care if its efficient and powerful. Its not Java and therefore we hate it. **nontech talk : PLEAAAAASEEEEE LET US DO IT!
4) Even oracle are getting Java barmy so perhaps we need to get ahead of the rest and get comfortable with the new thing
**nontech talk :ADVANCED, J2EE, MODERNThats what id try, but ill lay odds your boss will go: Anyone paying us to change it? Anyone (and by anyone I mean anyone paying us cash) complained about the existing system? Anyone except you give a rats ass about elegant code? Ok, go bring me coffee!
morgan
[ July 20, 2004: Message edited by: Morgan Bath ]
Morgan
SCJP (1.4), SCJD (1.4), SCWCD (1.3), SCBCD (1.3)
|