Explaining Synchronous Communication Pattern

Synchronous communication can be implemented in function calls that require the immediate return of data to the sender system.

The client sends a message to the server and waits until he or she receives a reply from the latter. Synchronous communication uses a single function call. Prerequisite for this is that at the time the call is made, the receiving system is also active and can accept the call and further process it.

A disadvantage of synchronous communication is that it must be ensured that both systems are active and can be addressed. If they are not, this can lead to disruption of processes. In particular, problems can arise if the receiving system is not available for long periods of time due to maintenance, for example, or a system upgrade.

Synchronous communication uses the Request Response Message Exchange Pattern (MEP). The client sends off a request and waits for an answer from the provider. The client is blocked during this. The client cannot start any more calls. A transport guarantee is not provided with synchronous methods since the client receives an indirect confirmation, through the response, that the call was processed successfully. The transactions, too, are not provided with synchronous methods. This means that each individual call is sent directly to the provider, and it is converted there. Calls are not collected first and then submitted together. All following calls are blocked. For this reason, there is no guarantee for call sequence.

If it is crucial that a synchronous method is executed exactly once, it must be sent as an idempotent (IDP) Web service. For idempotent services, the provider stores a message that is created in response to an incoming call before the response is actually sent to the consumer. The response is identified by the request message ID. For each incoming request, the provider can therefore determine if this request has already been processed. If a response already exists, it is sent back to the consumer again, without processing the message a second time.

1. Create a Consumer Proxy (Web Interface) from the WSDL of the Web Service Provider.

   In contrast to the service provider, we start here with the creation of the input and output interfaces from the WSDL. Thus, the interfaces correspond to those of the service provider.

2. Configuration with SOAMANAGER

   In the second step, you create a Logical Port and you configure the Web Service Consumer communication in SOAMANAGER. This allows you to test the entire communication with the service provider in the Web Service Navigator.

3. Create a Consumer Implementation

   In step 3, you create the consumer implementation which is used to call the consumer proxy.