2 WebLogic Server Multitenant

WebLogic Server Multitenant enhances the Oracle Platform for Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) and provides end-to-end lifecycle management—Web tier, middle tier, cache, and database.

This document introduces WebLogic Server Multitenant (MT) and describes its use in multitenant environments.



Many new WebLogic Server MT features such as resource groups, resource group templates, and deployment plan overrides are also available in the 12.2.1, non-MT version of WebLogic Server. This chapter notes when a given feature is available in the non-MT version and refers to the WebLogic Server documentation and online help where appropriate.

About WebLogic Server MT

Multitenancy in WebLogic Server provides a sharable infrastructure for use by multiple organizations. These organizations are a conceptual grouping of your own choosing, which you can think of as tenants. By allowing one domain to support multiple tenants, WebLogic Server MT improves density and achieves a more efficient use of resources while eliminating the hurdles typically present when trying to share multiple applications: runtime cross-application impact, security differences, data co-mingling, and administrative challenges.

WebLogic Server MT provides resource isolation within a domain partition, an administrative and runtime slice of a WebLogic domain that is dedicated to running application instances and related resources for a tenant. Domain partitions achieve greater density by allowing application instances and related resources to share the domain, WebLogic Server itself, the Java virtual machine, and the operating system while isolating tenant-specific application data, configuration, and runtime traffic, as shown in Figure 2-1.

Figure 2-1 WebLogic Server Domain Partitions

Description of Figure 2-1 follows
Description of ''Figure 2-1 WebLogic Server Domain Partitions ''

Each domain partition has its own runtime copy of the applications and resources. Changes in how WebLogic Server handles class loading provide both application isolation and efficiency. Deploying to multitenant environments requires no changes to your applications. For example, you could run multiple instances of a payroll application in different domain partitions without modifying the application.

WebLogic Server MT enables an end to end multitenant infrastructure, including multitenancy from the load balancer to the middle tier and cache tier, and to the database tier. WebLogic Server MT extends the Oracle WebLogic Server Enterprise Edition and Oracle WebLogic Suite products, and includes the following components:

  • Oracle WebLogic Server MT, which enables the consolidation of applications into fewer domains (by allowing partitions within domains) while maintaining secure isolation

  • WebLogic MT extensions to Java SE Advanced, which enables memory, CPU and I/O isolation, monitoring, and management for applications within a JVM

  • Oracle WebLogic Coherence Enterprise Edition to Grid Edition option, which enables the consolidation of caches into fewer Oracle Coherence clusters while maintaining secure isolation

  • Oracle Traffic Director, which provides WebLogic Server MT-aware and fully integrated tenant-aware local load balancing

For detailed licensing information, see "Oracle WebLogic Server Multitenant" in the Oracle Fusion Middleware Licensing Information User Manual.

WebLogic Server MT Supports Only Java EE Applications

In this release of WebLogic Server MT, only Java EE applications are supported. Products that depend on Oracle JRF (Java Required Files) are not supported.

Oracle JRF consists of those components not included in the WebLogic Server installation that provide common functionality for Oracle business applications and application frameworks. Oracle JRF consists of a number of independently developed libraries and applications that are deployed into a common location. The following components are considered part of Oracle JRF: Oracle Application Development Framework, Oracle Fusion Middleware Audit Framework, Dynamic Monitoring Service, Fabric Common, HTTP Client, Infrastructure Security, Java Object Cache, JMX Framework, JPS, logging, MDS, OJSP.Next, Oracle Web Services, Oracle Web Services Manager, Oracle TopLink, UCP, XDK.

This means that WebLogic Server MT does not support the following products:

  • Oracle Web Service Manager

  • SOA Suite

  • Application Development Framework (ADF)

  • WebCenter

  • Oracle Service Bus

  • Oracle Enterprise Scheduler

  • WebLogic SCA

Key Concepts in WebLogic Server MT

