Weblogic Multitenant

Weblogic 12.2.1 Multi-Tenant

With the development of partitions on Weblogic, Oracle has developed an infrastructure that is similar to containers, which takes advantage of the Weblogic server’s capacities such as clustering, transaction management and security [1].

These are the advantages of using Weblogic Server Multitenant [1]:

Time to market is improved.

1. The complexity of moving workload to the cloud and from the cloud is reduced.
2. It is possible to convert monolithic applications to smaller services.
3. It allows up to 3x hardware consolidation.
4. Reduction of OPEX by up to 25%

Since Weblogic Multitenant is based on the concept of partitions or micro containers. It is important to remark that these partitions allow the portability of applications reducing the time to market and allowing the movement to the cloud or vice versa.

Multi-tenant allows group applications that are scattered through several domains, which helps to optimize the use of hardware, making possible the reduction of OPEX.

In addition, a partition does not have any Operating System or JVM component. Applications and configuration artefacts compose partitions or micro containers and each one of these micro containers could use a managed server or a cluster.

In the following diagram, the topology shows two partitions deployed on the same cluster, which allow them sharing the JVMs that are part of that cluster.

With this in mind, in this post, I will show you how to reach the topology described based on partitions. I have created a domain with a cluster and I have an Oracle Pluggable Database available so now these are the additional elements created in this post:

1. Virtual targets. According to [2] a virtual target is the target used by a resource group at the domain level and partition level. Virtual targets are targeted to managed servers or clusters and they define access points to resources. Virtual targets give a separate HTTP server for each target as in the case of virtual hosts in Weblogic Server [2]. Since virtual targets set the access to resources and resources are group by resource groups, these require one or more virtual targets. When a resource group has a global scope (related to the domain) it is possible to select any virtual target that is not assigned to a partition. On the other hand, when a resource group is assigned to a partition, this can use only available virtual targets in the partition [2].

2. Resource groups. We can define it with an example, many times when we need two environments like development and testing, we should create two domains in order to separate applications and resources such as data sources, JMS servers, etc. With the introduction of Weblogic Multi-Tenant, you can group applications and resources to create a resource group with the elements needed by each environment. In addition, we should create partitions (one per each environment) to target one or more resource groups on these partitions. This configuration can be seen in the following picture.

Since this configuration consolidates several domains into one, this case is a platform-as-a-service scenario because each partition is a Weblogic platform to deploy applications and resources [2].

In addition [2] states that resource groups give coherence to application suits that before were scattered in a domain.

Resources groups can be created at the domain level or at the domain partition level. A resource group created at the domain level has a global scope and cannot be used by any partition. On the other hand, a resource group created at the partition level has an scope that only covers that partition, it means that applications at this level are not available at the domain level or for other partitions [2].

1. Partitions. According to [2] a partition is an administrative and runtime unit that is equivalent to a portion of a domain, which is used to run applications and their resources. Oracle recommends that you should not create more than 10 partitions per domain [2]. However, this number is up to you, but you have to consider the particular conditions of your deployments.

2. Security realms. I will create a security realm per partition in order to manage the security independently.

3. Partition users. The security realms created in the previous step will be used to define administrative users in charge of the administration of each partition.

Create virtual targets

Click on Virtual Targets under Environment

Click on New

In this screen you have to define the name of the Virtual Target, the target used by the virtual target, the hostnames configured to attend requests and the URI prefix to differentiate the development environment from the testing environment. Click on Ok

Do the same for the testing environment.

Create security realm for the partitions

Click on security realms

Click on New

Enter the new realm name, mark the two checkboxes and click on Ok.

Do the same for testing

Create users for the partitions

Click on security realms

Click on the new realm created for the development environment

Click on the users and groups tab

Click on new.

Fill the data remarked and click on Ok.

Do the same on the realm that belongs to the testing environment

Give administrative privileges to the new users

Click on each one of the new users

Click on groups tab

Select the Administrators group and click on save.

Do the same for the user that belongs to the testing environment.

Create partitions

Click on domain partitions

Click on new

Set a name for the partition, unmark the checkbox because we will create the resource group and click on next.

Select the virtual target that belongs to the development environment and click on next.

Select the virtual target and the security realm created for this partition and click on finish

Do the same for the testing environment

At the end, we will have two partitions

Create resource groups

It is important to remark that we will create resource groups at the partition level so you have the follow these steps.

Click on domain partitions

Click on the partition you want to configure, in this case the development environment partition

Click on resource groups

Click on new

Set the name for the resource group, unmark the checkbox highlighted, select the virtual target available for this partition and click on Ok.

This is the result

Do the same for the test environment

Configure the application

In this post, we will use a demo application called WeblogicMT.war; this is a web application that just executes a query against a pluggable database and shows the results on a dynamic page. In addition, it allows adding and deleting registers on a table called APEX_040200.WWV_DEMO_EMP. The following diagram describes the application architecture.

Therefore, we need to create the data sources and deploy the applications per each partition with the following steps.

Create the data source

Click on data sources

Click on new generic data source

Set a name for the data source, select the scope in this case the development resource group is selected, set the JNDI name, select the kind of database and click on Next.

Select the driver remarked and click on Next

Click on Next.

Fill the connection parameter for pdb1.sysco.no (the pluggable database for the development environment) and click on Next.

Test the configuration and click on Next

Click on finish

Do the same for the test environment. However, we have to use the other pluggable database pdb2.sysco.no and other resource group PartitionResourceGroupTest.

Finally, we have these data sources.

Deploy the application

Click on deployments

Click on Install

Select the application and click on next

Select the resource group and click on next

Click on next

Click on Finish

Do the same for the development application, but using a different scope. Finally, we will have:

Testing the environments

Development

In order to test the development environment, I used this URL:

http://ms01vhost122.sysco.no:9003/appdesa/WeblogicMT

I clicked on “Edit”

I changed the name as can be seen

After saving the register I run a query against pdb1.sysco.no, the pluggable database that belongs to the development environment to verify the change.

Testing

In this case, this address was used:

http://ms01vhost122.sysco.no:9003/apptest/WeblogicMT

I made a similar change that was verified on the pdb2.sysco.no database, the pluggable database that belongs to the testing environment.

What about security?

Two security realms with a user per each realm were created. We have this information.

Now we can use these users to connect to each partition

Connecting to the development environment.

Connecting to the testing environment.

References

[1] Oracle (2015) Oracle WebLogic Server Multitenant: The World’s First Cloud-Native Enterprise Java Platform [Online document] Available from: http://www.oracle.com/us/products/middleware/cloud-app-foundation/weblogic/weblogic-server-multitenant-ds-2742664.pdf (Accessed: 06 January 2016)

[2] Oracle (2015) Configuring Resource Groups [Online document] Available from: https://docs.oracle.com/middleware/1221/wls/WLSMT/config_resource_grp.htm#WLSMT1213 (Accessed: 06 January 2016)