Ask the Expert

How do you handle application and user state in a Service-Oriented Architecture?

How do you handle application and user state in a Service-Oriented Architecture?

    Requires Free Membership to View

The question of how to handle state is more of a n-tier issue than an SOA issue. The fact that the n-tier application is built on an SOA doesn't necessarily influence the decisions regarding user and application state. There is no one-size-fits-all answer in regards to how to handle state. But since the issue of state is extremely important in n-tier applications, it is beneficial to discuss some guidelines to help architects and developers make wise decisions in regards to where to store state.

We can basically group state into two general groups ? session and long-lived. State that must live longer than a single user session must be persisted to a data store. In most applications, this data is retrieved upon request so the application code can operate on the data and perhaps display it to the user. Session state is created for only a single user session and may or may not be persisted. This session state is used by the application for processing current user information that is irrelevant beyond the current use by the user.

The reason state becomes important is for performance issues. Many applications will perform poorly if all data is always retrieved from the database every time the user or application needs to access it. Retrieving the data once and caching it for further use can often increase performance. Developers must then decide where to cache the data.

For many applications the performance is best when the data is cached as closely to where it is used as possible. For data that is displayed this means caching it in the presentation tier. For data that is not displayed but is accessed by the business logic of the application this means caching the data in the business tier. In a SOA application, this data would be cached with the services.

The complexity of the application increases with the number of locations where the data resides. Whenever the data changes, developers must ensure that the data always stays in sync. Since the data in the database is typically considered the "real" data, anytime a cached data is modified it must be persisted and all cached versions refreshed.

This was first published in December 2002

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: