Bick Group

David Linthicum

Subscribe to David Linthicum: eMailAlertsEmail Alerts
Get David Linthicum: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: SOA & WOA Magazine

SOA & WOA: Article

Does Your SOA Include a Persistence Strategy?

Truth be told, traditional approaches to integration are really about keeping persistence at the points

Truth be told, traditional approaches to integration are really about keeping persistence at the points, within the source or target systems, and replicating data as needed. However with the use of true services, there is a clear advantage in keeping some persistence at a central-tier, for any number of legitimate reasons. Let's explore this in the context of an SOA.

Indeed, as we become better at building services we need to understand the infrastructure that the services will leverage, including orchestration, security, management, and data, and where those functions need to reside in the architecture. While SOAs are like snowflakes - every one a bit different, it's helpful to understand the requirement patterns that will lead to specific architectural decisions. Keep in mind that once these decisions are made, they are not easy to undo later.

Before we dive into this issue, it's helpful to understand the differences between an SOA and a more traditional application-integration infrastructure. The use of services adds a few new dimensions to more traditional information-oriented integration.

The first difference is the federation of services around the SOA. Services don't exist as clusters in a single server, they run on any system that exposes them, inside and outside of the organization. The creation of an SOA simply allows you to manage, leverage, and orchestrate these services, thereby creating composite applications and orchestrations to leverage their value. This is the core value of an SOA, as well as the enabling standards around Web services.

Thus, you end up with composites or processes created out of services that may exist over a dozen or more different systems, and as such persistence becomes more complex if done at the points. So, in these types of situations (which are becoming more common), it makes good sense to centralize the persistence for the composites and processes, as well as some supporting services, to a central data tier or central data service. This data tier exposes a custom schema view or views to the composites, and may also abstract some data at the points as well. This is done to provide a data service to the composites directly, or perhaps by using a data abstraction layer such as data abstraction middleware (e.g., IIS or federated database software).

Second are performance issues. If the composites are doing most of the processing, and it's really a center-tier process abstracting remote services, then it makes sense to collocate the data as close to the data processing as possible. This is done for both manageability, reliability, and for performance.

Integrity will also become less of an issue when leveraging this type of center-tier persistence. No need to lock a dozen or so tables when you can simply lock one. Moreover, security becomes an easier process as well, since it does not need to be as distributed.

Third is the storage and management of transactional data. We all understand the value of leveraging a message warehouse, or the storage of information flowing between systems. Having persistence at the central tier allows architects to store transactional information for many purposes, including analysis and integrity management issues (logging). Also, with the new focus on compliance and support of audits, this seems to be a likely place to store that type of information as well.

I would also include this notion in support of state-management information for services, processes, or composites. This includes supporting long-term transactions, or multiparty transactions. Again, the controlling data is maintained at a central, shared tier.

Last is leveraging centralized metadata. We all know that we need to understand and manage application semantics. Leveraging central-tier persistence allows the SOA architects to get a better handle on this issue, due to the fact that we can place abstracted and composite data elements at the central tier. Also, this is a prime location for a central repository and for the management of application semantics, perhaps using standards such as the semantic Web.

This is not to say that all SOAs will require a central data tier, but it may be a good idea for most. Again, you have to consider your own requirements. Common requirement patterns to watch for include the need to control metadata, state management, heavy database processing by the composites, and security issues. The data may reside in any data storage mechanism such as a relational database, object, or XML database. The choice is determined by the requirements within your SOA, including accommodation of existing legacy systems and schema management.

The use of persistence within an SOA is an inevitable reality. Thus, those building SOAs today should be prepared to cross this bridge. It's better to cross it now rather than wait for the water to rise...believe me.

More Stories By David Linthicum

David Linthicum is the Chief Cloud Strategy Officer at Deloitte Consulting, and was just named the #1 cloud influencer via a recent major report by Apollo Research. He is a cloud computing thought leader, executive, consultant, author, and speaker. He has been a CTO five times for both public and private companies, and a CEO two times in the last 25 years.

Few individuals are true giants of cloud computing, but David's achievements, reputation, and stellar leadership has earned him a lofty position within the industry. It's not just that he is a top thought leader in the cloud computing universe, but he is often the visionary that the wider media invites to offer its readers, listeners and viewers a peek inside the technology that is reshaping businesses every day.

With more than 13 books on computing, more than 5,000 published articles, more than 500 conference presentations and numerous appearances on radio and TV programs, he has spent the last 20 years leading, showing, and teaching businesses how to use resources more productively and innovate constantly. He has expanded the vision of both startups and established corporations as to what is possible and achievable.

David is a Gigaom research analyst and writes prolifically for InfoWorld as a cloud computing blogger. He also is a contributor to “IEEE Cloud Computing,” Tech Target’s SearchCloud and SearchAWS, as well as is quoted in major business publications including Forbes, Business Week, The Wall Street Journal, and the LA Times. David has appeared on NPR several times as a computing industry commentator, and does a weekly podcast on cloud computing.

Comments (5)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.