It comes up a lot at conferences and seminars: Where should my business logic reside - the database or the middle-tier? In the SOA world you might think that using the database was the wrong choice, but why not leverage your existing DB-level validation from your Business Services?
I recently had some correspondence with Kent Graziano of ODTUG fame on just this topic. He says, "essentially we generate the TAPI and the associated DB triggers on all tables. The developers then write simple insert, update, and delete SQL against the tables to pass the required data elements. The triggers fire the TAPI procedures and fill in the auto generated stuff (sequence ids, date created, user created, etc). And voila you get referential integrity without coding in the middle tier. One of our apps is even generating the journal records automatically for audit trail. In addition all these applications rely on Oracle views or materialized views (from our read-only ODS) as the source for all the drop down lists. Seems that may be an SOA-type approach as well since we have abstracted the data one layer above the actual database tables (and we reuse the same view definitions for multiple applications to insure one-source of truth across the apps)."
I don't see anything wrong with this approach. Of course, from an SOA point of view you must ensure that your services are just that, and not too fine-grained, but that can be dealt with in or above the DB level in whatever technology or framework you choose to develop business services in.
Moving forward, it might be that Kent's application developers will take advantage of the benefits of middle-tier business logic and rules - for instance using the ESB and Rules Engine of Oracle's SOA Suite - but that's another discussion! So, am I an SOA-heretic to use database logic and services in the same sentence?