Virtual Properties in Java XML Binding for Multi-Tenant Customization

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current systems, such as JAXB, struggle to handle per-tenant customizations in multi-tenant applications, as they are designed to work with domain models that have real fields and properties, making it difficult to manage virtual properties and provide adequate customization for different users.

Innovation Solution

The implementation of virtual properties defined by a metadata file allows users to extend Java classes without modifying the source, enabling customization through accessor methods that can be used to maintain extension data, and are supported in EclipseLink environments for object-to-XML mappings.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If typical XML binders like JAXB are used to map Java fields to XML, then the binding layer can handle standard domain models effectively, but it becomes difficult to handle per-tenant customizations and virtual properties in multi-tenant applications

Engineering Contradiction:
Improvecustomization capabilityVSAvoidbinding layer complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the properties into two distinct categories: real properties (defined in the Java class itself) and virtual properties (defined in external metadata files). This segmentation allows the binding layer to handle standard properties through conventional JAXB mechanisms while routing virtual properties through a specialized validation and mapping process, thereby managing complexity through structured division of labor.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces an intermediary validation mechanism that sits between the XML binder and the domain model. This intermediary validates virtual properties against metadata definitions before they are bound to the Java object, allowing the binding layer to accommodate customizations without directly handling the complexity of each virtual property definition.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If users are provided with a set of default properties in a generic application, then the application can serve multiple users broadly, but the default properties are insufficient to capture all data relevant to particular users

Engineering Contradiction:
Improveper-tenant customizationVSAvoidnumber of properties
Core Design Contradiction:
Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

The patent creates a universal property handling mechanism that can process both real properties (standard Java fields) and virtual properties (custom attributes) through a unified binding interface. The metadata-driven approach allows the same binding infrastructure to serve multiple tenants with different property sets, making the system multi-functional without requiring separate binding logic for each tenant.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent implements dynamic property configuration where the set of available properties is not fixed at compile time but can be extended at runtime through metadata files. Each tenant can dynamically add virtual properties to the domain model without modifying the underlying Java class, allowing the property quantity to adapt to each tenant's specific needs.

Inventive Principle:
Principle #15Dynamics

3Ease of manufacture

If virtual properties are defined by a metadata file to extend Java classes without modifying source, then users can customize applications, but the binding layer must handle additional complexity in mapping these virtual properties

Engineering Contradiction:
Improveclass extension easeVSAvoidmapping complexity
Core Design Contradiction:
Ease of manufactureVSDevice complexity

Solution Approach 1:

The patent uses metadata files as a copy or representation of the domain model's extended structure. Instead of modifying the actual Java class source code, the system creates a metadata copy that describes virtual properties and their mappings. This metadata copy is then used by the binding layer to generate appropriate mapping logic, simplifying the extension process while managing mapping complexity through automated code generation from the metadata template.

Inventive Principle:
Principle #26Copying

Data Source

PatentUS9529576B2Systems and methods for object to XML mappings
Publication Date: 2016.12.27 ORACLE INT CORP
  • US9529576B2 patent drawing
  • US9529576B2 patent drawing
  • US9529576B2 patent drawing

AI summary

Systems and methods are provided for automatically provisioning resources based on application characteristics. In accordance with an embodiment, a system can include a computer, including a computer readable medium and processor. The system can further include one or more servers executing on the computer and an extensible application deployed to the one or more servers, wherein the application includes a plurality of real properties. A plurality of tenants can each utilize the application at the one or more servers. The extensible application is configured to be customized for each tenant, wherein customizing includes for each tenant, defining one or more virtual properties for the application in a metadata file, and mapping the one or more virtual properties to the application using the metadata file.