Re: What I Learned on my Vacation - Part I - WebSphere

Hi Joe, you have covered the primary areas folks are faced with when trying
to use WebSphere to write and run their servlets. I have found WebSphere's
servlet engine seems to work pretty well too, but I am probably biased,
ibm'er that I am. There is a definite learning curve with WebSphere that
everyone will suffer thru, no doubt about it.  WebSphere v3 is a whole
different beast than v2, it is much richer in function as well as in
complexity.

The catch-22 is you will meet with frustration if you don't read the
WebSphere doc.  But without a working knowledge of the servlet API, JSPs,
browser/webserver/appserver concepts, not a whole lot of it will stick on
the first reading.  I think you have to play around with WebSphere a while,
then go back and reread it and it will make a lot more sense.  Personally
for me, it wasn't until I understood the steps of how an incoming URL from
a browser got processed/mapped to the physical location of a servlet, jsp,
html, gif, etc. in WebSphere, that I felt I had reached a major milestone.

I would like to add some /*** commentary  ***/ to your commentary - for the
most part your observations are right on, but there are some clarifications
to be made as well as amplifying what you have discovered.


What I Learned on my Vacation
Part I - WebSphere

What can I say?  WebSphere works.  It works pretty darned well.  Of course,
it's not without its little pecadillos, but in general it's a pretty solid
product.  Specifically, though, I learned the following:

1. Components.  There are really four basic components to web applications:
HTML, servlets, JavaServer Pages and Java beans (the sort of generic term
for all your other Java support classes).  Each is handled slightly
differently by WebSphere, but they're pretty straightforward once you get
the hang of them.

1A. HTML.  HTML access is controlled completely by the MAP and PASS
directives of your HTTP configuration.  I've also done some preliminary
research on the use of ACLs (Access Control Lists), enough to figure out
how
to secure access.  I'll talk about that a little later.

/***  There are actually two options for controlling HTML access, and the
key is whether the "file serving servlet" has been configured for the web
application containing that the HTML page.  If the containing web
application does not have the file serving servlet configured, then the
HTTP webserver is charge of serving the HTML page.  If the file serving
servlet is configured, then the HTTP webserver's plugin code will send the
http request to the WebSphere's servlet engine, which in turn will locate
the HTML page and return it back to the HTTP webserver.  WebSphere
"default" web application does not have the file serving servlet
configured, so I am suspecting it was this web application that you have
been working with.  When the file serving servlet is configured, then the
HTML pages must be placed alongside the JSPs in the web app's document
root.  (Only one document root is allowed per web app.)  I think the
primary tradeoff here is speed vs. organization: it is better
performancewise to have the HTTP webserver serve static HTML than to send
the request to an out-of-process servlet engine.  But if you have a bunch
of web app's, you can organize your HTML files into each web app's document
root - it is better for your sanity.
***/

1B. Servlets.  The location of servlets are controlled by the CLASSPATH of
your Web Application.  This is defined in the "advanced" tab of your web
application definition in the webadmin console.  The web application
definition is underneath the servlet engine definition, which is underneath
the application server definition, which is under the node definition.

/****  What is nice about the web app classpath is that it is reloadable.
That is, if you update the servlet, the change will be picked up
automatically.  This is the default, which you can override.  Or you can
place the servlet class file in WebSphere system classpath, which is
searched ahead of the web app classpath.  If you do place your servlet in
the system classpath, an update to that servlet classfile is not picked up
automatically.  This can be a source of frustration for those unaware of
this distinction.  A useful configuration option is to configure your
servlet to "Load at Startup", where the servlet's init() method will be
called when the Servlet Engine is started.  Putting as much setup stuff in
here can be useful, rather than waiting for the first time the servlet is
invoked by a client.
***/

1C. JavaServer Pages.  I'm still a little fuzzy here.  As close as I can
determine, JavaServer Pages are handled by the web document root of the web
application.  I'm not sure what decides that a given URL is a JSP or a
servlet request, but when a JSP is identified, the path portion of the URL
is appended to the web document root to determine where the JSP is located.

/*** Here is about as good a time as any to describe the URL mapping to the
physical mapping.  If this is understood relative to JSPs, then it is just
a matter of applying it to the other types such as html, servlets, etc.
Two key items in mapping an incoming URL is the web application's web path
(e.g. "/webapp/examples") and the Servlet Web Path List of the jsp
processor configured for that web application.  For example, the jsp10 (JSP
servlet) has a Servlet Web Path List of "/*.jsp", and when combined it
forms: "default_host/webapp/examples/*.jsp".  So a URL such as
http://hostname/webapp/examples/myJSP.jsp gets mapped to the JSP servlet in
the "examples" web app.  Similarly, understanding how the "file" serving
servlet and the "servlet invoker" get mapped is also worth noting.
****/

1D. Beans.  I've found that by far the easiest way to handle beans is to
put
them in a jar and put the jar in your application classpath.  It's simple,
and as long as your jar files are relatively small, there's no problem.
When you upload a new jar file, WebSphere reloads it automatically.

1E. Overall. I put all my HTML, JSP, and servlets underneath my web
document
root.  I use the PASS directive in my HTTP configuration to point the HTML
to the appropriate directory.  That way, all of my components, static or
dynamic, are accessible in the same relative URL structure.

/*** As mentioned earlier, it can be okay to do this but when developing
more and more web applications, it can get a bit unwieldy.  By defining the
file serving servlet to web apps, you sacrifice some speed for the sake of
organization, and you can place related html, gif, jsps, etc. all in one
place.
***/


2. Sessions.  Sessions are an interesting concept.  Most importantly,
sessions are meant to be permanent; you're not supposed to go back and
forth
between a user session and an anonymous session.  In fact, if you do, you
lose your session variables.  I've been using ACLs to secure my sessions,
and they work quite well.


Anyway, that's Part I of What I Learned on my Vacation.  I'll be giving
another update a little later in the week, I hope.  Are there any
particular
areas anyone would like covered?



+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---