So, an application is hereby defined as a set of code, objects, components, services, layers or tiers that exist within a trust boundary. They trust each other, and have no need to replicate business logic (validation, calculation, manipulation, authorization) due to lack of trust. If data is validated or manipulated in one layer, all the other layers just assume it was done correctly.
A corollary of the above statement is that the constituent entities making up an application are encapsulated -- at least in a logical sense. In other words, external entities (users or other applications) can not directly interact with code, objects, components, services, layers or tiers except through the application's formal interfaces (UI/presentation or service interfaces).
Assuming we agree on the above definition and corollary, it is very obvious that the only time a data source can be a layer within an application is if that data source is exclusive to the application.
If the data source is not exclusive, then other applications or users can directly interact with it without going through our application's presentation/UI layer. In such a case (which is the norm, not the exception), the data source cannot be a data layer within an application. It exists outside the trust boundary and thus must be considered as an external entity (like a user or another application).
What does this mean from a practical perspective?
Well it means that our application can't trust the data source. But more than that, it means that we need to fundamentally rethink the architecture of an application (or service).
What is a user? From the perspective of an application, a user is a data source and an event source. In an object-oriented world view the user could easily be characterized as just another object in our model. In a service-oriented world view the user could easily be characterized as just another service with which we interact.
In fact, we can go so far as to equate ADO.NET, XML, Web services, HTML and a GUI as all being nothing more than external interface technologies. What I' m suggesting here is that maybe there is no such thing as a presentation/UI layer -- at least not in a substantively different way from a data access layer (or a service agent layer). This idea is illustrated below.
Sunday, November 30, 2008
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.
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.
data layer
New!!!
IT Job Bank
Find IT jobs near you.
Enter Location: (City, State or ZIP)
powered by:
It is commonly held as a truth that applications have a UI layer, a business layer and a data layer. In most of my presentations and writing I use a four-layer model: UI, business, data access and data storage. In this case the "data storage" layer is really the same as the traditional data layer in a three-layer model.
But I want to challenge this idea of a data layer. Over the past few months, in discussing service-oriented architecture (SOA) as well as distributed object-oriented architecture, I have become increasingly convinced that the idea of a data tier, data layer or data storage layer is fundamentally flawed.
Note that in this article I use the word "layer" to describe logical separation between concepts regardless of physical configuration, while "tier" means a physical separation. That said, the reality is that a typical data layer really is also a data tier, because most data layers exist in the form of SQL Server, Oracle or some other server-based database engine.
Service-orientated design leads us to the idea that any software component used by more than one other software component (used by more than one "client") should be a service. A service is a powerful unit of reuse, providing a contractual interface by which clients can interact with the service.
More importantly, a service defines a trust boundary. This means that a service protects itself against invalid usage by clients. This is one of the defining elements of service-orientation and is a key benefit. The benefit is that a service can safely service many disparate clients because it trusts none of them. The service ensures that all clients get the same behaviors, and that any data sent to the service by any client is checked for validity based on the rules of the service.
My contention is that the traditional "data layer" is the ideal candidate to be a service.
Consider all the layers in a typical application:
* User or other consumer
* Presentation technology
* UI logic
* Business logic
* Data access logic
* Data source
We tend to think of these as a stack, from user down to persistent data s
IT Job Bank
Find IT jobs near you.
Enter Location: (City, State or ZIP)
powered by:
It is commonly held as a truth that applications have a UI layer, a business layer and a data layer. In most of my presentations and writing I use a four-layer model: UI, business, data access and data storage. In this case the "data storage" layer is really the same as the traditional data layer in a three-layer model.
But I want to challenge this idea of a data layer. Over the past few months, in discussing service-oriented architecture (SOA) as well as distributed object-oriented architecture, I have become increasingly convinced that the idea of a data tier, data layer or data storage layer is fundamentally flawed.
Note that in this article I use the word "layer" to describe logical separation between concepts regardless of physical configuration, while "tier" means a physical separation. That said, the reality is that a typical data layer really is also a data tier, because most data layers exist in the form of SQL Server, Oracle or some other server-based database engine.
Service-orientated design leads us to the idea that any software component used by more than one other software component (used by more than one "client") should be a service. A service is a powerful unit of reuse, providing a contractual interface by which clients can interact with the service.
More importantly, a service defines a trust boundary. This means that a service protects itself against invalid usage by clients. This is one of the defining elements of service-orientation and is a key benefit. The benefit is that a service can safely service many disparate clients because it trusts none of them. The service ensures that all clients get the same behaviors, and that any data sent to the service by any client is checked for validity based on the rules of the service.
My contention is that the traditional "data layer" is the ideal candidate to be a service.
Consider all the layers in a typical application:
* User or other consumer
* Presentation technology
* UI logic
* Business logic
* Data access logic
* Data source
We tend to think of these as a stack, from user down to persistent data s
Sunday, August 17, 2008
dive is good
must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now must dive now
Monday, May 19, 2008
Subscribe to:
Posts (Atom)