I'd like to use UML to draw a high level diagram of my system's message driven architecture.
I am struggling to identify the correct diagram to draw a system of EIP microservices which exchange messages via message channels.
Which UML diagram is most appropriate for this?
When you say EIP, I assume you mean Enterprise Integration Patterns, I.e. a varied collection of patterns for enterprise application integration such as Message Router, Message Broker, Message Channel, Service Call and so on, as documented in several popular books and papers. If this is the case, then your reference to the Message Channel pattern makes sense and I think I understand what you mean.
The UML is a general-use language set, and can be used to represent many different aspects of your architecture, so the answer to your question depends on what you are attempting to show and at what level of abstraction. If your focus is on messaging (message timing, ordering and so on) then you need to use one the the behavioural languages within the UML; if you want to represent messages (structure, types, content etc) then you can do so with a structural language. The answer from 8bitjunkie suggests Communication Diagrams for the behavioural side, but you could also use Sequence Diagrams, Activity Diagrams and State Charts depending on your focus/need. Sequence Diagrams allow you to identify timing aspects more clearly than Communication Diagrams. For message structure I'd recommend Class Diagrams. The UML can also be extended through Tagged Values and Stereotypes to include much greater specificity and add structured detail if you would like; there is no real limit to the structured information you can capture in a UML model.
From the introduction of enterpriseintegrationpatterns.com:
The UML Profile for EAI [UMLEAI] enriches the semantics of collaboration diagrams to describe message flows between components. This notation is very useful as a precise visual description of a system that can serve as the basis for code generation as part of a model-driven architecture (MDA).
Collaboration diagrams are replaced in UML 2 with Communication Diagrams
However the introduction of enterpriseintegrationpatterns.com goes on to say:
We decided not to adopt this notation... {because} ...the UML Profile does not capture all the patterns described in our pattern language.
At the current time of writing (April 2019), it appears that the last time that the EAI profile for UML was published was March 2004. This predates the excerpts from enterpriseintegrationpatterns.com, which according to the way back machine was first published in August 2015.
This suggests that UML 2 is ill-equiped to describe message-driven system architectures which embody EIPs.
You can use a component diagram and/or a composite structure diagram. If, in your case, each microservice is instantiated only once, then you only need one of these diagrams. Otherwise, it would be good to have a component diagram show the class level and a composite structure diagram show the instance level. See question Component diagram dependency vs assembly.
A message queue can be modeled as a separate component with stereotype <<queue>>, or as an interface with stereotype <<queue>>. Modeling a queue as a separate component is the best choice if the queue is not owned by one service. However, if it is owned (only one service puts/publishes messages on it), then a separate queue-component clutters the diagram and it would be better to model it as an interface, provided by the message producer and required by the message consumers.
