Standards for Technology in Automotive Retail

 
 Home -  News Feed 

I.VI. Communication Patterns Overview

This section provides and overview of the different communication patterns described in this document. For more detailed description, please refer to Communication Patterns chapter in the document.

Synchronous vs. Asynchronous

Synchronous communication refers to sending a message to a service provider and receiving a response within a short timeout period (recommended timeout is 100 seconds) on the same connection. A synchronous method invocation of a web service maps to one HTTP request/response cycle and it is similar to the way web pages are requested using a browser.

Synchronous method invocations are used when a response needs to be received immediately, say, to display it to a user in an interactive transaction.

Asynchronous communication, on the other hand, refers to sending a message without waiting for a response. A response is sent in a separate communication back to the originator. The response might be generated after a few seconds, a few hours, or even a few days depending on the business rules.

Synchronous communication, due to its nature, adds more requirements on both the server and the client than asynchronous communication. The server MUST process the received message and return a response within the preset time window, or return an error message.

One-Way vs. Two-Way

In compliance with the WS-I Basic Profile 1.1, STAR currently uses HTTP as the underlying transport protocol for Web Services. And, thus, follows the same request-based model. In a request-based model, the client always initiates the communication and the server always sends the responses on the same TCP connection to the IP address from which the request originated. This model works well with web services and especially with low-end clients that do not have a fixed IP address or the infrastructure to support inbound requests.

In a one-way, request-based communication model, only the service provider is required to have a fixed IP address and the necessary hardware and software to listen to incoming messages. The client, on the other hand, can be very simple and can use any type of Internet connection, even those that do not provide a static IP address.

Due to its low requirements on the client end, the request-based model is suitable for dealer-to-OEM communication.

To achieve a two-way communication model, the original one-way model is duplicated in reverse: the client exposes the same set of web services and becomes a service provider too. This way, both sides are clients and service providers at the same time and they both can initiate requests to the other side. Based on business requirements and the agreement between the two parties, the client might chose not to implement the full set of functionality as the server to keep the implementation simple.