Re: Apache Geronimo Principles & Goals

[Dain Sundstrom <da...@iq80.com>]

Sorry for the late reply.  I have had these notes for days and just  
keep forgetting to post them.  Notes in line...

On Apr 23, 2006, at 8:07 PM, Aaron Mulder wrote:

> Apache Geronimo Principles & Goals
>
>
> === Principles ===

How about stating these with heading words like "Competitive",  
"Flexiable", and "Just Works" that tie into the Goals section.  This  
is kind of the executive summary...

>  * Be competitive with other application servers
>  * Be flexible to include exactly what a user wants (lightweight,  
> heavyweight,

I know it is the same thing, but I'd state it as "only what a user  
wants and nothing more"

>    product integration, customized admin tools, etc.).  Make it  
> easy to get
>    there from the initial download.

flexiable enough to adapt to (almost) any operating environment.  I  
thinking of university environments where 90% of the server install  
is shared and students get their own apps and logs dirs.  Another one  
is ISVs with shared installations for customers.

>  * 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")

I would state this one as "Just Works" or "Simple".  The server  
should work as an average-joe would expect.  If I throw a jar into  
web-inf/lib and restart my web app it should get picked up (it  
doesn't currently).

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

4) Installer -- select from the above "canned" solutions and customize

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

and changing the directory layout.

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

This feature should be available via a utility, so a user can easily  
add a "download a think-client" button to their web application.  I'd  
also add "create an applet" and "create an installer" options.

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

Benchmarks we create should reflect real world applications.

> Application Portability
> -----------------------
> It should be as easy as possible to port applications to Geronimo,  
> meaning:

"to and from Geronimo"

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

It should be clear when you are using a geronimo specific feature to  
avoid a surprise later.

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

Geronimo should run on as a many platforms 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").
>
>
> 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.

I think we should explicitly state we will never support unreleased  
versions (i.e., no upgrade support from unstable builds).


Just Works
----------
Geronimo is arguable the last to the J2EE table and there is a lot of  
built up knowledge in our users.  We should leverage that knowledge  
as much as possible.  There should be no-surprises and no-docs  
required.  In places where we deviate from the defacto standard, we  
should try to make the break obvious and explicit.  The worst are  
subtle differences and they should be avoided.

-dain

Re: Apache Geronimo Principles & Goals

[Matt Hogstrom <ma...@hogstrom.org>]

Dain Sundstrom wrote:
> Sorry for the late reply.  I have had these notes for days and just keep 
> forgetting to post them.  Notes in line...
> 
> On Apr 23, 2006, at 8:07 PM, Aaron Mulder wrote:
> 
>> Apache Geronimo Principles & Goals
>>
>>
>> === Principles ===
> 
> How about stating these with heading words like "Competitive", 
> "Flexiable", and "Just Works" that tie into the Goals section.  This is 
> kind of the executive summary...
> 
>>  * Be competitive with other application servers
>>  * Be flexible to include exactly what a user wants (lightweight, 
>> heavyweight,
> 
> I know it is the same thing, but I'd state it as "only what a user wants 
> and nothing more"

Probably nitpicky but I think only what a user needs.  There could be wierd dependencies that 
include more than a user wants.

> 
>>    product integration, customized admin tools, etc.).  Make it easy 
>> to get
>>    there from the initial download.
> 
> flexiable enough to adapt to (almost) any operating environment.  I 
> thinking of university environments where 90% of the server install is 
> shared and students get their own apps and logs dirs.  Another one is 
> ISVs with shared installations for customers.
> 
>>  * 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")
> 
> I would state this one as "Just Works" or "Simple".  The server should 
> work as an average-joe would expect.  If I throw a jar into web-inf/lib 
> and restart my web app it should get picked up (it doesn't currently).

Intuitive comes to mind.

> 
>> === 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
> 
> 4) Installer -- select from the above "canned" solutions and customize
+1...server templates :)
> 
>> 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.
> 
> and changing the directory layout.
> 
>> 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).
> 
> This feature should be available via a utility, so a user can easily add 
> a "download a think-client" button to their web application.  I'd also 
> add "create an applet" and "create an installer" options.

We should define who we are talking about.  For a single developer the above makes sense.  Are the 
above tools adequate for the user that has 12,000 servers with some minor differences in deployment 
options?

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

Integration with load balancers would be a neat add-on.  For instance when a server comes online it 
can interact with the load balancers to accept work / go offline.

 >>
>> 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).
> 
> Benchmarks we create should reflect real world applications.
> 
>> Application Portability
>> -----------------------
>> It should be as easy as possible to port applications to Geronimo, 
>> meaning:
> 
> "to and from Geronimo"
> 
>>  - 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
> 
> It should be clear when you are using a geronimo specific feature to 
> avoid a surprise later.
> 
>> Some popular J2EE applications should be ported to Geronimo to confirm 
>> that
>> the process is as painless as possible.
> 
> Geronimo should run on as a many platforms 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").
>>
>>
>> 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
>>
Lots of samples that people can copy and use as a start for their own projects.
>>
>> 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.
> 
> I think we should explicitly state we will never support unreleased 
> versions (i.e., no upgrade support from unstable builds).
> 
We should also support users for some number of releases.  Given the relative youth of Geronimo some 
fundamental changes are to be expected (changes in schema, etc.) however over time we will disrupt 
our users with subtle changes (configId to moduleId comes to mind :)  We'll need to consider our 
changes as they will have longer term implications.
> 
> Just Works
> ----------
> Geronimo is arguable the last to the J2EE table and there is a lot of 
> built up knowledge in our users.  We should leverage that knowledge as 
> much as possible.  There should be no-surprises and no-docs required.  
> In places where we deviate from the defacto standard, we should try to 
> make the break obvious and explicit.  The worst are subtle differences 
> and they should be avoided.
> 
> -dain
> 
> 
>