Resource Proxies for Multi-Tenant Java Isolation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing application server technologies face challenges in efficiently supporting multi-tenancy for enterprise Java applications, leading to redundancy and difficulties in isolating and managing resources across multiple tenants.

Innovation Solution

The system employs resource proxies and application tenancy context to enable multi-tenancy by allowing a single Java EE application instance to serve multiple tenants, using resource proxies to communicate with tenant-specific resources and manage resources on a per-tenant basis, supporting both shared and tenant-specific customizations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If a single Java EE application instance serves multiple tenants using resource proxies, then resource redundancy is reduced and resource management efficiency is improved, but system complexity increases due to the need for resource proxy configuration and tenancy context management

Engineering Contradiction:
Improveresource management efficiencyVSAvoidsystem complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent introduces resource proxies as intermediary objects between the shared Java EE application instance and tenant-specific resources. These proxies abstract the complexity of resource allocation from the application code, allowing a single application instance to efficiently access multiple tenant-specific resources (databases, JMS queues, etc.) without increasing application-level complexity. The resource proxy layer handles the mediation between shared code and tenant-specific infrastructure.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the resource access layer by introducing separate resource proxy objects for different resource types (JDBC proxies for databases, JMS proxies for message queues, etc.). Each proxy is configured with tenant-specific connection parameters while maintaining a unified interface in the application code. This segmentation allows independent configuration and management of each resource type without affecting other parts of the system.

Inventive Principle:
Principle #1Segmentation

2Reliability

If resource proxies are used to enable multi-tenancy, then inter-tenant isolation is improved, but configuration complexity increases due to the need to manage multiple resource proxy instances and their tenant-specific settings

Engineering Contradiction:
Improveinter-tenant isolationVSAvoidconfiguration complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements universal resource proxy classes that can serve multiple tenants through a single codebase. The same JDBC Proxy class, for example, can be configured to connect to different databases for different tenants by loading tenant-specific connection parameters from configuration files or system properties. This universality eliminates the need for separate proxy implementations for each tenant while maintaining strong isolation through configuration-based resource routing.

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

Solution Approach 2:

The patent leverages parameter changes in configuration files and system properties to enable a single resource proxy implementation to adapt to different tenants. By changing connection parameters (URL, username, password, pool size) based on the current tenant context, the system achieves isolation without requiring code changes. The resource proxy reads tenant-specific parameters at runtime and adjusts its behavior accordingly, simplifying deployment while maintaining isolation.

Inventive Principle:
Principle #35Parameter changes

3Reliability

If tenant-specific resources are instantiated separately for each tenant, then inter-tenant isolation is strengthened, but resource sharing and cost efficiency are reduced

Engineering Contradiction:
Improveinter-tenant isolationVSAvoidresource redundancy
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The patent merges the infrastructure layer by implementing shared resource pools that serve multiple tenants through resource proxies. Instead of having completely separate databases and message queues for each tenant, the system uses a single database instance with schema-level isolation or a single message queue with topic-based routing. The resource proxy layer merges access to these shared resources while maintaining logical separation between tenants, reducing infrastructure redundancy and costs.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The patent uses virtual copying through resource proxies that present tenant-specific resource views to the application. Rather than physically replicating entire infrastructure stacks for each tenant, the system creates virtual copies of resource interfaces that route to shared underlying resources. This allows tenant-specific customization and isolation while sharing actual physical resources, achieving a balance between isolation and efficiency.

Inventive Principle:
Principle #26Copying

Data Source

PatentUS10050903B2System and method for multi-tenancy enablement of enterprise JAVA (TM) applications using resource proxies and application tenancy context
Publication Date: 2018.08.14 ORACLE INT CORP
  • US10050903B2 patent drawing
  • US10050903B2 patent drawing
  • US10050903B2 patent drawing

AI summary

In accordance with an embodiment, described herein is a system and method for multi-tenancy enablement of enterprise Java™ applications using resource proxies and application tenancy context. In according with an embodiment, the system and method can provide a plurality of deployable resources which can be used within the application server environment, and one or more application deployments, wherein each application deployment includes at least one of tenant-specific code and shared-tenant code. The system and method can further determine an application tenancy context of a thread, and point to one or more resource proxies, each of the one or more resource proxies being configurable to communicate with a tenant specific resource. Each of the one or more resource proxies can use the application tenancy context of a thread to communicate with a tenant specific resource.