I'm looking for a way to clearly diagram how multiple applications communicate via a service bus. The best I've come up with so far is a sequence diagram, but I really don't like that. Sequence diagrams necessarily relate some sort of sequence, and that's really not what I want. Furthermore, since every service communicates with the service bus and sequence diagrams place each service on a separate column, as the number of services increases, you end up with a lot of overlapping arrows.

For example, given 4 services FOO, BAR, BAZ, and QUX:

  • FOO publishes messages of type publish and regen.
  • BAR publishes messages of type requeue.
  • BAZ subscribes to messages of type publish, regen, and requeue, and publishes messages of type transmit.
  • QUX subscribes to messages of type transmit.
  • Any service can publish any message type at any time (there is no implied sequence).

What kind of diagram should I use to clearly and unambiguously represent this information?

Here's the best I've come up with so far:
Sequence diagram

1 Answer 1


I'm looking for a way to clearly diagram how multiple applications communicate via a service bus.

That would be awesome. Unfortunately, I don't think it is possible for configurations of any complexity. A sequence diagram for simple scenarios is probably as good as anything else.

Components on a bus both publish and subscribe to messages. Some of the messages may be causally related, forming a protocol. It it difficult to show this graphically, especially the causal relations, when there is more than one protocol in play on the bus.

Electrical bus diagrams have been around for a long time

electrical bus diagram

but they deal with a quantity of a uniform commodity (electrical power) not discrete signals.

I like to show messages sent (on the right) and received (on the left) by each component (and the subchannel/topic structure, if applicable), but again for anything but the simplest of scenarios the diagrams quickly become cluttered and nearly useless.

enter image description here

So let's go back to a more fundamental question: what is the purpose of the diagram? What are you trying to show?

If you are trying to show causal relations between components and messages, then diagramming one protocol at a time using a sequence diagram (or equivalent) should be fine.

If you just want to show the protocols for reference, then putting messages sent and received by each component should be sufficient documentation, but causal/temporal relationships are lost.

Good luck, and please let us know if you find or invent anything better!

  • Thanks for taking the time to respond. For complex orchestrations of messages ('conversations' within 'protocols') yes, sequential diagrams are fine. But at the moment I'm trying to tackle a high-level overview of what service are responsible for publishing a given message type and what services may be affected by a given message type, not really the sequence of messages involved. I'm hoping for something standardized, but if I end up inventing my own, it would probably look a lot like the electrical bus diagram you gave as an example.
    – p.s.w.g
    Aug 22, 2013 at 20:14
  • @p.s.w.g: you're welcome. Added example diagram, built using Balsamiq Mockups. I use small circles to make the connection points stand out, in case I need to annotate gateways or other constraints Aug 22, 2013 at 20:29
  • Yeah something like this would work. I think I prefer the little arrows in the electrical diagram to having a left/right distinction, but this gives me some ideas.
    – p.s.w.g
    Aug 22, 2013 at 20:41
  • @p.s.w.g: i found the little arrows got in the way for larger diagrams ;) Electrical components rarely (that i've seen) consume and produce power, so the arrows are static. That's why I went with the left/right distinction (arbitrarily). I also try to put incoming messages closer to the box for the component, and outgoing messages closer to the bus line - but it's definitely not an ideal solution. Looking forward to seeing what you come up with! Aug 23, 2013 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.