This posting may very well be banter. You have been forewarned.

Services

Everywhere I look I see services. I can get pizza delivered, my clothes dry-cleaned, and my shopping delivered to my home without ever leaving my computer. These are all services provided by someone, somewhere. A little closer to home I have my TV which delivers a digital service, radio which delivers an analog service, phone line which delivers a communication service, an XBOX which delivers an entertainment service, and even my kitchen counter, which props up the toaster and bowl of fruit, is performing a useful service.

Definition

Here’s a site I often use that provides a service that explains the meaning of words. The word I am interested in, surprisingly, is “service”:

an act of helpful activity; help; aid

Ok I ignored the other definitions but they all pretty much relate back to the concept of something, someone or some corporation doing something useful for others. Sometimes we pay for services, sometimes they are free. But really, services are there to help and form the cornerstone of our very society.

Now that you love services as much as I do, you’ll completely appreciate what this means in software engineering: A service is any code component that helps your application achieve completeness. It is not necessarily something that communicates over the wire, via named pipe or some message queuing application. It isn’t always found in the form of XML, JSON, or binary formats. Its just like your kitchen counter, a piece of code that provides a useful function to your application.

Too abstract?

I think we often get too wrapped up in someone’s interpretation of various buzz words and lose site of the meaning of the words themselves. I have no problems using the term ‘service’ in a way that relates in no way to objects going over the wire, WCF, ASMX, etc. Instead, our repositories, factories, presenters, controllers, managers, builders, all those code classes that have a single responsibility, they are all services. For example, in an app I am working on now for a client (ASP.Net, WCF, MS SQL) I am using the MVP pattern and am using IOC (Ninject). I wanted my presenters to be responsible for navigation, but didn’t want them to know anything about page urls. So I created a ‘NavigationService’ (with matching interface) with a simple ‘Navigate’ method on it. It takes a view ‘name’ and looks up the sitemap to work out where to navigate to. This works great because now my presenters are controlling page flow without knowing anything about how navigation works. Its highly testable since my NavigationService can be mocked out easily (thus the interface). You obviously don’t have to put the word ‘service’ in the name, its just sometimes helpful if your class can’t easily be classified as a repository, factory, etc. If you had ‘Helper’ somewhere, generally you could probably replace that with ‘Service’ since it means the same thing.

Service Oriented Architecture

Yes SOA means Service Oriented Architecture, not Service Oriented Application, and certainly not Service Only Architecture, which is what some people seem to think it means even when they say the word ‘oriented’. The term ‘oriented’ means ‘aligned’ or ‘related’ and in my mind, the literal translation of the phrase means “an architecture where the majority of modularisation is achieved through services”.

OASIS is a standards group and has a reference model for SOA which states:

“Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”

When we hear the word ‘distributed’ in computing we automatically assume disparity and remoteness. But again if we look to our word salad service (dictionary) we get:

“to divide into classes”

Oh this is almost too easy! Of course it doesn’t mean software classes (example, plant species as classes of plant distribution) but it fits too well to ignore. And those capabilities are of course our helpers, repositories, etc. The last part of that statement says “that may be under the control of different ownership domains”. I guess the point here is that it doesn’t have to.

What’s your point?

Lets say I have a smart client application, WPF since that’s my drug of choice. I’ve broken it down into a main EXE and a separate DLL where I store all my repositories, builders, factories, presenters, etc. I go to great lengths to ensure everything acts like a service (as per my explanations above). All my capabilities are distributed into separate classes.

In this scenario, am I implementing a Service Oriented Architecture?

Well I’m overly focused on services, some services call others, each is defined by a contract (since I use IOC to locate and resolve them), the implementation is hidden behind the interface, and the only implementation not in a service is the UI. So as far as I’m concerned, the answer is yes!

The great thing about IOC and services in general in .Net is that you can easily turn one of those interfaces into a WCF service contract with very little effort. You want to ‘distribute’ over the wire? You can! The important thing is that you have control over how the services are surfaced.

So the final takeaway is this: consider SOA for every application you ever design. This doesn’t mean WCF, ASMX, named pipes, etc. It just means designing your application with individual services that take care of all your application needs. If you can do that, you will realise clean abstractions, encourage testability, improve maintainability, and create reusability. And I can assure you, once you adopt this style (and a good IOC container to help), you’ll never go back.

The Azure Part

Some of that service stuff above is not overly relevant to what I’m going to talk about next. But SOA in general certainly is. Windows Azure supports division of labour very well: If your services are all located within one application assembly, then just provision one web project. If you feel you need to scale out certain services due to work load, slap some service contracts on them and push them into a new instance of their own. Want to keep some of those services on premise? No problems, use the Service Bus to route requests to your on-premise services, easily skipping through those firewalls. Want your data in the cloud too? No problem, stick it in SQL Azure or just plain old Windows Azure Storage if necessary. Hell you could even put it in Amazon S3 if you wanted, Azure doesn’t care: it supports these service abstractions easily and doesn’t know if the service you are calling is hosted in Azure, on-premise, through the service bus, or some external service (eg. S3, Flickr, etc).

Summary

The point I am trying to make is that if you follow the SOA principles above, your application design will “just work” when you want to move to Azure. The applications that are hardest to move to Azure are those with tightly coupled components and leaky abstractions. Its certainly difficult to adopt this style of development at first and is certainly something that your architect should be involved in continuously (code reviews, etc). But even if you don’t plan on moving to the cloud, its a great way to build your applications and helps you benefit in the long term. Once you get used to the style, it certainly improves your development speed, and removes dependencies on the components being built in other teams. And it certainly works well for large and small projects alike.