Search

CN-121996223-A - Method for automatically generating OSDK based on ontology entity metadata

CN121996223ACN 121996223 ACN121996223 ACN 121996223ACN-121996223-A

Abstract

The invention belongs to the technical field of information technology and software development tools, and particularly relates to a method for automatically generating OSDK based on entity metadata of an entity, which solves the problems of high coding cost, multi-map conflict and non-uniform protocol caused by entity change. The method comprises the steps of collecting and normalizing entity metadata, constructing an object description structure comprising class definitions and constraints, automatically generating entity classes and access interfaces, mapping and editing the interfaces according to the constraints and constructing loads, converting objectified calls into standardized requests and analyzing results, implementing map-level isolation loading, monitoring changes and triggering differential thermal updating. The invention realizes real-time synchronization of the modeling end and the development end, ensures consistency and standardization of entity access logic while solving naming conflict, and remarkably improves reliability and maintenance efficiency of the system.

Inventors

  • Guo Pengzhan
  • LUO JIANFENG
  • MA WANLI
  • ZHANG JIE
  • ZHAO ZHENGBIN
  • CAI WEI
  • LI QIJIAN
  • YAN JIE

Assignees

  • 中电安世(成都)科技有限公司

Dates

Publication Date
20260508
Application Date
20260407

Claims (8)

  1. 1. A method for automatically generating OSDK based on ontology entity metadata, comprising the steps of: S1, interfacing a knowledge graph modeling service through a preset interface protocol, extracting original metadata, performing integrity check and naming regularity on the original metadata, completing type normalization processing according to a preset mapping matrix, converting the modeling platform type into a target programming language strong type identifier, and combining a main key and an empty mark to form normalized entity metadata; S2, constructing a multi-dimensional object description structure serving as a middleware of a metadata and code generation layer in a memory based on normalized entity metadata, wherein the multi-dimensional object description structure comprises an object class name, a module path identifier, a map global unique identifier, an entity unique serial number, a field definition list, a main key field index set, a non-empty constraint field set, an editable field set and metadata display information; S3, automatically generating a target language entity object class inherited from a preset body object base class, encapsulation serialization and attribute observer logic according to an object description structure, implanting an object access interface in the entity object class, acquiring a query interface object with chained calling capability through the interface, and maintaining a query state machine in the query interface object to realize transparent access of bottom map data; s4, automatically generating an entity editing capability set according to a main key field index set, a non-null constraint field set and an editable field set in the object description structure, capturing field changes through an attribute observer and comparing constraint rules when new addition or modification operation is initiated, and constructing editing request data containing physical field mapping; S5, converting the application layer objectification call into a standardized communication request of a server specification, after receiving a server response, mapping the original data into an entity object class instance or set according to an object description structure by a result analysis engine, and executing type secondary verification; s6, constructing an operation environment according to spectrum isolation, creating independent operation catalogues for each spectrum in a physical memory to store source codes and byte code files, and realizing name space isolation among the spectrums through a custom class loader; And S7, polling a modeling service change log, triggering a differential updating flow when metadata change is detected, re-executing the steps S2 to S4 to generate a new object description structure and a new entity object class, and reloading the updated class definition by a corresponding class loader through a hot reload instruction.
  2. 2. The method of claim 1, wherein the type normalization process of step S1 further comprises recognition logic for the complex data structure: When the date and time type is processed, uniformly adopting a specified standard format as an intermediate conversion protocol, and automatically configuring a corresponding date analyzer when the entity object class is generated; The step S1 also comprises automatic processing logic of field mapping conflict, wherein when the original field name of the entity contains reserved keywords of the target language, legal object attribute names are generated through a preset renaming rule, and mapping relation pairs of physical field names and logical attribute names are recorded in the object description structure: P map =(FieldName raw ,AttributeName obj ),P map is a field mapping tuple, FIELDNAME raw is an original physical field name, and AttributeName obj is an object logical attribute name.
  3. 3. The method of claim 1, wherein the object description structure in step S2 is defined as nine tuples: ODS={N cls , M mod , ID graph , ID ent , L field , L pk , L req , L edit , I info }; the method comprises the steps of N cls , M mod , ID graph , ID ent , L field , L pk , L req , L edit , I info and I info , wherein the N cls is an object class name following a hump naming method, the M mod is a module path identifier, the ID graph is a map global unique identifier, the ID ent is an entity unique serial number, the L field is a field definition list comprising a physical name, a logical name and a normalization type, the L pk is a main key field index set, the L req is a non-empty constraint field set, the L edit is an editable field set excluding a main key, and the I info is metadata information comprising a display name and a meta description.
  4. 4. The method according to claim 3, wherein the entity object class generated in step S3 is written into a static field definition by a meta programming technique to record a map ID and an entity ID corresponding to the entity, the entity object base class implements an observer mode for monitoring a change state of an object attribute in real time and recording the change state in an internal state bitmap, the object access interface adopts a responsive programming model, the query interface object implements a streaming construction of a query condition by defined operators, each operator call returns a new interface object copy to ensure invariance of query expression, and a chained call stack is parsed into a logical query tree to generate a standardized query domain specific language DSL at run-time.
  5. 5. The method for automatically generating OSDK based on entity metadata according to claim 1, wherein the editing request data generating process in step S4 includes a pre-verification engine, wherein the pre-verification engine scans a non-empty constraint field set before constructing a newly added payload, throws out a structured exception and prevents a request from entering a network layer if a filling-in missing is found, and when constructing a modified payload, adopts a dirty checking technology to include only fields which have actual value offset and belong to an editable field set into an update payload by comparing an original value with a current value in the entity object class instance.
  6. 6. The method for automatically generating OSDK based on entity metadata according to claim 1, wherein the result parsing engine in step S5 sets a multi-level cache mechanism, maintains an object pool in a memory according to a map global unique identifier and an entity unique serial number, and for repeated query requests with the same primary key identifier, the parsing engine preferentially retrieves instantiated objects from the object pool and manages object lifecycles by using a weak reference mechanism, and the result parsing engine adopts a streaming parsing technology, instantiates the objects while reading streaming data of a server, and calls a type converter in real time to normalize each line of data.
  7. 7. The method of claim 1, wherein the schema-level isolation mechanism in step S6 further involves isolating versions of third-party dependency libraries by configuring separate resource description files for each schema-generated code space and maintaining a schema-level object list that records a structural signature for each entity, ensuring validity of the reference by checking the structural signature when referencing the entity across the schemas, and the class loader preferentially retrieves the running catalog of the corresponding schema to resolve the co-name entity conflict when loading the entity class.
  8. 8. The method for automatically generating OSDK based on ontology entity metadata according to claim 7, wherein the synchronization updating process in step S7 adopts a double-buffer switching strategy, namely, in the process of regenerating and compiling a class file, the object class of the old version still provides services to the outside, and only after the new version class completely passes the compiling verification and is successfully loaded into the shadow space, the transient reloading in the running process is realized by switching the reference pointer of the class loader, so that the metadata updating process is ensured to have no perception to the service layer in the high-concurrency access scene.

