> I have been reading this thread closely because I have very similar
questions - "So in what kind of situations can EJB really benefit both
client and developer?"
>
Situations in which the developer wants to bury his head in the sand
regarding performance in order to gain a false sense of security regarding
portability and maintenance.
> I have recently started learning EJB and found its persistence and
transaction management fascinating. It's fun and challenging with many
design issues to be resolved to optimise the whole system. However, I
believe it is not without some drawbacks, like, first of all, having to buy
an expensive application server, more complicated architecture and layers,
network traffic and etc.
>
Persistence is nothing new--we've been wrestling with Object-Relational
mapping since C++ first came to the market (and Smalltalkers have been
wrestling with it long before then), and we've never found a
one-size-fits-all solution to the problem/issue. Transaction management was
already mostly solved by the XA Specifications years ago--we just mapped it
to Java.
>So, considering all its goods and bads, for what kind of system whould you
recommened having EJB and when would you not?
>
When would I recommend having EJB: Almost never. When would I not: Almost
always. :)
> Is it the size of the system? Or is it the size of the company? How big
a company has to be to benefit from EJB?
>
Well, preferably, the larger the company size, the better, because then you
have more people to duck behind if and when the project fails. :)
> Or is it the importance of transaction management?
>
TM is definitely a powerful thing, and should be used when required; that
stated, most EJB projects go against a single database (or even a single
vendor/multiple database cluster), and won't need distributed transactions
at all.
> What are the critical issues to consider before deciding whether to have
EJB or not?
>
Specifically, if you write code to the vendor-neutral EJB Standard, you
produce a system whose performance runs slightly worse than that of a turtle
in slow gear--without using the various vendor value-added features, you
can't even access an entity bean in any kind of performant way. (That's
technically not true--you can work around this problem in EJB by creating
atomic composite structures and passing those back and forth, effectively
marshalling and unmarshalling the parameters by hand--the so-called "Value
Object" pattern--but this becomes VERY tedious VERY quickly.)
Ted Neward
{.NET || Java} Course Author & Instructor, DevelopMentor
(http://www.develop.com)
http://www.javageeks.com/tneward
----- Original Message -----
From: "june" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 15, 2002 2:24 AM
Subject: Re: [EJB-INT] As a Person Looking into EJB...
> I have been reading this thread closely because I have very similar
questions - "So in what kind of situations can EJB really benefit both
client and developer?"
>
> I have recently started learning EJB and found its persistence and
transaction management fascinating. It's fun and challenging with many
design issues to be resolved to optimise the whole system. However, I
believe it is not without some drawbacks, like, first of all, having to buy
an expensive application server, more complicated architecture and layers,
network traffic and etc. So, considering all its goods and bads, for what
kind of system whould you recommened having EJB and when would you not? Is
it the size of the system? Or is it the size of the company? How big a
company has to be to benefit from EJB? Or is it the importance of
transaction management? What are the critical issues to consider before
deciding whether to have EJB or not?
>
> There must be situations where EJB is most recommended and other
situations where EJB is NOT recommended. Enlighten me please.
>
> Another question, Atong said;
>
> > > > Porting an
> > > > application written for SQLServer to DB2 was bad enough (both
> > > > supposedly
> > > > conforming to the SQL standard). In fact, the database
> > > > access language part
> > > > of the porting effort (which is where the two systems shared
> > > > the greatest
> > > > degree of commonality due to the standard) was the easiest
> > > > and simplest
> > > > part. 90% of effort was on wrestling with "little"
> > > > idiosyncracies of the
> > > > two systems. Given the fact that each of them has to competitively
> > > > differentiate itself, the most interesting part of their
> > > > system was all
> > > > outside the realm of the standard.
>
> I was always told that change of database is not too much problem for a
properly designed Java application, especially with properly designed DAO
objects, and personally did not have much trouble with changing dabatase
although I have to admit it was a small application . What could be the
"little" idiosyncracies that made the porting a bad experience?
>
> Learning every day,
> June
>
>
> ----- Original Message -----
> From: "Atong Appa" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, January 15, 2002 10:34 AM
> Subject: Re: As a Person Looking into EJB...
>
>
> > Robert:
> >
> > Thanks for you reply. In your case, what specific value-adds do you
find in
> > EJB? That is, why would you recommend inserting the EJB layer between
your
> > application logic and database? Is it for easier persistence management
> > (are you using BMP or CMP)? Is it for transaction management (this one
I'm
> > curious about--EJB xtn model seems overly complex to me). Or, is it
> > portability? Or, something else?
> >
> > Thank you.
> >
> >
> > Atong
> >
> >
> > >From: Robert Schulz <[EMAIL PROTECTED]>
> > >To: 'Atong Appa' <[EMAIL PROTECTED]>
> > >Subject: RE: As a Person Looking into EJB...
> > >Date: Tue, 15 Jan 2002 10:00:25 +1100
> > >
> > >Hi Atong,
> > >
> > >We do built "real" stuff - contact / matter / document
> > >management. 50 screens, 20 domain objects.
> > >
> > >It's fully thin client with the following layers
> > >
> > >Browser / HTML+JavaScript (IE or Mozilla)
> > >Web Server / for static content / SSL (Apache)
> > >Servlet Engine / html rendering and application logic (Resin / Tomcat
> > >whatever)
> > > (you probably need an app framework for this layer)
> > >EJB Server / business objects / facade beans (JBoss)
> > >Database / persistence (Postgres / Oracle / whatever)
> > >
> > >We deploy everything on Linux. Having differnet
> > >processes running the different layers is a good thing, as
> > >you can naturally cluster onto different machines when you
> > >need to.
> > >
> > >Hope this helps.
> > >Cheers,
> > >
> > >Robert.
> > >
> > >
> > > > -----Original Message-----
> > > > From: Atong Appa [mailto:[EMAIL PROTECTED]]
> > > > Sent: Tuesday, January 15, 2002 6:24 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: As a Person Looking into EJB...
> > > >
> > > >
> > > > I have been asked to look at EJB by my company. After some
> > > > research, I have
> > > > some questions which I hoped people on this mailing list
> > > > could help out.
> > > >
> > > > First all, all indications are remote entity beans are not to
> > > > be used for
> > > > small-grain objects. The reason for this is because it
> > > > incurs too much
> > > > network traffic. Makes sense...
> > > >
> > > > This seems to suggest that one should use session bean
> > > > facades with entity
> > > > beans working in the EJB server, using perhaps 2.0's local
> > > > entity beans. I
> > > > even read upon a "design-pattern" for this.
> > > >
> > > > Now, suppose I would like my application to run as an
> > > > HTMP/JSP/XML app,
> > > > where the user is using a browser. The client is talking to
> > > > my servlet.
> > > > The question is then whether I should have this servlet make
> > > > EJB client
> > > > calls.
> > > >
> > > > If I do, I end up with 4-tier architecture where: the client uses
the
> > > > browser. The HTML req comes to the servlet. Servlet makes EJB
client
> > > > calls, EJB client makes calls into EJB server. EJB server
> > > > makes database
> > > > calls.
> > > >
> > > > I end up with 4 processes (1 for CLIENT, 1 for SERVLET + EJB
> > > > CLIENT, 1 for
> > > > EJB SERVER, and 1 for DATABASE). This seems a bit excessive.
> > > > I then must
> > > > ask whether EJB is adding real value here. If I (for network
> > > > performance
> > > > reasons) have to make my session bean facades coarse-grain
> > > > and have all
> > > > interesting business logic happen inside EJB SERVER, what
> > > > value does EJB add
> > > > other than a glorified RPC and the supposed promise of portability?
> > > >
> > > > Wouldn't it make more sense for me to call "what would've
> > > > been the session
> > > > bean implementation in EJB SERVER" directly from my SERVLET?
> > > >
> > > > I'm not convinced at all about this promise of portability.
> > > > Porting an
> > > > application written for SQLServer to DB2 was bad enough (both
> > > > supposedly
> > > > conforming to the SQL standard). In fact, the database
> > > > access language part
> > > > of the porting effort (which is where the two systems shared
> > > > the greatest
> > > > degree of commonality due to the standard) was the easiest
> > > > and simplest
> > > > part. 90% of effort was on wrestling with "little"
> > > > idiosyncracies of the
> > > > two systems. Given the fact that each of them has to competitively
> > > > differentiate itself, the most interesting part of their
> > > > system was all
> > > > outside the realm of the standard.
> > > >
> > > > I'm afraid the same is true with EJB. In fact, seeing how the spec
is
> > > > evolving and chaning all the time, I'm afraid it's even worse.
> > > >
> > > > If someone actually did real life, big app development using
> > > > servlet and
> > > > EJB, could you chime in and shed some light on this
> > > > architecture issue?
> > > >
> > > > No offense, but I'm not much interested in evangelist howling or
some
> > > > theoretic empty-talk. I'm looking for practical advices based on
real
> > > > experience.
> > > >
> > > > Thank you.
> > > >
> > > >
> > > > _________________________________________________________________
> > > > MSN Photos is the easiest way to share and print your photos:
> > > > http://photos.msn.com/support/worldwide.aspx
> > > >
> > > > ==============================================================
> > > > =============
> > > > 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".
> > > >
> > >
> > >
> > >**********************************************************************
> > >
> > >visit http://www.solution6.com
> > >visit http://www.eccountancy.com - everything for accountants.
> > >
> > >UK Customers - http://www.solution6.co.uk
> > >
> > >*********************************************************************
> > >This email message (and attachments) may contain information that is
> > >confidential to Solution 6. If you are not the intended recipient you
> > >cannot use, distribute or copy the message or attachments. In such a
case,
> > >please notify the sender by return email immediately and erase all
copies
> > >of the message and attachments. Opinions, conclusions and other
> > >information in this message and attachments that do not relate to the
> > >official business of Solution 6 are neither given nor endorsed by it.
> > >*********************************************************************
> > >
> >
> >
> >
> >
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: http://mobile.msn.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".
> >
>
������������������������������������������? �� � �??��~���&���ܢf�v����a����???
(��&?�??
��ǧu??h?-����6�k?��(��?w%�ע�?n�r��azg��?�� ��� ? ��
DD???�z����i�ǧu??h?-����6�k?��(��?w%�ע�?n�r��azg��???
>
===========================================================================
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".
