Chapter 3 System Architecture Examples
This chapter presents two representative service models and system architecture examples as patterns for implementing the ODS-RAM.
Distributed Service Model: an approach in which domain owners themselves build a Self-Serve Data Platform and provide Data Product/Ontology Product based on DPQM
Federated Service Model: an approach in which a managed service provider delivers the basic software stack that constitutes DPQM on behalf of the domain owner, while the domain owner retains responsibility for providing Data/Ontology Product
The architecture for implementing distributed data management varies depending on "which functions are provided by which party and to what extent."
3.1 Distributed Service Model
Figure 1 illustrates an example system architecture for the Distributed Service Model.
Figure 1 Example System Architecture for the Decentralized Service Model
In the distributed service model, both data providers and data users each hold the functions necessary to enable distributed data management. Typically, the following elements are deployed on the participant (data provider, data user) side. For details on each function, please also refer to the ODP.
Metadata Exchange
Discovery and Search
Identity and Trust, Credential Service
Transaction (Control Plane Orchestrator, Data Plane Module)
Logging
Heuristic Contracting, Clearing and Payment (optional)
3.2 Federated Service Model
Figure 2 illustrates an example system architecture for the Federated Service Model.
Figure 2 Example System Architecture for the Federated Service Model
In the federated service model, ODS Middleware are deployed as DSSP on the data provider side. DSSP supplements areas that would be burdensome for participants to prepare individually, enabling participants to focus on "providing and consuming data."
3.3 Opt-ins and Backward Compatibility
In the ODS-RAM, each layer is independent of the others and fulfills its role in the overall distributed data management function through loose coupling. This allows the number of layers required to be selectively determined based on the nature and characteristics of the domain.
For example:
if the data destination and meaning within a given cross-domain context are clear, it is acceptable to implement Data Product first using L3 through L1, omitting the Ontology Product (a set comprising L4 through L2).
In terms of the federated service model configuration described above, it is also acceptable to prioritize the implementation of L3: Identity and Trust and Credential Service, L2: Transaction, and L1: Data Store and Industry Services.
In implementing the ODP, emphasis is placed on a Minimal Yet Viable design that allows opt-in participation in response to market demands centered on Save Money and Make Money. To achieve this, protocols are structured with loose coupling and backward compatibility built in at the design stage. The components that make up the two service models presented in this chapter should be understood as elements that are selected according to the characteristics and maturity of the market, and introduced and expanded incrementally.
The following chapters proceed as follows:
Chapter 4 presents the procedures for building a minimum configuration capable of performing data exchange between participants, using the deploy definition files provided by ODS SDK for Onboarding. The build targets are presented as L3, L2, L1, Logging, and Clearing and Payment (optional).
Chapter 5 presents the methods for creating semantic definitions using SAMM (Aspect Model files, web service API definition files, and instance files) as provided by ODS SDK for Semantics, as well as the procedures for registering with the Discovery Service, using the SDK, and setting up the environment.
Last updated