In addition to domain partitions, WebLogic Server MT includes these new concepts:

  • Tenants—Tenants represent distinct user organizations, such as different external companies (for example, CompanyA and CompanyB), or different departments within a single company (for example, HR and Finance), that use applications and resources within a WebLogic domain.

    A tenant is a logical grouping of your own choosing; it is not a configurable object. That is, you manage domain partitions, not tenants.

    A tenant's identity is the association of a given user with a given tenant. For example, you might choose to associate the tenant Finance with a specific domain partition called Finance-partition.

    The system derives to which tenant a given user belongs from the user's identity as prescribed by the user identity store. Further, the user's identity helps the system enforce what that user will be authorized to do as they move throughout the system, including but not limited to which tenant the user belongs.

  • Resource Groups—A named collection of (typically) related deployable resources, such as Java EE applications and the data sources, JMS artifacts, and other resources that the applications use.

    A traditional WebLogic Server domain may contain many types of deployable resources: Java EE applications, JMS servers and queues, data sources, and such. In this traditional model, if an application suite contains multiple Java EE applications and various resources that support those applications, the administrator defines these resources and deploys these applications individually rather than as a coherent unit.

    WebLogic Server MT introduces resource groups, simply as a convenient way to group together Java EE applications and the resources they use into a distinct administrative unit within the domain. The resources and applications are "fully qualified" in that the administrator provides all the information needed to start or connect to those resources, including credentials for connecting to a data source and targeting information for Java EE applications. A resource group will either contain these deployable resources directly or refer to a resource group template that defines the resources. Resource groups can be defined at the domain level, or be specific to a domain partition.

    All the resources in or referenced by a resource group are targeted together (to the same target). Resource groups can be started and stopped.

  • Resource Group Templates—A named, domain-level collection of deployable resources intended to be used as a pattern by (usually) multiple resource groups. Each resource group that refers to a given template will have its own runtime copies of the resources defined in the template. A resource group template is a convenient way to define and replicate resources for multiple tenants. Resource group templates make it very easy to deploy the same collection of applications and resources to multiple domain partitions.

    Resource group templates can define:

    • Application Deployments

    • Library Deployments

    • JDBC System Resources

    • JMS System Resources

    • Coherence System Resources

    • File Stores

    • JMS Servers

    • Messaging Bridges

    • Path Services

    • Persistent Stores

    • SAF Agents

    • Foreign JNDI Providers

    • Mail Sessions

    • WLDF Modules

    Resource group templates are defined at the domain level, and then referenced by one or more resource groups.

    Resource group templates are particularly useful in a SaaS environment where WebLogic Server MT activates the same applications and resources multiple times, once per domain partition. Some of the information about such resources is the same across all domain partitions, while some of it, such as the attributes of a JMS queue or of a DB connection, varies from one partition to the next. For example, the URL, username, and password used to connect to a data source would be different among different partitions. WebLogic Server MT will activate the application suite represented by the template differently for each partition. You can specify override configuration MBeans and resource deployment plans to override some attribute values in a partition. For more information, see Configuring Resource Overrides.

  • Virtual Targets—Virtual targets encapsulate where a partition or resource group runs and how to route traffic to them, including addresses, protocol settings, and targeting. Request routing is determined by the host name and optional URI.

    May include:

    • Host name and port

    • Optional URI

    • Network Access Point/Channel

    • Protocol specific configuration

    • Target clusters and Managed Servers

    Virtual targets isolate a domain partition and the global (domain-level) runtime from the physical attributes of the target WebLogic Server instances so that your application does not have to know these details.

About Scope

When you deploy an application or library, you have four deployment scope options:

  • Global. This is the equivalent of the domain level in a non-partitioned environment.

  • Resource group template, which is always at the domain level. Whether the application or library you deploy to a resource group template is available at the domain level or a partition depends on the scope of the resource group that references the resource group template.

  • Resource group in a partition. This is the only scope that is limited to a partition.

  • Resource group at the domain level.

You cannot share an application or library between domain partitions: the application or library is available only within the partition. When you deploy the application or library, you specify the resource group in the partition. In FMW Control, applications and libraries that are deployed to a resource group in a partition display the name of the domain partition and the resource group within that partition where they are deployed.

The key difference between an application or class running at the domain level and an application or class running in the context of a partition is:

  • Applications or classes running at the domain level are available across the domain and are not available in partitions.

  • Applications or classes running in the context of a partition are available only within that partition.


The recommended, best practice is that you deploy all applications and resources to domain partitions.

About Resource Isolation

Resource isolation is critically important within a partitioned environment. When you create a resource group in a domain partition, WebLogic Server MT creates runtime copies of all of the resources needed by the application, including JMS servers, JMS stores and JMS modules (including connection factories, queues, topics, and such), JCA adapters, and other associated resources.

When you deploy an application or library within a partition, any configuration changes you make are specific to that partition. WebLogic Server MT ensures that applications in one partition refer to the resources that apply to that partition only and not to resources associated with other partitions.

