Hi ,
Its not a big deal to design the system if we use the power of
Interface concept of Java appropriately to have the
server-side-functionality work with any client with minimal amount of
changes creeping in. At a higher level you can first fix up the API the
application is supposed to expose with spi(service provider interface)
packages for portability across various kinds of clients but the core
Server-side logic and Business components intact. Infact design it that way.
I dont know how critical your application is and the scope of it also and so
I was being very pessimistic in my suggestions. As Juan says if you are 100%
sure that your application will never have a web interface and its never
gonna go on to the public/private network also, then yes, the designers can
make some optimizations to save time and brain-storming sessions.
But remember this is valid iff you the probability that the
server-side sees a web-Client(over the public network or private network at
any point in time) is ONE else there is no harm in leaving some leads out so
that we can make the core-server-side functionality adopt to variety of
clients, just a minimal but efficient effort would make many lives happy
when they get back to change the stuff.
Have a nice day.
Thanks & Regards,
kris
-----Original Message-----
From: Juan Pablo Lorandi [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 21, 2002 7:14 PM
To: [EMAIL PROTECTED]
Subject: Re: EJB What's the best ?
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".
===========================================================================
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".
