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.

0 files changed, 0 insertions, 0 deletions