Service-oriented architecture... whatever that really means...
You may have heard around the office the term Service-Oriented Architecture or "SOA", but wonder what it actually means? Well. the answer can vary on who you ask, but one thing is for sure.
"SOA is an architectural style which is composed of a collection of loosely coupled, discoverable, interoperable and reusable services."
Just to reiterate, SOA is really just a term for a bunch of services whether they be business services, technology services or any other collection of services that are loosely coupled, discoverable, interoperable and reusable.
- Loosely coupled - Meaning that the services try to be independent of each other (loosely coupled), as each service performs a unique function. It is also possible that a service can be made up of sub-services (these are called composite services).
- Discoverable - They can be found! For example, if you open a phone book or newspaper and find the number for your local car dealership, this means that their service is discoverable. As you have found their service.
- Interoperable - The services can exchange information with each other and the outside world, making them interoperable.
- Reusable - They can be reused elsewhere, for example, we wouldn't buy a new lawn mower every time we wanted to mow the lawn.. we would re-use the existing one.
Any business can follow a Service-Oriented architectural style. The style is not just restricted to software, but it can be used in any relevant context. But what does SOA mean in the software world?
Dun dun daaaaa...
A web service is an implementation of SOA, just on the World Wide Interwebs. And what do we use to communicate on the web? Network protocols!.
Web services commonly use protocols such as HTTP and SOAP for interaction between a client (your computer) and a server (the server that is hosting the resource you are requesting).
The best thing about web services? Plain and simple, integration. Two giant businesses offering the highest quality applications, can merge their functionalities together easily with the help of Web services. They don't need access to each others code repositories or a detailed explanation on how everything works under the hood. Both applications are able to make their service discoverable and boom, the services are ready for consumption. In a web service context there is usually a service provider, service consumer and service repository. The provider will publish the web service to the service repository (eg. a phone book) for it to be discoverable, then the consumer will use the web service and receive a response promised by the web service.
This diagram below attempts to illustrate the roles played in a web service:
But remember we can't have web services without...
SOAP (Simple Object Access Protocol)
It's a protocol specification exchanging XML a.k.a "structured information" in web services. It relies on the use of application protocols for transmission (as the message content is independent of the method of transport). Take for example, a web service provider wanted to publish a service to make a simple "note" accessible to the whole world, what would they do? Well they would transfer this note into XML format, maybe something like the below:
A SOAP message consists of:
- An envelope element - this identifies the XML document as a SOAP message
- A header element - header information
- A body element - which is where the call and response information is contained
- A fault element - which is used error handling
Once they are added, the SOAP message is constructed, your service function is created eg.
getNote(), then it is ready to be published to the service repository. This is done by updating the Web Services Description Language, I like to think of it as a phone book and your updating the phone book with newly added phone numbers. Great, so now the WSDL has been updated, and the web service is now discoverable. A web service consumer can then consume the web service (ie. call
getNote() in their application) and they will receive a SOAP response back with the note they requested.
Some Benefits of SOAP?
- Platform, Language and Transport independent
- Built-in error handling
- Automation when using some products
REST (Representational State Transfer)
REST, or Representational State Transfer is another way of implementing a web service. It is the ideology of everything is a resource. Every resource is identified by a unique uniform resource indicator (URI), for example take the following two URIs,
https://mywebservice.com/Australia/ which returns a big list of all the states, cities and suburbs in Australia. And another URI
https://mywebservice.com/Australia/Queensland/, which returns a filtered version, only showing the cities and suburbs in the state of Queensland.
One more example:
Another important point to note with REST is that it is stateless. This means that when you access that earthquake data linked above, it is the most current state of the resource (ie. most recent data available). You might go for a quick walk, come back and there has been an earthquake in that time. Now the data has been updated and you will no longer be able to access the previous data before you went to go for that walk.
Some Benefits of REST?
- Lightweight baby!
- Scalable - Supports large numbers of requests
- Reliable - No single point of failure
Microservices is another form of Service-Oriented architecture, which is still in its early days. What is it? It is architectural style adopted by big tech players such as Netflix, Spotify and Google. The general idea with Microservices is that instead of having one big monolith application where you run all your services on one process, you split them up so that each service runs on a seperate application. For example, if you have a website that offers a mail service, a word processing service, a search service etc. you have a seperate application for each. This keeps it modular and provides a hard boundary between each service. This is an excellent architectural style for large-scale applications as it splits up the application making it more manageable for teams and developers. It enables them to move faster following a rapid deployment approach, pushing code out to production multiple times per day.
By having boundaries between services, things become decentralized and no longer is there a single point of failure. ie.
Application goes down -> All services go down. It also is brighter for the business world too! If there are only 1 or 2 services that fail, the system is still considered semi-functional, thus reducing the impact that it has on the company and the end-user. Boundaries also make it easier for software testing, by enabling developers to test locally on their machines without deploying their code to a test environment first.
Another way it is changing the business side of software is by isolating teams, mmm no.. I don't mean isolating collaboration or ideas.. but isolating each team to a separate service, eliminating inter-team dependencies. This enables teams to move faster and continue building without having to slow down and wait for things like approvals, processes, or bugs to be fixed... you get the idea.
Microservices embrace the DevOps culture, where developers work together with operations for the good of rapid development. Expecting failure is a must have when dealing with distributed systems, things are always going to break or go wrong. As many users flood in requesting information, it might put pressure on your datastore... causing it to fail, but how can we overcome this? Lets just shard the datastore to distribute the load. Or, too much pressure on compute? Maybe switch to a cluster of containers to spread out the load on compute, then utilise a container manager to do health checks and monitoring on all the nodes in your cluster.
Partial deployment is another beautiful thing about microservices. It's possible to use techniques such as A/B testing to roll out new features or versions to a subset of users, then monitor the generated metadata and analyse the results for improvements. Super cool.
But before jumping into a microservices approach, you have to remember like anything it has pros and cons and it might not be particularly suitable for your style of application. From what I can see the best method of choosing an architectural style is to analyse your requirements and know what you are delivering, then choose the style that is most relevant to you!