GlassFish - World's first Java EE 7 Application Server


Install Wide Features

Management across domains

  • create, list, view, delete domains, start, stop domains
  • create, list, view, delete, start, stop nodeagents
  • show status of all domains/nodeagents
  • archive(backup) existing domains
    • maintain a version history of archived domains
    • rollback to previous versions
    • install new gf bits (archive old bits/domains)
  • archive existing apps (is this useful?)
    • rollback to earlier versions
  • search facility (search application names etc)

Distribution

  • Software distribution across machines in a single one-click install
    • A glassfish install consisting of domains and clusters can span several machines. Distribute and instal any piece of software across these machines.
    • Hands free setup: A user provides a list of machines (with login account information) where GF should be installed and type of GF configuration to be installed on each of these machines. A GF install agent script (or tool) will go in and install the configurations on each of these machines.
  • Interaction with the update center
  • Ability to create pre-packaged bundles that can be distributed. For e.g: Create a bundle of GF+mysql driver(configured to point to a production db) + portal. Another example would be GF+predeployed applications.
  • Ability to migrate applications from development environment to production environment through one-click.

Tools

  • web based tool runs in a light weight web container. Manages the entire install.

Deployment Descriptor Editing

  • Certain descriptors of Deployed Applications should be editable from the admin console/admin CLI. This would help users avoid repackaging and redeployment in some cases.

Application Management and Monitoring

  • Make monitors first class citizens. A monitor is a condition or a rule. For example, average response time from a servlet should fall within a certain range. This could be tied in to self management rules
  • Show health and availability of :
    • any application deployed in the appserver
    • any component of the appserver, such as web container, ejb container, etc.
  • Health is defined as a set of monitors for a particular application or component. When one or mor monitor rules are violated, health is 'critical'. User should be able to see, why the health of an application or component is 'critical' at any given time. This is Root Cause Analysis. Some corrective action should be suggested as well.
  • CallFlow based features
    • Monitor particular application
    • Monitor containers only (e.g turn on CF for web container)
    • CF Lite that can be turned on all the time
    • Periodic monitoring of CF that can capture Container specific and Application Specific statistics
  • Incorporate Statistical Information to show
    • Mean, Median, Mean Time Between Failure (need to define what failure is)
    • Probability when the next crash (application/server) will be (e.g if a customer sees that based on past history, there is a 90% probability that app server might crash in the next 2 days. He may want to reboot the server before crunch time)
  • Identify the amount of resources used by a particular application.
  • Specify application grades (Critical/Non-Critical application).
  • Ability to throttle non-critical applications.
  • Email/SMS when server/application crashes

Role Based Administration