geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Apache Geronimo Principles & Goals
Date Mon, 24 Apr 2006 03:07:11 GMT

Here's a little something I've been assembling to help as we move past
certification and look for what's next.  I'd like to post this (or
something like it) to the web site, ideally for the 1.1 release so
it'll be there for people wondering (at a high level) where we're
going from here.


Apache Geronimo Principles & Goals

=== Principles ===

 * Be competitive with other application servers
 * Be flexible to include exactly what a user wants (lightweight, heavyweight,
   product integration, customized admin tools, etc.).  Make it easy to get
   there from the initial download.
 * Be the IntelliJ of app servers (it thinks like you do, works like you
   expect, etc.) -- alternately, be the OS X of app servers (easy to use and
   even the hard stuff "just works")

=== Goals ===

Geronimo should meet anyone's needs from very lightweight to very heavyweight.
Generally, the distribution option should be:

1) Minimal -- kernel and command-line/script administration tools only
2) Web -- web container and web admin tools
3) J2EE -- certified J2EE stack with web admin tools

The included tools must make it extremely easy to download and install
additional features (e.g. plugins) to add on to the basic distribution.  And,
of course, anyone is free to create more comprehensive distributions by
bundling plugins and distributing the resulting package.

It should be possible to get an app running and then have "1-click" options
to strip down the server to only what that application requires.  It should
also be possible to easily replicate a Geronimo installation to another
machine (or to another existing Geronimo installation).  It should also be
possible to export an environment to run a J2EE application client in
(ideally, export it as a dynamic Java Web Start configuration so you can just
run it on your local PC by clicking a link in the console).

Performance & Scalability
Performance must be comparable to other application servers in key areas.
Geronimo should support clustering of web and EJB components for scalability
and fail-over fault tolerance.  Geronimo should work with common hardware

Benchmarks should be made available with clear instructions for users to
configure and run them on Geronimo as well as on other application servers.
There should be clear performance tuning guidelines, and the performance
tuning options should be extremely accessible (e.g. provide a dashboard-
style page with all the settings to tune a web application in one place
along with recommendations for the various settings).

Application Portability
It should be as easy as possible to port applications to Geronimo, meaning:
 - reduce the need for Geronimo-specific XML configuration files
 - simplify and minimize required settings in Geronimo-specific XML
   configuration files (e.g. eliminate nested namespaces, provide optimized
   file formats for common things like database pools, eliminate target names
   in references)
 - Isolate the application classpath from Server internals (Spring, logging)
 - Make common but non-standard code work (global JNDI lookups, etc.)
 - Support file layouts, config files, scripts, termininology from other
   popular application servers (or stay as similar as possible)
 - Provide conversion tools to import configurations from other app servers

Some popular J2EE applications should be ported to Geronimo to confirm that
the process is as painless as possible.

Administration & Management
Geronimo should provide command-line, Ant, Maven, and web versions of all
key tools.  This includes tools to:
 - get a list of available plugins
 - download and install plugins
 - deploy/redeploy applications
 - start and stop the server
 - export an application client wrapped in Java Web Start, even including
   auto-generated SSL keys/certs for mutual authentication.

The web console should be at least as function as the BEA WebLogic web
console.  It should make it easy to both configure the server and gather
runtime statistics.  It should make it easy to run a second Geronimo instance
on the same machine (using different network ports).  It should be possible
to rearrange the console content to suit the user's needs/style, or at least
provide breadcrumb-type access to frequently used functions.

It should be possible to set up several Geronimo configurations that share
the same core installation files but have their own configuration files,
deployments, etc. similar to WebLogic domains (but not like JBoss which
copies too many JARs into each configuration).

Geronimo should include a Windows Service to run the server.  Ideally, it
would also have a service like BEA Node Manager to start and stop servers
on remote machines.

Geronimo should include scripts or command-line tools that make it easy to
perform and/or automate common tasks such as deploying a new database pool or
adding a new JMS destination.

Geronimo should provide packaged integration for management tools such as MC4J
and JConsole.  It should be easy to construct custom management tools using
Geronimo maangement APIs.

Individual plugins should be able to include management plugins that fit into
both the console and the command-line tools.  The user should be able to
update the layout and navigation to customize their own experience.

Development Tools
In additional the aforementioned tools, Geronimo should provide detailed
integration with popular IDEs including Eclipse, IntelliJ, and NetBeans.  The
integration should include starting and stopping the server, debugging, and
generating Geronimo deployment plans for application modules.

Geronimo should also include comprehensive XDoclet support.

Geronimo should provide tools to streamline development wherever possible,
including things like (note Rails influence):
 - generating persistence classes and simple web screens on top of them
 - populating a database with test data
 - rolling back to a previous version of an application

Developer Experience
Geronimo should produce high-quality error message.  Every deployment should
be validated according to the relevent specification's rules before Geronimo
attempts to configure and run it.  The deploy tool should always display
relevant errors to the user (without additional arguments).

It would be great to create a more robust error-handling system with codes
for internationalized messages, linked to a Wiki with discussion and reports
from the field on when each error was encountered, how to work around it,
links to related Jira issues & patches, etc.

It should be possible to easily enable performance traces that break down the
time spent in each user-provided method (or important Geronimo function such as
a persistence operation or JTA commit) over the course of a single
call/transaction.  It's OK if this introduces overhead, so long as it produces
usable aggregate information (62% of each call to /myapp/hello spent "here").

Geronimo should include comprehensive free documentation, including:
 - Reference for server and application configuration, emphasizing why
   particular settings are important, when you should use them, and how you
   decide what to set them to
 - Howto's for writing your first J2EE applications with Geronimo
 - Howto's for advanced server / administration tasks
 - Detailed guides for available plugins

Production Integration
Geronimo should provide canned integration with popular open source and
commercial products in categories such as:
 - Databases
 - Distributed caching
 - LDAP, single sign-on, & identity management
 - Portals
 - SOAP/XML stacks
 - ESB/JBI/integration tools
 - Scheduling
 - Reporting
 - Web frameworks
 - Debugging/optimization tools
 - Performance testing
 - ISP virtual hosting / control panels
 - Applications (samples, business apps, bug trackers, CI, etc.)
In many cases this will include an actual Geronimo plugin, but for some areas
it may only include documentation (how to configure the tool and Geronimo to
work together) or code and documentation (if the integration requires extensive
customization so a plugin isn't flexible enough).  In any case, the package for
each product should include comprehensive documentation.

Updates and Upgrades
Geronimo should include a strategy for updating a server in-place to the latest
maintenance release, or at least to apply critical fixes.  Ideally, this will
not break any existing plugins or applications.

For major new versions of Geronimo, there should be an upgrade tool to convert
configuration files, in any cases where Geronimo will not accept configuration
files built for the previous version.

View raw message