Besides handing over the source code to GE, some documentation was also produced.
The documentation consists of a few documents describing how to set up the envi-ronment and how compile the Web application and Web service. The documents also describes the service in a more detailed way so that the developers taking over the project can understand how the service works and how the different operations should be invoked.
75
Figure 7.1: A listing of the report types that are available. If you press the small icon in the Description column, the preview image for that report is displayed. If the SELECT button is pressed, the input form for the parameters is displayed.
Figure 7.2: This is an example of an automatically generated input form. Here the Branch list has been filled based on the selected value in the Country list and on the value in the Organisation no field. The date chooser to the right of the End value field is displayed when you press the small icon. The report is generated when you press the REQUEST REPORT button and you are transferred to the REQUESTED REPORTS page.
Figure 7.3: A listing of the statuses of the reports that have been requested by the user. The status of both of the reports ia Done, this means that they are ready for download. If you press the DOWNLOAD button you are transferred to a page where you can download the report file(s) and if you press the DELETE button the report is deleted.
Figure 7.4: This is the download page for a report. Here the DOWNLOAD button has been pressed and a Save file dialog has been opened.
Figure 7.5: The page for administrating which user has access to a report. In this case six of the users have been given access to the report.
Figure 7.6: The page for administrating which Data IDs a user has access to. In this case the user has been given access to nine Data IDs.
Figure 7.7: This is the main view in the tool for creating new report types. The tool generates a database script that inserts the new report type into the database. When you press the Add button att the bottom the view for adding a parameter to the report type is displayed.
Figure 7.8: This is the view for adding a parameter to the new report type.
Conclusions
When demonstrating the system to various people at GE we got mostly positive com-ments and suggestions on extensions. The small amount of negative comcom-ments gives us the confidence to say that we have succeeded in implementing a system that is easy to use and general enough to support all now available reports. Because of the flexibility of the parameter types, it will most likely also be able to support all future reports as well.
The form handling in Spring Framework made the input form for the report pa-rameters easy to use. It provides the user with helpful error messages that makes it easier for the user to enter correct values. Many of us has experienced the frustration of filling out a form only to have all information lost at the next stage because of some small incorrectness in one of the fields. Our implementation always makes sure that the information you have entered in the form stays there until all the information is correct.
The system has overall good performance and robustness. No formal measurement of the systems performance has been done but most of the pages load within a few seconds. This makes the system feel responsive. The robustness of the system was tested by starting a large number of threads (100) that all made requests at the same time. This proved that the service handles concurrency correctly.
The time plan we decided upon at the beginning of the thesis was mostly based on speculative assessments of how long the different parts of the project would take. This is because none of us had any experience in planning projects of this size. However, since we completed the work in time, the assessments proved to be accurate enough. The things we missed to take in to calculation when making the time plan were the search for, and testing of different APIs and containers. This made the implementation task take about 2 weeks longer then planned.
8.1 Restrictions/Limitations
During the testing we found no major limitations. However, there are some things that could be improved and these things are discussed here:
– The security between the Web application and the Web service is configured so that only the incoming messages are digitally signed and encrypted. We found that report files larger then 2 megabyte could not be sent if encryption and signature is used both ways. This is probably due to some limitation somewhere in the
85
WS-Security implementation. However, since both the Web application and the Web service run within the same protected environment this does not make the system insecure.
– When a report consists of many files the work of downloading them one at a time becomes a repetitive and tedious task.