This chapter is from the book
This chapter is from the book
This chapter is from the book
Accessing Metadata
Once metadata is stored, it must be accessed. Metadata beneficiaries have different access requirements, and a beneficiary-specific analysis process, covered in Part IV, is a prerequisite to finalizing the overall metadata solution interfaces. The following metadata access possibilities exist:
Direct query—Either via a front-end interface or a DBMS query language, the metadata store is queried directly based on its underlying schema.
Tool-driven access—An interfacing tool (development tool, reporting tool, etc.) presents metadata to the beneficiary. The metadata exists in the tool's metadata store.
API-driven access—Tools, applications, or other software use metadata solution-specific APIs to get to the stored metadata.
Remote procedure calls (RPCs)—From a reverse point of view, the metadata solution uses procedures inherent to the "keepers of the metadata," so to speak, as a means of retrieving metadata from its resting place. Typically, metamodels in this scenario need to accommodate the location and access procedures associated with each metadata source that falls within the scope of the served beneficiaries.
Batch export—Creation of a simple extract, download, or file brings a set of metadata from the metadata solution to the requesting beneficiary.
Standards-based metadata exchange—As exchange standards become finalized, more metadata solution implementations leave the access of the metadata to exchange mechanisms that are not vendor specific. XML is a popular example.
Portal/directory-based access—Based on specific search engines, metadata is retrieved and displayed to the requestor by matching metadata instances to search requirements.
The type of access that is best for a beneficiary is selected based on the analysis of architectural requirements.
Revisiting the Metadata Architecture
Metadata everywhere, beneficiaries everywhere, and the relationships among them never seem to be planned or logical. The metadata architecture organizes the metamodel components based on a logical spread of metadata sources. Specifically, metadata of record assignments are validated based on the availability of a specific metadata store, whether it is part of a tool, application, or other metadata solution. Consider Figure 11-4 and the patterned relationships among metamodels. In a well-planned metadata architecture, the integrated metamodel represents a uniform conglomeration of the specific and unique metamodels that reside across the architecture. Common metadata is represented in a common metamodel. It is then supplemented with the interface points that may be necessary to connect the common metadata to the metamodels of each architectural component.
){kind=link}
Figure 11-4 A sample metadata architecture
Where the Tools Fit In
As we evaluate metadata access, one questions always is, How do various metadata suppliers and recipients fit into the overall plan? The most common metadata forces in the architecture are those tools we all know and love. We use them to create data, analyze data, and process data. We use them to develop source code, configure applications, and maintain hardware/software assignments. We use them to tune our databases and monitor system performance. A day without tools is like a day without sunshine. As we use all these tools, we create and use metadata over and over again. Now that we have not only strategically identified which metadata is of importance to our beneficiaries, but also sourced all of it, the tools are crucial components of the overall metadata solution inasmuch as they buy and sell metadata. The metadata solution architecture relates all components into an organized and accessible set of logical metadata.
Determining the Scope of Coverage
As we evolve our metadata architecture, focusing on the participating tools and their ability to either access metadata or be accessed, the scope of metadata coverage begins to tighten. Although there are formal ways to scope a metadata solution,6 it is important to note that sometimes technical issues force the elimination or redirection of some metadata aspects of the solution. If some tools are full of valuable metadata, but have no clear-cut way of being accessed, many metadata solution designers may rethink the immediate solution to account for this lack of clear interface capability. Other ways of scoping the metadata solution relate the amount of beneficiaries to be covered in the first implementation to the specific functions that will be addressed by the metadata solution, or even to what metadata will be included.
Metadata solutions that try to address all needs with the first implementation are destined to fail. When metadata solutions are scoped so that increased functionality, metadata accessibility, and beneficiary service are added over time, the metadata solution becomes exponentially more successful.
Consider the fact that metadata is just one part of the overall metadata solution. Consider also that metadata is typically addressed by a full metadata solution as part of an overall metamodel or series of metamodels.