anchor.diff:  image::webapp/src/main/webapp/images/overview.png[link="https://raw.githubusercontent.com/isisaddons/isis-module-publishmq/master/webapp/src/main/webapp/images/overview.png"]
   
   
  -One of the design objectives for the PublishMq module is to allow the ActiveMQ queue (and therefore any Camel routing) to be either embedded (as in the example app) or to be remote.  This is one of the reasons why the payload posted to the queue is the XML representation of a JAXB object (the `ActionInvocationMemento`).
  +One of the design objectives for the PublishMq module is to allow the ActiveMQ queue (and therefore any Camel routing) to be either embedded (as in the example app) or to be remote.  This is one of the reasons why the payload posted to the queue is the XML representation of a JAXB object (the `InvocationDto`).
   
   To make the example app easier to run, the fake SOAP service representing the external system is actually deployed as a CXF servlet within the example app itself, mounted at `/soap/ExternalSystemAdapter/DemoObject`.   It exposes an API for the Camel routing to post to, and also exposes a query API that simply lists the messages received.  Of course, "in real life" this external system would be running somewhere else on the network (as the diagram shows).
   
  
positive.code:   </route>
  </camelContext>
  ----
  <1> subscribe to ActiveMQ for incoming action invocation events (in XML form).  This uses the internal `vm://` protocol for speed
  <2> unmarshal to a (JAXB annotated) `InteractionDto` object
  <3> using the `AddExchangeHeaders` component provided by this module to add the metadata from the `InteractionDto` to the Camel message.  This allows the message to be routed
  <4> use Camel to select which sub-route to following, using...
  
negative.code: 
  [WARNING]
  ====
  The above screenshot is out-of-date, showing the format of the `aim.xsd` for 1.12.x, rather than `ixn.xsd` for 1.13.x
  ====
  
  
  