This document outlines the service issues in the implementation of conventional n-tier physicalarchitectures.
The purpose of this document is to outline the implementation (and profitability) consequences of software design domains for the construction of enterprise software applications – with particular regard to the selection of Erlang/OTP for such a task.
The scope of this document is a 3-tier logical application architecture – subject to the followingassumption:
the client interface is a browser
– that is to say it performs no business logic or validation
There is a clear difference between two separate domains:
-ilities-ality (ie functionality) pertains to the ability of a piece of software to perform certain tasks and is auser-facing process. “Does your software do this, enable that, allow the user to do the other…?”By contrast the –ilities pertain to the management of the whole system, they are:
performabilityThe scope of this paper is the –ilities and
canonically, but not necessarily, a web browser running on some class of ‘personal computer’