Domain Partitions for Multi-tenancy in WebLogic Server 12.2.1

One of the signature enhancements in WebLogic Server 12.2.1 is support for multi-tenancy. Some of the key additions to WebLogic for multi-tenancy are in the configuration and runtime areas where we have added domain partitions, resource groups, and resource group templates. This post gives you an overview of what these are and how they fit together.

Domain Partition

A domain partition (partition for short) is an administrative and runtime slice of a WebLogic domain. In many ways you can think of a partition as a WebLogic micro-container.

In 12.1.3 and before, you define managed servers and security realms in the domain and you deploy apps and resources to the domain. You target the apps and resources to managed servers and clusters to control where they will run.

And in 12.2.1 you can still do all that.

But you can also create one or more partitions in the domain. Each partition will contain its own apps and resources. 

You can target each partition to a managed server cluster where you want the partition’s apps and resources to run. (More about targeting later.)

You can start and shut down each partition independently, even if you have targeted multiple partitions to the same cluster. You can have different partitions use different security realms.

Plus, for each partition you can identify partition administrators who can control that partition. You can begin to see how a partition is a micro-container — a slice of the domain which contains it.

Resource Group and PaaS

Suppose you have a set of Java EE applications and supporting resources that are a human resources solution, and you have another set of apps and their resources that are a finance package. In 12.1.3 you would deploy all the apps and all the resources to the domain. You might target them to different clusters — in fact you would have to do that if you wanted to start up and shut down the two packages independently.

Or, in 12.1.3 you could use separate WebLogic domains — one for the HR apps and one for the finance ones. That would give you more control over targeting and starting and shutting down, but at the cost of running more domains.

With 12.2.1 we introduce the resource group which is simply a collection of related Java EE apps and resources. You can gather the HR apps and resources into one resource group and collect the finance apps and resources into another resource group.

Things get even more interesting because each partition can contain one or more resource groups. 

If you were thinking about running two separate domains before — one domain for HR and one for finance — you could instead use one domain containing two partitions — one partition for HR and one for finance. With our simple example the HR partition would have a resource group containing the HR apps and resources, and the finance partition would have a resource group containing the finance apps and resources.

In 12.2.1 you actually target each resource group. If it makes sense, you could target the resource groups in both the HR and finance partitions to the same cluster. And, because you can control the partitions independently, you can start or shut down either one without disturbing the other. The managed servers in the cluster stay up throughout. When you start up or shut down a partition, it is the apps and resources in the partition’s resource groups that are started up or shut down, not the entire server.

People often call this the consolidation use case — you are consolidating multiple domains into one by mapping separate domains to separate partitions in a single consolidated domain. This is also called the platform-as-a-service (PAAS) use case. Each partition is used as a WebLogic “platform” (a micro-container) and you deploy different apps and resources to each.

Resource Group Template and SaaS

There is an entirely different way to use partitions and resource groups to solve different sorts of problems, but we need one more concept to do it well.

Suppose you wanted to offer those HR and finance suites of apps, running in your data center, as services to other enterprises.

In 12.1.3 you might create a separate domain for each client and deploy the HR and finance apps and resources the same way in each domain. You might use a domain template to simplify your job, but you’d still have the overhead of multiple domains. And one domain template might not work too well if one customer subscribed to your HR service but another subscribed to HR and finance.

In 12.2.1 terms this sounds like two resource groups — the HR resource group and the finance resource group — but each running once for each of your enterprise customers. Using one partition per client sounds just right, but you would not want to define the two resource group repetitively and identically in each customer's partition.

WebLogic 12.2.1 introduces the resource group template for just such a situation.

You define the HR apps and resources in a resource group template within the WebLogic domain. Do the same for the finance apps and resources in another resource group template. Create a partition for each of your enterprise customers, and as before, in each partition, you create a resource group. 

But now the resource group does not itself define the apps and resources but instead ">references the HR resource group template. And, if one customer wants to use both suites you create a second resource group in just that customer's partition, linked to the second resource group template.

When you start the partition corresponding to one of your customers, WebLogic essentially starts up that customer's copies of the apps and resources as defined in the resource group template. When you start another client’s partition, WebLogic starts that customer's copies of the apps and resources.

