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.