Hi,
Its an existing solution with majority of business logic in stored
procedures
The requirement is
Migrate much of the business logic from the database Stored
Procedures into the EJB and Retain the complex calculations in the stored
procedures within the database space for efficiency
If this is the case, Which is the best solution??
Does Calling the SPs from BMP make sense??
Regards,
Swaminathan
-----Original Message-----
From: Ramakrishna N [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 02, 2002 5:50 AM
To: [EMAIL PROTECTED]
Subject: Re: Calling a SP from Entity bean
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".
****************************************************************************
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".
