JP6101269B2 - Efficient provision of multiple metadata representations of the same type - Google Patents

Description

Conventional technology

  [0001] Computers are being deeply integrated into the workforce, home, mobile devices, and many other places. Computers can process large amounts of information quickly and efficiently. Software applications designed to run on computer systems allow users to perform a wide variety of functions, including business applications, schoolwork, entertainment, and the like. Software applications can be designed to perform specific tasks, such as word processing applications for drafting documents or email programs for sending, receiving, and organizing emails. Many.

  [0002] In some cases, software applications may be designed to implement various forms of metadata. This metadata may be represented by different metadata types. Different types can be used for different users based on what metadata type each user expects to see. In such situations, a plurality of different metadata files are typically stored and used to provide various metadata types. Storing and implementing such an array of metadata can lead to inefficiencies when extracting and applying the correct metadata file.

  [0003] The embodiments described herein are aimed at dynamically adapting metadata for use with native data encoding and efficiently changing object model type references. . In one embodiment, a computer system instantiates a metadata reader with an object model description to access various parts of the metadata in the object model description. The metadata reader is configured to read native metadata, which is metadata expressed in the encoding expected by the metadata reader. The metadata reader determines that the accessed metadata was encoded with non-native encoding, and then what metadata change should be performed to convert this non-native encoding to native encoding judge. The computing system then dynamically adapts the object model metadata from the non-native encoding to the native encoding according to the determined change. Thus, the object model can be read by the native runtime.

  [0004] In other embodiments, a computer system instantiates a type lookup table. This type lookup table receives the type definition request and responds with the appropriate type definition. This type lookup table contains metadata that can be read by a metadata reader. The instantiated type lookup table receives a type definition request for the specified type from the type requester. The computer system implements a type reference in the type reference table, and for the metadata reader based on what type is requested and what type is appropriate for the current consumer of the metadata reader. Different types are exchanged dynamically. The computer system then provides the requested type definition to the type requester based on the dynamically exchanged type.

  [0005] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

  [0006] Additional features and advantages are set forth in the description that follows, and in part will be apparent to those skilled in the art from this description, or may be learned by practice of the teachings herein. The features and advantages of embodiments of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. Features of embodiments of the present invention will become more apparent from the following description and appended claims, and can be learned by the practice of the invention described below.

