Should Your SOA Include a Persistence Strategy?

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 some cases, in keeping some persistence at a central-tier, for any number of legitimate reasons. Let’s explore this in the context of a 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, everyone 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.

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 using a data abstraction layer such as data abstraction middleware.

If the composites are doing most of the processing, and it’s really a center-tier process abstracting remote services, than it makes sense to collocate the data as close to the data processing as possible. This 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.

We all understand the value and 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 multi-party transactions. Again, the controlling data is maintained at a center, shared tier.

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 some. Again, you have to consider your own requirements. Common requirement patterns to watch for include the need to control metadata, state management, heavy database process by the composites, and security issues. The data may reside in any data storage mechanism such as a relational database, object, XML database, or through an abstraction layer. The choice is determined by the requirements within your SOA, including accommodation of existing legacy systems and schema management.