150: Distributed Computing: SOA

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 alread