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 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.

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.

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

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

I appreciate your concern that using option 2 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.

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 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.