Hi, Using SPs makes more sense with EJB1.1 but with J2EE1.3(EJB2.0) we have better features like RMI/IIOP which is used to access your business logic from any platform. If you have just the SPs then what is this Middle-Tier gonna do for you ? Its an over-kill to buy an App-server just to handle concurrency. This makes the application a simple 2-tier JDBC application and if that suffices your requirement then nothing like it. It all depends on the requirements of the application whether to use simple JDBC or EJBs in between. Dont forget a most important point here if you use SPs you are locked to the DB-vendor and what if you want to change your back-end, re-implement all the Sps where in you handle all the Transaction-management and doing complex calculations inside the SP using SQL ? I feel its the requriements that are gonna decide the destiny of your application when you have SPs already available. But if its a fresh application, no matter how simple it is, I see no point in going for Sps when I have J2EE1.3 which can do looooot many things for you and you can have most complex applications deployed on it and using JCA you can even connect to the legacy systems to pull data out. There definitely are umteen advantages by using pure J2EE than using Sps. Sps hold good if you are 100% sure that your application's backend never changes, logic never changes and the computation inside never changes. And in that scenario dont go for J2EE at all but make it a straight JDBC app.
Well skill-upgradation is the basic thing in IT, let me quote a statement which I heard from sbd quite somtime ago - He who cannot read is not an illiterate in this contemporary world but he who cannot learn is definitely one. If you have your business logic in java its platform independent, the basic advantage of java. Have a nice day. Regards, kris -----Original Message----- From: Eric Williams [mailto:[EMAIL PROTECTED]] Sent: Monday, July 01, 2002 4:16 PM To: [EMAIL PROTECTED] Subject: Re: Calling a SP from Entity bean This type of blanket statement is not much help. On the other side, let me list some of the benefits associated with stored procedures: 1. Stored procedure programming languages often outlive the database client programming languages. You reduce the cost of porting your client to a new language when you implement a portion of your application in stored procedures. 2. Implementing a portion of your application logic in stored procedures makes it accessible from any client programming language. If I have to access the same logic from VB and EJB, then it is much easier to call a stored procedure from both VB and EJB than it is to try to bridge from VB to EJB. 3. Performance. You can achieve some dramatic performance improvements by using stored procedures to reduce the I/O between your database client (which is often a server tier) and the database. 4. You may have developers that are more familiar with stored procedure programming than they are with Java (or any other programming language, for that matter). People skill-sets are an important factor in deciding how to implement an application. I'm not saying you should always use stored procedures.... but they can be an important part of your architecture that helps you meet your goals. -eric Ramakrishna N To: [EMAIL PROTECTED] <nramakrishna@VIR cc: TUSA.COM> Subject: Re: Calling a SP from Entity bean Sent by: A mailing list for Enterprise JavaBeans development <EJB-INTEREST@JAV A.SUN.COM> 07/01/2002 02:14 PM Please respond to Ramakrishna N Hi, I would vote to leave all the SPs behind and move your Business-logic into either EntityBean or SessionBean based on your requirements, performance estimations and design-patterns that are being used. If not today tomorrow you will have to get-rid of SPs so the earlier the best, if you want more flexibility at the middle-tier. Hope this helps. Regards, kris -----Original Message----- From: Swaminathan K.N. [mailto:[EMAIL PROTECTED]] Sent: Monday, July 01, 2002 2:15 AM To: [EMAIL PROTECTED] Subject: Calling a SP from Entity bean Hello All, Can anyone tell me the reason for calling a Stored Procedure from a Entity Bean ( CMP or BMP ) assuming some business logic is there in Stored Procedure. Does it make sense?? Assuming the existing business logic is available in a Stored Procedure, What is the approach to be taken to move the business logic to the Session bean as much as possible?. Should we leave some of the business logic in SP itself? Regards, Swaminathan **************************************************************************** This communication contains information, which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, printing, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error, please notify the sender immediately and then destroy any copies of it. **************************************************************************** =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
