The choreography enabled by this standard is depicted in the two diagrams below. The actions on both sides (represented by red boxes) are exemplary only and only represent a typical information exchange in accordance with this standard. It comprises of these steps:
- A Release Distributor contacts the Release Creator by accessing its web service end point using a secure HTTPS connection, asking for a list of Releases that are available for it;
- The Release Creator responds with an Atom feed page containing a series of Atom feed entries.
Each of these entries provides a brief description of a Release plus a URL that can be used by the Release Distributor to obtain the Release.
The Release Creator should only make available an Atom feed entry for a Release, once it can deliver the relevant
NewReleaseMessageand its Resources.
The Release Creator should also take care that at no time more than one
NewReleaseMessagefor the same Release appears in the Atom feed.
As a consequence, a Release Creator should remove entries from its Atom feed as soon as it needs to update a
NewReleaseMessagethat is referenced in the Atom feed. The Release Creator should also make sure that the appropriate status code of 404 is returned upon a Release Distributor calling the now outdated
GET ERN Messageor
GET ERN Resourcecall;
- The Release Distributor contacts the Release Creator again by accessing the web service end point using the URL provided in Step 2 using a secure HTTPS connection, to get a
NewReleaseMessageusing the URL provided in the Atom feed entry;
- The Release Creator responds with a
NewReleaseMessagein accordance with the relevant standard as agreed between the Release Creator and the Release Distributor;
- The Release Distributor ingests the
NewReleaseMessageand extracts the URIs for each of the Resources that are part of the Release;
- The Release Distributor downloads and ingests each of the Resources from the Release Creator in the case of network based URIs using the
GET ERN Resourcecall.
- Alternatively, if the URIs specify either a local path managed by the Release Distributor to where the Resources have been pre-delivered or a location on an SFTP server, the Release Distributor obtains and ingests the Resources.
- The Release Distributor informs the Release Creator that it has ingested the entire Release (including its Resorces) by using the
DELETE ERN Messagemethod with the URL used to obtain the
NewReleaseMessagein Step 3.
Figure 1 – Basic ERN Web Service Choreography
Wherever this Clause references the
Figure 2 – Additional Commands in the ERN Web Service Choreography
Specifically not shown in the diagrams is the approach to exception handling.
It is for instance possible that a Release Distributor requests a
NewReleaseMessage based on the information received on an earlier
GET ERN Feed command – but that that
NewReleaseMessage no longer exists at that URL. In that case the response from the Release Creator’s web service could be a “redirect” with a 301 status code which could trigger the Release Distributor to request the Release using the information received in the reply.