Patent Application
20080183725
Computational and memory demands on computing systems continue to increase exponentially as technology develops newer and ever more powerful applications. One such area that has seen recent growth relates to requirements that database processing technologies. These technologies deal with dimensional aspects such as row and column processing and are now being coupled with other processing models such as traditional object models having a class/inheritance structure. Thus, many systems often have a need to support both relational database models and object based models where there also needs to be methods in place to bridge the gap between these models. In contrast to concrete programming models described above, other types of models include conceptual models that are viewed as design artifacts that allow developers to describe components in terms of desired structure. Demands to support such models are often placed on available operating systems where a plurality of applications interact with the operating system but employ the system to interact with other applications. Some discussion on these differing types of models is now provided before a discussion on metadata aspects of applications employing such models.
Object-oriented programming (OOP) is a programming language relates to classes or types which encapsulate state and behavior. Historically, a program has been viewed as a logical procedure that takes input data, processes it, and produces output data. The programming challenge was seen as how to write the logic, not how to define the data. Object-oriented programming takes the view that what one really is interested in are the objects to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the display objects on a computer desktop (such as buttons and scroll bars).
One aspect in OOP is to identify the objects to manipulate and how they relate to each other, an exercise often known as object modeling. When an object has been identified, it can be generalized as a class of objects. Then, define the type of data it contains and any logic sequences that can manipulate it. Each distinct logic sequence is known as a method. A real instance of a class is called an “object” or, in some environments, an “instance of a class.” The object or class instance is what executes on the computer. The object's methods provide computer instructions and the class object characteristics provide relevant data. In contrast to object models, relational database models are now described.
The relational model provides a model for describing structured data based on an assertion that all data can be described as a series of n-ary relationships. At the core of the relational model is the ability to describe any structure in terms of a series of related tuples which one can reason about with relational algebra. The relational model supports common relational databases that are often supported by some type of query language for accessing and managing large amounts of data. Structured Query Language (SQL) is a prevalent database processing language and may be the most popular computer language used to create, modify, retrieve and manipulate data from relational database management systems. In general, SQL was designed for a specific, limited purpose—querying data contained in a relational database. As such, it is a set-based, declarative computer language rather than an imperative language such as C or BASIC which, being general-purpose, were designed to solve a broader set of problems.
Conceptual models typically provide a grammar with which one can describe a model. Conceptual models are typically, just as described, conceptual—where they have typically been design time artifacts that are realized in terms of database schemas or object models. Conceptual models provide developers with a tool to describe the behavior or nature of a problem in an abstracted manner, where schemas are often employed as a component of such models. For example, a conceptual schema, or high-level data model or conceptual data model, provides a map of concepts and their relationships. A conceptual schema for an art studio, for example, could include abstractions such as student, painting, critiques, and showcases.
Regardless, of the model employed in a respective system such as an object model, relational database model, conceptual model or other model, there is common requirement that is associated with each of the respective models which includes having metadata associated with each of the models. Metadata includes information that characterizes data and describes the structure of the data. For instance, metadata is often used to provide documentation for software components, for presentation of data, or provide information as to how certain data came into being or the details regarding the particular aspects of the respective model that the data relates to. Typically, an application or framework developer that requires access to metadata across several different metadata domains must implement special case logic to deal with these disparate representations of metadata. Furthermore, any correlation between the disparate systems or attempts to be agnostic in terms of the sources of the metadata requires explicit special case logic and abstractions to be implemented. Such an approach to processing metadata is not sufficient for modern development platforms.
The following presents a simplified summary in order to provide a basic understanding of some aspects described herein. This summary is not an extensive overview nor is intended to identify key/critical elements or to delineate the scope of the various aspects described herein. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
An architecture and programming interface is provided that allows processing of metadata according to a common development/interface framework. Metadata is aggregated from disparate data domains such as from an object domain, conceptual domain, relational domain, or other data domain. As the metadata is collected or aggregated from multiple data sources, it is stored in a manner that is abstracted from the form from which the metadata was collected. Application Programming Interfaces (APIs) are provided that allows access to and manipulation of the abstracted metadata such as via queries or other types of data access, where the APIs provide methods for common access patterns. By providing a common form to collect/manipulate metadata, complex interfaces dealing with the nuances of each respective domain can be mitigated while component development across differing data models simplified.
In one aspect, aggregation services for disparate metadata sources are provided. This includes providing abstractions for processing metadata from different sources including an item collection which understands how to self-populate metadata from a persistent source. In one specific example, this can include a metadata workspace for aggregation that registers multiple item collections and how to dispatch query requests to the appropriate item collections. The metadata workspace and item collection provide an example system, where the broader concept provides an abstraction for sourcing and realizing disparate metadata in terms of a common grammar and API. An aggregator allows one to utilize metadata across different domains with a common API or facade over the lower abstraction (e.g., the workspace). The item collection abstraction exposes a query-able collection of metadata concepts and encapsulates loading, serialization, and validation logic, for example, which simplifies development by providing a consistent framework. The Metadata Workspace provides a registration service for registering a number of item collections and a common framework over the item collection's query API's.
To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways which can be practiced, all of which are intended to be covered herein. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.
A common framework providing abstraction interfaces and storage over disparate metadata sources is provided. In one aspect, a metadata processing and storage system is provided. The system includes an aggregator component that stores metadata from at least two disparate data domains. A framework component encapsulates the metadata according to an abstraction model that describes the disparate data domains. One or more application programming interfaces can be provided to interact with the aggregator component to facilitate data access according to the abstraction model.
As used in this application, the terms “component,” “API,” “aggregator,” “model,” and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Also, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal).
Referring initially to
The aggregator component 110 and programming interfaces 140 allow processing of metadata 120 according to a common development/interface framework. Metadata is aggregated at 110 from disparate data domains 120 such as from an object domain, conceptual domain, relational domain, and/or other data domain. It is noted that the aggregator component 110 can also store mapping information and can be considered another form of metadata, but may or may not be considered a separate domain. As the metadata is collected or aggregated from multiple data sources at 110, it is stored in a manner that is abstracted via the meta-model 130 from the form from which the metadata 120 was collected. Application Programming Interfaces (APIs) 140 are provided that allows access to and manipulation of the abstracted data such as via queries or other types of data access. By providing a common/abstracted form to collect/manipulate metadata at 110, complex interfaces dealing with the nuances of each respective metadata domain 120 can be mitigated while component development across differing data models can be simplified.
In one aspect, aggregation services (described in more detail with respect to
It is noted that in the context of the system 100, the term query refers to generalized questions that may be asked of aggregator component 110 or the metadata workspace. For instance, one may invoke a finder-like operation (such as get Item (String Identity)) where attempts are made to find an item by its identity. Similarly, one may leverage Language Integrated Query or other type (example object query language (OQL)) constructs to execute a more expressive query over the in-memory metadata instances.
In general, databases can be used to store structured data in one example. The structure of this data, together with other constraints, can be designed using a variety of techniques, one of which is referred to as entity-relationship modeling or ERM. The end-product of the ERM process is an entity-relationship diagram or ERD. Data modeling often employs a graphical notation for representing such data models. An ERD is a type of conceptual data model or semantic data model.
The first stage of information system design uses these models to describe information needs or the type of information that is to be stored in a database during the requirements analysis. The data modeling technique can be used to describe any taxonomy (i.e., an overview and classifications of used terms and their relationships) for a certain universe of discourse (i.e., area of interest). In the case of the design of an information system that is based on a database, the conceptual data model is, at a later stage (usually called logical design), mapped to a logical data model, such as the relational model, this in turn is mapped to a physical model during physical design. It is noted that sometimes these phases are referred to as “physical design.” Thus, the metadata domains 120 can be associated with different models and/or different stages of the modeling process, where each stage or portion of the model can have a different metadata domain. Before proceeding, it is noted that the system 100 can be provided as a metadata aggregation system. This includes means for aggregating metadata (aggregator component 110) from one or more metadata domains 120. This can also include means for representing the metadata (abstraction model 130) according to a common data meta-model, where the represented data applies as a generic form across the metadata domains 120.
Referring now to
At 210, metadata is defined over a plurality of metadata domains and according to various models. For example, such models could include object models, relational database models, and conceptual models. Thus, metadata can be associated with each type of respective data model which can vary across data domains. At 220, an abstraction is defined for the various metadata forms defined at 210. Such abstraction includes an encapsulated form where the particulars of the metadata and its associated data model are abstracted or generalized in view of the form. This can include defining abstract interfaces and methods that are called in a generic manner regardless of the underlying form of the metadata or the associated model from which the metadata is derived. At 230, metadata is aggregated from across the metadata domains described above. This can include pulling data in across a network (or networks) from multiple data sources and storing the metadata according to the generic or framework forms dictated by the respective abstraction model such as shown at 240. Thus, when the metadata data is accessed in the future, it will be manipulated via its generic or encapsulated form as opposed to its original form and model structure. At 250, after the data is stored in its abstracted form, the data can be manipulated via one or more application programming interfaces.
As will be described in more detail below, the abstraction and interface principles described by the process 200 enable various features and functions. This includes:
Providing a Metadata Workspace as an aggregator and framework over disparate metadata;
Providing a Metadata Item Collection as an extensible model for loading and managing metadata from a persistent source;
Providing a Metadata Type Hierarchy as an in-memory realization of an Entity Data Model (or other data models that employ metadata);
Providing a Metadata Perspective as a component for abstracting the type and source of metadata from consumers;
Enabling Projection of a conceptual model on to a target system;
Employing a Provider Manifest as a component for defining a concrete set of types and type semantics; and
Enabling Query services for metadata described in terms of the respective model. As can be appreciated, other features and functions can be provided by the abstractions and APIs described herein.
Referring now to
In order to have a common way to query over the metadata 310 and to reason about or relate metadata from disparate sources at 320, a common model such as an abstraction model described above is provided to express the metadata. For instance, metadata surfaced in the Metadata Workspace 310 can be describable in terms of a common meta-model. The common meta-model in one example can be an Entity Data Model (EDM) described above. An instance of the EDM can be used to describe and relate the following types of metadata in an Entity Data Platform:
Conceptual Models: Models that describe domain entities at a conceptual level that may be realized in classes and/or database tables;
Database Models: Models that describe a database (tables, relationships, constraints . . . );
Client Mappings: Models that describe the relationship between a conceptual model instance and a database model instance;
Object Mappings: Models that describe the relationship between a class and a conceptual Entity;
Primitive Type Mappings: Mappings between primitive types and a target database's primitive types. This can include mapping between EDM primitives and CLR (common language runtime) primitive as well as EDM primitives and target database primitives. By providing intermediary primitive types and the EDM meta-model, a neutral “canonical” representation of both shape and primitive enables a system to perform any model-model transformation; and
Type Semantics: Services that describe common semantics for types (comparable, promote-able . . . ). As can be appreciated, more or less metadata components can be provided than the examples described herein. After metadata components have been suitably abstracted, services for accessing/manipulating such metadata can be provided such as described in more detail below with respect to
Referring now to
Return all Mappings where the Conceptual Entity Type is in the “com. company” namespace and the Target (database) Entity Type has a property (column) named “Salary.” This is a more expressive and powerful component for interacting with metadata than the typical approaches of iterating through arrays of methods. It also underscores the capability of leveraging metadata from disparate sources. In such a query at 410, the conceptual model, the database model and the client mapping participate to yield the desired results.
At 420 of
The metadata runtime services use abstract primitives and a metadata hierarchy as a canonical schema which can serve as the intermediate transformation point between two real type systems. Such an intermediary schema supports an n-1 model transformation, where n type systems plus the canonical representation of primitives map to a canonical representation instead of to the n-1 other type systems. This helps provider writers by reducing the set of types they need to be concerned with other than just EDM types, as opposed to every other type system that might exist. The Metadata runtime services also provide the components for loading the concrete transformations to be used in a given context plus the type semantics to be used in the given context. Consumers of the metadata runtime services can perform transformations of primitive types or reason about the semantics of a given primitive type from a particular type system. Along with respective metadata services, now metadata extensibility examples will be described in more detail below with respect to
Referring to
At 520, consumer specific metadata extensibility can be provided. Consumers of the metadata runtime model may also register their own item collections or specialized item collections in order to load metadata from different sources. A more common scenario is that a consumer may want to decorate an existing metadata instance with more information that is contextually useful to the application or framework being constructed. The metadata runtime supports design and runtime decoration of members and types by consumers through the use of attributes and facets.
Turning to
At 620, projection of a conceptual model onto a target type system is considered. At runtime, there are at least two type systems in a typical solution—the type system of the object runtime and the Target store's type system (the type system of the underlying database). In the EDM and Entity Services, conceptual models are generally defined in terms of abstract primitive types that can be mapped to one of these concrete type systems. The realization of a model at runtime causes it to be bound to the target type system before operation execution can take place. The binding facilitates store agnostic definition of models which become concrete and usable in the context of an underlying store.
In order to provide a context for the various aspects of the disclosed subject matter,
With reference to
The system bus 718 can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, 11-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), and Small Computer Systems Interface (SCSI).
The system memory 716 includes volatile memory 720 and nonvolatile memory 722. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 712, such as during start-up, is stored in nonvolatile memory 722. By way of illustration, and not limitation, nonvolatile memory 722 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory 720 includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).
Computer 712 also includes removable/non-removable, volatile/non-volatile computer storage media.
It is to be appreciated that
A user enters commands or information into the computer 712 through input device(s) 736. Input devices 736 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit 714 through the system bus 718 via interface port(s) 738. Interface port(s) 738 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 740 use some of the same type of ports as input device(s) 736. Thus, for example, a USB port may be used to provide input to computer 712 and to output information from computer 712 to an output device 740. Output adapter 742 is provided to illustrate that there are some output devices 740 like monitors, speakers, and printers, among other output devices 740 that require special adapters. The output adapters 742 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 740 and the system bus 718. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) 744.
Computer 712 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 744. The remote computer(s) 744 can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer 712. For purposes of brevity, only a memory storage device 746 is illustrated with remote computer(s) 744. Remote computer(s) 744 is logically connected to computer 712 through a network interface 748 and then physically connected via communication connection 750. Network interface 748 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).
Communication connection(s) 750 refers to the hardware/software employed to connect the network interface 748 to the bus 718. While communication connection 750 is shown for illustrative clarity inside computer 712, it can also be external to computer 712. The hardware/software necessary for connection to the network interface 748 includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.
What has been described above includes various exemplary aspects. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing these aspects, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the aspects described herein are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.
