File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Servlets and the fly likes whether this architecture is feasible!!!!!!! to mike, tony and matthew ....sheriffs Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "whether this architecture is feasible!!!!!!! to mike, tony and matthew ....sheriffs" Watch "whether this architecture is feasible!!!!!!! to mike, tony and matthew ....sheriffs" New topic

whether this architecture is feasible!!!!!!! to mike, tony and matthew ....sheriffs

Rishi Singh
Ranch Hand

Joined: Dec 09, 2000
Posts: 321
We are working on a web-based application which is based on MVC pattern with servlets as controllers, a relation package ( which corresponds to the database bean ) and for view in place of JSP we are using PerlUtil5 class and creating templates and doing pattern matching for final display to the browser.

Now whenever we speak about a web application, we have some number of servlets which governs the functionality of the buisness-logic and they execute with-in the web-container.Now the architecture proposed here has one common gateway which can be called as the MainServlet which is the entry point to the application.
All my buisness logic is put in java classes which are called by the Main servlet depending upon the request which in turn connects to Database and gives me the resulset.So we r having only one servlet in our application and this contains all the necessary details like connection pooling,session management,persistent connection,patching templates as per response,etc.
Now I would like to know from the sheriffs as to what are the pros and cons of this architecture, whether it would function as desired, what are the implications if tommorrow I need to add-on distributed web components, or go for n-tier architecture, or multiple app-server, a distributed database which is not the case at present.Whether the same architecture can be implemented if there is a need to make this application distributed.
I would like a very detailed answer to this and if this could be possible why is this architecture not having a mention in by Sun people themselves(perhaps they can answer my query in a best possible manner).
If anyone would like to know more of this architecture , I am availabe at

[This message has been edited by Rishi Singh (edited November 01, 2001).]
Matthew Phillips
Ranch Hand

Joined: Mar 09, 2001
Posts: 2676
I'll be honest with you. I am pretty new to servlets and don't have the answer.
Matthew Phillips

Matthew Phillips
Manjunath Reddy
Ranch Hand

Joined: Jul 26, 2001
Posts: 60
Id rather have the gateway class(servlet) to be further neatly demarcated into business facade for implementing various functionalities.
Like paymentGateway
PersonalizationGateway...and so on.
This will aid any enhancements and keep the source of the gateway managable while also maintaining the size of the class for easy debugging.
just my .02
Rishi Singh
Ranch Hand

Joined: Dec 09, 2000
Posts: 321
I would one of the sheriffs to point out the possible pitfalls of this architecture..where it can go wrong and if there is a need in future to add distributed web components to it, whether it would be easy integration!!!
Angela Poynton
Ranch Hand

Joined: Mar 02, 2000
Posts: 3143
Being a Sheriff doesn't necessarily mean more technical expertise, (take me for example), all it means is that we have more administrative power in these forums.
I'm not a huge expert on Servlets.
However, I have been working on a commerical website which has many different functional areas.
What we have is a a ControllerServlet for each functional area of the site and a SiteControllerServlet which intercepts each request and dispatchs to the appropriate ControllerServlet.
This allows us to develop / add /remove an area of functionality independantly of others on the site and keeps the SiteControllerServlet just in charge of navigation.

Pounding at a thick stone wall won't move it, sometimes, you need to step back to see the way around.
Rishi Singh
Ranch Hand

Joined: Dec 09, 2000
Posts: 321
Sorry Angela,
I was not very clear about the role of the sheriifs and would like to sought pardon for the same!
I would like u to go through my other post in which I have tried to put forth my query in a rightful manner. meanwhile can u tell me the performance issues and any other overheads which u guys faced in ur site which u said is based on a single Site Controller and controller based on ur different modules
Junilu Lacar

Joined: Feb 26, 2001
Posts: 6529

One basic OO design rule: A class should have one role/responsibility and do it well. (As opposed to having many roles/responsibilities). Your description of the Main Servlet fits "The Blob" (a.k.a "The God Class") anti-pattern. "Shrek" your application: make it layered, like an onion (or cake or parfait depending on your preference ). Each layer will have it's own well-defined responsibility.
From the rest of your description, it sounds to me like you should take a look at the Jakarta Struts framework. More and more people are using it and we even have a bartender here at the ranch who has written a few articles about it (sorry, I lost the links to those but maybe Kyle can provide them).
Junilu Lacar
Sun Certified Programmer for the Java� 2 Platform

[This message has been edited by JUNILU LACAR (edited November 03, 2001).]

Junilu - [How to Ask Questions] [How to Answer Questions]
Dave Van Even
Ranch Hand

Joined: Jul 19, 2001
Posts: 101
I've been using the STRUTS MVC framework for quite some time now..
maybe you should check it out ? It works exactly like you have been doing, but it is tested by thousands of people and is a little more that just a framework with a MainServlet It has an extensive taglib and has some advanced stuff to make your everyday life easier
read this quick tutorial to get an idea
subject: whether this architecture is feasible!!!!!!! to mike, tony and matthew ....sheriffs
It's not a secret anymore!