Choosing a message choreography

The sender and receiver of a DDEX formatted message need to agree on the message choreography that will be used for the exchange of those messages. Each of the DDEX standards that specifies an approach to message exchange provides detailed explanations of how this should be set up, and implementers should follow that specification in each case. However, below is general explanation of some of the message exchange issues that these specifications will cover and that implementers need to be aware to achieve the successful exchange of DDEX formatted messages with their business partners.

Cloud-based storage

Most DDEX messages are exchanged using cloud-based storage methods such as file transfer protocol (FTP). DDEX recomments however, that the Secure File Transfer Protocol (SFTP) is used for the exchange of DDEX messages, because it encrypts both the command that executes the file transfer, as well as the data being transferred.

For the sender of the message

Using SFTP, unique upload and download folders should be created according to the choreography for the particular standard you are implementing. Each batch folder is named according to the DDEX file creation date/time. Files containing the messages must be placed in a folder together with a manifest. A folder and file naming convention is generally specified in each standard and must be adhered to. Generally, the manifest is uploaded into the SFTP delivery folder, once all the message files in a batch are uploaded.

Multiple files frequently have to be used to avoid over-large file sizes. It is advisable that file sizes should not exceed 250Mb. Throughout the DDEX standards all incoming and outgoing files follow a standardised, descriptive naming convention, including version and timestamp. This approach reduces the possibility of processing the same file multiple times.

For the receiver of the message

Messages should be ingested in order of the folder timestamp. Once the messages and the manifest have been correctly received the recipient should upload an acknowledgement.xml file. DDEX recommends using acknowledgements when using the SFTP choreographies, to support non-repudiation.

Acknowledgement and non-repudiation

DDEX messages are, in effect, an extension of the commercial contract between the sender and the recipient of the message. It is therefore very important that the sender of a message knows that the message has arrived and can prove that it has arrived. Equally, it is often important for a recipient to be able to show that a specific message has not been received. The benefit of having non-repudiatable messages is particularly relevant for sensitive communications such as take-down notices sent from a record company or distributor to a DSP because, in this case:

• The record company or distributor needs to know that a take-down notice has been received by the DSP so that the record company or distributor knows that its legal obligation are fulfilled, for instance, to the artist that has requested the content to be taken down; and

• Equally, if the content hasn't been taken down, the DSP would want to be able to show that the record company or distributor had not sent the take-down notice and, thus, be able to demonstrate that the fault is not with the DSP.

DDEX's message exchange protocols support non-repudiation. However the SFTP message exchange choreographies in the various standards do not mandate the use of the acknowledgement messages even though it is these acknowledgement messages that deliver non-repudiation.

Web Services

A means of message exchange which is gradually becoming more prevalent when exchanging DDEX formatted messages is the use of web services. This is in part because web services automatically support non-repudiation. There are two approaches that can be adopted using web services.

Asymmetric web service architecture

In asymmetric web service messaging the communication is always initiated by only one partner, which “calls” the web service facility provided by the other partner. These calls can be used to seek specific data or request the other partner to carry out a specific action.

However, this approach can lead to an increased and unnecessary number of messages being sent by the requesting partner. This is because the requesting partner needs to keep regularly asking the other partner if new data has been posted by the other partner until such time as such data has been posted and can be sent to the requesting partner. On the other hand symmetrice web services means that both partners can rely on the fact that once new data is posted it will be communicated to the other partner. This inefficiency does have one major advantage though, which is that there is no need for both partners to host a server.

Symmetric web service architecture

In the symmetric choreography both partners host a server and both are able to initiate the communication. This option greatly reduces the number of messages that are needed to perform the same actions and places more control in the hands of both partners.