ArchiMate constructs: representing point-to-point and publish-subscribe messaging
Representing data-oriented interconnections
We have identified three alternative ArchiMate constructs for representing a data-oriented interconnection. Our preference is to use a single ArchiMate element to model one real-life entity which determines the interconnection. The alternative representations for that entity (and its relationships) are the following:
- Use a Technology Service element and use Flow relationships to attach Application Components. The direction of the flow denotes the flow of data.
- Use a Data Object element and use Access relationships to attach Application Components. Components can either read, write or read-and-write data (the Access type).
- Use an Artifact element and use Access relationships to attach Application Components. Components can either read, write or read-and-write data (the Access type).
Representing interconnections realized through point-to-point and publish-subscribe messaging
The meta-models for point-to-point and publish-subscribe messaging:
The element representing the object that holds messages (queue or topic) will be stereotyped with <<queue>> or <<topic>> respectively, and the name of the element will be the name of the object it represents.
We have noticed that the pros and cons of a representation do not differ either we are modeling queues or topics, so we shall discuss them together.
Using Technology Service elements to represent queues and topics
In this representation, the Flow relationship denotes the role of the attached component. The message producer and the message publisher are attached as data sources, while the message consumer and the message subscribers are attached as data sinks.
PROS
- The Technology Service element representing the queue / topic emphasizes the use of additional services of a messaging system.
CONS
-
In this construct, the Technology Service element is used to denote the service associated with a specific object (a single queue or a single topic), which may be misleading. Implicitly, the actual technology service is being provided by a messaging system (middleware) and it is common to view such services more broadly, like "queuing services" or "publish/subscribe" services.
-
The view includes an element from the ArchiMate Technology Layer and therefore does not conform to the Application Cooperation viewpoint.
Using Data Object elements to represent queues and topics
The Access relationship is used for all attachments. The message producer and the message publisher use the write access, while the message consumer and the message subscribers use the read access.
PROS
- The use of the Data Object element emphasizes messages: producers / publishers are creating messages (data objects) which are subsequently read by consumer / subscribers.
- The view conforms to the Application Cooperation viewpoint.
CONS
- The use of the Data Object element could be misleading as that element is not intended to represent a queue or topic (an entity supporting the exchange of messages) but rather messages as such.
Using Artifact elements to represent queues and topics
The Access relationship is used for all attachments. The message producer and the message publisher use the write access, while the message consumer and the message subscribers use the read access.
PROS
- The Artefact element is likely the most appropriate choice to represent queues and topics. Queues and topics are comparable to files and database tables.
CONS
- The view includes an element from the ArchiMate Technology Layer and therefore does not conform to the Application Cooperation viewpoint.