THIS IS A DRAFT.
This is a proposal for some steps to be taken in order to make the KPE architecture more flexible and exploitable.
The proposed tasks are organized under top-level headings below.
Move the responsibility of adding events to the HPA log from the KPE client application to the front-end services
Changes and their purpose
The responsibility for adding events into the HPA log should lie on whichever system component is responsible for performing the task that corresponds to the logged event. For most logged actions the responsible component is a front-end service and thus we should remove the logging functionality for these actions from the client application and implement it in the front-end services.
The following would be accomplished:
- The timestamp problem (noted as critical by ped.partners) can be fixed by making these changes (i.e. making front-end services responsible for both modifying KR data and HPA data, which would enable them to make sure that the timestamps are correct in both).
- This change will result in a more sound architecture by eliminating the possiblity of different client applications performing the same actions (by calling front-end service methods) but logging these actions differently.
We need to determine all the actions that should be logged by the front-end services instead of the client (e.g. see from these lists: "general list", ASDT, VMLE).
Changes to the KPE client
- The front-end services need the user URI in order to log HPA events, which means we need to implement authentication for front-end service calls. The client needs to add the Josso session token into a WS-Security SOAP header for all service calls. This work is done (finalized in SVN changeset 10705).
- The code for initiating HPA logging calls must be removed from some of the KPE client's Command classes.
- The client needs to change the endpoint for some of its service method calls (see the points about the new front-end service below).
Changes to the front-end services
- The front-end services need the user URI in order to log HPA events, which means we need to implement authentication for front-end service calls. We might be able to implement this in one place once per every web server (as an interceptor) such that the services themselves wouldn't need to be modified.
- A new front-end service needs to be created to handle the higher-level functionality of logging certain actions. In order to apply certain (logged) actions the KPE client would call this service (instead of the existing front-end services) and this service will then be responsible for calling the existing services in order to process the required action (e.g. create a shared space) and then calling HPA to log this action (with the same timestamp).
- The routines for handling calls to the HPA Log service need to be written. This is probably a straightforward SOAP call + handlers.
- In order to enable synchronization of timestamps in the KR and the HPA logs, some existing CRUD service methods that set timestamps in the KR need to return the timestamp they've set so that the new front-end service can read it and use the same timestamp in the HPA log calls (some services currently only return a success/failure indicator).
Changes and their purpose
A coherent system architecture implies that the grouping of its modules is logical and easily understood. We propose that the following services would be combined into one due to the fact that their functionality is so closely related.
- Knowledge Process Service
- Knowledge Browser Service
- Knowledge Annotator Service
- Vocabulary Service
- Content Item Service
- Content Item Diff Service
- Clipboard Service
- FIXME: do we need to have explicit licensing information for the services we wish to combine? (Ali's opinion: probably yes)
- The source code for the services to be combined needs to be put into one web service project.
- Possible method name overlaps need to be resolved (by renaming methods)
- The service endpoints need to be consolidated in the client apps as well.