geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Apache Geronimo Principles & Goals
Date Wed, 26 Apr 2006 17:50:31 GMT
Hernan,

I am really looking for more discussion/feedback before posting this
as representative of the project at large.  It would be more helpful
to have your comments on the content.

Thanks,
    Aaron

On 4/26/06, Hernan Cunico <hcunico@gmail.com> wrote:
> Hi All,
> I put in confluence the Principles and Goals that Aaron wrote. These are listed as the
first bullet
> in the Geronimo v1.1 documentation.
>
> Matt, do you have those graphics for Geronimo deployment options? I can include them
if you send
> them over :)
>
> Here is the link to the Geronimo v1.1 documentation (well, just a few place holders so
far :)  )
>
> http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Apache+Geronimo+V1.1+-+Documentation+Draft
>
> Cheers!
> Hernan
>
> Matt Hogstrom wrote:
> > Aaron,
> >
> > I agree with the general outline below.  I mentioned in one of the 1.1
> > posts that in order to be competitive it would benefit the project to
> > define some goals around the releases.  I think the principles below
> > help to provide the framework for prioritization of goals.  I'd like to
> > take your thoughts below along with representations of the scenarios we
> > want to be effective.  I have a set of charts I noodled on about a month
> > or two ago that shows graphically how Geronimo can be deployed. I'll
> > look to get those out on the website and get people's feedback on them.
> > I think this will help as well.
> >
> > Aaron Mulder wrote:
> >
> >> All,
> >>
> >> 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.
> >>
> >> Thanks,
> >>     Aaron
> >>
> >>
> >>
> >> 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.
> >>
> >> 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
> >> 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.
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >
>

Mime
View raw message