I aggree with Steven, but I think that, if the issue on servlet programming is
only speed, then something very important is missing, and that is
representation power. I've been looking at this list for some time now, and
this speed issue appears time-to-time.
It's important to put in perspective that when we talk about web services
today, we are talking about something much bigger than implementing a dinamic
web page. It's important to understand that the meaning of web service has been
expanded greatly in the last 2-3 years, and we can think in a web service today
as a supporter for a much deeper process(es) in a organization.
If we agree on that, than we can agree that java has been prepared, in the last
years, to provide a common, object oriented and feature rich language and
environment to build strong, feature rich distributed processes and business
objects. Let's see:
- Applets only to start (distribute your process with your clients)
- Servlets and JSP's to provide a web service.
- Support for distributed abstractions like RMI and CORBA Objects
- Support for object distribution services like Enterprise Java Beans,
Java/CORBA bridge and RMI-IIOP
- A number of distributed services, like shared data toolkit, java management
services, ..., java spaces, ..., uh.
- A metaphor for abstraction encapsulation: beans
- Multiplatform support.
- ...the list is long and integrated.
I think the real issue is not speed, despite the fact that speed is important
(I know that), but the real issue is that servlets are only the peak on the
iceberg, they provide you a comfortble mechanism to provide distribution on
processes easily, comunicating each other or among different mechanisms. I
don't know any other language or mechanism providing the same representation
power to us.
Hope this helps or raise questions.
Wellington Lacerda
Brazil
"Steven J. Owens" wrote:
> maurice munoz <[EMAIL PROTECTED]> asks:
> > > How fast is CGI(perl) compared to Servlets.
> > > How is that determined.?
>
> The typical servlet article or book just blithely states that
> servlets are much faster than CGI scripts. The original servlet white
> paper Sun released mentioned some of the cases where CGI scripts might
> be as fast or faster, but it doesn't seem like anbody has actually
> done any formal comparisons.
>
> If you're asking how fast "CGI" per se is, compared to servlets,
> the question doesn't make any sense. CGI is just a standard for how
> to ask the web server to run a program and send the output to the
> browser. You probably mean to ask, how fast are CGI scripts, compared
> to java servlets. However, this also doesn't make any sense, because
> CGI programs can be implemented in a huge variety of ways. They're
> usually implemented in some flavor of scripting language, which has
> lead to the common usage of the phrase "CGI script" to refer to CGI
> programs. But CGIs can be written in Perl, C, C++, Cobol, Fortran,
> even Java :-).
>
> Okay, so assuming that you're talking about the mainstream of CGI
> programming, like Perl, Python, etc, the answer in a large part still
> depends on how the CGI scripts are implemented, and how they're run.
> Leave aside issues of how the particular programmer chose to structure
> the code. Any demo can be rigged, as the recent Microsoft-funded
> Mindcraft comparison between Linux and NT demonstrated. Give me a
> skilled Perl coder and a skilled Java coder and I'll have both of them
> code pathological approaches that will surely lose compared to normal
> scripts or servlets. Likewise, have one code in a "moderate" fashion
> while the other goes all-out to optimize and I'll bet I can have either
> one win.
>
> So assume the programs are both designed and coded in a
> moderately sensible way. The speed issue usually boils down to a
> number of factors, only one of which is how the speed of the "typical"
> language implementation:
>
> The Perl crowd, for example, maintains that Perl is often as fast
> as well-coded C for doing text-intensive stuff - and of course, not
> every C coder is going to be able to write code up to that level of
> quality. Of course, I've never seen any statistical studies and proof
> of this fact, either. I did hear vague rumors last week that somebody
> did a study that showed Perl code loses to Java code (not CGI scripts,
> just plain code) in most cases, but again, I don't know the details -
> for all I know, the "most cases" doesn't include the stuff used for
> 80% of CGI scripting.
>
> Other factors that have an impact are the circumstances of how
> the program is started, whether it's kept in memory, when compilation
> happens, where the interpreter or virtual machine that runs the
> program needs to be loaded, whether the program needs to open
> connections to any resources (like database handles) or can get them
> from a pool or keep persistent resources, and so forth.
>
> Since CGI scripts are typically written in Perl and start from
> scratch for every request, there are a number of factors we might
> assume are present: forking a process to run the script, loading the
> script file, loading in the the Perl interpreter, loading any modules
> required by the script, loading any resources (opening database
> handles), and then finally actually running the script, doing whatever
> it does, sending the results back to the user, and then throwing all of
> that away to start over again next time.
>
> Servlet proponents point out, quite rightly, that all of that
> takes up a heck of a lot of resources - and time. However, Perl
> proponents point out that some fairly common techniques and tools -
> like mod_perl, which makes the perl interpreter part of the webserver,
> and fastCGI, which runs the CGI scripts as a separate server the
> webserver can hand off CGI requests to, both of them providing tools
> for persistent resources (usually database handles) and running
> scripts as daemons - will deal with most of the above issues.
>
> On the flip side, writing a simple "standard" CGI script in Perl
> is quite easy and fast; because you're throwing everything away after
> running the script, you don't have to worry nearly as much about
> things like memory leaks, allocating and deallocating variables, etc.
> Compared to a servlet, CGI scripts are a snap to write. However, when
> you switch to writing CGI scripts to run as daemons under mod_perl or
> fastCGI, with persistent data and resource pooling, writing a perl
> script is significantly trickier - kind of like writing a servlet.
>
> Steven J. Owens
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> ___________________________________________________________________________
> 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
