Full duplex continued: Moving closer together
Knives back in our boots I like Clemens' new post quite bit. Or even: I agree with his solutions for the scenarios depicted.
However, I know few developers who are going to build such kind of systems within the next 10 years. Or to be honest: I know none.
That doesn´t mean, I think there are none, but only makes a statement about the 5000+ developers I "touch" each year.
As useful and necessary Clemens´ solutions are, I don´t think, we can motivate those 5000+ developers to adapt them anytime soon. Plus, I still doubt they make sense for all of them. At least as long as the technology to implement them is not here and easy to use. (Always remember COM+: A good technology and sound concepts below it do not guarantee broad success and adoption of the ideas!)
This is why I still cling to the notion of in-proc resource components. Or maybe I should call them light weight services? ;-)
Anyway, I don´t see Clemens and me that far apart in our views. We´re just looking at applications of different scale. This becomes clear, when I say, that Clemens´ "data services" are treated as separate applications in my architectural picture. Just because some component delivers data, I don´t think it can only be a resource component. If it´s big enough (or independent/autonomous enough) sure it can be made into an application of its own. SQL Server for example is an application of its own - but my application should communicate with it thru a resource component wrapping an abstraction layer around its services.
So let me refine my overview picture like this:
Resource components (the green boxes) also communicate with applications - if they represent data sources/sinks.
Now, you could say, make the green boxes part of the orange ones (applications) and you´re in a service only world. Yes, right. But I find it valuable for developers to actually see the resource access components - and have alternatives: Sometimes data access is using another application (service), sometimes not.
Even though I´m very much in favor of clear rules, I think this much "doubt" (like Clemens calls it) is perfectly ok or even necessary in terms of an easier migration path to a service oriented world.
Since developers today still think in applications (not services) I want to provide them with a picture as close to their thinking as possible. That means: leave as many concepts in place as possible. That´s why I just moved around the boxes in our common architecture picture. I did not remove "frontend", not did I remove "data access". Me believe is, this way more developers can relate to what I´m proposing.