The short answer is, Yes. You can make a virtual service meet this requirement.
If the protocol is JMS, set up multiple responses for a given request, set the appropriate Think Spec, and the OOTB features should handle the remainder of the heavy lifting for getting responses on the wire.
If the protocol is HTTP, there are other considerations. HTTP protocol is synchronous (request / response); thus, VSM design considerations come into play. At this time, the HTTP 2.0 spec is unsupported.
Questions:
1) How long is 'some time'? Ex: a few hundred millis, 5 seconds, 2 hours, etc.?
2) Does the service support functional or performance testing?
The most common approach is to set up two or more responses for a given request in your VSI.
Logic is added to the VSM to iterate over the list of responses held by lisa_vse_response. The first response (sync response) in the list is sent from the Responder Step. The first response is synchronous and closes the HTTP connection. After sending the sync response, the VSM loops back and sends the remaining responses (async) using an HTTP or REST step. A responder step is unusable because the connection is closed. Your async responses are technically HTTP Requests at this point. Depending on the amount of time you want to wait, you might add a JSR step containing a Thread.sleep(xxxx) to cause the necessary wait to occur, take the VSE response body from the list and place it in a {{property}} that is used in the HTTP request step. Note: Care should be taken and you need to understand the impact of the service design on your testers if you add sleep time.
For functional testing, with a higher than average TPS expectation, placing the Async logic in a single VSM may cause throughput issues if the service is 'sleeping' for long periods of time in between responses.
An alternative approach is to delegate the job of sending Async responses to a secondary VSM. One might use the Shared Model Map or Persistent Model Map to store the async responses from the list. A Java date timestamp (current datetime + wait time before sending expressed as millis since last epoch) might be the potential Hash key. The secondary service could iterate the model map and determine when it is time to send subsequent responses. The secondary service sends the responses as HTTP requests. If magic dates, strings, etc. are expected in the async responses, you will need to send each response to testExec.parseInState( theResp ) in the primary service before placing the response(s) on the map. The secondary service will have no context on which to extract values from the original incoming request. And, you may need to add logic to determine the Endpoint to send the requests too.
You might also need to deal with what happens when Live Invocation, tracking, and learning modes are used. 'Async' HTTP is not a viable use case for learning and tracking - in my opinion -- because the callback information for the async side is lost.