7 Data Structures
This section provides information on the core data structures/data models that are used by this Building Block.
The resource model shows the relationship between data objects that are used by the Information Mediator Building Block. The data elements provide detail for the resource model. All data element schemas can be viewed, commented on, and modified in the schemas section of the Information Mediator Building Block GitHub repository.
7.1 Resource Model
The Mediator Building Block key element is Service. The Service is used by a consuming Building Block or an application and offered by a provider Building Block or Application. Both Provider and Consumer must be Members of the Mediator Building Block. Members of the Information Mediator Building Block can be an organization (governmental or not, business or not) or a person (citizen as a rule).
To become a Member of Mediator Building Block participants must fulfill declared requirements and apply for onboarding. In the process of onboarding a Member is registered with Mediator Building Block and gets credentials to connect to Mediator Building Block. Normally it is done the way that a Member provides a certificate of recognized Certification Authority (CA), and requests signed with this certificate are considered legitimate requests of the Member. A member entity can access the Pub/Sub configuration and register a room to publish its own event type as a publisher through its own admin.
Members can browse a directory of Services available in the Mediator Building Block. Each service is described in OpenAPI.
7.2 Data Elements
7.2.1 Member
Fields:
Schema reference member.json
7.2.2 Application
Fields:
Schema reference application.json
7.2.3 Service
Fields:
Schema reference service.json
7.3 PubSub Layer
7.3.1 Resource Model
The Resource Model is an extension of the Access Layer model:
7.3.2 Data Elements
7.3.2.1 Event
An event is a message—a set of data sent to a topic. Each event has an id. The event corresponds to the message. Data elements of an event are described by event type OpenAPI description.
7.3.2.2 Event Type
An event type is schema definition for an event. Each event type is owned by a Room of a certain authority. (E.g. the Ministry of Health might own Room with the “new_birth” event type and define its schema.)
7.3.2.3 Publisher
A candidate application playing the role of IM-Publisher must be able to emit events to a specific Room.
7.3.2.4 Room
(N.B., this is often called a "topic" and we may shift to that in later versions.)
A candidate application playing the role of IM-Room must handle 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”). A room is located in the member’s local Information Mediator Building Block implementation and the member is responsible for all types of events in that particular room.
7.3.2.5 Subscriber
A candidate application playing the role of IM-Subscriber must be able to process events. It is done by defining a Service that will be called by Room to deliver an event. Subscribers are independent of each other and their business logic differs (as a rule). Each subscriber processes events from their own perspective.
7.3.2.6 Subscription
Last updated
