Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of david.blevins@visi.com
 designates 208.42.156.9 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v749.3)
In-Reply-To: <74e15baa0604232007p109de0f5hee3f6bd6e751c147@mail.gmail.com>
References: <74e15baa0604232007p109de0f5hee3f6bd6e751c147@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <668AD05D-E34A-4D12-B537-720CEFE2819C@visi.com>
Content-Transfer-Encoding: 7bit
From: David Blevins <david.blevins@visi.com>
Subject: Re: Apache Geronimo Principles & Goals
Date: Wed, 26 Apr 2006 12:55:14 -0700
To: dev@geronimo.apache.org

Excellent doc!  Some additional ideas inline....

On Apr 23, 2006, at 8:07 PM, Aaron Mulder wrote:
>
> 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 ===
>
>
> Flexibility
> -----------
> 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.

On the plugin aspect, if we can up with some basic test approach to  
them we could leverage gbuild to actually test each plugin version  
for compatibility with specific Geronimo versions.  Great way to keep  
quality up on the plugins or at minimum list the Geronimo and Plugin  
versions that are know not to be compatible.  Either way, the goal is  
predictability -- we don't want plugins to be a "don't use those,  
those things are like dynamite" kind of thing.

A great aspect of the plugin concept is that it allows for  
independent supporters of Geronimo.  Someone could very easily carve  
out a name for themselves as the author and maintainer of a useful  
plugin.  This creates little communities of independently lead  
developers circling the Geronimo app server.  People out there  
promoting and supporting their Geronimo plugins means more people  
supporting and promoting Geronimo.

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

I like the 1-click launch concept.  One idea I had when Geronimo  
started have the server squeeze out app clients with a public key  
signed by the server and have clients do mutual auth for additional  
security.  I can see this working in concert with that; a user logs  
in and gets a cert with their information in it signed by the  
server.  It's mentioned below, reiterating it here as it's just a  
cool concept.  One addition that I forgot to mention is that the app  
client binary itself is also sighed providing additional code-level  
security.  So in short, you need a valid cert with your info in it  
and a non-hacked client to connect to the server.

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

Tools to validate applications for at least minimum compliance would  
be great.  Perhaps more of an EJB need with the implicit nature of  
the relationship between an ejb and its home/remote interfaces as  
well with the expected format and existence of certain container-used  
callback methods.  Such a tool exists in OpenEJB 1.x, we use it at  
deploy time and it's usable standalone.  People really like and I'm  
aware of a few who use it in their build scripts who don't even use  
OpenEJB or Geronimo.  An updated version and similiar support for  
other J2EE components would be excellent.  It allows users to get  
their apps rejected early rather then for mistakes to slip through  
and strange errors to pop up at runtime that tend to look like  
complex server failures rather than simple compliance mistakes.

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

On the note of extending the command-line tools, here is the basic  
design we came up with so far:
http://www.openejb.org/Executables

I know the ActiveMQ guys like that concept and its probably something  
we could pull in and support at a more central level.  OpenEJB also  
has a telnet tool which has been pulled into XBean and cleaned up by  
Hiram.  The telnet environment could also be extended via a similar  
pluggable style.

http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-telnet/

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

I've had that thought for a while and one of the key things to make  
it work is the ability to have all those pages already created with  
at least the error message itself in it and a basic template for  
users to add info.  I created these client APIs for both JIRA and  
Confluence that will help make this not just a good idea for someday,  
but something we could start experimenting with now.

http://swizzle.codehaus.org/swizzle-confluence/
http://repository.codehaus.org/org/codehaus/swizzle/swizzle- 
confluence/1.0/swizzle-confluence-1.0.jar

http://swizzle.codehaus.org/swizzle-jira/
http://repository.codehaus.org/org/codehaus/swizzle/swizzle-jira/1.0/ 
swizzle-jira-1.0.jar

>
> 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").
>
>
> Documentation
> -------------
> 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.
>

Overall a very excellent document and something that is going to help  
the project significantly.  My $0.02 was largely already in it, but  
it's good to expand on the bullet points to help get discussion  
going.  The doc is really only useful if people think about it and  
add their ideas to it and we as a group discuss them and contemplate  
our possibilities as a project.  Feel encouraged to make at least a  
small investment in the doc rather than just say, "that's good enough."

All the best,
David