V4 Architectural Design Critique
From SoftwarePractice.org
Architectural Design Critique
Overall, we were fairly happy with the architectural design that was used for building our digital broadcasting system. We were able to generate a functional executable prototype from this architecture without encountering any insurmountable obstacles.
Our architecture meant that we were only forced to rely on one piece of off-the-shelf software; our web server, for which purpose we used the recommended solution of Jetty. The use of Jetty as our web server enabled us to use Java Server Pages to implement our server-side processing, to connect easily with our Java server, but it also presented us with some difficulties. A bug in Jetty made it difficult to write and debug our Java Server Pages as it would throw an internal error instead of printing a proper error message. For further development of the web interface, another Java Server Pages enabled web server, such as Apache Tomcat, may be a more appropriate choice.
We were able to avoid most of the difficulties involved with inter-process communication by using a simple client server model, where the client will initiate any connections, and when a response to a server request is required, it will block until the response arrives. This enables us to avoid synchronisation issues in the non-performance critical user interface software. The use of Java Server Pages on the web interface end greatly simplified the protocol structure, as both the web interface and the native Java user consoles were able to share the classes which defined the protocol commands and the command parameters, and avoid the duplication of any of the code to implement the client-server protocol.
A critical concern that needed to be taken into account for our architectural design were the performance constraints placed on the audio processing and analysis modules. These modules need to be able to process and analyse audio data streams in real-time in order to meet the needs of the radio station employees, customers and the audience. We were able to mostly solve this problem through the use of the filter pattern.
The processor manager runs as part of the command and control server, and creates processor objects, which run in separate threads as concurrent processes and are completely independent to the server. Each processor contains an audio input and audio output module and will load each of the filter modules that are enabled in the program configuration. The server will only interrupt the processing module, and the associated thread, when it is going to be terminated and no longer needs to continue processing audio data in real time.
There will need to be some additional inter-process communication in the audio pipeline filter model which is going to have to affect the design going forward, in order to properly support the required audio analysis filters, which will need to provide information back to the user interfaces to be interpreted. This would most likely require an asynchronous communication model where the data is transmitted continuously from the module as the audio is processed in real-time, and the user interface is refreshed with the updated analysis information at periodic intervals. This would enable analysis feedback in close to real-time without sacrificing the real-time audio processing and analysis which is required.
The only other potential change to the architecture that we can see moving forwards is with the inclusion of an audio codec library as an additional piece of off-the-shelf software. The audio input module is already implemented as a fairly generic Java interface which should be sufficient to handle most kinds of audio input, it will be necessary to include the additional processing of the audio decoder, and possibly re-encoding at some point with the audio output. This should not affect the architecture, but as we have not looked at or decided upon an audio codec library to use, this is not guaranteed to be the case.
