Skip to end of metadata
Go to start of metadata

 

In the asymmetric WebService messaging the communication is always initiated by only one partner, which is calling the WebService provided by the second partner.

This leads to an increased number of messages attempting to receive a changed response. This could lead into unnecessary messages, as instead of getting informed that there is something new, the partner needs to keep asking for news on a high frequency, maybe every 10 minutes to see if anything new has been posted.

This inefficiency does have one mayor advantage: there is no need for both partners to host a server.

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

Asymmetric Web Service Calls

Basic Level

 

Full Level

 

 

Calling

Receiving

Calling

Receiving

DeliveryFrequencyChangeRequestCall

 

 

RedeliveryRequestCall

 

 

ReleaseAvailabilityRequestCall

 

 

SupplyChainStatusCall

 

 

OrderedReleasesInQueueRequestCall

 

 

 

ReportRequestCall

 

 

 

InformationAboutAvailableRelease RequestCall

 

 

 

ReleaseStatusInformationCall

 

 

 



Figure 2: Lifecycle of a Release using asymmetric WebService calls

The ReleaseAvailabilityRequestMessage (2) can be used to request an ERN XML from a partner. Using a specific id inside the call a defined release can be requested. 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. To be able to query for a specific release, the orders that are in queue for the partner have to be known. 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 WebService 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 to 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, e.g. everything ingested, release is up in the shop now… There are many more messages, for a detailed description and the full list please refer to the Release Delivery Choreography Standard.

DDEX's asymmetric web service architecture for Release Deliveries 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

 

  • No labels

1 Comment

  1. Anonymous

    Hi, the text in Figure 2 is not readable, the resolution is too low. Is that possible to fix?