[0007] To further clarify the above and other advantages and features of embodiments of the present invention, with reference to the accompanying drawings, a more specific embodiment of the present invention will be rendered. It will be appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of the scope of the invention. Embodiments of the present invention will be further specified and described in detail through the use of the accompanying drawings (described and explained). In the drawing
FIG. 1 illustrates that embodiments of the present invention can operate, including dynamically adapting metadata for use with native data encoding and efficiently changing object model type references. , Showing computer architecture. FIG. 2 shows a flow chart of an example method for dynamically adapting metadata for use with native data encoding. FIG. 3 shows a flow chart of an example method for efficiently changing an object model type reference. FIG. 4 illustrates an embodiment for converting foreign metadata into native metadata. FIG. 5 illustrates an embodiment of encoding metadata using type references. FIG. 6 illustrates an embodiment for converting a foreign type system to a native type system by internal modification of the type reference. FIG. 7 illustrates an embodiment of a metadata container. FIG. 8 illustrates an embodiment in which a view of a metadata container is provided. FIG. 9 illustrates an alternative embodiment in which a view of the metadata container is provided.

  [0017] Embodiments described herein aim to dynamically adapt metadata for use with native data encoding and to efficiently change object model type references. . In one embodiment, a computer system instantiates a metadata reader with an object model description to access various parts of the metadata in the object model description. The metadata reader is configured to read native metadata. Native metadata is metadata expressed in the encoding expected by the metadata reader. The metadata reader determines that the accessed metadata was encoded with non-native encoding, and then what metadata change should be performed to convert this non-native encoding to native encoding decide. The computing system then dynamically adapts the object model metadata from the non-native encoding to the native encoding according to the determined change. Thus, the object model can be read by the native runtime.

  [0018] In other embodiments, a computer system instantiates a type lookup table. This type lookup table receives the type definition request and gives the appropriate type definition in the response. This type lookup table contains metadata that can be read by a metadata reader. The instantiated type lookup table receives a type definition request for the specified type from the type requester. The computer system implements a type reference in the type reference table, and for the metadata reader based on what type is requested and what type is appropriate for the current consumer of the metadata reader. Different types are exchanged dynamically. The computer system then provides the requested type definition to the type requester based on the dynamically exchanged type.

  [0019] The following description refers to a number of methods and method operations that can be performed. Note that the operation of these methods may be described in a certain order, or may be shown in a flow chart as they appear in a particular order, but is not required or required unless otherwise stated. It should be noted that a specific order is not always necessary. This is because certain operations depend on other operations that complete before this operation is performed.

  [0020] Embodiments of the invention include or utilize a special purpose computer or general purpose computer, including computer hardware, such as, for example, one or more processors and system memory described in more detail below. Can do. Embodiments within the scope of the present invention also include physical computer-readable media and other computer-readable media for sending or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. Computer-readable media that store computer-executable instructions in the form of data are computer storage media. A computer readable medium that sends computer-executable instructions is a transmission medium. That is, by way of example and not limitation, embodiments of the present invention can include at least two separate and different types of computer readable media: computer storage media and transmission media.

  [0021] Computer storage media may include RAM, ROM, EEPROM, CD-ROM, solid state device (SSD) based on RAM, flash memory, phase change memory (PCM), or other types of memory, or Can be used to store other optical disk storage, magnetic disk storage or other magnetic storage devices, or desired program code means in the form of computer-executable instructions, data, or data structures, Any other medium that can be accessed by a special purpose computer is included.

  [0022] A "network" is defined as one or more data links and / or data switches that allow the transport of electronic data between computer systems and / or modules and / or other electronic devices. It is done. When information is transferred or provided to a computer over a network (hardwire, wireless, or a combination of hardwire or wireless), the computer properly regards this connection as a transmission medium. Transmission media can be used to carry data or desired program code means in the form of computer-executable instructions or data structures and can be accessed by a general purpose or special purpose computer Can be included. Combinations of the above should also be included within the scope of computer-readable media.

  [0023] Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures are automatically transferred from a transmission medium to a computer storage medium (or vice versa). be able to. For example, computer-executable instructions or data structures received over a network or data link are buffered in RAM within a network interface module (eg, a network interface card, or “NIC”), and finally Computer system RAM and / or computer storage media that is less volatile in the computer system. Thus, it will be appreciated that a computer storage medium may be included in a computer system component that also utilizes a transmission medium (or even a computer system component that primarily utilizes a communication medium).

  [0024] Computer-executable (or computer-interpretable) instructions include, for example, instructions that cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions may include, for example, binary, intermediate format instructions such as assembly language, or even source code. Although the subject matter is described in language specific to structural features and / or methodological operations, the subject matter defined in the claims appended hereto is not necessarily limited to the features described or the operations described above. Needless to say. On the contrary, the described features and acts are only disclosed as example forms of implementing the claims.

  It will be appreciated by those skilled in the art that the present invention can be implemented in a network computing environment with a plurality of types of computer system configurations. Computer system configurations include personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers , Mainframe computers, mobile phones, PDAs, pagers, routers, switches, etc. The present invention can also be implemented in a distributed system environment, in which a local computer system and a remote computer system are linked via a network (hardwire data link, wireless data link). Or any combination of hardwire and wireless data links), each performing a task (eg, cloud computing, cloud services, etc.). In a distributed system environment, program modules may be located in both local and remote memory storage devices.

  [0026] FIG. 1 illustrates a computer architecture 100 that can employ the principles of the present invention. Computer architecture 100 includes a computer system 101. The computer system 101 may be any type of local computer system or distributed computer system, including a cloud computing system. A computer system can include a variety of different modules to perform a variety of different tasks. The computer system uses a variety of different interfaces to allow user interaction with the system. In some embodiments, a computer system may provide an integrated development environment (IDE) 107 that allows a developer to develop a software program. That is, in some cases, user 105 may be a developer and input 106 can be sent to interact with the IDE. The IDE can provide access to a variety of different programming constructs and other elements. In some cases, this can also include a metadata reader 115.

  [0027] Some embodiments described herein provide a single metadata file that presents one type of different views to different metadata consumers. This different view can be presented when the metadata is being read without forcing the metadata reader 115 to make these changes during execution. When a metadata reader is instantiated (over) by the object model description 116, the reader is required to detect the encoding of that metadata and make this metadata appear natural to the reader's consumer. You can determine the changes to get. The reader wraps this metadata in an adapter (eg, adaptation module 125), which allows the metadata reader consumer to be foreign (or “non-native” here) without modification. Change the encoding of the metadata so that it can operate over the encoding (eg, 117). Embodiments also describe encoding metadata that enables conversion in an efficient manner. As used herein, “native” encoding refers to metadata encoding that is in the format expected by the metadata reader. “Native” or foreign encoding refers to any metadata encoding that is not expected by the metadata reader.

  [0028] If the changes are very frequent, multiple copies of the metadata can be made for each type. Each of these copies includes distinguishable characteristics that allow the metadata reader to determine which views should be presented to which metadata consumers. Once a decision has been made, the determined view is provided to each consumer. Metadata consumers can pass choices to the reader and identify their preferred view type. The metadata reader can then use it to select what to present from among the view types. The remaining views are then hidden from the consumer.

  [0029] Some embodiments described in this specification include the following embodiments. 1) Automatic detection by metadata reader of changes required to natively adapt foreign object model encoding, 2) By object model to become a type from different object models instead Referenced type changes, 3) metadata encoding to enable efficient conversion between two different object model type systems, 4) metadata expected by metadata reader consumers -Metadata encoding changes to conform to the encoding standard, 5) Allows metadata consumers to transparently consume various metadata encodings without change, and 6) Different consumption For direct use by mer, one meta data file comprising a plurality of views of a single entity. Views are complete and consistent for each consumer, and only entities that require different views for each consumer have multiple views (ie this is a simple containing 3 copies of the metadata file) Not a simple zip file). That is, metadata consumers can easily specify the type of view they want. The metadata reader may also be able to select a complete and consistent metadata view based on consumer choices.

  [0030] When the metadata adapter 125 is instantiated with an object model 116 description, the adapter is consumed by a client that expects the object model to be in a specific native encoding. If the object model being read is not in its native encoding, the metadata reader detects (120) the change 121 necessary to transform the foreign encoding to the native encoding 126. be able to. An adapter is then instantiated to modify this metadata as it is read by the client, allowing the client to transparently read the metadata in various foreign encodings 117. Other metadata readers can only read in one specific format, rather than dynamically converting between the two formats.

  [0031] As clients of the metadata reader 115 use this reader to understand the object model, the metadata adapter transparently allows many class changes to non-native metadata. Yes, so that the native client can understand it directly. This includes changing the type referenced by the foreign type system to the type used by the native type system, and changing the metadata flag to an equivalent flag in the native system.

  [0032] The object model description 116 can be encoded to prepare for efficient conversion with minimal required processing time space. Embodiments included herein describe such encoding and allow for the conversion of a foreign type system to an in-place metadata reader native type system. . In this encoding, references to the types used by the object model are made via type references. In some cases, other metadata encodings may use a combination of type references and type definition tokens based on the relative position of the token and definition (for example, if they are both in the same metadata file) , Type definition tokens are selected, while if they are in different metadata files, type reference tokens are selected). In the embodiments herein, a type reference token is used even when a type definition token is available because it is in the same metadata file as the definition. By using type reference tokens instead of type definition tokens, the system herein can efficiently redirect types in a way that is expensive to reference by type definition tokens rather than type reference tokens. Is possible.

  [0033] When a type used by a non-native object model is encoded using a type reference, adapter 125 converts between type systems by converting the type reference target in-place. While leaving other users of the reference unchanged in the metadata. This allows retargeting of all foreign types to native types without the need to scan or update the entire metadata table.

  [0034] In addition, most of the types described in the metadata container have one view, which can be shared among many different consumers, and as explained above, the minimum It only needs to be adapted. However, there are types of classes that may use different views for different customers. Other implementations typically have multiple separate copies of the entire metadata file (one complete copy per view), or adapt or rewrite metadata during execution depending on the consumer Would have tried. The multiple copy solution allows the metadata deployer to manage two separate files, increasing complexity and having a type of unwanted copy that has a shared representation for both consumers. There is a risk of hindering performance. Adapting or rewriting on-the-fly will only work if it is a very simple conversion, and any important conversion will be very slow to read, and a new copy of the entire metadata will be temporarily stored in memory or disk. It may even be necessary to generate automatically.

  [0035] The embodiments described herein include one metadata container. This metadata container holds one metadata definition for types that should have the same view on all consumers. The metadata container also holds multiple copies of types with different (or need to be different) views. The metadata reader then provides each consumer with a different view of this container, showing that consumer a comprehensive view for the type that has them and only a consumer specific view for the rest. These concepts are further described below with respect to the methods 200 and 300 of FIGS. 2 and 3, respectively.

  [0036] With respect to the systems and architectures described above, the methods that can be implemented in accordance with the disclosed subject matter can be more fully appreciated with reference to the flow charts of FIGS. For simplicity of explanation, the method is shown and described as a series of blocks. However, it should be appreciated that the claimed subject matter is not limited to the order of these blocks. This is because some blocks may appear in a different order than shown and described herein and / or may appear simultaneously with other blocks. Further, not all illustrated blocks may be required to implement the methods described below.

  [0037] FIG. 2 shows a flow chart of a method 200 for dynamically adapting metadata for use with native data encoding. The method 200 will now be described with frequent reference to the components and data of the environment 100.

  [0038] The method 200 includes an act of instantiating a metadata reader with an object model description to access one or more portions of the metadata in the object model description, the metadata reader comprising: Configured to read native metadata, the native metadata includes metadata represented in an encoding expected by the metadata reader (operation 210). For example, the instantiation module 110 can instantiate the metadata reader 115 with the object model description 116. A metadata reader can be instantiated to access the metadata portion of the object model description. The metadata may be a native type (126), or a foreign, non-native type (117). The metadata reader is configured to read metadata encoded in the native format, but may not be able to read metadata encoded in any of a variety of different non-native formats Good. That is, the metadata reader determines that the accessed metadata has been encoded with non-native encoding (operation 220), and further performs the meta-data to be performed to convert this non-native encoding to native encoding. Data change is determined (operation 230).

  [0039] The modification may include changing (or re-encoding) a type referenced by non-native encoding to a type used by native encoding. The modification may also include changing a non-native encoding metadata flag to a native encoding metadata flag. Thus, after the change, the metadata reader can recognize the metadata flag. Other modifications can also be performed separately or in addition to those described above. In some cases, the data type can be rewritten to conform to the native encoding. These data types can be dynamically rewritten to make them readable and otherwise accessible to the metadata reader.

  [0040] The method 200 also dynamically changes the object model metadata from a non-native encoding to a native encoding according to the determined change so that the object model is readable by the native runtime. Also includes an action to adapt (act 240). For example, the adaptation module 125 can dynamically adapt the non-native metadata 117 to the native encoding 126 using decision changes 121 determined by the module 120. After the changes are applied, the object model 116 becomes readable by the native runtime. In this way, dynamic adaptation allows the user to read multiple different non-native encoding metadata. Regardless of the non-native encoding in which the metadata is encoded, the system described uses one or more different modifications to adapt the metadata to the native encoding readable by the metadata reader Turn into.

  [0041] In some embodiments, dynamic adaptation may be performed at the metadata import-read level. By adapting the metadata at the import-read level, subsequent adaptation at runtime can be avoided. In some cases, a visibility modifier may be applied to visualize dynamically adapted metadata internally or publicly. This visualization modifier can also be changed in the metadata by the developer 105 as desired.

  FIG. 3 shows a flow chart of a method 300 for efficiently changing object model type references. The method 300 will now be described with frequent reference to the components and data of the environment 100.

  [0043] The method 300 includes an act of instantiating a type lookup table (act 310). The type reference table receives a type definition request and responds with one or more type reference tokens stored in metadata that can be read by the metadata reader to provide a suitable type definition Composed. For example, the instantiation module 110 can instantiate the type lookup table 130. The type reference table 130 receives the type definition request and responds to provide a type definition 131 using the various type reference tokens stored in the metadata 117. The type lookup table 130 includes metadata that can be read by the metadata reader 115. The instantiated type lookup table receives a type definition request for the specified type from the type requester (operation 320). A type reference token is then implemented in the metadata of the type reference table 130 to move one or more types to the metadata reader 115 based on the requested type and the type readable by the metadata reader. (Operation 330). Thus, the types are dynamically exchanged using type look-up tables as required and as needed. Non-native type references are exchanged in-place with native type references. These dynamic exchanges provide a non-native type standardized view to the metadata reader.

  [0044] The method 300 also includes an act of providing the requested type definition to the type requester based on the dynamically exchanged type provided by the type reference token in the metadata (act 340). That is, the type reference table 130 can give the type definition 131 to the type requester based on the dynamically exchanged type. The type reference table may be instantiated to confirm that the type requester's request was received via the type reference. Types are exchanged in the type lookup table. In this way, the user request remains unchanged, but the native type definition is used instead of the non-native definition.

  [0045] Both native and non-native encodings of metadata can be created in the same metadata file. That is, the same metadata file can contain more than one encoding. If a metadata file has multiple encodings, the metadata reader determines the user requesting the metadata file, and based on this determination, determines the appropriate encoding for the metadata file. Can be passed to the user. Thus, when a user requests native encoding, a native view or native encoding is sent to the user. In this way, the encoding is complete and consistent for each user. To prepare for efficient execution, only metadata files that are accessed by different types of users are encoded in both native and non-native encodings. As mentioned above, dynamic adaptation can include a variety of different modification methods, changing the type referenced by non-native encoding to the type used by native encoding, and non-native encoding. Changing the encoding metadata flag to the native encoding metadata flag. In this way, various types of non-native metadata can be dynamically adapted for use with native data encoding.

  [0046] Additional embodiments are described with reference to FIGS. For example, in FIG. 4, the interaction between a native client, a metadata reader, an adapter, and a foreign object model is illustrated. Metadata received in the foreign encoding (454) may be sent to the metadata adaptation module 453 in order to be adapted to native encoding readable by the metadata reader 452. Native metadata client 450 (the other side of API boundary 451) can interact with a metadata reader (eg, using an API) to access natively encoded metadata.

  [0047] FIG. 5 illustrates metadata encoding using type references when using multiple types. For example, type consumer 510 may include type 1 (511A) and one or more other types (type n (511N)). These types can be linked to a foreign type definition (eg, 502A) via a type reference (506A). That is, type 1 (511A) can be linked to foreign type definition 1 (502A) via type reference 506A. Similarly, other types (type n) can be linked to foreign type definition 502N via type reference 506N. Foreign type definitions are stored in a type definition table 501, while type references are stored in a type reference table 505.

  [0048] FIG. 6 illustrates the conversion from a foreign type system to a native type system with in-place change of type reference. Thus, while type references 506A and 506N already pointed to foreign type definitions 502A and 502N (FIG. 5), the type references can be changed to point to different native type definitions. That is, the type reference 506A may be changed to point to the native type definition 626A, and the type reference 506N may be changed to point to the native type definition 626N. Thus, a foreign type system can be converted to a native type system.

  [0049] FIG. 7 illustrates that within a metadata container, each entity requesting multiple metadata views can have a separate copy of the view. These copies then reference shared views for entities that do not require different views. Thus, entity A in the metadata container 705 can have two different views: a first view 710A and a second view 710B. And entity A has two views, while entities B and C each have their own generic metadata views (711 and 712, respectively). Further, FIG. 8 shows that the metadata reader can automatically give the first metadata consumer 701A a view of the entity in the metadata container 705 that is consistent with its desired view. Thus, since consumer 701A prefers metadata view 710A, metadata reader 702 shows view 710A to entity A and shows generic views to entities B and C (711 and 712). FIG. 9 illustrates that the metadata reader 702 automatically gives the metadata consumer 710B a view of the entity in the metadata container that is consistent with its desired view. Thus, since consumer 701B prefers metadata view 701B, metadata reader 702 shows view 710B to entity A and shows generic views to entities B and C (711 and 712).

  [0050] Accordingly, methods, systems, and computer program products are provided for dynamically adapting metadata for use in native data encoding. In addition, methods, systems, and computer program products are provided for efficiently changing object model type references.

  [0051] The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that fall within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims (10)