Resource isolation in WebLogic Server MT encompasses:

  • Security—A unique security realm and identity domain for each domain partition.

  • Administration:

    • Partition-specific administration

    • Independent deployment, configuration, and software updates

    • Partition-specific monitoring and troubleshooting

  • Runtime:

    • Dedicated JNDI—WebLogic Server MT provides isolation between partitions at the JNDI level, which is partition-aware. Applications can bind named objects and retrieve them on a per-partition basis. Each resource is tagged (internally) with a partition-specific name, and is placed in a JNDI tree that is exclusive to the partition. Intra- and inter-application communication for a partition within a cluster is automatically isolated for the partition.

    • Isolated data—JMS, file system, and data sources

    • Resource isolation and fairness—Resource Consumption Managers (RCM) manage resources provided by the JVM or the OS. This allows system administrators to specify resource consumption management policies (including constraints, recourse actions and notifications) on resources such as CPU, heap, file, and network.

    • Partition Work Managers—Provide fairness of thread usage and prioritization of work requests among partitions that share the same WebLogic Server instance.

WebLogic Server MT Actors and Roles

Two main actors in WebLogic Server MT are WebLogic Server system administrators and partition administrators.

WebLogic Server system administrators create and delete partitions for tenants. Only system administrators can set or change the security characteristics of a partition (such as the security realm, SSL configuration), or reference a shared (domain-level) resource group or resource group template.

The significant difference between WebLogic Server system administrators and partition administrators is that partition administrators log in directly to a partition-specific security realm, as described in Administrative Roles for Configuration and Management.

Partition administrators manage partitions at the partition level, such as changing partition configuration, deploying applications, creating JMS resources, data sources, JDBC connections, and such, for each resource group in the partition.

Both system and partition administrators:

  • Create, modify, and delete resource groups in partitions.

  • Deploy and undeploy applications to resource groups in partitions.

  • Start and stop partitions—all of the resource groups and all of the applications deployed to those resource groups are started or shut down.

Analogous to their WebLogic counterparts, partition-constrained roles exist for Deployers, Operators, and Monitors.

Understanding SaaS Multitenancy

In a SaaS environment, if an application cannot internally provide a per-tenant view or the necessary per-tenant isolation, you might instead deploy separate instances of the application and its related server-side resources for each tenant. Each tenant might get its own stack that includes hardware capacity or Java virtual machines, WebLogic Server domains, Administration Servers, Managed Servers, clusters, and other related resources, such as web servers, data grids, networking, and storage. At the very least, this is inefficient.

The WebLogic Server MT SaaS model provides a way to get the most efficient use from server resources while still providing resource isolation. Each tenant gets an application instance plus resource instances on the targeted servers and clusters. The same application or applications run concurrently and independently on multiple domain partitions. No code changes to the applications are needed: WebLogic Server manages the domain partition identification and isolation.

In the SaaS model, you typically define one or more applications and the resources they depend on in a resource group template. You then reference this template from every domain partition in which you want to use the same applications. You make any domain partition-specific changes by editing the values of the associated resource group.

From a high-level view, the SaaS model procedural flow is:

  1. The WebLogic Server system administrator creates the JMS resources, data sources, and other resources for a resource group template.

  2. The WebLogic Server system administrator deploys the needed applications to the resource group template.

  3. When ready to deploy for a tenant, the system administrator does the following:

    1. Creates a virtual target, if necessary.

    2. Creates a domain partition configuration, including the resource group, pluggable database (PDB) info, the virtual target, the security realm, and targets the partition to a cluster or set of Managed Servers.

    3. Overrides particular resource group and application deployment values.

    4. Starts the domain partition, which starts all of the applications deployed to the resource group for that partition.

  4. After a domain partition is started, a partition administrator can view the runtime state of the partition applications and resources, view partition log entries, stop and restart the partition applications.

At deployment, the applications and resources in the resource group template are replicated and deployed for each domain partition in a resource group, with the following results:

  • WebLogic infrastructure is shared among domain partitions.

  • Separate application instances have their own JNDI tree and resources.

  • Runtime traffic is isolated end-to-end. You accesses the application via the virtual target.

  • Partition Work Managers provide fairness of thread usage and prioritization of work requests among partitions.

  • Data is segregated with pluggable databases (PDBs). The data source implementation creates a separate physical connection pool for each domain partition to its assigned PDB.

Testing Applications in a Saas Environment

