MWN choreography

The MWN standard defines two choreographies.

Secure File Transfer Protocol

If the MWN messages are to be exchanged using SFTP the following "helper messages" are defined in this standard:

The arrival of the batch on an SFTP server is signified by placing a manifest file at the appropriate location. The manifest file refers, all files that are part of the batch. The manifest may only be placed on the SFTP 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 SFTP server and other issues such as batch sizes.

Web Service Choreography

The standard defines two Web Service choreographies:

• One where the information is exchanged directly between a licensee and a licensor directly; and

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

In both cases, two interfaces are defined:

• The interface offered by a company that wishes to receive MusicalWorkRightsClaimRequestMessage from its business partners; and

• The interface offered by company that wishes to receive MusicalWorkRightsClaimNotificationMessage 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.

 Only the Licensor has published a Web Server

• The licensee calls the web service endpoint published by the licensor using the POST ClaimRequest call with a MusicalWorkRightsClaimRequestMessage;  

• The licensor replies to this call with a MusicalWorkRightsClaimNotificationMessage or a holding message which informs the licensee that the information will be provided at a later stage;

• The licensee regularly calls the licensor’s web service with a GET ClaimNotificationList call. 

• The licensor replies to this with an Atom feed providing a URL for all MusicalWorkRightsClaimNotificationMessages that are ready to be collected; and

• The licensee can then call the licensor's GET ClaimNotification  Web Service endpoint for each URL provided which the licensor will respond with the requested MusicalWorkRightsClaimNotificationMessage.

 Only the licensee has published a Web Server

• The licensor calls the Web Service endpoint published by thelicensee using the GET ClaimRequestList call;

• The licensee replies to this call with an Atom feed providing a URL for all MusicalWorkRightsClaimRequestMessages that are ready to be collected;

• The licensor calls the licensee’s web service with a GET ClaimRequest call for  each URL provided;

• The licensee replies to this call with a MusicalWorkRightsClaimRequestMessage;  and

• The licensor can call the licensee’s POST ClaimNotification Web Service endpoint with the requested MusicalWorkRightsClaimNotificationMessage once it has assembled the information.

 Both parties have published a Web Server

• The licensee calls the Web Service endpoint published by the licensor using the POST ClaimRequest call with a MusicalWorkRightsClaimRequestMessage;  

• The licensor replies to this call with a MusicalWorkRightsClaimNotificationMessage or a holding message which informs the licensee that the information will be provided at a later stage; and

• For each claim request that has not been able to be fulfilled immediately, the licensor can call the licensee’s POST ClaimNotification Web Service endpoint with the requested MusicalWorkRightsClaimNotificationMessage once it has assembled the information.

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