The notion that having business logic in component-based middleware rather than in stored procedures provides for better scalability is falacious. The middleware components have to retrieve data to which they apply their logic and they have to update the database with data to which they have applied their logic. Each call those components make to the database creates traffic over the finite resources of database and network connections. In practice, those resources prove to be far more of a botteneck than the processing capabilities of the database server. Hence, better scalability is achieved by simply having the component-based middleware apply security, transactional boundaries and connection management to calls from the presentation tier, and pass incoming data to stored procedures which implement the business logic, update the database and retrieve the data the presentation tier needs subsequently.
I've tried the business logic in component-based middleware solution and was surprised by how poorly it performed and scaled. Read Transactional COM+, (which is as pertinent to the EJB platform as it is to COM+), and since tried the business logic in stored procedures solution and have been very impressed with how it performs and scales.
| Juan Pablo Lorandi <[EMAIL PROTECTED]>
Sent by: A mailing list for Enterprise JavaBeans development <[EMAIL PROTECTED]> 07/17/2002 09:52 AM
|
To: [EMAIL PROTECTED] cc: Subject: Re: Why Ejb? |
Nicholas, tough I agree that in most cases this mixed combination works
wonders, it presents three problems:
1) Business logic is fragmented. Hence, when changing DBs you're in for
some trouble. Granted, if you're part of the IT staff on a company, that
won't be much of a problem, but if you're building re-usable
components(with the purpose of selling them afterwards in a component
marketplace such as Flashline) then you're in for a lot of trouble.
2) The strain on the database is higher. That compromises your ability
to scale both up and out, one of the goals in every TP engine built so
far. Tuxedo[CORBA] (built by BEA), MTS[COM+] (Microsoft), and the miriad
of J2EE servers allow for the application assembler to redefine the
physical architecture of a system that uses this component, leveraging
ease of scalability, not to mention cost.
3) Not all of the persistence managers are RDBMS. Many RDBMSs of choice
do not allow SPs and/or some do not compile SPs.
On the other hand, if you're just using SPs to perform CREATE, INSERT,
DELETE, UPDATE statements with no business logic on them, _most_
appservers won't take a big hit in performance since they will use
PreparedStatement. Most important RBDMS will compile the statement, and
also store it temporarily as long as the connection is alive. Since
connections are pooled, the differences in speed of execution between
using SPs and using PreparedStatements is negligible.
In the near future, you could also expect that the appservers compile
many of the auto-generated SQL statements into SPs as well.
Bottom line is, while in your particular situation usage of SPs means no
hassle but actual speed gains, then go ahead (and knock yourself out ;-)
) but from a service/component provider POV, like us here at
CodeFoundry, the choice must be done carefully for each case.
My 2c,
Juan Pablo Lorandi
Chief Software Architect
Code Foundry Ltd.
[EMAIL PROTECTED]
Barberstown, Straffan, Co. Kildare, Ireland.
Tel: +353-1-6012050 Fax: +353-1-6012051
Mobile: +353-86-2157900
www.codefoundry.com
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]] On Behalf Of Nicholas
> Sent: Wednesday, July 17, 2002 11:42 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Why Ejb?
>
>
> 100% portability is an illusion. Consider CMP and one
> must conclude that porting from one app server to
> another will come with a series of head aches
> regenerating all the proprietary extended descriptors.
>
> In this event, it could be argued that BMP offers a
> higher degree of portability, if not ease of use,
> since you have a higher degree of control over the
> actual SQL that is issued. Portability is in the eye
> of the porter.
>
> My point about SPs is that the Java code itself is
> better abstracted from the underlying database
> structure when it simply calls a CallableStatement and
> passes parameters. Admitedly, the downside is that the
> SPs themselves have to be regeneratred upon switching
> databases, but if you have anything like a serious
> application, and you are switching databases, that will the
> least of you worries.
>
> Anyways, I believe the trend is that medium to large
> sized companies (if not all companies) tend to have
> one standardized database (generally) for J2EE back
> ending, but they switch J2EE engines like they change
> their underwear.J2EE licenses are quite cheap compared
> to DB licenses.
>
>
> //Nicholas
>
>
> --- John Harby <[EMAIL PROTECTED]> wrote:
> > But they aren't portable across database vendors so
> > if this
> > is an issue you should avoid stored procedures.
> >
> > I'm also not sure exactly what "ISOMORPHIC" means in
> > this
> > context. Actually the functionality of stored
> > procedures
> > would comprise a superset of the functionality of
> > plain SQL.
> > For example in Oracle take a look at DBMS_PIPE.
> >
> >
> > >From: Nicholas <[EMAIL PROTECTED]>
> > >Reply-To: [EMAIL PROTECTED]
> > >To: [EMAIL PROTECTED]
> > >Subject: Re: Why Ejb?
> > >Date: Tue, 16 Jul 2002 14:02:44 -0700
> > >
> > >No No No !
> > >
> > >Does anyone on this list actually use stored
> > >procedures ?
> > >
> > >When you invoke a stored procedure, it participates
> > in
> > >the current transaction identically to a dynamic or
> > >embedded SQL statement. (Yes, you can mess it up by
> > >issuing a commit or a rollback in the SP, but that
> > >would be silly.) So, when you start a JTA managed
> transaction, calls
> > >to stored procedures are still within the context of that
> > >transaction. They are
> > not
> > >subject to different rules.
> > >
> > >Moreover, the same goes for security (in most
> > >databases). SPs do not have any magic security
> > >override, except that users may have permission to
> > >issues SP requests, but not have access to the
> > >underlying tables/views/other SPs. This does not
> > >affect the security model in J2EE at all.
> > >
> > >My new mantra: SQL ISOMORPHIC TO SP
> > >
> > >//Nicholas
> > >--- Ashwani Kalra <[EMAIL PROTECTED]> wrote:
> > > > You will have to use wrapper/facade in SLSB/SFSB
> > > > from which you can take
> > > > advanatage of the transactions and security. You
> > can
> > > > manage the transaction
> > > > in SPs also and propagate errors to the session
> > bean
> > > > methods.
> > > > Scalability issue will then shift to session
> > beans.
> > > >
> > > > ----- Original Message -----
> > > > From: "Vikram Naik" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Tuesday, July 16, 2002 3:46 PM
> > > > Subject: Re: Why Ejb?
> > > >
> > > >
> > > > > Hi,
> > > > > Thanks for the quick reply...
> > > > > Apart from getting generated SQL's
> > what
> > > > about the transactions
> > > > and
> > > > > scalability ????
> > > > >
> > > > > Vikram Naik
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: A mailing list for Enterprise JavaBeans
> > > > development
> > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > > > Ashwani Kalra
> > > > > Sent: Tuesday, July 16, 2002 3:19 PM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Re: Why Ejb?
> > > > >
> > > > > Two reasons :
> > > > > 1.EJB(cmp) makes code independent of the
> > Database.
> > > > > 2. You dont have to code sql queries for
> > > > inserting/updating etc.
> > > > >
> > > > > If you already have Sps then you can
> > completely
> > > > avoid Entity EJBs and use
> > > > > DAO to call SPs.
> > > > >
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > Cheers
> > > > > Ashwani Kalra
> > > > > http://www.geocities.com/ashwani_kalra/
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Vikram Naik" <[EMAIL PROTECTED]>
> > > > > To: <[EMAIL PROTECTED]>
> > > > > Sent: Tuesday, July 16, 2002 3:22 PM
> > > > > Subject: Why Ejb?
> > > > >
> > > > >
> > > > > > Hello All,
> > > > > >
> > > > > > Why should we opt of EjBs when stored
> > procedures
> > > > can give us better
> > > > > > performance?
> > > > > >
> > > > > > Your opinions will be highly appreciated.
> > > > > >
> > > > > > Thanks & Regards,
> > > > > > Vikram Naik
> > > > > >
> > > > > >
> > > > >
> > > >
> >
> >=============================================================
> ==========
> >====
> > > > > > 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".
> > > >
> > >
> > >
> > >=====
> > >Nicholas Whitehead
> > >Home: (973) 377 9335
> > >Cell: (201) 615 2716
> > >Work: (212) 622 5639
> > >[EMAIL PROTECTED]
> > >
> > >__________________________________________________
> > >Do You Yahoo!?
> > >Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
> > >
> >
> >=============================================================
> ==========
> >====
> > >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".
> >
> >
> >
> >
> >
> _________________________________________________________________
> > Send and receive Hotmail on your mobile device:
http://mobile.msn.com
>
>
=== message truncated ===
=====
Nicholas Whitehead
Home: (973) 377 9335
Cell: (201) 615 2716
Work: (212) 622 5639
[EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
========================================================================
===
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".
_________________________________________________________________
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
