Service Oriented Architecture or SOA for short can mean different things. At the core, is the ability to send a message over a network to an isolated destination for a specific business purpose.
The first thing is communication and sending messages. Let’s say you have five colleagues at work from different countries that each speak a different language. And you want to get everybody together to plan an important event. You have some time to organize this event so what do you do? Would you learn how to speak the other five languages? And would you recommend that the others learn to speak five new languages each?
This could work, but imagine not only the difficulty of learning five new languages but also making sure everybody else learned five new languages. And if you think your troubles are over, they’re just beginning. You all arrive at the planning meeting and don’t be surprised if the language changes several times back and forth. This problem has been solved already. A better approach is to use translators that know how to speak a specific language plus another language that’s common to all the translators. Each person has a private translation of what’s being said by the others. And whenever somebody needs to say something, those words get translated for everybody else to hear too.
Now that you have a system where each of you can understand everybody else, do you all meet and decide to plan the whole event several times over? In other words, do you sign up to handle travel, lodging, meals, advertising, finances, and the content all by yourself? What’s everybody else going to do? Hopefully not the same thing.
In SOA terms, you and the other five people are like new software solutions within a company. The last thing you want is to have multiple systems handling payments or licensing. With Service Oriented Architecture, whenever you’re designing a new software solution or adapting existing software to work better, instead of making each software complete and able to handle all the things it needs in it’s own way that only it understands, you instead create standalone services that are designed to perform a specific task.
These services are not the solution you’re building. But they help consolidate useful functionality so that other solutions can benefit. Listen to the full episode for more information, or you can read the full transcript below.
Transcript
Let me explain what all this means now in a couple ways you can relate to. This will be a short episode because I’m not going to get into all the details. The problem with this is that the details are different depending on who you talk to. SOA has been around for a long time and has changed over the years. It’s gotten mixed up with APIs and micro-services. Even the meaning of APIs has changed over the years. That’s why I started out with a vague description and some terms such as “specific business purpose” that are not much better. Don’t worry, I’ll tie it all together and in just a few minutes, you’ll have a much better understanding.
The first thing is communication and sending messages. Let’s say you have five colleagues at work from different countries that each speak a different language. And you want to get everybody together to plan an important event.
You have some time to organize this event so what do you do? Would you learn how to speak the other five languages? And would you recommend that the others learn to speak five new languages each?
This could work, but imagine not only the difficulty of learning five new languages but also making sure everybody else learned five new languages. And if you think your troubles are over, they’re just beginning. You all arrive at the planning meeting and don’t be surprised if the language changes several times back and forth. There’s got to be a better solution.
This problem has been solved already. A better approach is to use translators that know how to speak a specific language plus another language that’s common to all the translators. Each person has a private translation of what’s being said by the others. And whenever somebody needs to say something, those words get translated for everybody else to hear too.
I’ll get to the rest of the explanation right after this message from our sponsor.
Okay, back to the event you need to organize. You’ve worked out a system where each of you can understand everybody else. But why were each of you chosen for this big event? Probably because each of you has organized events before and you all know what needs to be done. So now, do you all meet and decide to plan the whole event several times over? In other words, do you sign up to handle travel, lodging, meals, advertising, finances, and the content all by yourself? What’s everybody else going to do? Hopefully not the same thing.
In SOA terms, you and the other five people are like new software solutions within a company. The last thing you want is to have multiple systems handling payments or licensing. And it’s even worse if these systems can’t communicate.
With Service Oriented Architecture, whenever you’re designing a new software solution or adapting existing software to work better, instead of making each software complete and able to handle all the things it needs in it’s own way that only it understands, you instead create standalone services that are designed to perform a specific task.
Maybe you need to figure out if a customer that sent an electronic request for information is still a valid customer before just sending the information. This is the type of thing that can be delegated to a service that knows how to validate customers. That’s all this service will do. And it’ll do that job better than anything else because it’s specialized.
This makes your new software more reliable and faster to develop because you can rely on these services instead of trying to figure these things out for yourself.
Back to the example of the event planning, it would be similar to each of you taking one aspect of the event and working on that in such a way that you can all make use of these aspects as services. Then you can put together the final event by making use of the work each of you have done.
It’s important to realize that the services don’t really know how they’re being used or why. They’re just useful for solving specific needs in a way that any software can send the service a message and get back a response.
Once you have your design divided up like this, then each of these services can be run on different computers and even in different locations.