Integration of services is one of the most critical solution elements of systems based on Service Oriented Architecture (SOA). There are few influencing factors which can significantly impact system capabilities depending on the type of the integration used. The most critical factors include and they are equally relevant for both regular services and microservices:
|From time to time, we will make service changes that may require service consumers to change as well. We have to ensure that the selected service integration technology requires this to happen as rarely as possible.|
|More service consumers down the road
|If more service consumers will be using a service in the future, the service integration capabilities should offer an efficient integration solution that will minimize service and service consumer changes and keep performance in a range of business SLAs.|
|When implementing integration interfaces for a service, its internal implementation details should be hidden internally and they should not be exposed to consumers of the service. If it is not the case, it means that if something is changed inside the service, we can break the service consumers by requiring them to change as well. That increases the cost of change and we want to avoid that. It also increases the risk associated with the changes.|
|Should communication be synchronous or asynchronous? This choice will shape the overall service integration implementation. Synchronous communication blocks until the operation completes. With asynchronous communication, a service consumer does not wait for the operation to complete before returning.|
|Stateful vs. Stateless
|While the synchronous integration mostly supports stateful services, the stateless services are mostly supported by the asynchronous integration. If the statefulness has to be supported by the asynchronous integration it may increase the complexity of the solution and data replication|
|Complexity of service interactions
|The complexity of the services’ interactions can further complicate overall integration especially in a case of the asynchronous integration.|
|Performance will be especially critical for the real-time processes with direct interactions with clients. The integration types supported by the services in the real-time processes can significantly impact performance during the peak hours of operations.|
|Technology agnostic APIs
|We want to ensure that the service APIs used for communication with consumer services are technology-agnostic. This means that the integration technology that dictates what technology stacks we can use should be avoided.|
|System breakdowns||There is a crucial question about the system availability if some of its components go down. It is acceptable for some types of applications to continue functioning in a partially available state if some of its services fail.|
Some Facts About Synchronous and Asynchronous Communications
Since it is straight forward with the synchronous communication to find out whether things completed successfully or not, the synchronous communication can be easier to reason about. However, since the synchronous communication blocks until the operation completes it can increase computing resources consumption and slow down performance during the peak periods.
Asynchronous communication is useful with the following types of executions:
- It works very well when we need low latency since it does not block a call while waiting for the result.
- It also works well with long-running jobs that would otherwise keep a connection between the consumer and a service open for a long period of time what would cause inefficient utilization of resources.
These two different modes of communication enable two different types of collaboration between the system components:
- request/response or
With the request/response collaboration, a client sends a request and waits for the response. This type of collaboration aligns well to synchronous communication. However it can also work for asynchronous communication. For example, a consumer can send a request to a service and register a callback, asking the service to send a corresponding response when the operation has completed.
With the event-based collaboration pattern, system components raise events when things change. Other components can listen to events and react to them. The event-based collaboration supports a very loose coupling between services and its consumers. The addition of the new consumers of a service and under assumption that the added consumers can listen to the events, would be pretty straight forward. This type of the collaboration keeps each service simple in a context of its integration. Generally event-based collaborations have advantages such as loose coupling, simplification of the system components, better performance, and it is more resilient to breakdowns. However at the same time it can increase the complexity of the interactions and data replication in a case of stateful services since this type of collaboration is stateless.
Service Integration Matrix
Preferable Integration Type
Service decoupling is the property that is supported by the asynchronous integration. Decoupling minimizes impacts caused by service changes.
|Additional service consumers||Asynchronous
Decoupling property of the integration becomes important when more service consumers start to use the service. The less coupling is involved the simpler and more cost effective integration solution will be implemented.
Since the asynchronous integration generally hides internal details of the service implementation it will better support the implementation locality.
The synchronous integration is the best fit for the stateful services. If the statefulness has to be supported by the asynchronous integration it would make implementation more complex and also increase data replication.
The stateless services are mostly supported by the asynchronous integration.
|Complexity of service interactions||Synchronous
More complex service interactions will make asynchronous integration less affordable option. Synchronous integrations simplify overall solution when more complex service interactions are required. However the performance aspect of the solution has to be considered and we should analyze the weight of the solution complexity factor vs. performance since the synchronous integration with complex interactions can significantly impact performance.
Asynchronous integration generally provides better performance than synchronous integration.
|Technology agnostic APIs||Asynchronous
The technology agnostic APIs are better supported by the asynchronous integration since it minimizes exposure of the service internal details and enables either loosely or fully de-coupled services.
A system that uses asynchronous integration is more resilient to breakdowns because its components function in a more independent mode. In some cases that can be acceptable but we have to be carefully about how much the currency of data (up-to-date information) is required in a process using the service.