You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scm@geronimo.apache.org by Apache Wiki <wi...@apache.org> on 2005/07/16 05:32:18 UTC

[Geronimo Wiki] Update of "Web Console" by AaronMulder

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Geronimo Wiki" for change notification.

The following page has been changed by AaronMulder:
http://wiki.apache.org/geronimo/Web_Console

New page:
This page is meant to summarize my thoughts on what should go into a web console.  I've looked at the donated web console, but haven't started digging into its construction yet.

== Overall Structure ==

Like any web app, the console needs to show individual blocks of content (data/forms/graphs), with blocks arranged into pages, and some way to navigate between pages.  This generally means one or more of:
 * tabs or navigation menus across the top
 * a navigation bar on the left
 * dynamic menus (drop-down options appearing below navigation menus, for example)
 * a tree widget

I haven't figured out the best approach yet.  The current donated console uses a static navigation area on the left, several blocks on each page, and no other real navigation other than putting links in the content blocks.  It would be nice to extend the navigation to a greater depth but I'm not sure the portal framework supports it.  I need to look into this.

Commercial consoles seem attracted to the tree view on the left.  The Applet-based navigation trees have the advantage that they can receive notifications pushed from the server and update themselves (which seems like it would require a bit of AJAX ninjitsu for a more static navigation system).  Still, it's not clear how necessary that is, vs for example periodic refreshes.

== Technologies ==

For a web-based console, portlets seem like a cool idea.  They may restrict navigation a bit (for example; could your navigation system include an entry for each deployed application, as opposed to only the category for applications?  not yet known), but it nicely segregates components.

Still, the appearance is kind of plain, and the console doesn't feel very dynamic.  It would be cool to experiment with Laszlo a bit.  :)

Ideally, we'll have a configuration API available.  Then we could build one or many front ends against it.  For example, we may want a command-line tool that lets you change conflicting network ports, using the same configuration API calls made by the web console.  I might want to fool with Laszlo without rewriting the underpinnings of the portlet-based console.

== Proposed Content ==

Here's what I'd like to see in a web console.  I haven't put the time into describing each of these areas in detail yet, though I'd like to.

 * Server
   * Basic Info (uptime, JVM, classpath, whatever)
   * Web settings (ports, threads, SSL, etc.)
   * EJB settings (ditto)
   * J2CA settings (work managers, may just call this category "Thread Pools" if that's what it is)
   * CORBA settings (ports, IOR settings, CSS/TSS, ???)
   * UDDI server (are there any pertinent settings?)
 * Services
   * Common Libraries (contents of repository, add/remove)
   * JDBC (add/edit connection pools, view statistics)
   * JMS (add/edit broker(s), connection factories, destinations, etc., view statistics)
   * J2CA (add/edit top-level connector deployments -- but is this different than apps/J2CA?)
   * Mail (basic defaults like SMTP server)
 * Applications (all below support deploy/start/stop/undeploy/redeploy, view configuration, view statistics)
   * EARs (navigate to children)
   * WARs
   * EJB JARs
   * J2EE Connectors
   * Client Apps
   * System Modules (everything that's not an app, connector, security realm, etc.)
 * Security
   * Login Modules (if they end up getting independent configuration)
   * Realms (groups of login modules, add/edit, view members, etc.)
   * SSL/Keystore (if it ends up being more widely used than in web apps)

Some of these areas exist in the donated console, and others don't.  Few of the areas seems as complete as I'd like them to be.  I actively dislike some, like the one that lets you drop tables from the system database...