You might find that one of the many benefits of using domain partitions in a SaaS environment is to test new versions of applications in a controlled production environment.

For example, assume that a business-critical application is deployed to Partition A. If you make significant changes to this application, you would probably want to test it in your production environment before it is generally available to users. WebLogic Server MT provides an easy way to do this. You could create Partition B and deploy the updated application, without affecting the stable version of the application running in Partition A.

You can target the updated version of the application running in Partition B to real production clusters and datasources, test and tune performance metrics, and so forth, all in a controlled environment.

Understanding PaaS Multitenancy

The WebLogic Server MT PaaS model is synonymous with consolidation. Consolidation means that you can deploy different applications from many tenants into the same WebLogic infrastructure. WebLogic Server MT shares the infrastructure and underlying resources including the domain, clusters, Managed Servers, hardware, and network. In the SaaS use case, the WebLogic Server system administrator typically manages all the domain partitions and their resource instances. However, in the PaaS use case, partition administrators are more likely to administer their respective domain partitions and the resources within them, including configuring resources and deploying applications.


  • Makes it easy to deploy applications from many tenants into the same WebLogic infrastructure.

  • Results in one domain to manage, one JVM consuming resources.

  • Isolates management. WebLogic Server system administrators manage the infrastructure. Partition administrators manage domain partition deployments and related resources.

  • Isolates the runtime, including domain partition-specific components: security realm (per tenant), virtual target (addresses), pluggable database, JNDI (internal traffic), JMS, Work Managers. Each tenant gets its own set of application instances and dedicated resources.

In the PaaS use case, each tenant would typically run different applications, and these applications may or may not overlap with the applications run by other tenants. When implementing a WebLogic Server MT PaaS solution, you would typically create self-contained resource groups that do not refer to resource group templates but instead represent applications and their related resources that are to be available only within that domain partition. However, even though a PaaS solution is less likely to use resource group templates, this does not mean you cannot use resource group templates in a PaaS solution if they fit your use case.

From a high-level view, the PaaS model procedural flow is:

  1. The WebLogic Server system administrator creates a virtual target, if necessary.

  2. The WebLogic Server system administrator creates a domain partition with a specified Partition Work Manager or quality of service (QoS) definition to manage the workload.

    The Partition Work Manager defines the relative priority and underlying memory and CPU availability for the partition.

  3. The WebLogic Server system administrator selects a security realm for the domain partition, and sets the list of available targets.

    Resources and applications in the domain partition are available only to users within the domain partition's security realm. Other tenants cannot see or access the resources or applications.

  4. The WebLogic Server system administrator assigns the domain partition to a partition administrator.

    Resources and applications are managed by the partition administrator. (The underlying Managed Servers and clusters are not managed by a partition administrator.)

  5. The partition administrator creates one or more resource groups for that domain partition and targets the resource group from the list of available targets.

  6. The partition administrator creates different JMS resources, data sources, PDB info, application deployments, and such for each resource group in the domain partition.

  7. The partition administrator starts the domain partition, which starts all of the applications deployed to the resource groups in the partition.

  8. Repeat steps 1-4 for each additional tenant.

End-to-End Lifecycle Management

Enterprise deployments of Fusion Middleware can be complex. WebLogic Server MT simplifies consolidating many domains into one using partitions for isolation and introduces new levels of coordination between component configurations.

WebLogic Server MT lifecycle management links together partitions across different components to form one cohesive unit that serves a tenant's needs. To do this, the lifecycle manager provides configuration integration across components.

When a partition is created, updated, or deleted—either through REST, WLST, Fusion Middleware Control, or the WebLogic Server Administration Console—the lifecycle manager detects these "out of band" actions and synchronizes its configuration with the Administration Server's configuration. The lifecycle manager then informs registered plug-ins, such as the Oracle Traffic Director (OTD) plug-in, of these changes to keep the entire environment synchronized.

When a domain partition is created or updated in WebLogic Server MT, the changes are orchestrated across multiple tiers:

  • The OTD configuration is updated and wired to the new partition.

  • Applications are wired to Coherence caches or services.

  • Data sources are wired to existing databases or pluggable databases (PDBs), or new PDBs are created.

Figure 2-2 depicts the end-to-end traffic segregation and flow from the Web tier to the database tier.

Figure 2-2 End-to-End Lifecycle Management

Description of Figure 2-2 follows
Description of ''Figure 2-2 End-to-End Lifecycle Management''