Implement ForwardResponseToService Sink And All Its Implications

MZS Schema Change:
- Add configuration for ForwardResponseToServiceSink
  (add parameters in mzs:DeliveryRequest/Config)
- Add sink configuration in application.yaml, convert from Spring
  Environment to ConfigType, and merge ConfigTypes.
- Validate sink configuration completeness.

Contract added:
- Add contract mzs2app.wsdl: This contract specifies how
  mzs:DeliveryRequestStatus' and mzs:DeliveryNotifications are
  forwarded to the sender application.
- Implement "ForwardResponseToService" Sink.
- Add and implement MsgResponse.sendToMzsClient() : This is a somewhat
  unfortunate solution because, intuitively, sending should be done by
  it's caller, the "ForwardResponseToService"-sink. However, this
  solution prevents differences between msg:DeliveryRequestStatus and
  msg:DeliveryNotification (and code that needs to handle differences,
  i.e. sending) from sprawling outside of the respective MsgResponse
  derivatives. We move the entire "send" process into MsgResponse to
  prevent a hard-to-maintain "if type == notification then do x else
  to y" construct in ForwardResponseToServiceSink. Otherwise,
  introducing the MsgResponse wrapper was pointless.

1 files changed, 9 insertions, 0 deletions

diff --git a/src/main/resources/application.yaml b/src/main/resources/application.yaml
index 2d0bed3..53d1951 100644
--- a/src/main/resources/application.yaml
+++ b/src/main/resources/application.yaml
@@ -36,6 +36,15 @@ delivery-request-configuration-profiles:
         active: false
         path: /msg-responses/
       log-response: true
+      forward-response-to-service:
+        active: false
+        mzs-client:
+          # TODO: ensure that only one url is needed to
+          # sent DeliveryRequestStatus / DeliveryNotifications
+          url: http://service.which.implements.mzs2app.wsdl/services/
+          # connection-timeout
+          # receive-timeout
+          # ssl...
 
   ssl-profile:
     msg-client: