The Importance of Persistence within a SOA
When I wrote about the 12 steps to creating a SOA a few months ago, I talked about the importance of data and abstract data, or the notion of data management within the SOA. Truth-be-told traditional approaches to integration are really about keeping persistence at the points, within the source or target systems.However, with the use of services there is a clear advantage in keeping some persistence at a central-tier. Let’s explore this in my first Blog on webservices.org
The use of services adds a few new dimensions to more traditional information-oriented integration:
First, 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 a SOA simply allows you to manage these services, creating composite applications and orchestrations to leverage their value. This is the core value of a SOA.
Thus, you end up with composites or processes created out of service that can 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 composite, as well as some supporting services to a central data tier. This data tier exposes a single schema to the composites, and may actually also abstract some data at the points as well. This is done to provide a data service to the composites directly, or the center data tier.
Second, performance issues. 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.
Third, the storage and management of transactional data. 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 for 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.
Finally, 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. This 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.
The use of persistence within a 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.
Trackback URL for this post: http://www.webservices.org/trackback/id/5738