Partition-Aware EJB Server Components for Multitenant Isolation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing application server technologies face challenges in supporting Enterprise Java Bean (EJB) and other application types in a multitenant environment, particularly in efficiently managing resource-heavy processing and isolating tenant-specific resources across partitions.
Innovation Solution
A system and method that includes an application server domain with partitions, an EJB container, and partition-aware server components, allowing for partition-specific code deployment and resource-heavy processing delegation, while ensuring tenant isolation through globally unique partition identifiers and resource group templates.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If traditional application server components are used in a cloud environment, then existing EJB support is maintained, but resource management efficiency and tenant isolation deteriorate
Solution Approach 1:
The application server is segmented into multiple independent partitions, each capable of running EJB applications for different tenants. Each partition has its own instance of server components (EJB container, connection pools, security realms), enabling isolated resource management and tenant-specific resource allocation without affecting other tenants. This segmentation resolves the contradiction by improving resource management efficiency through dedicated partition resources while maintaining manageable complexity through modular partition design.
Solution Approach 2:
The partition-aware server components are designed with multi-functionality to operate both within a single partition and across multiple partitions. The same server component can serve different tenants in different partitions, providing universal resource management capabilities. This universality improves resource management efficiency by allowing shared resources across partitions while maintaining tenant isolation through partition-specific code execution contexts.
2Reliability
If partition-specific code is deployed to each partition, then tenant isolation is improved, but deployment complexity increases
Solution Approach 1:
The deployment system uses a nested structure where partition-specific code instances are deployed within the context of a parent application deployment. The deployment tooling automatically manages the nesting of partition-specific instances within the EJB container, handling the complexity of deploying multiple code instances simultaneously. This nesting approach improves tenant isolation by ensuring each partition has its own code instance while reducing deployment complexity through automated nested deployment management.
Solution Approach 2:
The system uses code copying mechanisms to replicate partition-specific EJB application instances across multiple partitions. Instead of manual deployment to each partition, the deployment tooling creates copies of the application code and automatically places them in the appropriate partition contexts. This copying approach improves tenant isolation by ensuring each partition receives its own code copy while simplifying deployment through automated replication rather than manual configuration.
3Productivity
If resource-heavy processing is delegated to server components, then EJB application performance is improved, but server component complexity increases
Solution Approach 1:
Resource-heavy processing operations are extracted from the EJB application code and delegated to dedicated server components. Examples include connection pooling, security authentication, and transaction management, which are handled by specialized server components rather than within the EJB applications themselves. This extraction improves EJB application performance by reducing the processing burden on application code while managing complexity through dedicated, purpose-built server components that can be optimized independently.
Solution Approach 2:
Partition-aware server components act as intermediaries between the EJB applications and the underlying system resources. These intermediary components handle resource-heavy operations such as database connections, security contexts, and transaction coordination, shielding the EJB applications from direct complexity. The intermediary server components improve application performance by centralizing resource management while containing complexity within the intermediary layer rather than within the application code itself.
Data Source
AI summary
In accordance with an embodiment, described herein is a system and method for supporting Enterprise Java Bean (EJB) and other application types in a multitenant application server environment. The system includes an application server domain with a plurality of partitions, an EJB application, and a plurality of partition-aware server components that interact with the EJB container. The EJB application includes partition-specific code deployed as a separate instance to each partition, and shareable resources across two or more partitions. The system can additionally delegate resource-heavy processing functions of each EJB application to one or more of the server components. At runtime, the system receives a request for an EJB application in a particular partition, and creates an object to hold information of the particular partition. The server components, when invoked by the EJB container, obtains the partition information and execute in a context of the particular partition.