What is Service Oriented Architecture?

Jan 07, 2015

Table of contents:

1. Distributed applications and the problems of scale
2. What is Service Oriented Architecture?
3. How does Service Oriented Architecture solve the problem?
4. What is an example of Service Oriented Architecture?
5. When should you use Service Oriented Architecture?
6. When should you avoid Service Oriented Architecture?
7. Conclusion

A common term that is thrown about when talking about large applications is Service Oriented Architecture. If you are familiar with common design patterns of Enterprise applications or large scale web applications like Twitter you might have already heard the term.

Service Oriented Architecture is the solution to a very difficult problem. However, it’s often cast as the solution to all problems.

Implementing Service Oriented Architecture is very likely going to be the perfect solution to a small number of problems, but it can unravel into a total nightmare in the wrong situation.

In today’s article we’re going to be looking at Service Oriented Architecture, how it works and when it should be implemented.

Distributed applications and the problems of scale

One of the best problems to have in application development is the pain of growth. By the time you are really feeling the pressure of scale, you should be well on your way to success. You can pretty much get away with murder when an application is small. But growth will really shine a light into hidden problem areas.

A common problem for large Enterprise companies is having distributed software applications that are required to interact. For example, you might have a Customer Relationship Manager application, a Stock Management application and a customer facing website that should all be integrated in some way. The real value of these distributed application is when they are integrated to cut manual processes and to reveal business intelligence.

A second problem of growth is the slippery slope to a monolithic application. In the beginning, all applications start off as a single codebase. However as an application grows, and the number of developers increases, having hundreds of employees working on a single codebase is likely going to start to fall apart. When all development activity is trying to fit through the same door, it is inevitable that you will end up with road blocks.

What is Service Oriented Architecture?

Service Oriented Architecture is where you have separate services providing functionality to other applications via an open interface.

Each service is a self-contained unit of functionality that provides a common process to be consumed by other applications or areas of the Organisation.

Each individual application is a closed box where the internal implementation of the functionality is hidden from the outside world.

Any other application can interact with the service via a common interface.

How does Service Oriented Architecture solve the problem?

Service Oriented Architecture solves the problems I’ve outlined above in a number of ways.

Firstly, by providing each distinct service as an interface, any other application in the network can leverage the functionality without the overhead of integration.

Secondly, each unit of functionality can be developed in isolation aslong as the public interface remains consistent.

Thirdly, because the implementation of the service is hidden behind an interface, the application can be written in a totally different programming language or use a different method of data persistence that is better suited to the functionality of the application.

And fourthly, the individual units of functionality can be integrated in different ways by other members of the network to further increase productivity or evolve the initial use case of the application.

What is an example of Service Oriented Architecture?

Imagine that we’ve been brought in as consultants to an existing fashion retailer. The company has been operating on the highstreet for a number of years, but is looking to move the majority of it’s business online.

The company already has an existing Customer Relationship Management, Stock Management, Distribution Management and Financial Reporting applications from it’s offline business.

A previous consultancy created an ecommerce application using Open Source software that tried to encapsulate the entire customer, stock and distribution management lifecycle as a single codebase. Unfortunately this meant that the online and offline sides of the business were not integrated and the online application turned into an out-of-control monolithic codebase.

We can solve these two problems that the Organisation faces by implementing Service Oriented Architecture.

The first thing we need to do is to write interfaces that will sit in front of the existing offline applications for Customer Management, Stock Management, Distribution Management and Financial Reporting. These interfaces will provide a common protocol for interacting with these applications via REST. This means we can programmatically interact with these systems without having to know how they work internally.

Secondly we will replace each aspect of the existing ecommerce application one-by-one to use the existing service, rather than implementing the same functionality in isolation.

This will peal away the functionality of the monolithic application to leave only the core functionality of the consumer facing website. The responsibility for other areas of the business will be moved to the appropriate service.

By doing this we have integrated the online and offline systems and reduced the burden on the consumer facing web application. The Organisation benefits by having all of their data integrated and the development team can work on each service in isolation as long as they maintain their public interface.

When should you use Service Oriented Architecture?

Service Oriented Architecture is best used when there are distinct areas of the Organisation that should be integrated or when the wheels are falling off the bus due to scale.

Service Oriented Architecture fits well when you have new and existing applications that need to be integrated. When developing a new application in an existing Organisation, you don’t want the new development to be burdened by the problems of legacy applications. Legacy applications will often also be difficult to work with, and so by implementing an interface in front of the application, you can save yourself the headache of trying to tackle every problem in one swoop.

Another good opportunity to use Service Oriented Architecture is when you have reached a point of scale where the benefits of a single codebase are becoming problems. For example, you might need to rewrite certain aspects of the application in a different programming language, or you might need to use a different form of data persistence. Having lots of developers committing to the same codebase will often cause problems as communication becomes strained and people start stepping on other people’s toes. You don’t want the productivity of your developers to drop because they can’t ship their code.

When should you avoid Service Oriented Architecture?

Whilst Service Oriented Architecture is perfect in certain situations, prematurely implementing it will be nothing but a headache.

It’s fair to say that the right path for nearly all new applications should probably be a single codebase. Prematurely optimising for scale will usually mean you never actually get there.

Implementing Service Orientated Architecture will be a big increase in the required communication between different aspects of your application. Instead of just calling methods on an object, you now need to make requests across a network.

This means running Integration tests on your application will be much more difficult when using Service Oriented Architecture. Instead of running your tests on a single box, you will probably have to set up a whole testing infrastructure so you can test the boundaries of multiple services.

It will also be more difficult to roll out new features that touch multiple services. Instead of making big sweeping changes across the codebase, you will have to make small incremental changes so that you don’t disturb the equilibrium.

You should try to avoid implementing Service Oriented Architecture for as long as possible. A single codebase will take you a long way. By the time you really need to rethink your application’s architecture you will probably already know exactly where to draw the lines and what distinct services you will require.

It is impossible to predict the future, so don’t try to prematurely optimise for it.

Conclusion

Service Oriented Architecture is one of those terms that sound amazing in theory. Having the distinct aspects of an application as individual composable units that can be developed in isolation sounds like the answer to so many problems.

However, there is definitely a time and a place for Service Oriented Architecture. If you implement it because it sounds cool, rather than actually needing it, you will probably be making a mistake.

I really like the use of Service Oriented Architecture to integrate legacy or third-party systems within an Organisation. There is a huge amount of value to gain from integrating the isolated components of an existing organisation.

I think moving to a Service Oriented Architecture for an application that is feeling the pains of growth is another ball game all together. Breaking up an existing application into distinct services and then having them work together as a single application is a mammoth task not for the feint of heart.