Skip to content

Message Exchange Patterns

There are several message exchange patterns supported by Service Virtualization:

  • One-way
    • The client sends request to service and does not expect any correlated response.
    • When the service produces some message in a consequence of the request, it is usually published as another one-way message.
    • The service scenarios in service model provide a good way to describe this communication pattern as a sequence of operation where some of them have only request and others have only response.
  • Request-response
    • The client sends request to service and receives a correlated response from service.
    • The response is received either through the existing communication channel used for sending the request (i.e. in HTTP) or there is a correlation information (i.e. the messageId, correlationId headers) present in messages allowing coupling of responses received through asynchronous channel to corresponding request.
  • Solicit response
    • The service requests data from client by sending it a message that goes in a response direction (from service to client) but it is not correlated to any previous client request. The client responds with message sent in a request direction (from client to service) that is correlated to the message received from service. The service may continue with one or more responses correlated to that client message.
    • You can think of this pattern as a request-response in reverse.
    • SV supports this message exchange pattern both in simulation and in invocation mode.

Mode of virtual service

  • FORWARD_TO_REAL_SERVICE
    • Request is received by SV on virtual request endpoint. The message is learned and sent to real request endpoint with reply-to set to configured real response endpoint.
    • The real service then sends response back to real response endpoint where SV receives it, learns it and sends to the remembered reply-to from request or to the virtual response endpoint if a static routing is used.
    • In this case the virtual response endpoint is not needed when the client provides reply-to information.
  • SIMULATE_SERVICE
    • SV listens on virtual request endpoint and passes received messages to simulator.
    • Any messages generated by simulator will be sent to the reply-to target or to the virtual response endpoint when using static routing.
  • INVOKE_REAL_SERVICE
    • SV sends messages generated by simulator to the real request endpoint while setting the reply-to header to the real response endpoint.
    • SV listens for messages from real service on the real response endpoint and passes received messages to simulator so it can compare them to scenario calls and process simulation variables bound to responses.