This article is under development and will be subject of further modification after collecting more feedback from software developers and OPC Foundation.
Semantic-Data
over 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.body
(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.
properties
section 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.message-id
message-id
, if set, uniquely identifies a message within the message system. The message producer is usually responsible for setting the message-id
in such a way that it is assured to be globally unique. An intermediary may discard a message as a duplicate if the value of the message-id
matches that of a previously received message sent to the same node.user-id
to
subject
reply-to
correlation-id
content-type
content-encoding
absolute-expiry-time
creation-time
group-id
group-sequence
reply-to-group-id
content-type
:For clarity, as per section 7.2.1 of RFC-2616, where the content type is unknown thecontent-type
should 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, thecontent-type
should be set toapplication/octet-stream
.When using anapplication-data
section with a section code other than data,content-type
should not be set.content-encoding
:Thecontent-encoding
property is used as a modifier to thecontent-type
. When present, its value indicates what additional content encodings have been applied to theapplication-data
, and thus what decoding mechanisms need to be applied in order to obtain the media-type referenced by thecontent-type
header field.content-encoding
is primarily used to allow a document to be compressed without losing the identity of its underlying content type.content-encoding
properties are to be interpreted as per section 3.5 of RFC 2616. Validcontent-encoding
properties are registered at Hypertext Transfer Protocol (HTTP) Parameters.Thecontent-encoding
must not be set when theapplication-data
section is other than data. The binary representation of all otherapplication-data
section 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 multiplecontent-encoding
values except as to be compatible with messages originally sent with other protocols, e.g. HTTP or SMTP.
application-properties
section 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.NetworkMessage
structures to a selected AMQP Node.NetworkMessage
structure, which is polled from the selected AMQP Node.properties
properties
sections 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
ua-data
or ua-metadata
.content-type
subject
: defines the type of the message contained in the AMQP body
. A value of ua-data
specifies that the body
contains a UADP or JSON NetworkMessage
. A value of ua-metadata
specifies that the body
contains a UA Binary or JSON encoded DataSetMetaData
message.content-type
: specifies whether the message is binary or JSON data. OPC.UA.PubSub specification defines two possible encodings for the NetworkMessage
structure and is encoded depending on the selected encoding mapping as defined for the:content-type
is application/json
.content-type
is application/opcua+uadp
.application properties
application properties
sections are part of the AMQP Bare Message
used 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 :
3.2.4Properties
: Immutable properties of the message 3.2.5Application 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.
data
data
section is part of the AMQP Bare Message
and is contained in the body
section. The data
section shall be used to transfer the NetworkMessage
.NetworkMessage
that exceed the max-message-size limits depends on the encoding.MP NOTE:This functionality is an open issue reported to OPC Foundation: 0004269: Part 14 PubSub Section 7.3.4 it is not clear how to deal with long messages.;MP NOTEIt has been be reported to OPCF:For UADP encoding the specification requires:It is recommended that the MetaDataQueueName as described in 6.4.2.3.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$Metadata
is 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.
amqps://<domain name>[:<port>][/<path>]
wss://<domain name>[:<port>][/<path>]
AuthenticationProfileUri
of the PubSubConnection
, DataSetWriterGroup
, DataSetWriter
or DataSetReader
entities. If no authentication information is provided in the form of ResourceUri
and 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
BrokerTransportQualityOfService
values as follows:MP Note:This mapping requirements must be reviewed against AMQP specification. It seems that theBrokerTransportQualityOfService
is defined by the configuration model and not exist if this model is not used.
Keep Alive
KeepAliveTime
is 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 KeepAliveTime
is specified, the implementation should set a reasonable default value.MP NOTEIt must be explained what the connection means. The AMQP define connection for:
Containers session Link.