Administration Console for GlassFish V3 Release
Anissa Lam : anissa.lam@sun.com
Jason Lee: jasondlee at sun dot com
Ken Paulsen: ken.paulsen@sun.com
Created: January 7, 2009
Administration Console (GUI) is one of the tools for application server administrators to configure and monitor the application server.
The Administration Console was well received by the community and often viewed as a differentiator from other similar products in the market. For GlassFish V3, we need to continue to provide this user friendly administration tool. One of the more common complaints is performance, to ameliorate that issue, this release will contain several UI updates and changes that will improve performance and our ability to maintain and enhance the admin console. Some of the benefits of making these UI design changes include:
This release will include full support for Java EE 6 features. See section 4.4 for features which are NOT in scope for this release.
4.1.1 Scripting
This is based on the Scripting Support One Pager .
There will be 2 plugin modules implemented by the GUI team. One plugin is to support administration and application configuration for JRuby framework (Rails, Merb). Another plugin to support administration and application configuration for Django applications. Console will provide UI to do the deployment and listing of the deployed apps. Appropriate UI widgets will be used so user can configure the properties spelled out in 4.7.1.1 section of the one pager.
Based on the scripting one pager, there is not enough info at this point regarding the configuration for Jython/Django application. This one pager will be updated later.
There will be support for monitoring of the JRuby container. This will include both the configuration and viewing of the monitor data. More details coming ...
4.1.2 Application management
This is based on the Application Management One Pager .
Console will provide the UI for user to edit the and of the deployment descriptor as specified in the above one pager. This will be supported for web application only as no other container team has approached the GUI team for such support.
A table will be provided that listed out all the customized and , the default value specified in the deployment descriptor, and allows user to override that.
4.1.3 Non-war deployments
In v3 prelude, only war deployment is supported. For this release, all Java EE application types will be supported. This includes war, ear, jar, rar files, including wars with ejb jars. Gui will pass the bundle to the backend (upload to server side if needed), leaving the backend to determine what type of applications is deployed. Same for the case when user specifies the directory. Listing of applications in the tree node will be changed. We will not group the deployed applications into EAR, WebApp, EJB jar as we did in V2. This is because any deployed application can have multiple sniffers. Under the application tree node, all apps will be listed, and when user clicks on the app, the right frame will show all the sniffers associated with this app. For example, if there is ejb embedded in a war, the sniffer list will show both 'war' and 'ejb'.
Here is a snapshot of the table listing the applications
4.1.4 Grizzly Configuration
This is based on the GrizzlyConfiguration One Pager
GUI team will provide the support for Grizzly Configuration based on the following assumption:
- there is HTTP API to connect to server and do the configuration.
- the conversion from the old <http-service> will be done when server starts up, according to the Compatibility Impact section specified in the one pager.
A new tree node representing the network-config element found in the DTD for Grizzly configuration will be provided.
This is the navigation tree representing network-config
* Network Config Properties
* Transports Properties
* Transports -- Table listing individal transport
o T1 -- 12 attrs + properties
o T2
* Selection-Keys -- Table listing handlers
o SK1 -- 2 attrs + properties
o SK2
* Protocols Properties
* Protocols -- Table listing Protocol
o P1 -- General tab, http tab, ssl tab, port-unification tab, protocol-chain-instance-handler tab, protocol chain tab, Protocol-Filters tab, Protocol-Finders tab.
o P2
* Network Listeners Properties
* Network Listeners -- Table listing all Network listeners
o NL1 -- 7 attrs + properties
o NL2
* Thread Pools -- Table listing Thread pools (1+)
o TP1 -- 6 attrs + properties
o TP2
General Tab -- 2 attr + properties
http tab -- 14 attr + 4 attrs for file-cache + properties
ssl tab -- 11 atr + properties
port-unification tab -- 2 attr + property table
protocol-chain-instance-handler tab -- 2 attr + properties
protocol-chain-tab -- 3 attrs + property
protocol-filters tab -- table list out list of filters, creating or editing will bring up the appropriate page. Since filters are very low level, we will not show that in the navigation tree.
protocol-finders tab -- table list out list of finders, creating or editing will bring up the appropriate page. Since finders are very low level, we will not show that in the navigation tree.
According to the above design, there will be 21 new screens added for this.
The old tree node named Http Service will still exist, but the tabs will be modified according to the 'new' http-serive element found in the updated DTD
4.1.5 Logging support
This is based on the Logging one pager
According to this, any logging.properties that is used to maintain the configuration, any logging related elements that are in the domain.xml file for v2 will be moved to the logging.properties file for v3. GUI will provide 2 screens for this functions: the Logger Settings and Log Level settings for each modules. Depending on the support from backend, the Log Viewer may or may not be available for this release.
To provide the GUI support, it is assumed that there will be HTTP like API available and that will be responsible for reading and writing the properties to the properties file instead of domain.xml.
The one pager also mentions about supporting the 'retain-error-statistics-for-hours' properties. GUI will assume that the package 'com.sun.appserv.management.ext.logging' and all the interfaces under it, which is available in v2 will be available in v3 as well. Without this package, the current Log Statistics monitoring functionality will not be provided in GUI.
4.1.6 MQ Administration
The MQ Administration support for the v3 September release will achieve at least feature parity with v2. This includes the following:
Based on some community feedback, the following nice-to-have features will be evaluated to determine if time and other resources allow their inclusion:
4.1.7 Nice To Have Features
4.1.7.1 Multi-Domain Support
4.1.7.2 Upgrade Notification
Provide a notification to users when there is a newer version of GlassFish available to allow them to try it out or decide to (manually) upgrade.
4.1.7.3 Dashboard
Customization of common tasks or similar page to have features similar to iGoogle (add various widgets and customize layout to user's preference). This feature could also be applied to the RSS feed page.
4.1.7.4 Server Message Notification
Ability to send important message to users (ex. GlassFish Portfolio Launch) as a pop-up when they log in (similar to registration reminder?)
4.1.7.5 Advertising Widget(s)
Widget to show banner adds to deliver promotions (ex. free training, etc.) - This can be a replacement of the bottom frame (Marketing)
4.1.7.6 Enhanced Web Service Support
This section listed out all the PE functionality that is available in V2 Admin Console, but not in v3 Prelude. If there is any feature that is available in v2 developer profile, but not listed here, it means there is no plan to include that for v3 Sep. release. Any feature which is already in v3 prelude will be part of the sep. release.
4.2.1 EJB 3.1 Support
To provide support for EJB, the following Tree Nodes for navigation and GUI screens will be added. These screens exist in GF 2.1, and will be ported to v3. The following will be implemented as a plugin module to the admin console:
The attributes shown in the above screens will be based on the <ejb-container> element in sun-domain_1_3.dtd. If there is any changes in this element for v3, the EJB team should notify the GUI team.
issue: Do we need to provide the EJB Container Availability screen which exists in v2 ?
4.2.2 Transaction Service
To provide support for Transaction Service, the following Tree Node for navigation and GUI screens will be added. These screens exist in GF 2.1, and will be ported to v3. The following will be implemented as a plugin module to the admin console:
The attributes shown in the above screens will based on the <transaction-service> element in sun-domain_1_3.dtd. If there is any changes in this element for v3, the EJB team should notify the GUI team.
The Transaction Service screen assumes that AMX mbeans will be available and provide the get/set method for the attributes as usual. However, the support for recovering transaction will need special method to handle it. It is the responsibility of the backend to provide such a method through an AMX Bean .
4.2.3 Resources
The following resource will be supported: Java Mail Resoruce, Connectors Resources, Connector Connection Pools, Admin Object Resources.
Based on input from Kedar, JMS Resources tree node will be removed.
There may not be backend support for JNDI : Custome Resources and External Resources, so GUI will not support this.
A 'Ping' feature will be added to the JDBC Resource, JavaMail Resource and Connector Resources.
4.2.4 Configuration
Assuming the backend support is there, the following will be supported, having the same UI as in v2: ORB IIOP Listeners, Thread Pools, Admin Service, Connector Service, Diagnostic Service, System Properties.
According to Kedar, Management Rules will not be in Sept. release, and so will not be in the GUI.
4.2.5 Monitoring
We will add additional monitoring pages for this release based on the new monitoring lightweight framework. In V3 Prelude there were monitoring pages available in the admin console for HTTP Service, Web Container and JVM. The monitoring statistics for these pages were displayed in a tabular form. Below is a screen shot for the Web Container monitoring data in V3 Prelude:
:Additional Monitoring Pages:
In the release we will include additional UI pages for displaying monitoring data for the following components. The data will be presented in a tabular form as well.
a. JPA
b. EJB
c. JDBC
d. JRuby Container
e. (Grizzly) Thread Pool
Monitoring Configuration
In V3 Prelude the admin console provided configuration support for monitoring. The ability to enable/disable monitoring will continue to be supported for the additional components at a very high level. In future releases there will be support for turning monitoring ON/OFF at the attribute levels. Below is a screen shot for the monitoring configuration screen in V3 Prelude:
Monitoring Client-Side Script Support
In this release we will also provide the user with the ability to view monitoring data by deploying a client-side script through the admin console. To learn about the supported scripting languages click here. The client script can be uploaded or provided directly to the admin console through an html text area component. We will not provide any client script validation. The admin console will provide the user with a list of available supported probes for monitoring. These probes and their supported parameter names and types will be displayed in a table as a pop-up. The user will be able to review these probes in the admin console and elect to register and listen to these monitoring probe events in their client-side script. Once the admin console submits the script to the server for execution it will be necessary to establish a dedicated communication stream in order to display the monitoring responses in real time in the admin console. This data will be displayed in a table and will be updated as new monitoring data is pushed to the client. The admin console will allow the user to stop the script(via a button) from being executed in order to close the dedicated communication stream.
4.2.6 OnLine Help
In order to decrease the download size of Admin Console, the OLH jar file will not be part of the admin console core module. It will be hosted on the net such that when user press the Help button, we will bring up another browser window with the correct URL to open up that particular help topic. Besides having the smaller size benefit, this also allows any plugin module to host their help set on any machine. This also solves the technical issues of merging different help set from different plugin module. Another benefit is that the helpset can be updated anytime and can be localized to other language at a later time.
We will be making a number of User Interface changes. These changes are designed to increase our users' productivity while decreasing the complexity of our application to maintain and develop. These changes make our application more modern and consistent with typical designs that have appeared in web applications over the last several years. Below is a very rough screenshot depicting the features which we intend to introduce:
4.3.1 Remove frameset/frames
Framesets complicate our UI in many ways, as well as increase the load on both the client and the server. We will remove the framesets and use template pages which provide the page layout instead. This should allow the existing content pages in our application to remain mostly unchanged. In some cases we may choose to update content via asynchronous requests to achieve greater efficiency.
4.3.2 Bookmarkable URLs
We will ensure all new pages will be navigable via GET requests. Most existing pages already support this, we may port existing pages which do not support get URLs as time permits.
4.3.3 Move from tree-based navigation to a menu-based approach
We intend to remove the existing primary navigation tool (the tree) and replace it with a number of alternatives. One of the primary replacement schemes will be the use of menus. Menus provide an always visible navigation scheme, but do not consume large amounts of screen real estate. This will give a chance to create an action-oriented UI which is much more logical to users. Note: We need to evaluate how to best group the menus. We may also choose to consider providing multiple choices and/or ability to customize the menus to best server the majority of our users.
Above section removed due based on user response on the forum and blogs. A navigation tree like in v3 Prelude will be provided as before.
4.3.4 Allow tagging pages/windows and searching
We would like to provide a means of tagging and searching for content. This will enable our users for the first time to be able to find our pages via a search feature. A pop-up virtual window will be shown to the user when they press CTRL-F (or some similar shortcut combination, TBD), this dialog will accept tags in which to search from the user. It will then display pages which contain matching tags. Tags must be whole word matches for this release. Case will be ignored. Multiple keywords will return the intersection of the result sets of the given keywords.
Default tags will be defined for all pages we wish to be found via the search mechanism. We will also provide a mechanism for each page to be tagged by tags of our users' choosing. Tags added to pages will be shared across all admin users.
Feedback from community shows that we need to have a better UI for tagging support. We are re-evaluating this, thus this may not be in the Sept. release.
4.3.5 Move to a more desktop-like approach (windows/dialogs, minimize/maximize, OS X-style dock bar, etc)
A "dock bar" would offer users a "quick launch" mechanism for quickly getting to commonly used pages, or to store access to pages which they already have "open". We will make the doc bar customizable per user so that common tasks for each user can be stored on the doc bar. We will evaluate using the doc bar to store "minimized" windows.
4.3.6 Make use of the Preferences API to allow for per-user customization
Many of the above features will require persistent storage of data on a per user, or across user basis. The Java Preferences API provides support for doing this. We already have API support to access the Preferences API from within our pages. We will leverage this support to store per-user and per-application data to enable a wide range of features: tagging, favorites, default values, menu custimization, personalized windows, etc.
4.7.1 Exported Interfaces
4.7.2 Imported interfaces
The proposed UI changes will require much of the documentation and screen shots within the documentation to be updated to reflect the new navigation changes and look and feel. As we are moving to have the OnLine Help set to be hosted on the internet, this will impact the Doc team on creating the doc and hosting that.
This release will not support high availability, load balancing, clustering, etc.
Localization of Admin Console is needed.
The Administration Console will be packaged as a web application archive and shipped with the application server. Updates will be delivered as IPS packages via the Update Center.
The UI redesign needs to ensure the cross-site scripting (XSS) and other scripting attacks are not possible. The console must ensure protected content is not accessible to a non-authenticated user. The console must be capable of running over SSL.
The UI redesign will likely have some impact on any existing third party Prelude plugins, though this will be limited/mitigated as much as possible.
See section 4.7.2.
This version of the administration console will ship as part of the GlassFish v3, and will therefore follow its schedule.