Architecture

Design > Architecture

Release Information

Project:	PIMS
Internal Release Number:	0.1
Related Documents:	Software Requirements Specification Design > Security Worksheet Glossary

Overview

What are the most important facts that a developer should know about this system architecture?

It is designed to allow distributed development by fixing the dependencies between software layers early. Once version 0.1 has been developed, implementation of each requirement should involve changes to only a single layer, or in the worst cases a pair of layers.

What software architecture style is being used?

Client-server with applets and server.

3-tier web application: webserver, application logic, database.

What are the ranked goals of this architecture?

Establish interfaces early
Plan for known major requirements:
- Access control, a flexible framework for giving specific users read or write access to specific information.
- Audit trails, to show when and by whom information was entered.
- Transactional correctness.
- Investigate how difficult it is to allow local variation of data model.
Allow adoption of Oracle later
Allow performance enhancements later

Components

What are the components of this system?

See image above

The components of this system are listed below by type:

Presentation/UI Components
Application Logic Components
- Data Model API
- Laboratory API
Data Storage Components
- Persistence layer
- Database

Deployment

How will the components be deployed to processes and machines?

The deployment of components to processes and machines is clearly defined below:

All-in-one server
- Tomcat process
  - Tomcat web server
  - Persistence layer, data model API, lab API, servlets
- Database process
  - Trigggers and stored procedures, if any
  - RDBMS
- Client broswser: applets

What aspects/resources of their environment are shared?

The user's web browser or JVM performs the client-side operations. Everything else is on one server so machine resources are shared.

How are requests allocated to redundant or load-balanced servers?

Believed not to be necessary.

What alternative deployment configurations are possible?

The database could be moved to a different machine with a fairly simple change to a configuration file. Otherwise, nothing can be changed about the deployment.

If we decide to move to EJB to get transaction functionality etc then there will also be many options for scaling.

Integration

How will components be integrated? Specifically, how will they communicate?: The servlets, Lab API, Date Model API, and Persistence layer use direct procedure calls.; The database is accessed through JDBC.; Communication with applets is TBD.
What architectural mechanisms are being used to ease future extensions or modifications?: Many new UI and Lab API components will be developed, accessing the data model by API calls.; We could change the database by switching drivers. However to get any benefit from extra features would mean also changing the persistence layer.; Revisions to the data model can be made by repeating the code generation for the data base and Data Model API. This is likely to involve creating a tool to migrate existing data in the DB. It may involve changes to code in the Lab API.; Extensions and modifications can be made at the design-level, but deploying those changes requires recompilation and down-time.

Architectural Scenarios TBD

TODO: Provide architecture scenarios that show how objects will communicate across components, processes, and machines. Focus on scenarios where the architecture itself is changing, e.g., system startup, shutdown, adding or upgrading components, load balancing or fail-over.

The following sequence diagrams give step-by-step descriptions of how components communicate during some important usage scenarios:

Architecture Checklist

Establish interfaces early: Yes, the APIs for each layer will be designed and reviewed prior to implementing version 0.1.
Plan for known major requirements: Yes, the APIs will allow support for audit trails, transactions, and data ownership.
Allow adoption of Oracle later.: Yes.
Allow performance enhancements later: Denormalisation of the database tables could be allowed by an extension to the code generator and the persistence layers alone. The use of multiple servers is not beleived necessary, but could be supported easily if we use EJB for other reasons.
Has the architecture been communicated to the development team and other stakeholders?: Yes, this web site is available to the team, and the first step will be a review of this architecture.

Company Proprietary