I have a question whether it is a good or bad practice to use an SOA layer for the application servers to talk to the database. A web application server can obviously directly connect to a database, but in the hype to make everything SOA, the architects are mandating that everything has to make an SOA call to midtier servers that connect to the database. To me, this seems terribly wasteful that you have an application in the same datacenter as the database and the applications can directly access the database server, but they don't. There is already a level of abstraction on the application servers which looks identical to what we eventually end up with SOA, so this isn't a matter of a better interface.By using SOA you are adding a lot of steps to build up the request, send it out, have it received and then decoded and then finally make the database call and then you have to package that up, send it out, have it received, decoded and finally you can use the data.From what I have read about SOA, it is useful when you have geographically spread out systems where a server in Boston needs information from a server in Seattle and there is no way that a direct database connection could be possible. This is also useful when you have many different customers that need to call a central point to receive data according to a fixed contract.However, to use SOA as the means for just directly communicating with your database from your application seems to be a complete abuse of the concept and seems to provide little advantage while significantly slowing down the transactions. A typical usage would be to call a stored proc and instead of calling it directly, you have to use a SOA call to a midtier server to get the exact same information.So, am I crazy or what? Is everyone just drinking the SOA Kool Aid and applying SOA to absolutely everything until the point of absurdity? Or is there really some advantage to doing this?
Is it an abuse of SOA to use it as a database abstraction layer?
database;soa