-
Notifications
You must be signed in to change notification settings - Fork 0
architecture background
The system must only use open source technologies
The technologies chosen should be open source and suitable for deployment in a Linux production environment to ensure that there are not any ongoing licensing costs.
The system should use technologies that can be maintained by the SCD
Due to high staff turnover and the existing nature of the scientific computing cloud infrastructure, where possible we should use existing technologies/frameworks to ease maintenance - failing that we should use technologies they know how to support and only if there is a very good reason should we introduce a new technology. This will constrain the project to primarily use c++ and python
The system needs to plug in to the GridFTP system
The nature of the code being a plugin for GridFTP naturally limits the code to C++ and needs to be built as a dynamic dll (a .so file) so it can be loaded by the GridFTP system.
The development will be done using Scrum
Manual testing effort is limited so we should make as much use of automated tests as possible
Security
The entire reason for this plugin is to ensure security on the files that are transferred by GridFTP. The plugin needs to ensure the permissions are transferred correctly.
Testability
Given the system will have a number of different components it is important to ensure that each is independently testable to ensure that developers can work independently.
Maintainability
It is hoped that this system will be continually developed and maintained over a period of time. Given this, it is important that the code is developed to all of the appropriate coding standards and that ease of maintenance is considered during development. For example, deployments should be scripted to ensure that configuring system instance is quick.
Separation of concerns
Rational: The application should be developed with clear boundaries between different areas of responsibility.
Impact: The system will use the architectural layering defined for each component.
Use of frameworks and libraries
Rational: The use of standard frameworks and libraries, where appropriate, will enable efficient development and ensure that industry best practice is followed.
Impact: Where possible, third party libraries and frameworks should be used to facilitate development. They should be carefully evaluated prior to use to ensure that they are under active development, have clear documentation and a large community.
Error handling
Rational: The system needs to ensure that unexpected errors do not reveal details of the system’s implementation
Impact: Each component will use a consistent approach to error handling.
Logging
Rational: All components should implement logging appropriate to the components function.
Impact: Logging should be considered as a first class concern for all components since the logs will be important for monitoring and maintaining the system from a DevOps perspective.
Automated deployment
Rational: The system will need to be regularly and easily deployed to reduce maintenance
Impact: All components should be designed to be easily deployed.
Modular architecture
Within each component a modular architecture will be used to ensure that we have clean separation between different areas of responsibility.