I respectfully disagree. You shouldn't future guess reasons you cannot anticipate. You should provide solutions to existing problems. You can always add the Servlet layer(I'd prefer JSP) later on if really needed. >From my experience, and IMHO, future guessing almost always leaves you with a Babel tower project nobody wants to be in until it completion.
Basically, to work adding a servlet layer effectively disconnects the applet from the components; the servlet/jsp layer is basically HTTP, and thus it's mostly disconnected-- state is not retained(basically). Pros: It scales better(no state is kept on servers, thus, any server can reply to clients; also, load for each user having an applet on his desktop doesn't mean each user having a RMI connection to the server open). Replacing the Client (the applets) doesn't involve replacing the Business Components. Modifying the Business Components contract (Interfaces) doesn't imply changing the Client. Network partitions are less harmful to the application. Minimizes the number of round trips to the server. Cons: You must build an extra layer. It'll be disconnected, that is, won't retain state as easily. Using a service(or should I say, procedural) based architecture will meet Model 2 in Swing, and it won't be a boy-meets-girl story. You'll have to un-OOP your architecture. Depending on your application design (both the Applet & the Service layer) the application may become more network intensive(less round trips, but larger chunks of data). Basically, as Ramakrishna noted, the extra layer may give you extra liberty to adapt your application to serve different clients(Applets/Applications/Web Browsers/WAP Phones); if intelligently coded will use network resources more efficiently and will be more resilient to network failures. It'll also be a ton of work to do; if there isn't a diversity of clients or the network resources are more limited (like an internet app), I wouldn't get myself into that much trouble. My 2c, Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]] On Behalf Of Ramakrishna N > Sent: Tuesday, May 21, 2002 11:29 PM > To: [EMAIL PROTECTED] > Subject: Re: EJB What's the best ? > > > hi, > I would vote for the first one since at any point in time if > you want to make it web-enabled for whatsoever reasons which > you may not be able to figure out at this moment, the > transition would be very easy and it would invlove only > writing JSPs and that's how you design the current design > with Servlet as a Front-Component. > Hope this helps. > Have a nice day. > > regrds, > kris > > -----Original Message----- > From: boutte [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 21, 2002 5:25 PM > To: [EMAIL PROTECTED] > Subject: EJB What's the best ? > > > Hi, > > I have a simple question, i would like to know what is the > best solution for our environment ? > > Intranet / Ethernet 100 > JRE 1.4 plug into every clients (automatic downloading) > Weblogic 6.1 SP2 > > We have decided to make all the company specific software > turn into applets (since design is great JTable, JTree, > JSpinner ...). My question is for communication between > applet and Weblogic : What's the best ? > > Applet - Servlet - JNDI - EJB > Applet - JNDI - EJB > > Thanks for giving to me all advantages and disadvantages. > I have found no documents on the web (perhaps one ?) for > this architecture. > > Seb > > ============================================================== > ============= > 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". > > =========================================================================== 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".
