Mediation services get the data from one service and distribute it amongst more than one target service. These services receive the data, may normalize data or transform data with respect to a common data model, enrich the data by adding new fields or filling up the empty fields in the transformed data, and perform filtration based on some attributes before forwarding the data to a set of target services or not, and then ultimately calling the sets of target services.

For our sample scenario, we have one mediation service, which is Document Submitter. This service receives the data, and is supposed to call various other target services like other authorities through B2B and third-party channel services, or may send e-mails to trigger the manual processes. In calling the target endpoints, it might need to transform the data into the target format, enrich the data with some more fields like license keys, registry information, and authority-specific authentication mechanism, and filter the payload so as not to send the data all the time to all services, but only to limited desired targets:

As you can see, this service is very specific to the actual requirements, so we cannot give the sample code, but understanding this scenario, one can imagine how the code would look like. There is no sample code for Document Submitter. As you can see in the preceding the diagram, an experienced engineer can realize that the implementation of a Document Submitter mediation service is very specific to the actual requirements in which target services it will be calling eventually.