Description

Method for automatically generating OSDK based on ontology entity metadata Technical Field The invention belongs to the technical fields of information technology and software development tools, and particularly relates to a method for automatically generating OSDK based on ontology entity metadata. Background In the current knowledge-driven-core cognitive intelligent field, knowledge graph systems have become an infrastructure for processing large-scale unstructured data and implementing semantic association. As a core link of knowledge graph construction, ontology modeling defines key metadata such as names, unique identifiers, field attributes, data types, primary key constraints, associated descriptions and the like of entities through abstracting objective world entities. The metadata is not only the basis for the pattern definition of the bottom layer graph database, but also the logic skeleton of the upper layer business program for realizing data access and logic processing. In order for a business developer to efficiently interact with complex graph entities, a set of Software Development Kits (SDKs) are typically required to encapsulate the underlying communication protocols and data mapping logic. In the traditional technical implementation framework, the construction of the entity access capability is highly dependent on a manual coding process, namely, after the modeling activity is completed, a developer manually writes corresponding entity object classes (ENTITY CLASS), query condition packaging structures, editing parameter objects and request logic codes for interfacing with a back-end data service one by one according to a definition manual of a modeling platform. In a specific technical development stage, the manually driven coding mode meets the customization requirement of business logic to a certain extent. Through a hard coding mode, a developer can conduct fine-grained access control and result analysis aiming at each specific entity, and the attribute of the entity is accurately mapped to class members in the program language. However, as knowledge graph application scenes evolve toward agility, dynamics and multi-graph parallelization, the technical path based on static code maintenance gradually shows the inherent contradiction of the principle level. From the technical evolution perspective, the life cycle of the entity and the corresponding coding environment have obvious pace difference, namely entity metadata in a modeling platform are always in continuous optimization and adjustment, whether field addition and deletion, type normalization correction and main key rule redefinition belong to modeling activities which occur at high frequency, and artificially written SDK codes are essentially logical snapshots of the metadata at a specific time point, and the static snapshot mechanism leads to physical isolation between modeling results and object codes, so that any tiny offset of the metadata can be fed back to a development environment only through long manual reconstruction and release cycles, and the consistency and response speed of the system are greatly damaged. Deep analysis of the deep technical contradiction can be found that the entity object class, the filtering condition load and the call execution logic are usually maintained as independent units in the prior art. Such a fragmented maintenance mode is particularly vulnerable when dealing with complex constraints, such as rule-filling, editable rights, and primary key positioning policies of entities, and often is scattered in different check modules and logical loads at the code level. Because of the lack of a unified metadata driven model, the recognition of these constraints by the system is completely dependent on the experience judgment of the developer, which not only causes a great deal of repetitive labor, but also inevitably introduces hidden faults such as field mapping omission or inconsistent types. Further, under complex industrial working conditions supporting multi-map parallelism, different maps may have entities with the same name but different structures, and the existing class loading mechanism and interface definition mode often have difficulty in providing perfect namespace isolation and runtime switching capability, so that symbol conflict and memory logic coverage are very easy to generate in the concurrent operation or hot update process of the entities with the same name, thereby causing serious service execution deviation. A more critical bottleneck is that, due to the lack of a full-link automatic generation mechanism for invoking from metadata to the underlying service, the system often exhibits the feature of varying styles and scattered check rules for the construction of query (recall), add (Create), modify (Update), and Delete (Delete) capabilities of the entity. In a runtime environment, since the server execution logic is based on the latest metadata model, and the OSDK logic of the