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
Join the conversationComment
Share
Comments
Results
Contribute to the conversation