thank you, kostas! good job! if inter-servlet communication is
such an egregious violation of oo, there must be something wrong
with oo. if using the servlet context as the mechanism is what
people are unhappy about, then please, do come up with an alternative.
servlet collaboration makes sense whether they are co-located
or not. please, let's keep oo out of the argument!
george
"K.V. Chandrinos" wrote:
>
> On Tue, 22 Feb 2000, Ernie Varitimos wrote:
>
> > I disagree that accessing servlets through the servlet context is a
> > flawed architecture.
>
> I stand with you, and I try to support this claim further below.
>
> > I have yet to hear a reasonable, comprehensive explanation of why this
> > is a flawed architecture and what are the superior alternatives.
>
> Me too. The arguments (as nicely laid out by Craig in an earlier message)
> fall broadly in one of two general categories:
>
> 1) Protect the coder from his own stupidity
> 2) This is not good OO programming
>
> They both stem, I think, from an underlying belief (almost revealed in
> Craig's bottomline) that servlets are glorified CGI scripts, i.e.
> response-to-browser mechanisms. I intend to fight this belief and suggest
> that this should not be the case.
>
> The obvious answers to the arguments are:
>
> 1) The servlet engine COULD protect me from being too clever for my own
> good
>
> 2) There is a simple concept in OO design: the system cannot be in a state
> that the programmer cannot discover by calling an appropriate method, if
> the system HAS knowledge of its state. This is SAVAGELY violated by the
> current servlet engine design, so they cannot be good judges of good OO
> design.
>
> Not only that, but the solutions provided by OO-proponents are
> externalization of existing in-system information to persistent/shared
> objects, in a well hidden implementation of flags. Next, they will suggest
> we use GOTO statements to preserve OO methodology:-)
>
> I take the arguments one-by-one:
>
> "You should not get access to this information because it:
>
> * Is dangerous -- what stops you from calling init() and destroy()
> yourself, and thereby messing up the state your servlet thinks it
> is in versus what the servlet engine thinks it is in?"
>
> Ans.: Hopefully, the servlet engine:-) I do not see why the system could
> not stop me from calling these two particular methods that could 'mess up'
> the state, although in principle, I also do not see why not a privileged
> MasterServlet could not be authorised with loading and unloading other
> servlets programmatically. Millions of people would kill for that.
>
> "* Can potentially breach privacy -- application designers frequently
> store privileged information in servlet class variables (such as
> JDBC connections that are preinitialized) that could be potentially
> abused if they were accessible from any anonymous servlet that
> happens to be accessed. This argument also explains why you can
> not get a reference to any user session other than your own either."
>
> Ans.: This is a privacy issue that Java has to deal with in general.
> Blocking access to data is an effective but not concrete solution to
> privacy, otherwise 'public' and 'private' woudn't be in use.
>
> "* Leads to incredibly bad designs -- you will be tempted to use
> methods and variables in your servlet class to store shared state
> information in a servlet, instead of using an appropriate object
> oriented design for the shared information."
>
> Ans.: Saving me from myself then? As if current state of affairs does not
> allow me to go for bad designs:-? If one is OO-elastic enough to allow a
> system's state be hidden, I cannot see how far worse my designs to
> circumvent this can go... Probably, I will have to rewrite some code in a
> wonderful 'reuse' illustration.
>
> "* Not portable to distributed environments -- references to Java
> objects only work within the same JVM. What do you do if the "other"
> servlet you are trying to talk to is actually on a different server?"
>
> Ans.: I plead with the system to provide me a reference it ALREADY HAS in
> order to delegate requests to that other JVM.
>
> "Bottom line -- if you find the lack of getServlet() to be restrictive,
> this is a pretty good sign you should go back and review your design for
> adherence to good object-oriented architecture principles. It means you
> are trying to use servlets for what they are not."
>
> And they are what exactly? I cannot communicate my astonishment when I
> first looked at the servlets documentation in the early summer of 1997
> to write my first servlet for Jigsaw, and I saw that the use of
> servlets as opposed to CGI for HTML responses was stressed more than a
> zillion other uses. I said, OK, the Javasoft people want to catch an
> established market. But now, three Internet years later, are we still
> thinking that servlets are basically HTML responders? I mean, honestly,
> this separation of 'business logic' and 'response'(=servlets), doesn't it
> come from too much JDBC view of the world? Can you put hand on heart and
> tell me you would create extra classes if databases answered you in a
> split second and someone at MSoft could write a decent memory management
> module that wouldn't bring the world down if the database socket failed?
> Isn't it time we stopped using servlets as better CGI? Whatever happened
> to Generic servlet? What about all those people keying WAP applications as
> I bubble?
>
> Assume the following purposefully exaggerated example: I am using servlets
> to manipulate electric appliances at home. Each appliance is controlled by
> one servlet. I am leaving work and I know that turning on the water-heater
> while the boiler-kettle is on will bring down the fuse due to the great
> '50s wiring. What is the OO solution to this without:
>
> a) calling my wife to ask if she makes tea
> b) using any other Java product (they seem to come two in a day)
> irrelevant to servlets, like JSDT, JINI, huddini or whatever.
>
> Probably, writing out appliance registries to files, like good OO
> programmers should do... And all that while my system knows if the
> water-heater is on or not. I bet you, Booch would love this! But being a
> practical man, he would suggest I changed the wiring.
>
> In short, I agree with the rest (!) that the current view of what servlets
> are, dictates a design rework if you need ServletContext. It is the view I
> do not agree with:-) I just hope that servlets won't be the CGI of the
> '90s. Because they sure present a splendid opportunity to implement
> 'dynamic system behaviours' if they get properly strengthened. Servlet
> intercommunication is a pre-requisite for that and I eagerly wait to see
> what will be chapter 12 of Jason Hunter's next revision.
>
> Thank you for your time if you've got this far,
>
> Kostas
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
