On Mon, 21 May 2001, Gerald Richter wrote:
> I agree to Matt, there is nothing missing for an
> application server, it's mainly a matter of installation
> and documentation, so for people not familar with CPAN
> it's maybe hard to find.
you're both missing my point. sure there are lots of
components on cpan. but most of them have apis that look
different, are documented in different ways, and are
configured in different ways. you have to install each one
and figure out each configuration syntax (some use named
parameters to object constructors, some use globals, some
depend on specific tools). many of these tools are dependent
on an apache environment.
here's an example. let's say i want to make an application
using mason for presentation and dbi to access a database.
somehow i have to construct and configure the mason parser
and interpreter. normally this is done either in a startup
script executed via PerlRequire or via mason-specific config
directives. also somehow i have to specify database info so
i can make a connection to the db server. there are a
billion different ways i could do this.
a true application server would provide an environment with
a single consistent configuration mechanism. application
deployers have one place to specify both mason and database
parameters using the same naming conventions, value types,
etc. application developers can use the exact same facility
for application-specific configuration, and they have a
single naming interface for accessing config data. the
specifics of configuring mason and dbi are handled by the
application server's glue. that's how the application server
claims to integrate configuration, presentation and database
access. furthermore, the configuration system isn't tied to
a particular deployment environment. it doesn't matter to
the application developer or deployer whether the
application is being run under mod_perl, speedycgi, or in
some other engine.
then add apis for logging and for managing sessions, apis
that are accessible to developers writing web applications.
make it so the deployer can simply twiddle a config value
and data goes to syslog instead of a file. again, not using
the apache mechanism, but an abstracted layer. notice that
the application deployer doesn't have to go get
Apache::Session from cpan and install it. the application
developer doesn't have to construct a
Apache::Session::Oracle with oracle or dbi specific
parameters, he just has to construct a
TheApplicationServer::Session, which uses that config api i
talked about earlier to figure out how to deal with
persistence.
then add an api for reporting data to a management system,
perhaps snmp, perhaps something else. again, deployers turn
a knob to figure that out. developers just use the api to
make data available. nothing specific to any particular
component. no building mod_snmp, reading its documentation,
or figuring out its configuration system.
the end goal of a application server is to simplify the
entire process of developing and deploying a complete
application, not just one part of it. we're really talking
about a whole different order of magnitude.
there's a whole huge class of people that don't want to
spend their time figuring out cpan and deciphering various
module author's foibles. they want to write code that adds
value to their business. they want infrastructure tools that
are as consistent, orderly and simple as possible. turnkey
solutions. plug and play, if you will. this is what the
application server is. "download a bunch of stuff from cpan"
is not an application server.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
