This post originated from an RSS feed registered with .NET Buzz
by Robert Hurlbut.
Original Post: TechEd Day 2: Managing state across layers
Feed Title: Robert Hurlbut's .Net Blog
Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/rhurlbut/Rss.aspx
Feed Description: Development with .Net, Rotor, Distributed Architectures, Security, Extreme Programming, and Databases
Services shouldn't share databases One of the gems I picked up from the talk was that we shouldn't necessarily tightly couple everything at the database layer by putting it all in one place. Sometimes this is done for speed, but the benefit may disappear if you put it in a cluster.
Benjamin quoted Martin Fowler's post today about this strategy:
The recent rise of Service Oriented Architecture seems to mean very different things to different people, but one plausible thread is a rise of autonomous applications with their own ApplicationDatabase that communicate through service interfaces - effectively replacing shared database integration with rpc or messaging based integration. I'm very sympathetic to this view, particularly favoring integration through messaging - which is why I encouraged the development of EIP. In this view of the world the integration database is no longer the default assumption.
Since I work on the development of middleware applications daily, all using central databases, and all of them more-or-less tightly coupled, I found this very intriguing. You could say it was my “Aha” moment! I have been reading the SO literature for a little while, and I have been thinking of it as WebServices, even though I “know” its not just WebServices. But this made a lot of sense to me, along with the rest of Benjamin's post (and Clemens' helpful background reading for this talk).
I don't know yet where this will be used, at least with my own clients, but I can see the possibilities for the changes that will come in the future.
Previous Topic