This is the classic software-as-a-service (SAAS) use case. And, if you replace the word “customer” with the word “tenant” in this description you see right away how simply WebLogic 12.2.1 supports multi-tenancy through partitions, resource groups, and resource group templates.

There are other ways to use resource group templates besides offering packaged apps as a service for sale to others, but this example helps to illustrate the basics of how you can use these new features in WebLogic Server together to solve problems in whole new ways.

Some Details

The multi-tenancy support in WebLogic 12.2.1 is very rich. We’ve just scratched the surface here in this posting, and as you might expect there are other related features that make this all work in practice. This posting is not the place to cover all those details, but there are a few things I want to mention briefly.

Resource Overriding

About the SAAS use case you might be thinking “But I do not want each tenant’s partition configured exactly the same way as set up in the resource group template. For example, different tenants need to use different databases, so the JDBC connection information has to be different for different partitions.”

WebLogic 12.2.1 lets you create overrides of the settings for apps and resources that are defined in a resource group template, and you can do so differently for each partition. For common cases (such as JDBC connection information) these overrides expose the key attributes you might need to adjust. For each partition and for each resource within the partition you can set up a separate override.

We intend these overrides to cover most of the cases, but if you need even more control you can create — again, separately for each partition — a resource deployment plan. If you are familiar with application deployment plans in WebLogic the idea is very much the same, except applied to the non-app resources defined in resource group templates.

To illustrate, here is what WebLogic does  conceptually, at least  when you start a partition containing resource groups linked to resource group templates:

  • The system reads all the resource settings from the resource group template.
  • If there is a resource deployment plan for the partition, the system applies any adjustments in the plan to the resource settings.
  • Finally, if you have created any overrides for that partition, the system applies them.
  • WebLogic uses the resulting resource settings to create that partition’s copies of the resources defined by the template.


In this post I’ve mentioned targeting but WebLogic 12.2.1 lets you set up targeting of partitions and resource groups ranging from simple to very sophisticated (if you need that). My colleague Joe DiPol has published a separate posting about targeting.

What Next?

Here is the WebLogic Server 12.2.1 documentation that describes all the new features, and this part specifically describes the new multi-tenancy features. 

Remember to check out Joe DiPol's posting about targeting

For even more about the release of WebLogic Server please browse other postings on the WebLogic Server blog


Hi Tim,

What happens to the managed servers. We could always allocate different clusters for 2 different application.

Do we divide individual JVM/Managed Server as well with partitions or not.
This is what I saw in one of the videos by Dave Calebus?


Posted by guest on January 13, 2016 at 02:25 PM PST #

Thanks for the question. I am not sure I fully understand your question, but I'll try answering.

First, please read Joe's blog (see the link in my post) about targeting. That might explain some things.

You can use managed servers however makes sense for you. In some cases it might make sense to have different partitions use different servers. In other situations it's a good idea for partitions to share servers.

The example you mentioned (allocating two clusters for two different applications) that is still possible if you want to do it that way but you can instead share the same servers across multiple partitions. That can save resources and also be easier for admins to manage.

Posted by Tim on January 14, 2016 at 09:51 AM PST #


Let's say there's a scenario where 2 different organizations are using 2 different partitions (same domain) on same Weblogic Server installation. So, Org A uses partition A and Org B uses partition B. For deploying applications or for any valid reason, both the organizations need Weblogic console access. How do you provide security where Org A should not be able to tamper Org B applications present in partition B? (Would also like to know how Weblogic in cloud caters to such scenarios)


Posted by Sai on October 24, 2016 at 12:21 AM PDT #

Sai, thanks for your interest and your question.

The WLS administrator can assign administrator access *restricted to a particular partition* to a user, thereby allowing that user to perform admin operations on just that partition. When such a user logs into the console (or any other admin client vector), the console restricts what that user can see and do. The user can affect only that partition.

Here is the doc related to partition-level security:

that gives much more detail.

Here is Sazzad's blog that goes into more detail than I have here about MBean security (which underlies all admin access control):

And, lastly, because you are clearly interested in partitions and security, here is a brief article about isolating partitions from each other:


- Tim

Posted by Tim on October 24, 2016 at 06:00 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

The official blog for Oracle WebLogic Server fans and followers!

Stay Connected


« February 2017