Much like any other software, Software as a Service can also take advantage of Service Oriented Architecture to enable software applications to communicate with each other. Each software service can act as a service provider, exposing its functionality to other applications via public brokers, and can also act as a service requester, incorporating data and functionality from other services. It is important to understand that the SaaS methodology requires system architecture capable of supporting peak usage demands and the ability to process large numbers of transactions in a secure and reliable environment.
The software would need to meet certain criteria’s to work on a model such as this. The application would need to be well architected to sustain and provide the scalability, ease of use of the traditional desktop applications. There are three key points which would differentiate a successful SaaS application from an unsuccessful SaaS application:
• Scalability: Scaling the application means maximizing concurrency and using application resources more efficiently-for example, optimizing locking duration, statelessness, sharing pooled resources such as threads and network connections, caching reference data, and partitioning large databases.
• Multi-tenant efficient: Multi-tenancy may be the most significant paradigm shift that an architect accustomed to designing isolated, singletenant applications has to make. For example, when a user at one company accesses customer information by using a CRM application service, the application instance that the user connects to may be accommodating users from dozens, or even hundreds, of other companies-all completely abstracted to any of the users. This requires an architecture that maximizes the sharing of resources across tenants, but that is still able to differentiate data belonging to different customers.
• Configurable: if a single application instance on a single server has to accommodate users from several different companies at once, you can’t simply write custom code to customize the end-user experience-anything you do to customize the application for one customer will change the application for other customers as well. Instead of customizing the application in the traditional sense, then, each customer uses metadata to configure the way the application appears and behaves for its users. The challenge for the SaaS architect is to ensure that the task of configuring applications is simple and easy for the customers, without incurring extra development or operation costs for each configuration There can be four ways of hosting an application on the SaaS architecture. These are also called as the maturity models of SaaS:
• Ad-hoc/Custom: It is similar to the traditional application service provider (ASP) model of software delivery, dating back to the 1990s. Each customer has its own customized version of the hosted application, and runs its own instance of the application on the host’s servers.
• Configurable: The vendor hosts a separate instance of the application for each customer (or tenant). Unlike the previous one, each instance is individually customized for the tenant, at this level, all instances use the same code implementation, and the vendor meets customers’ needs by providing detailed configuration options that allow the customer to change how the application looks and behaves to its users. Despite being identical to one another at the code level, each instance remains wholly isolated from all the others.
• Configurable, Multi-tenant-efficient: The vendor runs a single instance that serves every customer, with configurable metadata providing a unique user experience and feature set for each one. Authorization and security policies ensure that each customer’s data is kept separate from that of other customers; and, from the end user’s perspective, there is no indication that the application instance is being shared among multiple tenants. This approach eliminates the need to provide server space for as many instances as the vendor has customers, allowing for much more efficient use of computing resources than the second level, which translates directly to lower costs. A significant disadvantage of this approach is that the scalability of the application is limited.
• Scalable, configurable, Multi-tenant-efficient: The vendor hosts multiple customers on a load-balanced farm of identical instances, with each customer’s data kept separate, and with configurable metadata providing a unique user experience and feature set for each customer.