AHH who doesn’t like architecture… It’s the architects that are responsible for designing high-rise buildings. It’s the architects that are responsible for designing amazing bridges all over the world. It’s the architects that are responsible for designing high performance & scalable software..

This article is dedicated to a software framework that I recently developed. I will cover the basics of Service oriented architecture, and cover the solutions architecture I used for the framework. Diving deeper in… I will cover the Service architecture (developed with WCF services) and the Application architecture (developed with MVC).

1. Service Oriented Architecture (SOA)

So we all know what SOA is ?.. if you need a refresher, please take a look at the following article: http://en.wikipedia.org/wiki/Service-oriented_architecture

Below is my visual interpretation of the SOA layers. I know…I know.. I’m sure there are some standards out there that define what shapes and icons to use for Software Entities in a model and diagram.. but I choose to use basic squares and simple shapes..!


On the LEFT-side is the grouping for the services. This can range from 3rd party services like Google Maps, Twitter, Facebook API’s etc. To your own custom services like traditional web-services, or WCF services.

In the MIDDLE we have.. the ‘cloud’.. AKA the network or internet connection.

On the RIGHT-side we have the consumers of our services. These are the applications that uses and requests data from the plethora of services available.. when and if required.

2. Solution Architecture

Diving a little bit deeper into my framework – call the Ghost Framework – because it was an ad-hoc framework built to support future development of internal systems.. no name was given to the project.. thus I called it the “Ghost Framework”..!


On the LEFT-side we have some pre-defined services that the framework will support. Namely a Navigation Service and a Security Service. The services are connected to one common database. However, this can be split into more modular databases, one for each service.. but in my case – it wasn’t necessary.

These two services expose functions for the retrieval of information used for Navigation menus in the application(s), and the security that oversees access to all the applications (things like ‘does the user have access’, what the user sees, what actions they can and cannot perform etc).

On the RIGHT-side we have the application(s). As a sample prototype, I built a simple deployment sign-off application. Nothing fancy.. just a small workflow system that captures deployment information and management approval. But the concept is that all applications developed with this framework will reside here on the RIGHT-side of the diagram.

3. Service Architecture

Lets focus on the LEFT-side, the Service Architecture for a moment. To provide a better understanding of the design, the diagram below focuses on the Navigation Service and its components.


Using a basic tiered-design, with a separation of concerns for each project..  each WCF Service for the framework is built with a minimum of 3 projects:

a. Entities – This project holds the ‘plain old CLR objects’ AKA POCOs, or DTOs, or a combination of both.

b. Managers – The main driver class for each project. All communication with the repository, and all business logic reside here within the manager object.

c. Repository – Classes that provide access to data sources (databases, file system etc)

To access the Navigation Manager’s class method, the request is received from across the wire (over the network or internet connection) to the hosted WCF Service. The hosted WCF Service method is then in charge of instantiating a Manager Class (in our case, the Navigation Manager), and then calling the respective method of the Manager object.

The Manager object then performs the necessary business logic and if any data access is required, the manager class does this by instantiating/calling repository class methods. Entity objects are passed back and forth, soon transformed into their XML or JSON representation before the data is sent back to the consumer in the form of a response.

4. Application Architecture

Now onto the RIGHT-side, the Application Architecture. MVC is the technology used to develop the applications.

The entry point to the application comes from the CONTROLLER classes. Controllers are responsible for loading the VIEWs, by generating MODEL objects for the view object to interpret. For more information on MVC, please take a look at the following article: http://en.wikipedia.org/wiki/Model-view-controller


The MVC project follows the standard MVC design. In addition to this, the diagram allows the creation of a Custom Project. This custom project follows the Entities-Manager-Repository design (as described in Section 3).

The MVC Controllers access the custom business logic via the Manager classes. What this achieves, is that it keeps the MVC controllers clean and simple. The bulk of the business logic are coded in the Manager classes. Data retrieval is performed by the Repository, and Entities are passed back through to the Controller via the Manger classes. The controller then populates a Model object for the corresponding View, allowing the View to interpret it and to render the UI.

The Custom Project section holds the core business logic of the application. This simply provides a separation of concerns from the MVC design of model, views and controllers.

So.. where does the Navigation Service come into play in all of this?  When the application loads, a Navigation controller is created. The Navigation controller is responsible for contacting the WCF Navigation Service to retrieve the navigation data. Once data is retrieved from the service, the controller transforms this data into a MODEL object, and passes this model object to the view object for it to render a html response.

Of course, additional service methods can be called from other controller classes, and also within the Manager classes – depending on your requirements.!