• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Can A Front Controller be a Magic Servlet

 
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Bruce,
Iam working on a web based ERP in which the architecture consisits of a gateway servelet which conforms to the Front-Controller Pattern, in a way it is similar somewhat to the strut's framework but we are use our own Authentication, Session Managemant module and not Http Session
1)The Gateway Servlet does the following things:
: Authentication
: Authorization
: State Management
: Session Management
: Run time Patching of Results
: Invokes the buisness logic function residing in Java Classes Using Reflection API and takes the result from the Java Class In form of String and displays it to the end –user.
Now my question is can this Gateway servlet qualify for the term "Magic Servlet" as described by you.What are the implications of the same.
Rishi Singh
SCJP,SCWCD
[ June 06, 2002: Message edited by: Junilu Lacar ]
[ June 06, 2002: Message edited by: Junilu Lacar ]
 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bruce can correct me if I'm wrong, but you could call this a "magic servlet" if you've found that it negatively impacts your system in some way. Perhaps that negative impact isn't in performance, but in inflexibility or unreadability. If you've noticed that the current architecture is causing some problems, then you might be able to classify it as an antipattern. If that's the case, you might simply think about having the servlet delegate some of those tasks.
Corey
 
Rishi Singh
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well Corey,
That's what I want to figure out whether having one controller servlet can be a impediment in terms of performance, readibility, extensibility, scalibility if it does the following things
If only someone more experienced can throw some light
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rishi Singh:
If only someone more experienced can throw some light


