Robert:
More questions and comments...
>From: Robert Schulz <[EMAIL PROTECTED]>
>To: 'Atong Appa' <[EMAIL PROTECTED]>
>Subject: RE: As a Person Looking into EJB...
>Date: Tue, 15 Jan 2002 10:42:15 +1100
>
>
>Well, you need to build some sort of
>persistence layer, otherwise you end
>up with SQL everywhere which will kill
>you in maintenance. We use CMP for the
>basic object retrival and persistence
>and BMP for complex lists, tree tables
>and such.
>
>I also like to have all validation logic
>and core business logic once in the business
>object (rather than all over the shop).
>
It sounds like you like EJB's persistence and component model aspect.
I have a few issues with EJB's persistence. In fact, the first one of these
problems is not even unique to EJB, but OO paradigm in general. Many of
objects has many columns of data (over 100 columns). When an application is
running, the user typically works only with only a handful of these columns
(human beings are not equipped to deal with 100's of pieces of info all at
once).
So, different applications ('modules' to be exact) work on different subsets
of this large number of columns. Yet, the business logic must be
centralized and managed in the context of one object class (like you
mentioned).
The problem is that OO paradigm wants the entire object to be realized in
memory before anything happens. This causes memory usage problems,
scalability problems, and performance problems. Previously, we've attempted
to implement 'partially initialized' object, but, like you said, this ended
up strewing bits of SQL in many places--maintenance problems.
For this kind of problems, EJB CMP is inappropriate. With BMP, we are
likely to end up with SQL spread out. Is there something in EJB to help out
with this kind of problem?
Also, we find that even for simple objects, we need to optimize SQL a great
deal. We would end up adding many access plan and query optimization
details to our SQL statements. This means we need to resort to BMP.
On a related issue, previously, we've done multi-level joins to get data out
of db in one round trip and then realize many instances of different object
classes. That is, the relationship between object classes and SQL
statements is not necessarily one-to-one. Rather, it is many-to-one -> one
SQL for many object classes. (Or, it could be one-to-many in the case of
partially initialized objects.) I understand that EJB 2.0 has 'dependendant
objects' that can help with this. Could you comment on your experiences
with that? (Frankly, I'm kind of thin on how it is supposed to work.)
I understand your desire to stick with standards. But, are you concerned
that EJB can survive and stay a viable standard (I am) for years to come?
We've been burnt by CORBA once before and so are a bit gun-shy about
emerging, new standard.
Thank you.
Atong
>This can all be done without EJBs, but you
>end up with a proprietary solution (which
>we had before) which is always a bit of a
>worry (especially when you need to get new
>people trained up).
>
>Hence we decided on EJBs. JDO might have been
>another option, but it does not have as much
>momentum.
>
>Whether or not to use EJBs depends on what
>you want to do - for short life cycle "throw
>away" apps, it is too heavy and the learning
>curve is too steep - you are better off using
>JSPs with a decent tag library.
>
>For anything which is big and still "your
>problem" in a years time, have a look at EJB.
>
>To get your feet wet, stick with the open
>source stuff - check out jboss. It's very solid
>and free.
>
>Cheers,
>
>
>R.
> > -----Original Message-----
> > From: Atong Appa [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, January 15, 2002 10:35 AM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > 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
> >
>
>
>**********************************************************************
>
>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.
>*********************************************************************
>
_________________________________________________________________
Join the world�s largest e-mail service with MSN Hotmail.
http://www.hotmail.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".