A computer-implemented method for efficiently changing an object model type reference in a computer network environment including a plurality of computing systems in a computer system including at least one processor and memory, comprising:
One or more types stored in a metadata file readable by a metadata reader in response to a type definition request, in response to instantiating a type lookup table An operation configured to use a reference token to provide an appropriate type definition, wherein the metadata file includes native and non-native encodings of the same metadata in the metadata file;
An operation in which the instantiated type reference table receives a type definition request for a specified type from a type requester;
In order to dynamically exchange one or more types for the metadata reader, based on which type is requested and which type is suitable for the current consumer of the metadata reader, Implementing a type reference token in the metadata of the type reference table;
Providing the requested type definition to the type requester based on a dynamically exchanged type provided by the type reference token in the metadata;
Including a computer-implemented method.   The method of claim 1, wherein non-native type references are exchanged in-place with native type references.   The method of claim 1, wherein the dynamic exchange provides a non-native type standardized view to the metadata reader.   The method of claim 1, wherein the type lookup table is instantiated to ensure that the type requester's request is received via a type reference.   The method of claim 1, wherein the types are exchanged in the type lookup table so that user requests do not change while native type definitions are used instead of non-native definitions. A computer system,
One or more processors;
System memory and
One or more computer- readable storage media storing computer- executable instructions ;
Including
When the computer- executable instructions are executed by the one or more processors, the computer system executes a method for efficiently changing an object model type reference, the method comprising:
One or more types stored in a metadata file readable by a metadata reader in response to a type definition request, in response to instantiating a type lookup table An operation configured to use a reference token to provide an appropriate type definition, wherein the metadata file includes native and non-native encodings of the same metadata in the metadata file;
An operation in which the instantiated type reference table receives a type definition request for a specified type from a type requester;
In order to dynamically exchange one or more types for the metadata reader, based on which type is requested and which type is suitable for the current consumer of the metadata reader, Implementing a type reference token in the metadata of the type reference table;
Providing the requested type definition to the type requester based on a dynamically exchanged type provided by the type reference token in the metadata;
Including computer systems. 7. The computer system of claim 6 , wherein non-native type references are exchanged in-place with native type references. 7. The computer system of claim 6 , wherein the dynamic exchange provides a non-native type standardized view to the metadata reader. The computer system of claim 6 , wherein the type lookup table is instantiated to ensure that the type requester's request is received via a type reference. 7. The computer system of claim 6 , wherein the types are exchanged in the type lookup table so that user requirements do not change while native type definitions are used instead of non-native definitions. .

Images