Index Changes

Difference between version and version     

Back to Web Console Async Progress Bar One Pager, or Web Console Async Progress Bar One Pager Info

At line 13 changed 1 line.
April 3, 2007
April 5, 2007
At line 15 changed 1 line.
the rest of this one-pager is under development...
2. Project Summary
2.1. Project Description:
At line 18 added 156 lines.
This project adds asynchronous progress bars to the admin web console
for operations which do not complete quickly. These progress bars are
displayed in the web browser, periodically advance while the operation
is being performed, and are dimsissed when the operation completes on
the server.
2.2. Risks and Assumptions:
The technology used to implement asynchronous progress bars depends on
AJAX JavaScript libraries and support within jsftemplating. This
combination is relatively new and somewhat unstable, so the progress
bars may not be reliable enough to use. In this case, a simpler approach
would be used.
3. Business Summary
3.1. Problem Area:
Users need to be reassured that an operation has actually started and is
still running. Today, clicking the Finish button for some use-cases can
result in a long delay, or even an HTTP connection timeout, before the
next screen is displayed. Users can mistakenly interpret the lack of
visual activity as a hang.
There may be problems getting async progress bars to work reliably
when the console URL uses SSL (may need to fall-back to simpler ones
in that mode).
4. Technical Description:
4.1. Details:
The implementation consists of client-side and server-side code.
On the client, new JavaScript functions,in pages that start potentially
long-running operations, are used to asynchronously poll for status on
the server, and based on that status periodically advance a SWAED-compliant
graphical progress bar.
On the server side, a managed bean acts as a proxy between the progress
bar javascript and the admin code processing a long-running request.
For a single component operation, using developer-profile, the progress bar
used is the indeterminate kind, i.e. when the estimated time is not known in
advance and there is no way to incrementally measure progress. This basically
just shows movement to indicate activity, but without times or percentages.
For multiple operations in developer-profile, or for multiple targets in
cluster-profile (or for both multiple operations on multiple targets) there are
a countable number of intermediate steps, so a more deterministic progress
bar can be used for the overall operation (e.g. four of six starts completed).
4.2. Bug/RFE Number(s):
4.3. In Scope:
At the very least, non-determinstic progress bars can be shown until the
operation completes. If possible, deterministic progress bars will used when
possible. Pages needing progress bars:
Nondeterministic progress bars used here:
4.3.1. developer or cluster profile deploy (to single target) deploy Service Assembly step 1 (upload or copy) deploy Service Assembly step 2 (Finish) deploy install (to single target) install Component step 1 (upload or copy) install Component step 2 (Finish) install Library step 1 (upload or copy) uninstall (single selection, from single target) undeploy (single selection, from single target)
Determinstic progress bars used here:
4.3.2. cluster profile deploy (to multiple targets) deploy Service Assembly step 1 (upload or copy) deploy Service Assembly step 2 (Finish) deploy install (to multiple targets) install Component step 1 (upload or copy) install Component step 2 (Finish) install Library step 1 (upload or copy) install Library step 2 (Finish, when multiple targets selected) uninstall (multiple selections and/or from multiple targets) undeploy (multiple selections and/or from multiple targets) manage targets (uninstall(s), install(s) from/to multiple targets)
4.3.3. developer profile uninstall (multiple selections) undeploy (multiple selections)
4.4. Out of Scope:
Progress bar not used here:
4.4.1 developer profile install Library step 2 (Finish) should never take more than a second.
4.4.2 cluster profile install Library step 2 (Finish) should never take more than a second
when zero or one target selected.
Predicting the time for an operation and adjusting that prediction as
intermediate steps complete is more expensive to implement yet does not
yield much improvement in managing the expectations of the user, so we
are not planning this kind of progress bar (e.g. like windows uses when
copying/moving large subtrees of files).
4.5. Interfaces:
Under investigation. Each client .jsf page could use a Woodstock progress
bar when/if that is stable. The particular AJAX functions needed to poll
depend upon which AJAX-supporting javascript files are bundled with
GlassFish or can be easily added. The server side interfaces may be JavaServer
Faces managed beans and/or jsftemplating handlers (or other AJAX specific
server-side code TBD).
4.6. Doc Impact:
There should be some discussion of progress bars in the web console online help.
4.7. Admin/Config Impact:
This reduces the chance that an admin will attempt to undo or redo a
long-running operation, but instead wait for the progress bar to be
replaced by a result screen.
4.8. HA Impact:
4.9. I18N/L10N Impact:
The new progress bars' labels will be internationalized using the file.
(i.e. new labels will need to be translated and new files and their
containing admin_xx.jar files will need to be generated.
Likewise for any changes to html in the online help that discusses progress bars, if any.
4.10. Packaging & Delivery:
Included in GlassFish installation jar file.
4.11. Security Impact:
Needs to work whether or not SSL is used for the console.
4.12. Dependencies:
Depends on Woodstock, jsftemplating, third-party JavaScript files (TBD).
5. Reference Documents:
6. Resources and Schedule:
6.1. Projected Availability:
August 2007

JSPWiki v2.4.100
« Home Index Changes Prefs
This page (revision-5) was last changed on 28-Sep-07 23:50 PM, -0700 by MarkWhite