Display messages in queues

Uit Via Nova Architectura Wiki
Ga naar: navigatie, zoeken
Figure 2 02 Most Important relationships between concepts.png ArchiMate Made Practical

Zie ook: ArchiMate in de praktijk


Messages that are received are processed in steps. Each step will change the status of the message. There is a separate queue for each message status in MQ-series, enabling further processing by the same or a different application. Insight is necessary regarding in which queue a message with a certain status is stored in order to be processed by what application. How do you model that?


The solution given here provides a pattern for the above question. It is not an explicit example. The core of the solution is that each queue is modeled as an artifact in the infrastructure layer. These queues are then connected to the queue manager with an assignment relation. The queue manager is system software that is running on a node.

The message with the appropriate status is also an artifact, and is connected to its queue an aggregation relationship. These artifacts realize data-objects in the application layer.

There may be as many queues, messages and data objects modeled as necessary. In the example below there are two, but that can be expanded with any desired number. Queues will typically have more technical names than the names used in the example.

Figure 5 28 Different messages in different queues.png

Figure 5 47: Distinct messages in different queues


If many queues and messages are modeled in this way, the model can become confusing. Also, the message is drawn several times in the application layer, which may suggest that there are several different data-objects. That however is not the case. It is the same logical data-object, but each time with a different status. Physically they are indeed separate XML messages.


When it is important to stress in the model that a message represents the same data-object, there are two alternatives. The first alternative shows the data-object just once. The specific status of the message is then reflected in the access-relationship between the data object and the application. This relationship then models the status.

Figure 5 29 State in an accessrelation.png

Figure 5 48: Describe the status of message in the access relation

Another possibility is to model a message using specializations for the different statuses of the original message. This indicates that on the one hand this is still the same data-object, but on the other hand can be used to explicitly show the different states. The specializations of the data object can be linked to applications. The figure below shows this way of modeling.

Figure 5 30 State as specialisation of a data object.png

Figure 5 49: Describe the status of message via specialisation of data-object

Relationships with other good practices

Refer to good practice 'Difference between system software and artifact'.