THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Area 2 of the open metadata model covers the basic types of asset that need to be governed in order to make best use of them. It builds out the core types of assets, extending from Asset, Infrastructure, DataSet and Process defined in 0010 Base Model. Figure 1 shows the structure of the model files for area 2. New classes and packages for this area are colored blue.
Figure 1: Summary of the Area 1 packages |
Connectors and Connections
In Area 0 we introduced the definitions for a server with an endpoint (model 0040). The server could host data and APIs. The Open Connector Framework (OCF) provides client java classes called connectors to enable an application, tool or engine to access this data and other deployed functions. A Connection metadata entity contains the configuration information to allow the OCF's Connector Broker to select and configure the appropriate a client application or tool to connect to a particular endpoint. The ConnectorType defines which connector implementation should be used to connect to the endpoint. The securedProperties holds authentication properties such as userId and password. They are securely stored to protect the assets. If they are missing then the security credentials of the current user are used with the connection.
Figure 2: Connectors and Connections |
Connection Linkage
The purpose of a connector is to access assets. In order for the connector to provide metadata about the asset it is accessing, there is a relationship between the connection and the asset. Notice the connection can only be associated with one asset - however assets may host smaller assets within them. In addition, some connectors are virtual connectors - by that we mean they implement an abstract to a business level asset and internally use one of more technical connectors as part of their implementation. The metadata repository can reflect these connection relationships using a VirtualConnection.
Figure 3: Defining the server capabilities and assets that a connection provides access to |
Data Stores
The base model introduced the concept of a data set. The data store definition shows how the data set relates to the server that it is hosted on.
Figure 4: Distinguishing between data set assets and the stores they are located in |
Data Sets
Figure 5 extends the concept of DataSet to include virtual data sets - that is data sets built up from calling other data sets.
Figure 5: Virtual Data Sets |
Deployed APIs
APIs provide access to data and function (such as analytical functions).
Figure 6: Providing remote access to function and data through APIs |
Software Components
Software components describe the code assets that are deployed to implement software capabilities.
Figure 7: Software components |
Files and folders
Files and folders describe physical files and how they are organized on the file system.
Figure 8: Files and folders |
Document Stores
Document stores describes a specialist type of server that manages documents and their metadata.
Figure 9: Document Stores |
Graph Stores
Graph stores describe a type of data store that has its content organized as a graph.
Figure 10: Graph Stores |
Events and Logs
Figure 11: Events and Logs |
Databases
Figure 12: Database Servers |
Metadata Repositories
Figure 13: Metadata Repositories |
Keystores
Figure 14: Secure stores for security information |
Code Tables
Figure 15: Code tables for storing valid values for enumeration fields |
Information Views
Figure 16: Views over tabular data |
Reports
Figure 17: Reports and data summaries |
Applications and Processes
Applications provide business or management logic. They are often custom built but may also be brought as a package. They are deployed onto a server. Some applications are written to support specific processes. Figure 15 shows how applications relate to processes and the servers that host them
Figure 18: Application and Processes |
Data Processing Engines
Figure 19: Data Processing Engines |
...