Communications - January 2013

figure 5. saas application interface from the back-end to the front-end.

incoming Read
Requests
A-e
A-e
A-e
F-j
F-j
F-j
K-o
K-o
K-o
P-t
P-t
P-t
u-Z
u-Z
u-Z

cess session state are easy to call. This provides support for a scalable and robust SaaS application.

The application session state, application reference-data cache, and calls to other services are available as concierge services. The platform prescribes how to access these services, and the application need not know what it takes to build them. By constraining the application functionality, the platform can increase the concierge services.

A-e
F-j
K-o
Automatic Pub-Sub
distribution of
updates

An example of session state is a shopping cart on an e-commerce site such as Amazon.com.

The plumbing for the session-state manager handles scaling. As the number of sessions grows, the session-state manager automatically increases its capacity.

This plumbing is also responsible for the durability of the session state. Typically, the durability requirements mandate that the session state survive the failure of a single system. Should this be written to disk on a set of systems in the cloud? Should it be kept in memory over many systems to provide acceptable durability? Increased durability requires more system implementation cost and may require increased latency to ensure the request is durable.

Typically, a session-state manager is used so frequently that it must provide a very aggressive SLA for both reads and writes. A 5ms or 10ms guarantee is not unusual. This means it is not practical to wait for the session state to be recorded on disk. It is common for the session state to be acknowledged as successfully written when it is present on two or three replicas in memory. Shortly thereafter, it will likely be written to disk.

Applying changes to the back end.

P-t
u-Z
Feeds
from
Partners
Backend
Processing
(Feed and Crawl)

Crawl the Web

Sometimes, front-end requests actually “do work” and apply application changes to the back end. For example, the user pushes Submit and asks for its work to be completed.

Application changes to the back end may be either synchronous, in which the user waits while the back end gets the work done and answers the request; or asynchronous, in which the work is enqueued and processed later.

Amazon.com provides an example of asynchronous back-end app changes. When the user presses Submit, a portion of the front end quickly acknowledges the receipt of the work and replies that the request has been accepted. Typically, the back end promptly processes the request, and the user receives an email message in a second or two. Occasionally, the email message takes 30 minutes or so when the asynchronous processing at the back end is busy.

Automatic services, state, and data. By understanding the usage pattern of a SaaS application, the platform can lessen the work needed to develop an application and increase its benefits. As suggested in Figure 3b, the application should simply worry about its business logic and not about the sys-tem-level issues. Interfaces to call other services, access cached data, and ac-

Patterns in saas applications:
the Back end

This section explores the patterns used in the back-end portion of a typical SaaS application. What does this back end do for the application? How does it typically do it?

The back end of a SaaS application receives data from a number of sources:

˲ Crawling. Sometimes the back end has applications that look at the Internet or other systems to see what can be extracted.

˲ Data feeds. Partner companies or departments may send data to be ingested into the back-end system.

˲ Logging. Data is accumulated about the behavior of the front-end system. These logs are submitted for analysis by the back-end system.

˲ Online work. Sometimes, the front end directly calls the back end to do some work on behalf of the front-end part of the application. This may be called synchronously (while the user waits) or asynchronously.

All of these sources of data are fed into the back end where they are remembered and processed.

Many front-end applications use reference data that is periodically updated by the back end of the SaaS application. Applications are designed to deal with reference data that may be stale. The general model for processing reference data is:

1.Incoming information arrives at the back end from partners’ feeds, Web crawling, or logs from system activity. Online work may also stimulate the back-end processing.