Buzzword Bazinga: Service Orientated Architecture

... is a grand way of building a system with a lot of moving parts. A simple system has two main things: resources and functions. Resources - such as databases and file systems - is where all information is stored and retrieved. Functions, and the applications that execute them, are the means to interact with the resources. Applications come in a number of guises such as web sites, desktop applications and mobile applications.

Depending on the size and scale of the system; applications can directly connect to these resources. Kind of like a Tie Fighter docking directly into the Death Star. The Death Star being a central core of massive evil; like, for example, a Microsoft Access Database.

But let's say distributing this evil is a galactical ambition and having one place where you can arm, equip and feed the Storm Troopers and send them out to do your nefarious bidding becomes a bottleneck. To scale, you would have look at spreading the resources and facilities around a bit. You could, for instance, take over a planet and build additional docking stations, dormitories with foosball (for those times when the rebels are not trying to overthrow you), and an array of vehicles you could use to turn small furry natives into road kill. The planet would then become a disconnected, fully functioning service of evil.

Add a few more planets into the mix and you have what makes this type of system design unique. In computing terms, these planets are loosely coupled (disconnected) application services that allow for extending the system core (evil) across a wider area (galaxy) and handing off resources (Men in White Helmets) and  functional responsibilities (killing cute things).

There are some other attributes of this style of system design, which include:

Open Standards 

To ensure that applications can easily integrate with the services, services are built using open standards. These standards are usually comprised of XML as the language format, HTTP or other web standards as transport protocols and SOAP and REST as the web service types. These are technology agnostic, allowing anyone to experience the Power of the Dark Side.

Coarse Grained

The services layer should be defined by the consumer. Consumers are often business applications with functional requirements that make sense to end users. These are called coarse grained requirements because they are big and chunky and are brilliant for the mental digestive system. The services interface should map closely to these business requirements. Endor may have a lot going under it's protective shield but from the Empire's perspective they are only really interested in functional requirement #342 keeping us safe from the pesky rebel fleet.

Stateless

One goal of this architecture is that the services should be stateless, or all information required to perform a (coarse grained) function is contained in one message. However, this is often difficult to achieve as a conversation may need to be kept open between application and service. This stateful vs stateless conundrum is one that has to be assessed on a case by case basis. If Han defrosted from his carbonite nap and was oblivious to the back story, he could have mistaken his slumber for a hefty dose of rohypnol and Starwars VI could have been a tense courtroom drama.

Before I stretch Star Wars analogies beyond reason, let me wrap up SOA.

Service Orientated Architecture in simple terms is a bunch of web services sitting between end user applications and the system resources. Each service is self contained, should be stateless, built using open standards and protocols, and aligned the business functions that they are serving.

Buzzword Bazingered, my Master.