When enterprise systems require communication, the question of which communication protocols and technologies to use arises. There are many forms of synchronous and asynchronous communications to choose from. There are some considerations to make upfront.

Which communication technology is supported by the chosen languages and frameworks? Are there any existing systems that require a certain form of communication? Do the systems exchange information in a synchronous or asynchronous way? What solution is the team of engineers familiar with? Does the system reside in an environment where high performance is crucial?

Looking from a business perspective again, communication between systems is necessary and should not get in the way of implementing a business use case. That said, exchanging information should at first be implemented in a straightforward way, matching the specific domain, regardless of whether the communication is performed synchronously or asynchronously. These considerations have a big impact not only on the actual implementation, but also as to whether the whole use case matches the chosen solution. Therefore, this is one of the first questions to be asked, whether the communication happens in a synchronous or asynchronous way. Synchronous communication ensures consistency and ordering of the exchanged information. However, it also comes with less performance compared to asynchronous calls and will not scale infinitely. Asynchronous communication leads to looser coupling of the systems involved, increases the overall performance as well as overhead and enables scenarios where systems are not reliably available all the time. For reasons of simplicity enterprise applications typically use synchronous communication, and also in regard to consistency.

The chosen way of communication needs to be supported not only by the language and frameworks, but also the environments and tools being used. Does the environment and network setup make any constraints on the communication? In fact, this was one of the reasons why the SOAP protocol was widely chosen in the past; being able to be transmitted over network port 80, which was permitted by the majority of network configurations. Tool support, especially during development and for debugging purposes is another important aspect. This is the reason why HTTP in general is widely used.

In the Java world, arguably most of the communication solutions out there are supported, either natively, such as HTTP, or by third-party libraries. This is certainly not the case with other technologies. This was, for example, one of the issues with the SOAP protocol. Implementation of the SOAP protocol was effectively only seen in Java and .NET applications. Other technologies typically chose different forms of communication.

Performance of the communication technology is an issue to consider, not only in high performance environments. Exchanging information over the network always introduces a huge overhead compared to both inter- or intra-process communication. The question is how big that overhead is. This essentially regards the density of information and the performance of processing messages or payloads. Is the information exchanged in a binary or plain text format? Which format does the content type represent? Generally speaking, binary formats with high information density and low verbosity perform better and transmit less data sizes, but are also harder to debug and comprehend.

Another important aspect is the flexibility of the communication solution. The chosen technology should not constrain the exchange of information too much. Ideally, the protocol supports different ways of communicating; for example, both synchronous and asynchronous communication, binary formats, or Hypermedia. Since our application's main concerns is the business logic, the chosen technology can ideally adapt to the overall requirements.

In today's systems, the communication protocol with the greatest usage is HTTP. There are several reasons for this. HTTP is well supported by all kinds of language platforms, frameworks, and libraries. The variety of tool choices is extremely high and the protocol is well known to most software engineers. HTTP does not make many constraints on how it is used and can therefore be applied to all kinds of information exchange. It can be used to realize both synchronous or asynchronous communication, Hypermedia, or straightforward invocations of remote functionality, such as remote procedure calls. However, HTTP does encourage certain usage. We will discuss semantic HTTP, remote procedure calls and REST in the next topic.

There are communication protocols that are, not necessarily, but typically, built on top of HTTP. The most prominent example from the past was SOAP; a more recent example is gRPC. Both protocols implement a remote procedure call approach. Remote procedure calls represent a straightforward form of calling a function of another system over the wire. The function needs to be specified with input and output values. SOAP realized these remote procedure calls in the XML format whereas gRPC uses binary protocol buffers to serialize data structures.

Depending on what the business requirements are in terms of synchronous or asynchronous behavior of the communication, it is highly recommended to implement the behavior consistently. In general, you should avoid mixing synchronous or asynchronous behavior. Wrapping services that contain asynchronous logic in a synchronous way doesn't make sense. The caller will be blocked until the asynchronous process is completed and the whole functionality will not scale. On the contrary, it sometimes makes sense to use asynchronous communication in order to encapsulate long-running synchronous processes. This includes external systems which cannot be changed or legacy applications. The client component will connect to the system in a separate thread, allowing the calling thread to continue immediately. The client thread either blocks until the synchronous process has finished or makes use of polling. However, it is preferred to model the systems and the style of communication after what makes sense for the business requirements.

There are quite a few protocols and formats of communications to choose from, a lot of them are proprietary. It is advisable for engineers to be aware of the different concepts and ways of communicating in general. Communication technology changes but the principles of exchanging data are timeless. As of writing this book, HTTP is the most widespread communication protocol being used. This is arguably one of the most important technologies to implement, it is well-understood, and has a great tooling support.