Re: The Revenge of the Geeks
BGB wrote:
I had generally imagined web-servers mostly like they were file-servers,
but with the plus-side of having a defined browser-level interface, and
the ability to use scripts or binaries to generate contents.
Terminology varies, but by widely-accepted convention a web server specifically
handles browser-like interactions using (mostly) HTML over HTTP[S]. An application
server, as others explained upthread, serves all kinds of services in service of
applications designed to run in that environment. It might, and often does, incorporate
a web server as part of the panoply of services provided. But the concept you must
grasp is that application servers, such as those that implement Java EE, are kitchen-sink
propositions, giving all kinds of help to applications from an "enterprise" (read "project",
"organization", or professionally cognate term) perspective.
You can play reductionist mind games all you want, I mean, really, isn't all "just" machine
code in the end? Playing that type of game utterly misses the point and to reply in such
terms is inappropriate. The point of any framework, or computer language, or toolkit, is
to educe a closer mapping between the ontology of the enterprise (in its literal English meaning)
and the ontology of the model you're building. To sit disingenuously in the wrong ontology
serves neither your education nor contributes to the common weal.
But you've been around this newsgroup a long, long time and by now you really should have
found out some of this for yourself. Java EE is well documented and the tools are free and open
source. So if you really had any genuine desire to understand the concepts and goals of the
specifications, you'd've done so already.
Java EE is like a high-level language, but for deployment and connection of services. It's one of
those things that separates mere programmers from people who can solve problems with software
systems. Its goals are deployability, scalability, ops-friendliness, orchestration-ability (sorry :-)),
stability, and pragmatic leverage for useful software systems. It encompasses a broad range of tools,
such as message queues, persistent storage, server clustering, resource management, orchestration,
troubleshooting, and more.
for a client-side app (probably a traditional desktop-style
application), it would use an HTTP server mostly like a file-server for
retrieving updated resources and similar. a CGI script could mostly
exist to provide a manifest and so the client app can know if/what files
to download.
dunno about an app working in a browser, I haven't personally really
looked much into this. the one thing I had noted which I felt might make
this worthwhile was "Google Native Client", but given it is Chrome-only
at this point, this is a drawback (better if Firefox supported it, but
the FF people apparently oppose it).
Adobe Flash sometimes seemed like a possible option, but isn't
particularly compelling, and the development environment apparently
costs money.
but, generally, I more prefer the desktop application experience...
--
Lew