Fast CGI Vs Java Application Servers

[Charles Handy]

How does FastCGI compare against java Apps running in java app servers
like TomCat, Sun One, WebLogic and WebSphere? Is there a business case
for switching from CGI to Java? Performance? Productivity? Features?
Object orientation? Code Reuse?

Any opinions?

[Alan Gauld]

On Sun, 29 Jun 2003 17:01:07 +0800, Charles Handy
<chppxf1@NOSPAM _yahoo.com.au> wrote:

How does FastCGI compare against java Apps running in java app servers
like TomCat, Sun One, WebLogic and WebSphere?
That depends on how your CGI apps are written. If its in QBASIC
running on apache on an NT box then probably the websphere
solution would be faster. If its Perl or Python then you might
not see much difference. If its C/C++ you might even find the CGI
route faster.
Is there a business case for switching from CGI to Java?
You can make a business case for just about anything if you
try...
Performance?
See above
Productivity?
Perl/Python CGI will almoist certainy develop faster than Java.
C++ is about the same IME
Features?
Maybe, Java's built in networking/security features are a big
plus, maybe the biggest plus.
Object orientation?
Nope, you can do that in Perl and certainly in Python (or Ruby).
Code Reuse?
Nope, that's much more about project organisation than
programming language.
Any opinions?

Lots but I'm trying to stay objective! :-)

Bottom line is: Does what you do now work for you? If so, don't
fix what's not broken...

Alan G.

[David N. Welton]

al********@btin ternet.com (Alan Gauld) writes:

Is there a business case for switching from CGI to Java?
As someone said, "java is great for engineering next generation
solutions to enable maximization of developer income by means of
enhanced buzzword use".
Features?

Maybe, Java's built in networking/security features are a big plus,
maybe the biggest plus.
For most of the other answers, Tcl scores about where Perl and Python
do, give or take some here and there. Here, it is worth mentioning
that Tcl has a very nice security architecture of its own, that you
can control from Tcl itself quite easily.
Object orientation?

Nope, you can do that in Perl and certainly in Python (or Ruby).
Or Tcl with an extension like [Incr Tcl].
Bottom line is: Does what you do now work for you? If so, don't fix
what's not broken...

Excellent suggestion.

--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/

[Irmen de Jong]

Charles Handy wrote:

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
- ...

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.

You don't have any of this readily available when writing (fast)CGI
applications; you have to implement all of these yourself.

--Irmen de Jong

[Irmen de Jong]

Måns Rullgård wrote:

Irmen de Jong <[e-mail]> 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
*applicatio n 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
application s; 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

[Cameron Laird]

In article <3e************ ***********@new s.xs4all.nl>,
Irmen de Jong <[e-mail]> wrote:

Måns Rullgård wrote:

Irmen de Jong <[e-mail]> 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
*applicati on 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
environmen t 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 <Ca*****@Lairds .com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html

[Ian Bicking]

On Sun, 2003-06-29 at 08:05, Kevin Kenny wrote:

Charles Handy wrote:

How does FastCGI compare against java Apps running in java app servers
like TomCat, Sun One, WebLogic and WebSphere? Is there a business case
for switching from CGI to Java? Performance? Productivity? Features?
Object orientation? Code Reuse?

Any opinions?

When anyone talks about scrapping working code, I refer them to
http://www.joelonsoftware.com/articl...000000069.html
Generally speaking, there's no good reason to ditch stuff that
works.

Sure there is -- you are doing something considerably different than
what you were doing before, and you are deciding whether to adapt what
you have or reimplement it in the context of your larger application
(though reimplementatio n and adaptation can be largely the same thing,
depending on what changes you are making).

I frequently see people who think they have code that's valuable, when
it isn't -- because maybe it was written with a difficult decision
process, or by someone who wasn't familiar with the domain, so it was a
struggle to write the first time, even though it could be reimplemented
in a matter of days.

I also see people who think one application is a close enough match to
another application that a different customer requires, that it makes
sense to just adapt the application.

Sure, Netscape is an example of an application that probably shouldn't
have been rewritten. But there is a qualitative difference between a
huge program like Netscape, and some random web app. Those are
radically different environments, and the amount of investment is
probably off by two orders of magnitude.

There's always a breaking point when reimplementatio n makes sense. If
not we'd all be programming FORTRAN. (Though I would agree that you
should seek to reimplement as small a piece as possible at any one
point)

Ian

[Ian Bicking]

On Sun, 2003-06-29 at 05:44, Irmen de Jong wrote:

Charles Handy wrote:

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
- ...

And since this is a Python newsgroup, it should be noted that in one
form or another you can achieve many of the same features in various
Python web frameworks (see:
http://www.python.org/cgi-bin/moinmoin/WebProgramming)

Many of them are application servers with an architecture not unlike
Java application servers. None of them are as complete as their Java
equivalents, but they may have all the features you really need.

Ian

[Irmen de Jong]

Ian Bicking wrote:

And since this is a Python newsgroup, it should be noted that in one
form or another you can achieve many of the same features in various
Python web frameworks (see:
http://www.python.org/cgi-bin/moinmoin/WebProgramming)

Many of them are application servers with an architecture not unlike
Java application servers. None of them are as complete as their Java
equivalents, but they may have all the features you really need.

Exactly.
From my own experience (we use J2EE application servers a lot in the
shop where I work): we've done some projects that could have worked
just as well in a much simpler environment, i.e. only a servlet/JSP
engine such as Tomcat (don't ask why we didn't do it like that
then... :-( )

While Python's web frameworks often more resemble a Java servlet/JSP
engine, instead of a "full" application server with the EJBs and
transactions and stuff, this extra burden often is just not necessary.

So, a solution based on (fast)CGI, or (preferrably) another Python
web framework, might work fine for many (if not most) situations indeed.

--Irmen de Jong

[Kyler Laird]

Irmen de Jong <[e-mail]> writes:

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:

Outstanding points. For trivial applications, CGI is fine, but beyond
that we get into the need for this infrastructure. Creating it from
scratch (or bundling it into each application) is a pain and demands
ongoing maintenance. It's great for "tinkerers" but doesn't make
sense for someone wanting to concentrate on building applications.

A Python solution for all of this is Zope.

--kyler