Scalability is the capability of software to adapt to increases in its target audience with no changes in code. This is critical in creating applications that can run anywhere from the desktop level to the enterprise level. If each new size of target audience for an application requires code changes, the cost of the application will rocket, and maintenance of the application will quickly become a nightmare. Designing an application so that it can work with very large size target audiences is designing it for scalability. The application that we'll develop in our case study will run from the desktop level to the enterprise level with no code changes. It was designed with scalability in mind.
Reliability in this context relates to atomic operations (transactions) that can be rolled back to the original state if any failure occurs during the transaction process. The atomicity of a transaction means that either all or none of the actions of the transaction are completed – no partially completed actions are permitted.
For example, if a bank customer performs a transaction to transfer money between two accounts they hold, the process will involve at some point removing money from one account and adding it to the other. If the transaction wasn't atomic, and a fault occurred, the customer might find the money had disappeared from the one account but never made it to the other! However, in the case of an atomic operation, the transaction would be rolled back to leave the account status as it was before the transfer was attempted.
This transactional rollback capability comes with a performance penalty though,
so the placement of processes under transactional control must be evaluated
as a trade-off between speed and reliability. In our case study, although the
business and data tier components are all placed under MTS (COM+ in Windows
2000) control, only a few processes are transactionally controlled. We'll be
discussing the topic of transactions specifically in Chapter 5.
Availability is the ability of the software to keep running under adverse conditions, such as power failures, heavy loads of network traffic, peaks in the number of users, and hardware failures of components such as power supplies. Some things related to availability are out of the software domain, such as uninterruptible power supplies and standby power generators, hard drive redundancy (redundancy is the duplication of functions and services critical to application activities) and error correction, or redundancy of power supplies for servers.
Availability will be a concern within the software development process. For instance, we might need to provide access to the software no matter how many users it has, or under what conditions the user or software are operating. That could require us to design the application so that it can be run on multiple servers or clusters of servers.
We will look in more detail at designing for scalability, reliability and availability in Chapters 5, 6, 7 and 8.
Once we start developing enterprise applications to take account of factors such as scalability, reliability, and availability, we're going to want to consider the possibility of dividing the tasks that the software performs over a number of different machines. For example if we have a large database supporting an application, we've got to make sure everyone can use the same database, even though there are going to be a number of users on different computers working at the same time. This brings us onto the topic of distributed applications.
Comments