:roll: What more do you expect? <sigh>.
Nobody out here can really say one way or the other without seeing what this "gateway" servlet really looks like. Wouldn't you (or someone on your team who has more experience) be the better judge of whether it is having a negative impact on all those application characteristics? After all, you're the ones who have to work with that servlet...
Again, in general (and please don't fault my lack of insight into your gateway servlet) you should try to learn to discern good and bad smells in your design. Things like cohesiveness (good) and too much coupling (bad). Follow good design principles.
Junilu
[ June 06, 2002: Message edited by: Junilu Lacar ]
 
Corey McGlone
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Junilu Lacar:

:roll: What more do you expect? <sigh>.


Well, here are a couple things to ask yourself...
Is it possible that we'll need this servlet to do more things in the future? Perhaps it will need to handle more pages or provide some other functions. If that's the case, it might be best to keep the servlet as simple as possible now so that it can be easily updated later. If your servlet gets to be a monster now, updating it will be a nightmare (or you'll have to refactor, which should have been done already).
Does the class diagram for the servlet take up a full printed page? If it does, I'd say that your class does too much. Delegate!
Are any of the functions of the servlet similar in a way that they can be easily grouped into subsystems? Perhaps a number of the functions (or future functions) could be grouped into a "Authentication Subsystem." If that's the case, you might have some key areas in which you could break up that "God Servlet."
This probably isn't as much help as you'd like but, as Junilu noted, you're really the expert when it comes to your system. It's impossible for me to tell you that having it do all of those things is going to have a negative impact. That's something you'll have to determine as it is specific to your system.
Corey
 
Rishi Singh
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Corey and Junilu,
I know iam the master, the inventor and the expert at my system.Well we had given a lot of thought and tried to model this "God Servlet" with Front Controller pattern and in a way follow the Struts Framework.But at the same time we are apprehensive about what could be the implications if tommorrow it needs to be deployed on two-app server for load balancing, or we need to add our suppliers alos as the potential users which would necessiate the use of xml.As we are in the phase of Scope Creep and the reqirements gets on adding quite often, I would ideally like someone to show me the Agile Shine pathway to come out of this "moving target"
 
Corey McGlone
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rishi Singh:
Thanks Corey and Junilu,
As we are in the phase of Scope Creep and the reqirements gets on adding quite often...


Are you still in the analysis phase and collecting requirements, or have you determined your requirements already and are ready to do your design? Scope creep isn't a phase. Scope creep happens when you allow requirements to change even after they should be been frozen. It is impossible to design a system when requirements are changing. Similarly, it is impossible to design a system before all of the requirements have been clearly defined.
It sounds like you've tried to do some design work and this has raised some questions about the requirements. At this point, I'd say that it sounds like you need to go back to the analysis phase and get some answers about what the system will and will not do.
Once you have the requirements, you may have to "scope out" some of the requirements in order to stay within time/budget constraints. Once you've made a decision as to what the system will (and won't) do. You should "freeze" the requirements so that you don't get impacted by scope creep. At that point, if your customer comes to you and says, "Well, it would be nice if the system did this, too." You can look back at the requirements and say, "If it's not in here, the system won't do it." Of course, it's usually nice if you tell the customer that you'll do that in a later release or some such thing. After all, the customer is the one with the money.
Corey
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Corey McGlone:

Are you still in the analysis phase and collecting requirements, or have you determined your requirements already and are ready to do your design? Scope creep isn't a phase. Scope creep happens when you allow requirements to change even after they should be been frozen.


Agreed; technology doesn't solve bad project management.
I would suggest an ammendment; waiting for a complete freeze on requirements isn't the only way to manage requirements. It is an important way to manage them if you are negotiating the terms of a fixed-price contract.
In other situations you can find a different balance between being able to depend on stable requirements yet allowing for reasonable change to requirements. Basically you:
1. gather and analyze requirements
2. prioritize them
3. break the project into stages based on requirement priority and risk management
4a. freeze the requirements for the stage you are working on
4b. (simultaneously) allow any incoming requirements changes to go into a hopper you don't act on.
5. go back to step 1 until done
You don't get this for free, in any way shape or form. The time for your total project can stretch, and you can be faced with re-work. It does allow you to predict the cost and deliverables of the upcoming stage. At the start of the next stage, if requirements have changed, if you are a skilled project manager or estimator you can say "this change will cost $X; do you want it that badly?".
Scrum is an example of an agile process that tries to do this. It works best if the stages are kept small, so that the risk of immediate re-work is minimized. That doesn't eliminate the risk of major re-work if an assumption-busting requirement appears late in the game, but that is why you want to be in a position to say how much it will cost to accomodate the change.
[ June 06, 2002: Message edited by: Reid M. Pinchback ]
 
Author
Posts: 71
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Do you have one controller for the whole system? If you don't break some of that stuff out, it's going to be much tougher to effectively maintain and reuse the code.
You could potentially have a magic servlet. I'd personally rather see some of that stuff wrapped as independent services.
 
Rishi Singh
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah Bruce,
We are having one Gateway Servlet doing all those stuff i.e authorization,authentication,invoking the java classes based on reflection, taking the result in form of a string from the java class and reading the template(this is a text file with placeholders which is patched at runtime and displayed).
Well we had thought of introducing sub-systems by delegating some stuff to a sub-gateway via the main one but later on we dropped that idea.
So what do u propose, still it is liable to become a magic servlet.
 
Rishi Singh
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Bruce,
I was just wondering and curious to know that the Struts Frmework which uses the Front-Controller pattern and has a Gateway Servlet which is the entry point to the application acts as a controller and determines which Java class will handle a particular request by referring to an XML file that contains mappings of URL paths to Java classes.
In addition it also can be used to run a form pre-processor to do simple form validation.
Can this also be classified as a
"Magic Servlet"
 
Rishi Singh
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
how do we refactor the magic servlet anti-pattern
 
Corey McGlone
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rishi Singh:
Hi Bruce,
...Struts Frmework...


If you're really interested in the Struts Framework, I suggest you check out Thomas Paul's Newletter Article. If you have any questions, however, you may want to direct those questions to the Jakarta Projects Forum.
How do you refactor a magic servlet? What's wrong with it? It does too much, right? I guess maybe you'd want to think about breaking that up.
Corey
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
WRT to the Struts ActionServlet and the Magic Servlet antipattern, one thing to consider is the cohesiveness of the class. The Magic Servlet (aka the Blob, aka Garbage Barge, aka Big Ball of Mud) is just a conglomeration of a number of unrelated methods. Refactoring involves identifying and grouping similar methods then breaking them out to separate objects such that each resulting object, including the original, is more cohesive and has better defined responsibilities.
I don't see the ActionServlet as an instance of the Magic Servlet. It's responsibilities are quite well-defined and related to the Controller layer of the MVC pattern. Well, maybe there are a few methods that are iffy but then again, the framework is still evolving.
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree that the basic ActionServlet is not a MagicServlet. Sometimes people do however rush to subclass ActionServlet in questionable ways to add features that could have been implemented via Action and proper use of scope bindings.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic