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.
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.
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.
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.
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.
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:
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.
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.