yaers of DB

our presentation to a large degree. We also control our UI and business layers -- after all, they are written in code by us for our particular application. The same is true of the data access layer -- it is just code we write to interact with the data source.

But now we get to the data source itself. Do we, in a typical application scenario, control the data source? More often than not the answer is no.

In most cases the data source is a database, a set of related tables. And the reality is that other applications or people almost always have direct access to those same tables. They are not under our control, and we cannot reliably ensure that they contain valid information based on the rules and practices established by our application.

This isn't to say that the data doesn't remain consistent based on the rules and practices set forth inside the data source, but those rules and practices rarely match those of our application -- at least not with perfection. It seems that there's always a mismatch between business logic and the rules embedded in the database itself.

What I'm getting at here is the thought that we can control neither end of the spectrum. From the perspective of our application the user and the data source are similarly outside our control.

In short, I am suggesting that the data layer is an external entity.

Microsoft's Pat Helland talks about services being autonomous entities that contain business behavior or logic. He also makes a point of noting that a service owns its data source. Were it true that a given service (application) had exclusive control and access to its data source, I'd buy into what he says, but that is rarely the case in real organizations.

Instead, a service (application) has shared use of a data source. Other services (applications) also have access to the data source. Other people (administrators, power users, etc.) often have direct access to the data source -- bypassing all application logic.

I hold it to be a truth that layers in a single application trust each other. I've written in my blog about trust boundaries and how any time we cross a trust boundary we must consider that we have two separate applications. This is because an application is defined by its trust boundary.

I realize that I'm defining the word application in a specific way, and that is intentional. Most of the problem with SOA discussions and even n-tier architecture discussions flows from semantic or terminology issues. We must define some set of terms for discussion.