Simplified SPOSAD CAT
The Simplified SPOSAD CAT architectural style provides a structure for SaaS applications that have support for scalability. Simplified SPOSAD is based on a 3-tier architecture with presentation, middle, and data tier.
For scalability, Simplified SPOSAD requires middle tier components to be stateless, thus, allowing a PaaS to clone these components and to use load balancers for providing access to them.
The Simplified SPOSAD style is based on SPOSAD but abstracts away from multi-tenancy features as well as the use of asynchronous communication. We propose the Simplified SPOSAD as a simple example for CATs.
Also Known As
Simplified Shared, Polymorphic, Scalable Application, and Data (Simplified SPOSAD)
Simplified SPOSAD suggests a 3-tier system with stateless middle tier, but leaves open the decision for a concrete database paradigm on the data tier . Therefore, an architect of a book shop may design the shop as shown in the figure on the right: he assigns each of the three Simplified SPOSAD tiers (presentation, middle, data) to a component (Book Shop Frontend, Book Management, Book Database). The roles' constraints assure the characteristics of Simplified SPOSAD:
- The middle tier has no connectors with a target in the presentation tier.
- Middle tier components have to be stateless.
- The data tier may only allow connections from the middle tier.
- The data tier needs to provide a database component.
As Simplified SPOSAD does not constrain the data tier further, the architect has the option to design the system with a relational or a NoSQL database that both promise a different scalability. Therefore, this variability constitutes a parameter of the data tier role.
A 3-tier architecture that requires a scalable middle tier.
Assume a classical 3-tier system that has to cope with increasing or spiking load scenarios. For instance, a book shop implemented via a classical 3-tier architecture may face a suddenly increasing load before Christmas.
To cope with high load, the middle tier of the shop could simply reject incoming requests. However, this is problematic as the shop provider potentially looses the opportunity to make profit from additional customers.
As a second option, the shop provider could over-provision the middle tier of the book shop such that the shop can cope with unexpected high load scenarios. However, in times with lower load, the provider has to pay additional money for maintaining the shops' infrastructure while making less profit because of fewer customers.
A third option for the provider is to add additional hardware resources once observing load peaks and removing it again when load decreases. For this approach, the provider has to setup and maintain additional resources. This setup may take too long such that the high load situation could already be over (and customers are unsatisfied). Removing hardware resources after high load situations requires additional effort and costs.
To cope with the latter disadvantages, a fourth option is to move the whole book shop to a cloud computing environment. This environment could then take care of automatically and effectively adding and removing resources on demand.
While cloud computing environments can cope with the before-mentioned disadvantages, they still do not guarantee that the book shop will actually scale. The reason for this lack is that the classical 3-tier style does not provide information how the middle tier can utilize additional resources (on a software level). Therefore, the shop provider cannot be sure that cloud computing enables the middle tier to cope with a higher load at all. The same holds for option two and three as well.
In summary, we need to balance the following forces:
- The middle tier should be able to cope with increasing and decreasing load.
- The middle tier should always be able to serve its customers.
- The middle tier should be cost-efficient.
- Cloud computing environments have pre-defined characteristics that should be optimally utilized.
Implement the system as a 3-tier architecture with stateless middle tier. You can store state on the the other tiers. For instance, on you can store state on the data tier by using a normal database.
In the following figure, we provide the CAT type for Simplified SPOSAD:
The following scenario describes a typical dynamic behavior of systems implemented according to Simplified SPOSAD.
Scenario I: Scalability
Suddenly a high amount of customers begin to use a Simplified SPOSAD system operating in a cloud computing environment. The cloud environment duplicates middle tier components and begins to load-balance these. This allows the system to cope with the high load. After a while, the load decreases again. The cloud environment, therefore, removes duplicated components again and stops load-balancing.
For implementing stateless middle tier components, component architectures like EJB have a dedicated support. For example, EJB allows to annotate components (sessions beans) by means of the @Stateless annotation.
Note that Simplified SPOSAD does not only describe SaaS applications. It also relates to PaaS environments that host SaaS applications. For example, the database can be a PaaS service that is used by the data tier of the SaaS application.
We also describe a the SPOSAD CAT, i.e., a version we did not simplify.
In CloudScale, we use Simplified SPOSAD as a running example for CATs.
We identified the following benefits for Simplified SPOSAD:
- The system becomes scalable by design.
We are aware of the following liabilities for Simplified SPOSAD:
- The middle tier becomes highly restricted because it forbids statefull components. Therefore, legacy systems may have problems to conform to Simplified SPOSAD.
Simplified SPOSAD includes the 3-tier architecture and Pipes-and-Filters architectural styles (for using load-balancers on the middle tier).
- Koziolek, Heiko. “The SPOSAD Architectural Style for Multi-tenant Software Applications.” In Proc. 9th Working IEEE/IFIP Conf. on Software Architecture (WICSA’11), Workshop on Architecting Cloud Computing Applications and Systems, 320–327. IEEE, 2011.