6.3.1 Introduction

The approach to the use of a web service protocol for communicating right shares and requests for right shares defined in this clause is asymmetric. Therefore, only one party will publish and maintain a web service. The other party will need call these web services and thus initiate the communication.

As a consequence, it is the party that calls the web service that determines the point in time when the communication takes place. So, whenever that party is able or interested in receiving data, it can call its business partner’s web service. It is then the responsibility of that business party to ensure delivery of the appropriate data.

This 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:

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

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

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

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

Theses communication methods and interfaces are depicted below. Figure 4 depicts a direct communication whereas Figure 5 depicts a hub-based approach. The individual steps in the communication methods are then defined in Clauses 6.3.2 and 6.3.3.

Picture 4.png

Figure 4 – Web service communication – direct communication

Picture 5.png

Figure 5 – Web service communication – indirect communication

Not shown in the diagrams are the recall messages and the approach to be taken with regard to exception handling. It is for instance possible that a licensee requests the delivery of a MusicalWorkClaimNotificationMessage based on the information received on an earlier delivery request command but that that MusicalWorkClaimNotificationMessage no longer exists at that web service URL. In that case the response from the licensor’s or hub’s web service could be a “redirect” with a 301 status code which could trigger the licensee to request the MusicalWorkClaimNotificationMessage using the alternative information received in that reply.