I do not think we are yet used to think of Java business logic as enterprise transactions. When we discuss invoking CICS/IMS and other legacy transaction FROM Java, it is never a question of installing these transactions on 5 web servers. They are simply considered as mission-critical 7*24 assets. They are there to be used. Even if the possibility did exist, nobody would discuss deploying them over-and-over again, as soon as there was a need for the business logic by some web (Java) application. We need EJB to deploy the next generation Java-based mission-critical business logic. They must be as safe, as monitored and as available as current legacy transactions. It must also be possible to reuse them in new transactions, constructed by combining several existing EJBs. This cannot be done using http (but maybe in the future!).
>From a programmer perspective, EJB (or any other OTM architecture) gives you the nice programming model of managed resources (you don't need to pass database connections around your business logic). But this alone doesn't justify EJB. Using JTA/UserTransaction from a servlet and implementing/running the business logic as ordinary java beans, would give you the same programming model (for resource access) and in many cases better performance (because of less services, like authorization and thread-safety). /Johan -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Atong Appa Sent: den 15 januari 2002 00:35 To: [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 =========================================================================== 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".
