2.2 Public interface of a solution
When the public interface of the solution is used both by a component of the solution and the client software, two cases are possible: one where there are dependency cycles, and one where the solution can be separated into two separate solutions, of which the first depends on the public interface of the second.

To simplify the analysis, dependency cycles will be separated into more than one solution. Solution A will then be evaluated according to the availability of components of the solution B, and availability of solution B will be evaluated in terms of the availability of solution A. Note that the two solutions could not be evaluated at the same time within the framework of the analysis; one of the two solutions should have an availability that is fixed. As mentioned in section Abstraction of virtual components, within the framework of this analysis, a solution is composed of only two types of components: the logic components and virtual components. Having as constraint that there is only one public interface per solution, this interface is implemented by a logic component of the solution, since only the virtual components are dependent on a logic component. It is the entry point of the solution and is implicitly the sole dependent of the public interface of the solution.
Contents · 11/26
- Design for High Availability
- Introduction
- 1 Hardware Abstraction
- 1.1 Isolating the levels of abstraction
- 1.2 Physical components category
- 1.3 Virtual Layer
- 1.4 Abstraction of virtual components
- 1.5 Characteristics of virtual components
- 2 High Availability Mecanisms
- 2.1 Framework for analysis of the mechanisms and assumptions
- 2.2 Public interface of a solution
- 2.3 Risk Control
- 2.4 One approach: duplication
- 2.5 Limits of replication of immutable virtual components
- 3 Evaluation of downtime risks
- 3.1 Dependency hierarchy
- 3.2 Bottlenecks
- 3.3 Method for calculating availability
- 3.4 Methodology of analysis
- 4 Evaluation in real cases
- 4.1 Basic software solution
- 4.2 Analysis without assumptions
- 4.3 Evaluation with addition of availability assumptions
- 4.4 Assumption in a cloud scenario
- Conclusion
- References