Composing Services into Layers

In this article I want to discuss a web services architecture that I have worked with over the last 7 years in a couple of different companies. The architecture I am discussing composes web services into layers, but there is much more to it than that. Nothing in this article is rocket science to an experienced services developer, but it is a way of working that has proven very reliable and easy to understand for developers that gets them working in a consistent way.

Typical 3 Tiered Architecture
Typical 3 Tiered Architecture

The diagram above shows what you will typically be used to working with in an enterprise. It is a standard 3 tiered architecture comprising of the following layers:

  • Presentation Layer: This contains any views that your users will interact with like, web sites, smart phone applications, desktop clients, etc.
  • Business Logic Layer: This contains the under lying logic for your application which may be comprised of web services, REST Services, windows services etc. The presentation layer shouldn’t contain any business logic and therefore should be quite dumb to the inner workings of your system, this is what the Business Logic Layer is for.
  • Data Layer: This contains your data storage. This typically is an SQL database (SQL Server, Oracle, and MySQL) or one of the newer blend of NoSql Databases (RavenDB, MongoDB, Cassandra). Typically your data layer may expose stored procedures to the Business Logic Layer, or your business logic may connect via an Object relational mapper such as Enterprise Library, NHibernate or SubSonic.

This article is going to concern itself predominantly with the Web Services part of the Business Logic Layer.

Advertisements