THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
<== Back to Area 1 - Collaboration | Forward to Area 3 - Glossary ==>
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 |
Files and folders
Figure 7: Files and folders |
Document Stores
Figure 8: Document Stores |
Graph Stores
Figure 9: Graph Stores |
Events and Logs
Figure 10: Events and Logs |
Databases
Figure 11: Database Servers |
Metadata Repositories
Figure 12: Metadata Repositories |
Keystores
Figure 13: Secure stores for security information |
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 14: Application and Processes |
Data Processing Engines
Figure 15: Data Processing Engines |
