Asymmetric web service architecture

In the asymmetric web service architecture, only one partner can start the communication, by calling the second partner's web service. The main benefit of the asymmetric web service architecture is that only one of the partners needs to host a server.

However, the asymmetric web service architecture leads to an increased number of messages from one business partner seeking to determine if anything has changed at the other business partner. For example, instead of getting informed about an update, one of the partners needs to keep asking if there is an update and this needs to be done frequently (for example, every 10 minutes) until an update has been posted.

DDEX's asymmetric web service architecture for ERN does not provide the full set of messages. To gain the full power of using web services, implementers will need to implement the symmetric web service architecture.

There are calls providing information and calls requesting a specific action.

Lifecycle of a Release using asymmetric web service calls

The diagram below demonstrates the lifecycle of a release using asymmetric web service calls. It is described as follows:

• The ReleaseAvailabilityRequestMessage (2) can be used to request an ERN XML from a partner;

• The response is either the ERN XML for the requested release, or if it is not available for pick up yet the status of this release in the message recipient's supply chain;

• A list can be requested using the OrderedReleasesInQueueRequestMessage (1). The result of this call is a report, the feedback is performed asynchronously and the report is delivered to a predefined (S)FTP location;

• In the asymmetric web service choreography, there is no call to inform the partner that the report got created and is ready for pick up. The receiver of the report needs to check for its status;

• If something happened to the resource files of the ERN XML, a RedeliveryRequestMessage (3) can be used to request the release be redelivered. There is no need to pick up the phone and ask somebody for the redelivery;

• After the files are ingested the SupplyChainStatusMessage (4) can be used to inform the partner of the status of the release in the system, for example, everything is ingested and the release is on the DSP’s service.

There are many more messages that can be deployed and the full list and a detailed description of each is set out in the standard.