> >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).
> >
>
This can be achieved without having to place them on a separate server,
particularly when all calls to that logic are being naturally funnelled
through an existing set of software--the servlet engine.
> 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.
>
This is the Object-Relational Impedence Mismatch summed up in three
paragraphs--Relations and Objects are two very different ways of viewing the
world, and it's almost impossible to match the two flawlessly. Yet we keep
trying to do so, because each offers unique strengths and flexibility not
found in the other. This is, without a doubt, one of the hardest areas of
objects to understand and "get right" (if such a thing is possible).
> 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?
>
No. EJB either punts entirely and says "the vendor will make it all just
work" (CMP) or else forces you to write it yourself (BMP).
> 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.
>
Amen.
> 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.)
>
Dependent objects are simply markers to the CMP-generative parts of the EJB
deployment mechanism that the dependent objects should be pulled back along
with the object that contains them. They're passed by value along with the
encapsulating object, which means that getting a dependent object value
requires getting their scoping object first. The container will generate the
necessary SQL to pull the peron's address back when it pulls back person,
for example.
Personally, I've had some success with simply pushing the data logic out of
the Java codebase entirely and into the database's stored procedure
language. Then I let the DBA do his thing, and I could care less how the
objects are stored. It means we have to define a formal API for obtaining
and updating data within the database, but I've found that to be a useful
exercise as well, particularly as it means the DBA knows precisely how the
database is being used and can therefore tune to his heart's content without
being "surprised" by a SQL query he didn't know about.
>
> 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.
>
The vendor-neutrality aspect of EJB is a sham--you cannot produce a
well-performant system in EJB without resorting to vendor value-adds, and
once you do, your portability wafts away on the winds.
Ted Neward
{.NET || Java} Course Author & Instructor, DevelopMentor
(http://www.develop.com)
http://www.javageeks.com/tneward
----- Original Message -----
From: "Atong Appa" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 14, 2002 4:16 PM
Subject: Re: [EJB-INT] As a Person Looking into EJB...
> 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".
>
>
===========================================================================
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".
