Design > Architecture

Release Information

Project: PROJECT-NAME
Internal Release Number: X.Y.Z
Related Documents:
LINKS-TO-RELEVANT-STANDARDS
LINKS-TO-OTHER-DOCUMENTS
TODO: Answer the questions below to help you define your system architecture. Consider how the reusable sample text relates to your project or prompts you to think of new ideas. Add, edit or delete text as needed.

Overview

What are the most important facts that a developer should know about this system architecture?
The core of the architecture is COMPONENT-NAME, maintained by PERSON-NAME. Start by understanding the API that it provides and how it relates to F-XX, then you will have a much easier time understanding the other components.
There are a few key rules that we have followed in the architecture that should never be violated:
  • Application logic components should never know about the presentation components.
  • Business objects are all completely persistent. Almost nothing else is persistent, i.e., we do not save sessions.
  • COMPONENT-NAME-1 pulls data, whereas COMPONENT-NAME-2 pushes data.
Please keep in mind that we started using LEGACY-TECHNOLOGY, but we are in the middle of a long term transition to NEW-TECHNOLOGY. Components are being converted one by one.
What software architecture style is being used?
Single-process desktop application (with plug-in extension modules).
Client-server with a custom thick-clients and server.
2-tier web application: webserver/app-server, database.
3-tier web application: webserver, app-server, database.
Single web service: app-server, database.
Network of web services.
Peer-to-peer with/without central server.
Pipe-and-filter.
Layers and partitions.
Computing grid / distributed servers.
What are the ranked goals of this architecture?
  1. Ease of integration
  2. Extensibility
  3. Capacity matching

Components and Connectors

What are the components of this system?
The components of this system are clearly defined in this UML Model with Component Diagram.
The components of this system are listed below by type:
How are the components connected to each other?
The communication links between components of this system are clearly defined in this UML Model with Component Diagram.
The components of this system communicate using:
  • Direct procedure calls within the same OS process
  • Event passing within the same OS process
  • A blackboard data structure, tuple-space, or shared memory
  • Standard input and output steams, named files, or pipes
  • Remote procedure call using RPC, RMI, XMLRPC, or TECHNOLOGY-NAME
  • Web services using SOAP
  • Message bus implemented with TECHNOLOGY-NAME
  • Standard protocols: HTTP, SMTP, SNMP, or PROTOCOL-NAME
  • Proprietary protocol: PROTOCOL-NAME
Components within the same process use direct procedure call or standard Java events. Plug-ins are also accessed through a API of direct procedure calls and standard events. Communication with the database uses a JDBC driver. Communication between the front-end and back-end servers uses XML-RPC.
What architectural mechanisms are being used to ease future extensions or modifications?
We could change the database by switching drivers. Otherwise, extensions and modifications can only be done at the design level.
New front-end components could be added so long as they access the back-end the same way. New plug-in components can be dynamically loaded, so long as they satisfy the plug-in API. Otherwise, there is no ability to add or exchange components, because this architecture uses direct dependencies between its components rather than implicit invocation. Extensions and modifications can be made at the design-level, but deploying those changes requires recompilation and down-time.

Deployment

How will the components be deployed to processes and machines?
The deployment of components to processes and machines is clearly defined in this UML Model with Deployment Diagram.
The deployment of components to processes and machines is clearly defined below:
The deployment of components to processes and machines is clearly defined below:
What aspects/resources of their environment are shared?
Everything is on one server so all machine resources are shared by all components.
All machines share the same bandwidth to the Internet. All machines access the same file server. So, if one component uses the resources heavily, other components may have to wait.
How are requests allocated to redundant or load-balanced servers?
We are not doing any load-balancing or redundancy for fail-over.
Load-balancing among front-end servers is handled by a load balancing device that we can make very few assumptions about. However, once a user session is established, the same front-end server will be used for all requests during that session.
What alternative deployment configurations are possible?
This is the only possible deployment.
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.
We have the ability to move the database process to a separate machine. We have the ability to add more front-end servers. The application logic running on the application server cannot be split or load-balanced.

Architectural Scenarios

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:

The following steps describe how components communicate during some important usage scenarios:

  • System startup
    • COMPONENT-NAME initializes first
    • COMPONENT-NAME-2 must check the DATA-STRUCTURE on start-up
    • COMPONENT-NAME-3 starts only when needed on the first request
    • Process IDs are written to the DIRECTORY-NAME/pid file
  • System shutdown
    • COMPONENT-NAME drives the shutdown process
    • COMPONENT-NAME-2 must flush DATA-STRUCTURE before shutdown
    • COMPONENT-NAME-3 sends a message to COMPONENT-NAME-4 then waits for it to shut down first
    • The shutdown script deletes all temporary and pid files
  • SCENARIO-NAME
    • STEP
    • STEP
    • STEP

Architecture Checklist

TODO: Answer the following questions to help evaluate your architecture with respect to each of your stated goals.
Ease of integration: Have mechanisms been provided for all needed types of integration?
Yes. In this system, all of the new components are designed to work together. And, the reused components are integrated via fairly simple interfaces.
Yes. In this architecture we are integrating several existing components and each one is wrapped in a way that makes it fit our standard component API.
No. We have not yet decided exactly how to integrate COMPONENT-NAME-1 and COMPONENT-NAME-2. That will be decided by MILESTONE.
No. The details of integration will be handled by SOMEONE-ELSE.
Extensibility: What types of components can be added later and how?
We have documented a plug-in API that defines what plug-ins can do. We are producing a simple plug-in SDK for third-party developers who want to build plug-ins.
The architecture is simple and well documented. That is a good foundation for future modifications by members of this project team.
This is a complete set of components. We are not planning on adding more in the future.
Capacity matching: How has this architecture matched component resource needs to machines?
The database can be on a machine with RAID disks and a hot-swappable power supply, while the web front-end components can be on cheaper machines that could fail individually without causing system downtime. The front-end web servers and application server are both CPU-intensive, so they are deployed to different CPUs.
Capacity matching is important but simple: we will just buy the most powerful machine for the main server.
We have not decided on machine capacities. Those decisions will be made after we have more data from early usage or at MILESTONE.
Has the architecture been communicated to the development team and other stakeholders?
Yes, everyone understands. Feedback is welcome.
Yes, this architecture design worksheet is posted on our project website.
No, this is a risk that is noted in the risk management worksheet.
TODO: Check for words of wisdom for additional advice on this template.
Company Proprietary
Copyright © 2003-2004 Method Labs. All rights reserved. License terms. Retain this copyright statement whenever this file is used as a template.