Skip to content

Commit

Permalink
Merge pull request #847 from omahs/patch-1
Browse files Browse the repository at this point in the history
Fix typos
  • Loading branch information
mandy-chessell authored Oct 11, 2023
2 parents 8c1b658 + 0481604 commit ee9f905
Show file tree
Hide file tree
Showing 3 changed files with 10 additions and 10 deletions.
6 changes: 3 additions & 3 deletions site/docs/concepts/repository-governance-engine.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,9 @@ hide:

# Repository Governance Engine

The repository governance engine describes a set of related [repository governace services](/guides/developer/repository-governance-services/overview) that perform governance on open metadata repositories such as dynamically manage [open metadata archives](/concepts/open-metadata-archives) based on changes in the open metadata.
The repository governance engine describes a set of related [repository governance services](/guides/developer/repository-governance-services/overview) that perform governance on open metadata repositories such as dynamically manage [open metadata archives](/concepts/open-metadata-archives) based on changes in the open metadata.

An repository governance engine is hosted in the [Repository Governance Open Metadata Engine Service (OMES)](/services/omes/repository-governance/overview) running on one or more [Engine Host OMAG Servers](/concepts/engine-host).
A repository governance engine is hosted in the [Repository Governance Open Metadata Engine Service (OMES)](/services/omes/repository-governance/overview) running on one or more [Engine Host OMAG Servers](/concepts/engine-host).

When a repository governance engine is called, it is passed a governance request type and request parameters. This is mapped to a call to a repository governance service through the [repository governance engine definition](/concepts/governance-engine-definition).

Expand All @@ -24,4 +24,4 @@ When a repository governance engine is called, it is passed a governance request



--8<-- "snippets/abbr.md"
--8<-- "snippets/abbr.md"
6 changes: 3 additions & 3 deletions site/docs/education/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,13 +15,13 @@ We are currently in the process of rewriting our Dojos. There are three dojos av

* [Day 1](/education/egeria-dojo/running-egeria/running-egeria-intro) - How to run Egeria.
* [Day 2](/education/egeria-dojo/developer/overview) - How to build connectors and utilities that use Egeria.
* [Day 3](/education/egeria-dojo/metadata-governance/overview) - How to manage and maintain yor metadata.
* [Day 3](/education/egeria-dojo/metadata-governance/overview) - How to manage and maintain your metadata.

You can still also see the [Original Egeria Dojo](/getting-started/egeria-dojo), but it is not recommended that you rely on it since it is no longer tested. Instead, look for future days of the updated dojo.

## Hands on Labs

The [Hands on Open Metadata Labs](/education/open-metadata-labs/overview) provide an interactive environment that allow you to experiment with different capabilities of Egeria. They are organized by role so you can select the roles of interest to you.
The [Hands on Open Metadata Labs](/education/open-metadata-labs/overview) provide an interactive environment that allows you to experiment with different capabilities of Egeria. They are organized by role so you can select the roles of interest to you.

## Individual tutorials

Expand Down Expand Up @@ -49,4 +49,4 @@ Sometimes it is useful to learn about a new technology by understanding how it c

[Egeria's webinars](/education/webinar-program/overview) run each month and provide a deep dive into a particular topic. All webinars are recorded and are available on YouTube.

--8<-- "snippets/abbr.md"
--8<-- "snippets/abbr.md"
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 ee9f905

Please sign in to comment.