SOA Persistence
A recent article in InfoWord on SOA persistence seems somewhat surreal because it manages to discuss the topic without mentioning the industry standard for SOA persistence - Service Data Objects.
The article makes the case that some SOA applications require a data services tier - which seems to be the opposite of what the data access part of a a SOA should be - loosely coupled, lightweight, distributed, and highly flexible. The argument for a data tier is based on the special requirements of composite applications
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.
This makes sense for complex composite applications (not that there's no mention of Service Component Architecture), however, the article falls apart when it continues and uses locking database tables as the argument.
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.
This is the 'ideal' use case for Service Data Objects - because using the SDO API for SOA persistence means that databases are not locked during long running, loosely coupled, SOA transactions.
PJ Murray
CodeFutures Software