Implement Zuse2App Services

- Add zuse2app.wsdl contract.
- Add MsgResponse as an type-agnostic view for DeliveryRequestStatus
  and DeliveryNotification messages. Reason: Both DeliveryNotification
  and DeliveryRequestStatus messages have similar fields and need to
  be treated similarly (e.g.: receive from msg service, store to
  repository, verify signature, store to file...). In order to prevent
  duplicated code, the wrapper interface provides a type-agnostic view
  onto these messages for depending components to operate on.
- Add MsgResponseHandler interface; decides how to process
  MsgResponse. Also implement this handler with a multi-threaded
  single-node implementation.
- Add MsgResponseSink interface; decides how to archive MsgResponse.
- Implement and test SafeResponseToFileSink.

Change Identifier for MsgResponses:
- Before, DeliveryRequestStatus and DeliveryNotifications had their
  own repositories. Now, both types are stored in the same repository
  (the MsgResponse repository) to streamline the handling of
  MsgResponses. We need to change the identification of MsgReponses,
  otherwise the identifiers (AppDeliveryID) clash.
- MsgResponses are not identified by:
  <AppDeliveryId>+<typeSpecificSuffix>
- Rewrite StoreSOAPInterceptor to accommodate fact that, both
  DeliveryRequestStatus and DeliveryNotification messages have
  different IDs upon storage / retrieval.

Restructure packages and components as follows:
- client: All components that are involved when consuming a web service.
- process: "fabric" of MoaZS; contains business logic that
  orchestrates back-end tasks of MoaZS's operational services, e.g.:
  by processing a delivery request.
- service: Implementation of MoaZS's front-end services.

Refactoring:
- MoaZSException: Remove unused fields. Before: Store mzsrequest,
  tnvzresult, msgrequest and msgresult as members. Now: Only keep the
  fields that are needed later, e.g for generating a
  msg:DeliveryRequestStatus element. Add copy constructor to Builder.
- Put storage of byte[] into a dedicated "BinaryRepository". Reason:
  This was useful in a former design. Now it's not really needed
  anymore.
- Put "create Endpoint" code into EndpointFactory. Reason: Eliminate
  duplicated code when configuring a service.

Testing:
- Activate Stacktraces in surefire.

0 files changed, 0 insertions, 0 deletions