Addressing remarks

1. X-GovStack-Client header

Information Mediator Building Block specification declares, that the client application is described in X-GovStack-Client header. Sample implementation does this in X-Road-Client header. Adaptation is needed on the test harness side.

Agreed. However, the current tests are not compliant with the IM-BB specifications (see section 4: GovStack test harness report and issues), requiring modifications regardless. This includes, for example, also adapting protocol headers to receive correctly formatted responses.

X-Road was chosen as the basis of our technical proposal for its robustness and suitability. However it operates with a set of defined protocol headers (like X-ROAD-CLIENT-ID) which are deeply integrated into its architecture. Changing these headers, even if it appears to be a simple task of renaming, would essentially amount to altering the protocol's core structure. This is not merely a cosmetic change but a fundamental alteration to how X-Road operates and interacts with its components, such as X-Road Metrics. Such modifications would lead to a protocol-level fork, diverging significantly from the standard X-Road implementation.

Creating a protocol-level fork for the sake of header naming would mean embarking on a path of developing a new, parallel version of X-Road. This contradicts our goal of providing a sample implementation using a proven, stable, and widely-adopted system. Implementing a forked version would require significant resources for development, testing, and maintenance, essentially leading us to create a new version of an underlying technology, which was never the intention.

Moreover, diverging from the standard X-Road protocol to create a solution that is ostensibly 'X-Road in essence but different in protocol' would add complexity without tangible benefits. It would create challenges in future updates, compatibility, and maintenance, straying from the goal of demonstrating a practical and implementable solution.

Considering these factors, within the scope of creating a sample implementation, adhering to X-Road's existing protocol is the most pragmatic approach. It allows us to leverage a tested and reliable framework without the overheads and risks associated with protocol-level modifications. This approach aligns with our objective of demonstrating a functional, scalable, and adaptable solution for the GovStack ecosystem, rather than reinventing the wheel.

Our recommendation is to utilize X-Road in its current, proven form, ensuring stability and reliability in the sample implementation, while acknowledging the need for more flexible or different solutions in other contexts or future developments. This approach respects the specifications team's vision for a ubiquitous solution, while pragmatically addressing the technical and resource constraints of the current project.

We also did delve into changing message headers at a proxy or adapter level. However that also would entail significant work without enhancing functionality or clarity. Although we devised a plan for this, we concluded it would not be feasible or valuable within the sample implementation context.

A schematic detailing the required changes to effectively 're-skin' X-Road for this purpose will be provided below.

Open

2. Management API

Management API of Information Mediator not covered in Sample Implementation.

Further clarification on this remark is needed. The sample implementation provides all management operations via API (accessible externally via X-Road) and, for the most part, through a user interface as well: PubSub subsystem.

3. PubSub API mapping

IM PubSub API is functionally a subset of PubSub API of Sample Implementation. To use the implemented API in the test harness URL rewriting must be provided by adaptation.

Agreed. We propose amending the IM PubSub API definition to better align with the BB specifications and API capabilities. The current API does not support all capabilities outlined in the specifications.

For instance, the specifications require Exponential Backoff Retry logic, both during room creation and as an overridable feature in subscriptions. The IM PubSub API lacks the means to input necessary information for these functionalities.

Given the low maturity of the test harness for IMBB (refer to section 3: GovStack test harness report and issues), updating the API would not constitute a complete overhaul of the harness, as it currently lacks implementation for most of the API testing.

4. PULL acknowledgement

Acknowledging of messages is missing in PULL delivery mode. The result of the PULL request might be missed in transport. In this case, a message will be lost.

Agreed, acknowledgment functionality in the PULL delivery mode is currently not implemented. Implementing this would require establishing a protocol (or adapting existing ones) for PULL communication. Within our current solution, a message is considered delivered once it is pulled.

To facilitate acknowledgments, the receiving system would need to process the message and then either send back a response via a new REST message to a specified endpoint or use a predetermined protocol.

However, as the support for PULL subscription in general, is deemed optional in the specifications and our agreement, we do not believe it is essential to specify or implement this in the sample implementation.