| 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): |
| None |
| 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 |
| 4.3.1.1. deploy (to single target) |
| 4.3.1.1.1. deploy Service Assembly step 1 (upload or copy) |
| 4.2.1.1.2. deploy Service Assembly step 2 (Finish)4.3.1.1. deploy |
| 4.3.1.2. install (to single target) |
| 4.3.1.2.1. install Component step 1 (upload or copy) |
| 4.3.1.2.2. install Component step 2 (Finish) |
| 4.3.1.2.3. install Library step 1 (upload or copy) |
| 4.3.1.3. uninstall (single selection, from single target) |
| 4.3.1.4. undeploy (single selection, from single target) |
| Determinstic progress bars used here: |
| 4.3.2. cluster profile |
| 4.3.2.1. deploy (to multiple targets) |
| 4.3.2.1.1. deploy Service Assembly step 1 (upload or copy) |
| 4.2.2.1.2. deploy Service Assembly step 2 (Finish)4.3.1.1. deploy |
| 4.3.2.2. install (to multiple targets) |
| 4.3.2.2.1. install Component step 1 (upload or copy) |
| 4.3.2.2.2. install Component step 2 (Finish) |
| 4.3.2.2.3. install Library step 1 (upload or copy) |
| 4.3.2.2.4. install Library step 2 (Finish, when multiple targets selected) |
| 4.3.2.3. uninstall (multiple selections and/or from multiple targets) |
| 4.3.2.4. undeploy (multiple selections and/or from multiple targets) |
| 4.3.2.5. manage targets (uninstall(s), install(s) from/to multiple targets) |
| 4.3.3. developer profile |
| 4.3.3.3. uninstall (multiple selections) |
| 4.3.3.4. undeploy (multiple selections) |
| 4.4. Out of Scope: |
| Progress bar not used here: |
| 4.4.1 developer profile |
| 4.4.1.1 install Library step 2 (Finish) should never take more than a second. |
| 4.4.2 cluster profile |
| 4.4.2.1 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: |
| None |
| 4.9. I18N/L10N Impact: |
| The new progress bars' labels will be internationalized using the String.properties file. |
| (i.e. new labels will need to be translated and new String_xx.properties 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: |
| None |
| 6. Resources and Schedule: |
| 6.1. Projected Availability: |
| August 2007 |