MWN message exchange

The MWN standard can be carried out using one of two different communication protocols.

File exchange protocol

If the MWN messages are to be exchanged using a file exchange server the following "helper messages" are defined in this standard:

Message Name

Initiating Event

Sender

Recipient

ManifestMessage

A party has finished collating MusicalWorkClaimRequestMessages and/or MusicalWorkClaimNotificationMessages  in accordance with this standard into a batch and wishes its business partner to commence ingesting it.

Sender of "main" messages

Recipient of "main" messages

FtpAcknowledgementMessage

A party receives a batch of messages and then acknowledges receipt of each message (not agreement with its content).

Recipient of "main" messages

Sender of "main" messages

The arrival of the batch on a file exchange server is signified by placing a manifest file at the appropriate location. The manifest file refers to all files that are part of the batch. The manifest may only be placed on the file exchange server, once all other files have been completely uploaded. The standard also includes definitions of folder naming, XML file naming, supporting file naming for the file exchange server and other issues such as batch sizes.

Web service protocol

The standard defines two web service communication methods:

  • One where the data is exchanged directly between the communication partners; and

  • One where the data is exchanged via a central hub.

In both cases, web service interfaces need to be available:

  • Web service interfaces offered by a company that wishes to receive MusicalWorkClaimRequestMessages from its business partners;

  • Web service interfaces offered by a company that wishes to receive MusicalWorkClaimNotificationMessages from its business partners;

  • Web service interfaces offered by a company that wishes to receive MusicalWorkClaimRequestRecallMessages from its business partners; and

  • Web service interfaces offered by a company that wishes to receive MusicalWorkClaimNotificationRecallMessages from its business partners.

Direct choreography

There are a number of approaches, depending on who of the two parties offers a web service. The first two cases are asymmetric in that only one of the two parties offers a web service. These cases are subsets of the hub based choreography. The last case is where both a licensee and a licensor offer a web service and this is, in turn a subset of the asymmetric cases:

All the call messages referenced above are defined in the standard.

Search