Fast CGI Vs Java Application Servers

[Cameron Laird]

In article <3efed46f$0$49115$e4fe514c at news.xs4all.nl>,
Irmen de Jong  <irmen at -NOSPAM-REMOVETHIS-xs4all.nl> wrote:
>Måns Rullgård wrote:
>> Irmen de Jong <irmen at -NOSPAM-REMOVETHIS-xs4all.nl> writes:
>> 
>> 
>>>>How does FastCGI compare against java Apps running in java app
>>>>servers like TomCat, Sun One, WebLogic and WebSphere?
>>>
>>>
>>>A (fast)CGI program compared to the actual Java program may not be
>>>much of a difference, depending on the program of course. What is
>>>a *huge* difference is that the Java app is running inside an
>>>*application server*. A (J2EE) Application Server provides a
>>>rich environment on which to base your scalable enterprise applications:
>>>- security
>>>- connectivity
>>>- scalability (performance, clustering)
>>>- maintainability / managability
>>>- error reporting/logging
>>>- component based (EJBs)
>>>- database connectivity and object persistence
>>>- transactions
>>>- ...
>> 
>> 
>> Someone mentioned buzzwords elsewhere in this thread.
>
>Very true ;-)
>
>But the fact remains, that you get the above mentioned things
>in one way or another when using an application server.
>Wether you *need* them is a totally different matter.
>As somebody else pointed out, if what you do now works for you,
>don't fix what's not broken...
>
>>>All of these are standardized in some way (as part of J2EE).
>>>In theory you can move your J2EE application to a different
>>>environment running on a different vendor's app server without
>>>much sweat.
>> 
>> 
>> That is, after you spent three weeks trying to figure out the correct
>> classpath, if one even exists.
>
>That's why I said "in theory".
>Classpath issues are the least of your problems.
>(and really should not take you more than an hour to figure out).
>
>>>You don't have any of this readily available when writing (fast)CGI
>>>applications; you have to implement all of these yourself.
>> 
>> 
>> Hey, it could be fun.
>
>I cannot imagine how it can be fun to design, build and test your
>own XA transaction layer or object persistence.
>
>But, for simple web applications, it *is* fun to build them from
>the ground up. You learn a lot by doing so.
>
>--Irmen de Jong
>

Me, too.

Kevin, Irmen, et al. have already covered all the high points.
Here are my reactions:  in big-department, J2EE-committed groups,
there often is utter incomprehension about what we're saying.  When
we seriously propose CGI (or FastCGI) with a "toy" language like
Python or Tcl, they see that as the rough equivalent to grinding
flour by hand, rather than buying a loaf of bread at the grocery.
Some decision-makers don't even believe existence proofs that CGI-
based approaches can meet requirements.

Application servers do have some wonderful functionality; it's
quite hard to find EJB service, load-leveling, some senses of
object persistence, ... as supplied by Tomcat, WebSphere, in the
"scripting language" world.

Java-oriented people underappreciate the extent to which applica-
tion servers *need* such built-ins, simply because development is
so clumsy with them.  VERY few of the sites that have paid for
Web clustering *need* it, in any sense that I can understand, 
except to compensate for problems the clustering-aware software
itself creates.  More generally, application server-based projects
oriented to Java simply have big, big start-up costs.  It can be
quicker writing a new little logging facility in Perl than just
trying to get the application server working at all.  That's what
I've seen, at least.

Be very careful about the "security" argument.  Yes, Java is a
"secure" language--in very specific senses.  The security require-
ments of your particular situation might be entirely orthogonal.
In the dimensions that matter to you, Perl or Tcl might be *better*
than Java in supplying the kind of security you're after.
-- 

Cameron Laird <Cameron at Lairds.com>
Business:  http://www.Phaseit.net
Personal:  http://phaseit.net/claird/home.html