Background

The JBoss Application Server gained popularity at a grassroots level in large part due to its relative ease-of-use.  While the interfaces to AS have remained constant over the past five major releases, the development landscape has changed significantly.  In recent years our flagship project has been lauded as slow, unwieldy and cumbersome by an audience seeking more rapid feedback during application testing[1].  We have reached the maturity to become competitive within enterprise production environments at the expense of the principles which originally brought about our success.

Objective

Deliver an integration project whose primary demographic is composed of application programmers.  While suited for production, the focus should be on useability during the development phase.

A View of the JBoss Application Server

• Standalone installable software
• Dedicated OS Process
• Start / Stop done from command line or automated scripts
• Deployment done via filesystem copying
• Configuration through flat files
• $JBOSS_HOME standard layout (server, lib, client subdirectories, etc)

Regardless of the features provided or specifications implemented, the above high-level interfaces to interaction with the server have come to define what is expected of the project.  Additionally, AS is the upstream provider towards a direct revenue stream in the form of EAP, which imposes restrictions on how dramatically we may change the final distribution.  It will be difficult to abandon the points above, though we may augment them (as will be done in the upcoming release of EmbeddedAS alongside AS 6.0.0.M1).

Proposed Useability Requirements

• Extensible typesafe configuration API for all aspects of the server 
  • server.getConfiguration().as(WebConfiguration.class).bindPort(8080).bindAddress("localhost");
  • May be frozen during server initialization (before startup) and locked immutable afterwards
  • Becomes the end-user hook into authoritative metadata view (eg. ProfileService)
  • All components integrating with AS must obtain their config from the same metadata store
    • ProfileService
    • The API counterpart to a unified domain.xml
• No preinstallation requirement (eg. JBOSS_HOME)
  • Maven users may declare a single dependency
    
    • May transitively bring in further components
  • Ant/etc users may import one artifact
  • Single distribution may encompass all binaries and resources required to run (ie. one JAR)
• No filesystem assumptions
  • Overrides to configuration is done declaratively
• No ClassLoader assumptions 
  • Resources cannot be expected to be packaged in a particular manner, hence part of any specific CL
• Slim boot dependency  
  • Intended for the Application Classloader which does not leak, allowing a small --classpath dependency for the runtime.
  • All other deps may be brought in via a larger JAR defined in a URLClassLoader
• Intelligent defaults/conventions 
  • Boot up things required of testing, nothing else
  • But give users the option to plug in/deploy other stuff.   
    • EJB 2.x
    • Admin Console
• Focus on boot performance 
  • Webapps running in seconds
  • Problems identified during integration when bringing in new subsystems
  • Slow pieces to be fixed at the project level
• Only true components allowed in 
  • A "component" is defined as something able to run on its own
  • We then rebuild the runtime to simply integrate pre-approved projects
  • In the end, we have something functionally equivalent to AS
• Maintain session state on application redeploy[5]

Many ideas outlined above have been previously discussed at the 2009 Internal AS Meeting[2], on the community Wiki[3], and in the public development list[4].

Comparison Matrix

Phased Development

1. Create new integration project under its own brand name
2. Define end-user APIs.  Likely to closely resemble those currently provided for EmbeddedAS, with additional hooks into ProfileService typed configuration.  Will address lifecycle, configuration, and deployment.
3. Begin importing components into the new runtime.  Monitor each for impact upon boot time, and raise problems upstream until fixed.  Projects must respect the contract to keep low overhead.
4. Alpha release ship criteria - EJB3, JPA, JBossWeb, JMS, JCA
5. Timeboxed releases once initial ship criteria is met

References

[1] Google Search for "jboss sucks": http://www.google.com/search?q=jboss+sucks
[2] AS Meeting: https://docspace.corp.redhat.com/clearspace/docs/DOC-22312
[3] AS WishList: http://www.jboss.org/community/wiki/JBossASTop10

• Folks saying they've gone to GlassFish/OpenEJB
• Repeated requests for "fast boot time"
• Requests for zero-turnaround hot deployment won't matter if the server is up and running quickly.

[4] jboss-development Discussions: http://lists.jboss.org/pipermail/jboss-development/2009-April/thread.html#13907

[5] Glassfish Session State on Redeploy: http://blogs.sun.com/alexismp/entry/short_screencast_on_glassfish_v3