5 Cross-Cutting Requirements
This section will highlight important requirements or describe any additional cross-cutting requirements that apply to this Building Block.
Last updated
Was this helpful?
Development
This section will highlight important requirements or describe any additional cross-cutting requirements that apply to this Building Block.
Last updated
Was this helpful?
The cross-cutting requirements described in this section are an extension of the cross-cutting requirements defined in the and the . This section will describe any additional cross-cutting requirements for this Building Block or differences with the Architecture Blueprint.
Application APIs will contain POST endpoints which are not idempotent. GET/PUT/DELETE APIs are idempotent relative to Information Mediator Building Block, but the idempotents of intermediated services depend on the service provider and cannot be specified at this level.
Databases should not include business logic. We propose that this is a design recommendation which intends to make business logic all live in a clearly visible and accessible location. This may not always be followed, as the benefits of stored procedures (e.g., in reducing database transaction round-trips, etc.) may sometimes outweigh this general design recommendation.
The Service Access Layer of the Information Mediator is synchronous first. The Pub/Sub Layer is asynchronous.
Standard formats are used for communication with other Building Blocks. Inside Building Block non-standard protocols can be used.
OpenAPI spec 3.0 is supported in the first version. Moving to OpenAPI 3.1 is planned for the future.
The Performance Requirements specify the basic parameters that an implementing government might use to establish performance requirements for scalability, throughput, and response times when reasonable/necessary. For example:
Minimum Throughput = 100 requests/sec.
Maximum Latency = 1 sec.
Concurrency = 1000 concurrent requests.
All solutions MUST be able to monitor and report, including but not limited to, resource consumption, throughput, latency, average latency, queue depth/backlogs, etc.
All of these indicators MUST be available through an administrative API.
The local monitoring agent should be configurable via web interface.
Retries and back-off strategies must be configurable.
The following standards are applicable to data structures in the Information Mediator Building Block:
Ideally, all Building Blocks should be able to run a “monitoring agent” which handles reporting out logs, requests, Building Block-specific indicators, etc. to a monitoring service (e.g. )
Specific “” requirements are in the functional requirements section.