Age | Commit message (Collapse) | Author | Files | Lines |
|
- Reason: Components, which rely on one of those, usually also rely on
the other, so merging them reduces amount of dependencies.
- Frame operations in DeliveryRepository API as "store" and "retrieve"
operations.
- Rename: Convert *Id in local variable names to upper case.
|
|
StoreSOAPBodyBinaryInRepositoryInterceptor:
- Replace "generate body's id via concatenation" with "give the right
generator function the app delivery id and let the generator
function do the work". Reason: Prevent the logistics of deriving IDs
to spill into unrelated components.
MsgResponse refactor:
- Make MsgResponse an abstract class.
- Derive ResponseID's ONLY in MsgResponse::createResponseID.
Others:
- Ensure that all invocations to DeliveryRepository.getResponse and
BinaryRepository.get use "responseID" instead of ambiguous "id" or
incorrect "appDeliveryID".
- Move SingleThreadedDeliveryPipeline into process package.
|
|
- 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.
|
|
- Resolve nested try-catch blocks
- Log error if error occurs
- MoaSPSSSignatureVerifier: Replace string concatenation with format strings
|
|
- Interpret `ISignatureVerificationService` response properly (by
following security layer spec [1] and moaspss handbook [2]).
- Add config flag `moa.spss.is-manifest-check-active`
- Change SignatureVerifier Interface: Remove @return boolean, just
throw an exception when a validation error occurs. Reason: In case
the signature cannot be validated, the application always needs the
reason for the validation error, which requires the verifier to
throw an exception. In turn, the only valid return value for
`verify()` becomes `true`, which can be omitted at that point.
- Add testcase for verifying a valid enveloped xml signature
- Remove Certificates that are not needed.
[1] https://www.buergerkarte.at/konzept/securitylayer/spezifikation/20140114/core/core.html
[2] https://apps.egiz.gv.at/handbooks/moa-spss/handbook/handbook/usage/usage.html
|
|
|