3 Terminology
Terminology used within this specification.
Term | Description |
---|---|
Building Block | Software modules that can be deployed and combined in a standardized manner. Each Building Block is capable of working independently, but they can be combined to do much more. Building Blocks are composable, interoperable software modules that can be used across a variety of use cases. They are standards-based, preferably open-source, and designed for scale. Each Building Block exposes a set of services in the form of REST APIs that can be consumed by other Building Blocks or applications. Ingress access is access from external applications to GovStack Building Blocks and applications. Egress access is access from within GovStack Building Blocks and applications to external applications. |
Use Case | A use case is a piece of functionality described as a sequence of actions (steps) to achieve a specific goal in a specific context of usage. E.g., in one use case, the Information Mediator Building Block may be used to let a Building Block access a service provided by another, or in a different use case may be used to relay an event notification from one Building Block to several other Building Blocks via a Publisher-Subscriber (Pub/Sub) model. Each use case may involve a collection of modules or Building Blocks. A relatively small set of these Building Blocks can be readily applied to a wide variety of use cases in low-resource settings. |
API | An application programming interface (API) is a connection between computers or between computer programs. It is a type of software interface, that offers a service to other pieces of software. A document or standard that describes how to build such a connection or interface is called an API specification. A computer system that meets this standard is said to implement or expose an API. The term API may refer either to the specification or to the implementation. |
3.5 Service Access
Term | Description |
---|---|
Member | A member is an organization that is authorized to communicate via the Information Mediator for a particular GovStack implementation. |
Application | An application is a running instance containing one or more Building Block instances and zero or more use case implementations. An application uses an Information Mediator Building Block to communicate with other Building Blocks or applications. An application typically has a single responsibility. |
Service | A service is a minimal piece of functionality provided by a Building Block or use case implementation. A service can be local (inside one application) or remote (between different applications). Remote services are consumed using REST protocol and they are described by OpenAPI specification. For example, the “registration” service might be accessed at a particular URL and allow a requester to “register a patient” by sending a POST request with proper patient data. |
Security Server | A security server is the main piece of software that is responsible for implementing the “service access” layer of the Information Mediator. This software acts as a gateway and is responsible for mediating requests between various members, applications, and services. It might be not just a single piece, but also a clustered or serverless deployment. |
3.6 Pub/Sub
Term | Description |
---|---|
Publisher | A Publisher produces events and sends them to rooms. Each event has an event type associated with it. Publishers can produce events of different types. |
Room | A Room is a Pub/Sub entity that handles the distribution of events. Each Room has a set of connected event types (E.g., the “birth” Room might contain three event types: “new_birth”, “birth_complication”, and “infant_death”). |
Subscriber | A Subscriber can process events of a certain event type. Subscribers are independent of each other and their business logic is different (as rule). Each subscriber processes events from their own perspective. |
Last updated