What is it?
Service Oriented Architecture is a software system design principled aimed at constructing small logical systems. As we know from testing small components are easily testible which is why SOA is a very common architectural pattern in large distributed systems.
A service has four properties:
It represents a single business activity and has a specific outcome
It is self-contained
It is a black box for its consumers (it shouldn’t know how other services work)
It may have multiple other dependent systems
SOA integrates distributed, separately maintained and deployed software components. You will rarely hear the term SOA in job postings, instead you will see a common term called Microservice Architecture.
Difference between SOA and Microservices
SOA is a modular means of breaking up monolithic applications into smaller components, while microservices provides a smaller, more fine-grained approach to accomplishing the same objective. While this is pretty… fluffy… To be honest for the most part they are largely the same thing (queue hate comments).
Defining Concepts
A manifesto was published for service-oriented architecture in October, 2009. This came up with six core values which are listed as follows:[8]
Business value is given more importance than technical strategy.
Strategic goals are given more importance than project-specific benefits.
Intrinsic interoperability is given more importance than custom integration.
Shared services are given more importance than specific-purpose implementations.
Flexibility is given more importance than optimization.
Evolutionary refinement is given more importance than pursuit of initial perfection.
Patterns
Each SOA component typically falls within one of these roles:
Provider - It creates a web service and provides its information to the service registry. The provider also has to decide what category the service should be listed in for a given broker service
Service broker, service registry or service repository - Its main functionality is to make the information regarding the web service available to any potential requester.
Service requester/consumer - It locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its web services.
Implentation
Service-oriented architecture can be implemented with web services. An example would be SOAP which has gained wide industry acceptance in various industries.
Architectures can operate independently of specific technologies and can therefore be implemented using a wide range of technologies, including:
Web services based on WSDL and SOAP
Messaging: ActiveMQ and RabbitMQ
RESTful HTTP APIs
gRPC
Implementations can use one or more of these protocols.
Why?
This style of architecture promotes reuse at the service level rather than classes level. This allows a significant amount of code-reuse by repackaging IP. Entire services include more than just classes, they include Logging Frameworks, Load Balancing, Databases, Audit Logs… etc. Migrating a system to SOA is a lot like refactoring code however it’s just a lot more work. In this way Organizations that adopt SOA often start out with a monolith system, hopefully avoiding the Premature Optimization Problem. The next logical evolution in the system is to prioritize the service that is most used and abstract it.
For my company it was a core service that managed the emailing of data to our customers in a specific industry format. We wanted to build new products that would use the same method of delivery so it made sense to abstract that code and use it in the new product. 7 Products later we are still using that Microservice. Every time we build something new, we save weeks of development time having to not research and build this system, or incur the penalty of copy-pasta.