SOA has Roots in Agile and Functional Programming
SOA got popular around 2k years when business was moving to more complex functionality and more and more data. Them it came several buzzwords and vendor-like things, but soa was never about technology was always about principles and a specific way to think, see and build things, the service orientation. To capture this view a group of awesome people created the soa manifesto.
SOA Manifesto
The structure and ideas on the manifesto are very similar to the original agile manifesto. So if we take a look on some toughs on the soa manifesto we can find roots in agile for this ones:
* Business value over technical strategy.
This is the root on agile that wants always to add value to the business with great software. So here the idea is the same soa purpose is the same as agile purpose do the best. Agile do it with continuous delivery of well engineering software with tests, refactoring, code review, pair programming, constant costumer engagement and welcome change and much more.
SOA do it with SO and having services that easier to maintain and understand and allow you to change the business with agility instead of being hold down by it department. Thats delivered through flexibility, reuse, backward compatibility, versioning and much more.
On the agile manifesto you find this as:
Our highest priority is to satisfy the customer
through early and continuous deliveryof valuable software.
* Strategic goals over project-specific-benefits.
We can see agile here again. We can link to the idea of do something for the business not for the it department. often people get wrong ideias about they work in organization, often people do what is best for they not necessarily what is best for the business. It says the your service its a business service you cannot have SOA if just a small part of your it use it, them you have a webservice or APIS like they call it now a days, everything is an API from google, facebook, twitter, whatever but not necessarily all SOA.
In agile:
Individuals and interactions over processes and tools
* Intrinsic Interoperability over custom integration.
In the past i word with system are this was not a concern whatsoever. Thats a big problem because doing this you end up killing your-self. You do 1 system, them you do a second system them you endup doing a 3 system just to integrate the other 2 and this is wrong.
Its much more hard to integrate and maintain, so this is a very important principle, you can do it with any technology but people often choose REST/HTTP to do this because the are interoperable by default you dont need make any effort to it.
Talking about software architecture it make sense to think on internal and external services sometimes if you need talk to the web or external consumer through, since you night need more flexibility and make sure your apis dont break all the time.
Where is agile here?
Customer collaboration over contract negotiationResponding to change over following a plan
How could you respond quickly yo change if your architecture dont allow you to do so? And how could you collaborate if your software just do whats do for you or for a small group of people things need to able to be easy to naturally integrate to enable you todo service composition(FP core concept).
So you avoid do things of EJB for instance because ejb just work with java, its better do in soap for instance because SOAP you can call it from other languages and systems but would be even better do it over http.
* Shared Services over specific purpose implementations
This means we need to able to SHARE the services, yes we are talking about REUSE, but they dont use the word REUSE, why not? Because reuse is not by acaccidentesign. So you design the service according to the business and you design the reuse or not.
When you have specif things its bad? no. I do SOA for years and there are specific things but they are there by design and are things that are shared a lot, but thats just reflect the business, architecture is a reflect of business decisions(some people called decisions as requirements, they are the same).
In agile:
Continuous attention to technical excellence
and good design enhances agility.
* Flexibility over optimization
This is one of the principles people dont get it most. In order to be flexible you need not be monolithic and to have composable and different components. In SOA there is no components, or classes or functions, just services, services are citizen of first class.
This don`t mean you will not have:
* Applications
* External Services (APIs)
* Shared Data(I know its kinda against micro-services)
* Data Service
* Techinal Services
* GUI
But you balance what should be in the service and what should not be. Sometimes you need to sacrifice the performance because flexibility its way more important. So internally for instance your services could be using akka with google protocol buffers but externally you might what user Java or REST/HTTP with JSON? why? because more people can consume it.
In Agile:
Welcome changing requirements, even late in
development. Agile processes harness change for the customer's competitive advantage.
* Evolutionary Refinement over pursuit initial perfection
Well this is pure agile:
Working software over comprehensive documentation
Deliver working software frequently, from a
couple of weeks to a couple of months, with a preference to the shorter timescale.
In the past people was doing stop-the-world SOA adoption, often 5 years adoption plan in a very waterfall way with zero or none benefit in the end. This sounds and its is really about XP, the idea of always make things work and keep learning never stop learning but dont stop, keep going, keep building and keep learning them improve(refactoring).
Where is the Functional Programing in SOA?
(More on CORE FP Concepts - check my slide share presentation).
SOA has services, what is a services? Its a business implementation of something, so you pass some data to the service and it returns data. So this looks like a function definition and it is :-).
When you think about a SOA Service Contract, what are the elements that are part of the contract, well thats depends on how you do some but could be:
SOA Service Contract Definition
- The DATA(Input - all objects for the service input data), output: all objects that represent the data from the output).
- Operations - what you can do: search, update, delete, get, etc...
- Behavior - This means what the service does, and how it does.
- Format: if you return dates could be: yyyy-mm-dd or mm-dd-yyyy for instance.
- Serialization format: you return JSON, XML, Oct-Stream or binary for instance.
- Operation mode: if its sync or async
Could be even more. But if you think around functions you have something very similar the difference if the context but the ideas are the same. So all functions have #1 #2 #3 #4.
#5 could be considered the default form the sample and #6 all new modern FP langs have things like Stm, CSP, actors, threads, rx, channels, queues, etc... so it means they have abstractions and way to handle to this.
Functional Programing have 4 main concepts, first is based on math that is Lambda Calculus and things like High Order Functions and Functions First, we see a lot of Function First in soa, specialy are doing code on demand.
If you are doing REAL micro-services you might see Immutability and NO Side effects as well because the micro-service is based on isolation ideas the same ideas as functional programing use to benefit in: reuse and parallelism.
There is a nice fit of SOA, Agile and Functional Programing to deliver best software and help people to deliver value to the business.
Cheers,
