Fast CGI Vs Java Application Servers

Discussion in 'Python' started by Charles Handy, Jun 29, 2003.

  1. 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?
    Charles Handy, Jun 29, 2003
    #1
    1. Advertising

  2. Charles Handy

    Alan Gauld Guest

    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.
    Alan Gauld, Jun 29, 2003
    #2
    1. Advertising

  3. (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/
    David N. Welton, Jun 29, 2003
    #3
  4. 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, Jun 29, 2003
    #4
  5. Måns Rullgård wrote:
    > Irmen de Jong <> 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
    Irmen de Jong, Jun 29, 2003
    #5
  6. In article <3efed46f$0$49115$4all.nl>,
    Irmen de Jong <> wrote:
    >Måns Rullgård wrote:
    >> Irmen de Jong <> 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 <>
    Business: http://www.Phaseit.net
    Personal: http://phaseit.net/claird/home.html
    Cameron Laird, Jun 29, 2003
    #6
  7. Charles Handy

    Ian Bicking Guest

    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/articles/fog0000000069.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 reimplementation 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 reimplementation 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, Jun 29, 2003
    #7
  8. Charles Handy

    Ian Bicking Guest

    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
    Ian Bicking, Jun 29, 2003
    #8
  9. 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
    Irmen de Jong, Jun 29, 2003
    #9
  10. Charles Handy

    Kyler Laird Guest

    Irmen de Jong <> 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
    Kyler Laird, Jun 30, 2003
    #10
  11. Kyler Laird wrote:
    > Irmen de Jong <> 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.


    That depends. Many companies want to write their own base modules, so
    that they can be extended to meet their needs. This is very time
    consuming, but the upside is that you know the code perfectly and are
    able to fix bugs/enhance the code very fast.

    > A Python solution for all of this is Zope.


    And a Tcl solution is AOLserver and OpenACS :)

    --
    WK
    Wojciech Kocjan, Jun 30, 2003
    #11
  12. Kyler Laird <> writes:

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


    There are several solutions for Perl, and I'd imagine that there's at
    least one for Tcl, but that's sort of beside the point.

    Going the Java route buys you some things. There are a lot of Java
    developers out there, and with baseline-competent management, Java can
    do a decent job of protecting you from less competent developers.
    (Much as I like Perl, the same cannot be said for it.) There is a
    standard interface between the web application and the container that
    can handle the more annoying problems such as object persistence,
    session state, and authentication, not to mention more difficult
    things like load balancing and clustering.

    At the same time, Java has a lot more overhead. You'll need more
    hardware and probably more support staff, and the easy availability of
    Java support staff is no indication that they're any good. And then
    you get to run into the single biggest Java headache. Because the
    implementation involves everything running in a virtual machine, and
    many code libraries are closed-source, with just the interface and the
    compiled bytecode available, it can be extremely difficult to track
    down a bug: even identifying with any certainty whether the issue lies
    in your code, in the library you're calling, or in the JVM can be a
    pain.

    I suppose what I'm getting at is that if you're comparing FastCGI to
    Java based solely on performance, you're ignoring a whole host of
    criteria that can be equally as important: development speed,
    available support, and scalability, just to name a few. In
    particular, if you've got programmers and admins on staff who can do
    good work with FastCGI, don't force them to use Java instead; the
    results will probably be horrible at first, and any performance
    improvement you expect to see by switching to Java will be more than
    offset by the learning curve.

    My advice would be to use Java for a project or site that is large
    enough to afford the overhead, and to use a language-based approach
    (mod_perl, Mason, Zope) otherwise. If you're the only person working
    on the project, it's almost certainly too small to be worth the
    overhead.

    Charlton
    Charlton Wilbur, Jun 30, 2003
    #12
  13. Charles Handy

    Kyler Laird Guest

    Wojciech Kocjan <> writes:

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


    >That depends. Many companies want to write their own base modules, so
    >that they can be extended to meet their needs. This is very time
    >consuming, but the upside is that you know the code perfectly and are
    >able to fix bugs/enhance the code very fast.


    Sure, and I do this. But I do it under Zope where I don't have to
    create from scratch (and maintain) anything that is not specific to
    my projects.

    --kyler
    Kyler Laird, Jun 30, 2003
    #13
  14. (Paul Boddie) writes:

    > wrote in message
    > news:<20030630120924.209$>...


    > > Switching a working application to a new language is about the
    > > greatest possible crime there is against code reuse.

    >
    > "We believe in code reuse. Apart from the system we just threw away,
    > of course."


    It's also possible that the old application just barely works, and
    that it will take more work to bolt new things onto the side of it
    than to rewrite it from scratch. If we're talking about a 15-year-old
    C application that had a web interface bolted onto it a few years
    back and which has been undergoing continual change and occasional
    expansion, I could certainly see a case for rewriting the whole mess.

    Charlton
    Charlton Wilbur, Jul 1, 2003
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    646
  2. Michele Simionato

    Python is darn fast (was: How fast is Python)

    Michele Simionato, Aug 23, 2003, in forum: Python
    Replies:
    13
    Views:
    551
  3. Sanny
    Replies:
    4
    Views:
    337
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=
    Sep 16, 2007
  4. Luigi Ma
    Replies:
    0
    Views:
    124
    Luigi Ma
    Nov 21, 2007
  5. Charles Handy

    Fast CGI Vs Java Application Servers

    Charles Handy, Jun 29, 2003, in forum: Perl Misc
    Replies:
    9
    Views:
    206
    Charlton Wilbur
    Jul 1, 2003
Loading...

Share This Page