THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
<== Back to Area 0 - Extensions to the base model | Forward to Area 3 - Glossary ==>
Area 1 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 1. New classes and packages for this area are coloured 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 |
Connector Directories
Connector directories help to organize the connection definitions into logical groups to help people/tools locate the relevant connections. They are managed through the Connector Directory OMAS API.
Figure 3: Organizing connections into connector directories |
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 4: Defining the server capabilities and assets that a connection provides access to |
Data Stores and Data Sets
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. In addition, some data sets are virtual - that is they are build up from calling other data sets. Figure 5 shows the data stores and virtual data sets linking to the data set.
Figure 5: Distinguishing between data set assets and the stores they are located in |
Deployed APIs
Figure 6: Providing remote access to function and data through APIs |
Metadata Repositories
Figure 7: Metadata Repositories |
Files and Folders
Figure 8: Definitions for describing files and folders |
Document Stores and Collections
Figure 9: Specialized stores for managing documents |
Databases
 |
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 x shows how applications relate to processes and the servers that host them
 |
Security Assets
 |