When building out a services-oriented or microservices architecture, you'll expose your services so that they can be called remotely over a network. You can choose to do so by leveraging whatever remoting protocol is native to your programming language of choice. In the Java world, this could mean using Java serialization and RMI, or even EJB, to communicate between your services. The problem with this approach is that it locks you into that language, making it difficult or even impossible to introduce services written in another language.

As your architecture grows bigger, it's not realistic to think that all of your services will always be written in the same language and will communicate with that language's native remoting protocol. Additionally, if you ever want to expose some of your business functionality outside your own software, like an external API, then having a language-specific API will only limit that API's adoption. When faced with such...