Which ActiveMQ properties/settings should be stated in an interface specification document?

1
votes

A customer wants to exchange data between his application and our application via ActiveMQ, so we want to create an Interface Specification Document which describes the settings and properties that both applications must use so that they can communicate. We don't know which programming language or API the customer will use; so if the specification is incomplete they might implicitly use settings that we don't expect.

So I'm wondering which settings must be the same on both sides, and which settings can be decided by each application on its own. This is what I have so far:

Must be specified in document:

  • connector type (openwire, stomp, ...)
  • connector settings (host name where broker runs, TCP port, user name, password)
  • message type (TextMessage, BytesMessage...)
  • payload details (XML with XSDs, JSON with schema, ...)
  • message encoding (UTF-8), for text payload
  • use queues, or topics, or durable topics
  • queue names
  • is any kind of request/response protocol being used
    • use single queue for requests and responses (with selectors being used to get correct messages), or use separate queues for requests and responses
    • how to transfer correlation ID used for correlating requests and responses
  • message expiration

Must not be specified in document:

  • ActiveMQ broker version (all versions are compatible, right?)
  • message compression (it should be transparent?)

What did I miss? Which things should be stated in such a document to ensure that two applications can communicate via ActiveMQ?

1
interfacelanguage-agnosticactivemqcommunicationspecifications

1 Answers

1
votes

What did I miss?

You missed message headers. These can be broken into two categories:

  1. Built-in (JMS) headers
  2. Custom headers

Examples of the built-in headers are things such as JMSMessageID, JMSXGroupID, etc. In some cases, your interface definition will need to include details of whether and how these values will be set. For example, if messages need to be grouped, then any message producer or consumer using the definition will need to be aware of this.

Similarly, if there will any custom headers (common uses include bespoke ordering, source system identification, authorization tokens, etc.) attached to the messages need to be part of any interface definition.

In fact, I would argue that the interface definition only needs to include two things:

  • a schema definition for the message body, and
  • any headers + if they are required or optional

Everything else you have listed above is either a deployment or a management concern.

For example, whether a consumer or producer should connect to a queue or topic is a management concern, not an interface concern. The address of the queue/topic is a deployment concern, not an interface concern.