UML: Should an asynchronous request-response message exchange be modelled as two ports/interfaces or one

Question

I want to model an asynchronous request-response message exchange in UML.

The request is sent from a client to a server. The server responses asynchronously.

This can be modelled in a component model in two ways:

Option 1

Request and response are two different interfaces with one method each. The server provides the request interface while the client provides the reponse interface. The interfaces are required vice versa. In UML I would model the server and the client as components having one port each. Both ports expose two interfaces: a provided one and a required one which are linked from client to server (request) and from server to client (response).

Option 2

Request and response is one interface with one method. The response is simply the return value of this method. The server provides and the client requires this interface. The message exchange is modelled as link from the client to the server.

I think option (1) is more appropriated for asynchronous exchanges while option (2) is the preferred way for synchronous ones. However, making such a distinction would expose a detail in the component model which actually belongs to the behavioural diagrams.

• Is there any standard or "best practice" to model an asynchronous message exchange in component models?
• If option (2) is the "right" way to do it: how should one specifiy that the client must comply with an interface contract in order to receive a response?

Answer 1

I believe you are correct in the assessment that option 2 is better for synchronous messages and option 1 for asynchronous messages.

By their very nature asynchronous messaging schemes (even if it is solicited) are more complicated to model. Option 1 would be the better option to model the messaging you describe.

I appreciate your concern that using option 1 would include a fair level of detail that may be too much for the diagram in question.

You could model a custom relationship or association (named appropriately, e.g.: <<CustomRqRs>>) and use that to link the components. This simplifies the diagram, better describes the interaction and offers better modelling of the message and response itself.

---

When modelling it is always important to bear in mind that it is primarily there to communicate intent; design, usage, possible implementation, function etc. Simpler is almost always better. Model it accurately, model it well, but keep it simple.