Scott Stewart

data layers, soa, and tootb

There is a very interesting article over at TheServerSide today by Rocky Lhotka entitled “The Fallacy of the Data Layer”. IMO, there aren't too many people that really “get it” more then Rocky.

Now, before you link over there, read the article, and start getting all worked up...I've followed enough of Rocky's blogs, articles and comments to go out on a limb and assume that he is not suggesting we go into work tomorrow morning and start replacing our Ado.Net data access code with web services. Instead, I think the article challenges us to continue questioning the notion of exactly what role web services play (if any) inside an application.* By thinking out of the box here a little about data sources, and their similarity to other external interfaces, I think Rocky helps focus attention back to the fact that the application itself should in deed be the center of the architecture.

This is the very basic point that seems to get lost in most other articles that mention SOA. And when it gets lost in articles its one thing, but when the point is missed in real world architecture, it can be painfully expensive. I am speaking first hand about this experience.

By thinking of the Data Layer as we would any other external interface, we better align it with other similar responsibilities; things that give data, receive data, and otherwise interact with our application (i.e. event actions). But we also do one more thing that I think is really the kicker here, we eliminate one more reason why people feel overly compelled to use web services inside an application.

Because accessing a data source has additional security concerns, it is often the case that not all physical tiers of an application can physically connect to a given database. When this happens, and we are not looking at our architecture as Rocky suggest in the article, then we often end up with an application architecture that gets pretty messy. We end up with an application that eventually gets split in two (if not more) pieces by a web service. We have part of the application (that can't see the database) on one side of the web service, and the other part of the application on the inside of the web service (the part that can see the database), and we somehow think that these two applications are really one. Business logic begins to get duplicated in both halves of the application. It becomes very tricky to determine which half of the application is responsible for what. We often find that we need some behaviors from one side of the application on the other side. We duplicate security, we duplicate validation, up to the point that someday we realize that what we have now is two applications instead of one. Not only do we have two applications, but they are two very similar applications, often with copies of the same business code in both. The only real difference being that at the edge of one we interact with users and at the edge of the other we interact with a database. Both interact with one another. And often this split of the application with a web service is initially done because of data layer concerns. This is seen and heard in many architectures discussions today and is often described as using a web service between the front end and back end of an application.

You might think, whats the big deal in describing the split in the application as above or saying that data access is a service; “don't I still have this problem of two applications divided by a service“. The answer is yes and no. In the previous description, we attempted to rationalize a single application split in two, but now we have two clearly defined application responsibilities, and therefore two applications. The application that is the Database service, has clearly defined duties. As an application, its externally exposed service is simply sending and receiving data. Internally, this data is simply persisted to a Database. Any business logic performed, would be clearly defined to the responsibility of retrieving and persisting this data; ie. data type, length etc. But, truly only from the perspective of data persistence. The other application (which is our actual business application) is the single domain that all business logic takes place. This includes business rules on data validations, code to perform special calculations, applying user settings, and all role authorizations, etc. The stuff that makes up the core of what the application is about. We no longer have all of this duplicated between both (halves) of the application. Why?- Because we now have two applications, not one application with two halves.

*By inside an application, I am speaking of between layers of an application