1.2 Name(s) and e-mail address of Document Author(s)/Supplier

1.3 Date of This Document

2 Project Summary

2.1 Project Description

Administration Console (GUI) is one of the tools for application
server administrators to configure and monitor the application server.

2.2 Risks and Assumptions

GlassFish V3 Admin Console is not currently planned to be
compliant with HCI-Admin guidelines. HIE support will be needed if
compliance is to be targeted.

The Admin Console is written on top of the JSFTemplating
framework, which is a java.net open source project. It is assumed that
JSFTemplating will continue to evolve with features to support the
Admin Console.

The Admin Console will be using the Woodstock components, a
JSF component set. It is assumed that the released version, Woodstock
4.3, which will be integrated, will not have major fault that prevents
the Admin Console from utilizing it.

Almost all of the features and enhancements depend on back end support, and that that an API will be provided.

Detecting the available modules for installation or update depends on the API provided by Update Center 2.0.

The console is expected to support management of a number of
JavaEE 6 features. It is assumed that the specs will be complete, with
reference implementations usable in a reasonable amount of time to
allow the implementation of its supports in the console.

This release will have some UI refactoring.. While this work
has the possibility of impacting timelines, it is expected that that
will not be the case. Without this refactoring, there is a significant
risk that problem areas in our application may impact the schedule
(namely Tree-breadcrumb issues, and frameset issues).

Able to host the Online Help set online is a risk factor.

3 Problem Summary

3.1 Problem Area

3.2 Justification

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:

Modernize the look and feel of the application

Provide bookmarkable pages

Improve performance

Enable customizations

Provide a less coupled design which encourages community participation of additions to the admin console.

Mitigate use of complicated, unsupported components

4 Technical Description

4.1 New Functionality

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

4.1.5 Logging support

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:

tree node: Connection Factories

tree node: Destination Resources

tree node: JMS Hosts

tree node: Physical Destinations

Based on some community feedback, the following nice-to-have features will be evaluated to determine if time and other resources allow their inclusion:

Prune (delete) messages in destinations

Display the number of messages in the destination. Browsing (e.g. displaying the message header, message id and especially the type: TextMessage, BytesMessage, ObjectMessage etc.) would be useful as well.

Configuration of the max, current number of retries, redirection to DLQ etc. Configuration of the max # of messages in a destination.

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

Metro / WSIT administration - setting up policy, etc.

REST / JERSEY administration

4.2 PE Functionality

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:

tree node: EJB Container

3 tabs: EJB Settings, MDB Settings, EJB Timer Service

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:

tree node: Transaction Service

screen: Transaction Service

screen: Recover Transactions

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 SupportIn 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.

4.3 UI Design Changes

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.

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.4 Bug/RFE Number(s)

Display the list of virtual servers a webapp has been deployed to - 490

4.8 Doc Impact

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.

4.9 Admin / Config Impact

4.10 HA Impact

This release will not support high availability, load balancing, clustering, etc.

4.11 I18N / L10N Impact

Localization of Admin Console is needed.

4.12 Packaging & Delivery

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.

4.13 Security Impact

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.

4.14 Compatibility Impact

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.