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".
