Skip to content

Commit

Permalink
fix typos
Browse files Browse the repository at this point in the history
Signed-off-by: omahs <73983677+omahs@users.noreply.github.com>
  • Loading branch information
omahs authored Sep 20, 2023
1 parent 422c9d6 commit fbbe98a
Showing 1 changed file with 4 additions and 4 deletions.
8 changes: 4 additions & 4 deletions site/docs/introduction/key-concepts.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,9 +3,9 @@

# Key concepts of the Egeria technology

The functions needed to support the [open metadata ecosystem](/introduction/challenge/#the-open-metadata-ecosystem) are complex and need to be organized so they can be understood and adapted over time as the needs of your organization changes and grows. There is also an belief that it should be possible to dynamically activate and deactivate capability in the open metadata ecosystem through APIs allowing a self-service and local ownership approach to be adopted. This way, an organization does not need a large IT team to manage the deployment.
The functions needed to support the [open metadata ecosystem](/introduction/challenge/#the-open-metadata-ecosystem) are complex and need to be organized so they can be understood and adapted over time as the needs of your organization change and grow. There is also a belief that it should be possible to dynamically activate and deactivate capability in the open metadata ecosystem through APIs allowing a self-service and local ownership approach to be adopted. This way, an organization does not need a large IT team to manage the deployment.

The organization of the components requires some new terminology to be introduced to lable the different types of components, their purpose and how they connect together. The [overview](/introduction/overview) introduced the concept of the [OMAG Server Platform](/concepts/omag-server-platform) deployed multiple types in different processing centres and running [OMAG Servers](/concepts/omag-server). These OMAG Servers are specialized to perform specific functions. Figure 1 shows the different types of OMAG Servers and how they work together.
The organization of the components requires some new terminology to be introduced to label the different types of components, their purpose and how they connect together. The [overview](/introduction/overview) introduced the concept of the [OMAG Server Platform](/concepts/omag-server-platform) deployed multiple types in different processing centres and running [OMAG Servers](/concepts/omag-server). These OMAG Servers are specialized to perform specific functions. Figure 1 shows the different types of OMAG Servers and how they work together.

![Figure 1](egeria-solution-components.svg)
> **Figure 1:** This picture shows the different types of Egeria's OMAG servers and how they are connected together in a solution. They are not all required. You choose which ones you need, and how many of them to run, to match the needs of your organization. The servers are organized into three rings. In the inner-ring (labeled *Integrated Metadata*), a Metadata Access Server, Repository Proxy and Conformance Test Server are members of an *Open Metadata Repository Cohort*, or "cohort" for short, communicating via Egeria's peer-to-peer protocols. In the next ring out, called *Integrated Governance*, are the Governance Servers connected to the Metadata Access Server in order to access metadata in the open metadata ecosystem. In the outer ring, called *Governance Solution*, are the View Server and Presentation Server also connected to the Metadata Access Server.
Expand Down Expand Up @@ -45,13 +45,13 @@ The exchange of metadata uses the [cohort events](/concepts/cohort-events) to gi

![Cohort member types](cohort-member-types.svg)

A third party metadata server can embed the Egeria libraries in its own runtime or, more commonly, use a special OMAG Server called the [Repository Proxy](/concepts/repository-proxy) to host connectors that map between the events and APIs of the third party metadata server and the Open Metadata events and APIs. The Repository Proxy manages all the interaction with the other members of the cohort.
A third party metadata server can embed the Egeria libraries in its own runtime or, more commonly, use a special OMAG Server called the [Repository Proxy](/concepts/repository-proxy) to host connectors that map between the events and APIs of the third party metadata server and the Open Metadata events and APIs. The Repository Proxy manages all the interactions with the other members of the cohort.

The cohort protocols are peer-to-peer and the membership is dynamic. When a third party metadata server connects to the cohort, either directly or through its Repository Proxy, it automatically begins receiving metadata from all the other members. When it shares metadata, it is shared with all the other members. Each member is free to choose what to share and what to process from the other members of the cohort.

Other types of OMAG Servers that can be members of the cohort:

- The [Metadata Access Server](/concepts/metadata-access-server) supports Egeria's [Open Metadata Access Services (OMAS)](/services/omas), or access services, for short. These access services provide specialized APIs and events for different types of technologies. The Metadata Access Server optionally provides a *native metadata repository* that supports any type of open metadata. It is a valuable member of the cohort because it is a metadata gap-filler. By that we mean that is can store relationships between metadata from different third party repositories along with additional types of metadata not supported by any of the third party metadata repositories. It may optionally have the access services enabled so it can also act as a metadata access point.
- The [Metadata Access Server](/concepts/metadata-access-server) supports Egeria's [Open Metadata Access Services (OMAS)](/services/omas), or access services, for short. These access services provide specialized APIs and events for different types of technologies. The Metadata Access Server optionally provides a *native metadata repository* that supports any type of open metadata. It is a valuable member of the cohort because it is a metadata gap-filler. By that we mean that it can store relationships between metadata from different third party repositories along with additional types of metadata not supported by any of the third party metadata repositories. It may optionally have the access services enabled so it can also act as a metadata access point.
- The [Conformance Test Server](/concepts/conformance-test-server) is used to verify that a member of the cohort is operating correctly. It is typically only used in test environments because it sends out a lot of test metadata on the cohort and validates the responses from the cohort member it is testing.

## Integrating metadata into solutions
Expand Down

0 comments on commit fbbe98a

Please sign in to comment.