This article is under development and will be subject of further modification after collecting more feedback from software developers and OPC Foundation.
Semantic-Dataover the Advanced Message Queuing Protocol (AMQP) to be compliant with the specifications mentioned in the section Normative references.
Connections, channels, and sessions are ephemeral. If the underlying connection collapses they must be reestablished.
Links are named, and the state at the node can live longer than the connection on which they were established. A link is unidirectional. A link is created in a session, identified by a unique name, and attached to a node specified by an address. The link is created inside an AMQP Session and, thanks to the multiplexing feature of AMQP protocol, the same session can be used for many links all inside the same TCP connection.
header: the Transport headers for a message.
delivery-annotations: delivery-specific non-standard properties at the head of the message.
message-annotations: properties of the message which are aimed at the infrastructure and should be propagated across every delivery step.
properties: immutable properties of the message.
application-properties: structured application data. Intermediaries can use the data within this structure for the purposes of filtering or routing.
application-data): consists of one of the following three choices:
data: contains opaque binary data.
amqp-sequence: a sequence section contains an arbitrary number of structured data elements.
amqp-value: contains a single AMQP value.
footer: details about the message or delivery which can only be calculated or evaluated once the whole bare message has been constructed or seen (for example message hashes, HMACs, signatures and encryption details).
Not all fields are exposed in the library API of the AMQP stack.
propertiessection is used for a defined set of standard properties of the message. The properties section is part of the bare message; therefore, if retransmitted by an intermediary, it must remain unaltered.
content-type:For clarity, as per section 7.2.1 of RFC-2616, where the content type is unknown the
content-typeshould not be set. This allows the recipient the opportunity to determine the actual type. Where the section is known to be truly opaque binary data, the
content-typeshould be set to
application/octet-stream.When using an
application-datasection with a section code other than data,
content-typeshould not be set.
content-encodingproperty is used as a modifier to the
content-type. When present, its value indicates what additional content encodings have been applied to the
application-data, and thus what decoding mechanisms need to be applied in order to obtain the media-type referenced by the
content-encodingis primarily used to allow a document to be compressed without losing the identity of its underlying content type.The
content-encodingmust not be set when the
application-datasection is other than data. The binary representation of all other
application-datasection types is defined completely in terms of the AMQP type system.Implementations must not use the identity encoding. Instead, implementations should not set this property. implementations should not use the compress encoding, except as to remain compatible with messages originally sent with other protocols, e.g. HTTP or SMTP.Implementations should not specify multiple
content-encodingvalues except as to be compatible with messages originally sent with other protocols, e.g. HTTP or SMTP.
application-propertiessection is a part of the bare message used for structured application data. Intermediaries can use the data within this structure for the purposes of filtering or routing.
NetworkMessagestructures to a selected AMQP Node.
NetworkMessagestructure, which is polled from the selected AMQP Node.
propertiessections are part of the AMQP
Bare Message. The table below describes how the selected properties of the message are populated when an AMQP message is constructed.
subject: defines the type of the message contained in the AMQP
body. A value of
ua-dataspecifies that the
bodycontains a UADP or JSON
NetworkMessage. A value of
ua-metadataspecifies that the
bodycontains a UA Binary or JSON encoded
content-type: specifies whether the message is binary or JSON data. OPC.UA.PubSub specification defines two possible encodings for the
NetworkMessagestructure and is encoded depending on the selected encoding mapping as defined for the:
application propertiessections are part of the AMQP
Bare Messageused for structured application data. Intermediaries can use the data within this structure for the purposes of filtering or routing.
MP NOTES:The AMQP message properties shall include additional fields defined on the WriterGroup or DataSetWriter through the KeyValuePair array in the WriterGroupProperties and DataSetWriterProperties. The NamespaceIndex of the QualifiedName in the KeyValuePair shall be 0 for AMQP standard message properties. The Name of the QualifiedName is constructed from a message prefix and the AMQP property name with the following syntax ...AMQP defines two kinds of properties :
Properties: Immutable properties of the message
Application Properties: Intermediaries can use the data within this structure for the purposes of filtering or routing. The PubSub Application cannot be recognized as the intermediary.Is not clear which one and how to implement this requirement.
datasection is part of the AMQP
Bare Messageand is contained in the
datasection shall be used to transfer the
NetworkMessagethat exceed the max-message-size limits depends on the encoding.
MP NOTE:MP NOTEIt has been be reported to OPCF:For UADP encoding the specification requires:It is recommended that the MetaDataQueueName as described in 220.127.116.11.6 is configured as a sub-topic of the related QueueName with the name $Metadata.Unfortunately the AMQP does not define the terms: 'sub-topic' and QueueName. It is also not clear if
$Metadatais terminal symbol or refers to somethings else.MP NOTE:For MQTT the following limitation is stated:
The messages sent through MQTT are limited to one per Application Message, but for AMQP it is not present.
DataSetReaderentities. If no authentication information is provided in the form of
AuthenticationProfileUri, SASL Anonymous is implied. If the authentication profile specifies SASL PLAIN authentication, a separate connection for each new Authentication setting is required.
MP NOTE:This requirements are not clear because it is not related to Publisher/Subscriber interoperability- it is not common knowledge necessary to communicate over AMQP. This parameter could be relevant for the PubSub Application and Container interoperability. This section must be revisited after getting more.
Quality of Service
BrokerTransportQualityOfServicevalues as follows:
MP Note:This mapping requirements must be reviewed against AMQP specification. It seems that the
BrokerTransportQualityOfServiceis defined by the configuration model and not exist if this model is not used.
KeepAliveTimeis set on a
WriterGroup, a value slightly higher than the configured value of the group should be used as idle timeout of the connection ensuring that the connection is disconnected if the keep alive message was not sent by any writer. Otherwise, if no
KeepAliveTimeis specified, the implementation should set a reasonable default value.