In this article we are looking at the profiles of the WSO2 API Manager. What are they and what do they do? You will learn how to optimize a profile as part of a Distributed Distribution of the API Manager.
Carbon Core
WSO2 products are for the most part built on the Carbon Core. Carbon Core is a set of libraries that is used by (almost) all products from WSO2. It offers a set of functionalities that all of the products have in common such as clustering capabilities, user management, but also bundle management using the Management UI. These are all part of the Core. There are also the functional components that will make the product behave like an Enterprise Integrator, an API Manager, an Identity Server, or a Streaming Processor.
Different and the same
Most of these components are jars based on Java. Not all products are the same. And by that, I mean it not from a functional perspective, because of course, the Identity Server, and an API Manager are different types of products, the same goes for the Enterprise Integrator.
You can also argue that the products perhaps are a bit more common than you think, especially when you talk about the API Manager and the Enterprise Integrator. And then, the cooperation between products is also bigger than you might think. For instance, the API Manager has part of the key manager that also is included in the Identity Server. The API Manager and Enterprise Integrator used the same message mediation (Synapse).
The Enterprise Integrator is basically a monolith. It is one big block of functionality that starts on its own JVM, without the possibility of basically allowing it to have a setup in different JVMs with different functionalities. To be complete and correct, when you look at the Enterprise Integrator, also the Message Broker and the Business Process Server as well as the Analytics are like that, but they are, or should be, considered as separate products. They will always run on their own JVM.
What I mean with the monolithic nature of the Enterprise Integrator, and the Micro Integrator as well, is that those products are installed as one big block. The API Manager, however, although it uses similar components, has a setup that is called a distributed deployment.
Running WSO2 API Manager
If you download the WSO2 API Manager zip file, and you run it, you are basically going to get one JVM that has all of the five components of the API Manager in there: Publisher, Devportal, Key Manager, Traffic Manager and Gateway.
Therefore, you could do a distributed setup for distributed deployment, where each of these components can run in their own JVM environments. And one of the things that you can do is to start them with a so-called profile.
What is a Profile?
A profile is a defined configuration that only loads the OSGi bundles that it needs in order to perform its functionality, as for instance, the Key Manager. This means that the bundles are not necessary for this specific functioning of this component, for instance, the SYNAPSE configuration is not loaded in this specific case. The result is, of course, that we have a lower memory requirement, because instead of all the jar files, we are just loading some of the jar files. So that can be a benefit.
But how can we see what is actually in those profiles?
That is what we are going to find out. So how do we know what kind of profiles are available for a specific product? Well, it is quite simple. You take the product and you start, for instance, in a terminal session on Linux, you can also do it on Windows (the functionality is also available for Windows).
Installing API Manager
I am assuming that you have Java installed (Java 8, or Java 11, OpenJDK or Oracle) and you have set JAVA_HOME. There is now no barrier that would not allow you to do the setup of the running of the API Manager. If you have not installed it, look at this blog about installation of WSO2 products.
So, let’s start the API Manager by unzipping an out-of-the-box version on the desktop and with the prerequisites that I just described, you can basically start the API Manager with the shell or batch script, and it will run.
In our case, we are going to add another parameter to the API Manager, and that is a parameter -DosgiConsole. So, as you can see here from the screenshot, you just put in a space and then the extra parameter.
And then what will happen is that you will see a message on the console. When the system is starting, the OSGi console is started and typically is the interface to the internal workings of the API Manager.
That means that throughout the OSGI console, you are able to take a look at the loaded bundles, settings and so on. It allows you to refresh bundles, it will allow you to see what is inside a bundle as far as Java classes go, et cetera, et cetera. In general, there are over 20 pages of help commands that will show you everything you need to know, on a very deep level of technical depth.
The OSGI console also allows you to type in a command. You have to wait until it is done. Otherwise, the log messages will obscure stuff that you are typing in. What you can do when it stops, and you see the Management UI URL, in the terminal press Enter and as by magic, a cursor appears and you can type provlp, and it will allow you to an Enter.
That will give you the profiles that are currently in the product. And as you can see, we will see a number of specific profiles with regards to the operation. So, for instance, the API gateway as a worker node, the Devportal, the Publisher, Traffic Manager, and the Key Manager and of course, the Default Profile, because the Default Profile is used when there is no profile added as the parameter. Adding a profile to the provlp command shows the individual jars (only a small number shown).
So, we know that there is a specific setup inside a profile. We can also take a look in the [APIM-HOME]/repository/components directory where we see the directories for these profiles.
It has about 550 individual jars listed for this profile. The format is jar name, version, and location within the directory structure. This overview gives more information than the OSGI console. However, the OSGI console shows a multitude of additional commands to work with profiles.
Optimization of a profile
But a Distributed Deployment is more than simply enabling a profile. There is the actual configuration to set up the Distributed Deployment (out of scope for this article) but before there is also the profile optimization. We need to remove or comment out some of the subcomponents, like for the Publisher the JMS connection, WS transports and a number of other things. Luckily, this does not need to be done by hand.
Profile setup
We can use a script to make the changes. When executing the script, we are prompted for the removal or change of a large number of files. As you can see, about 1800 files are removed from the setup. The script is actually a real script rather than executing a Java class and can easily be inspected. You need to do this for all profiles. Treesize is a great tool for Windows to high level look where the changes are.
This is before the update:
And this is after the update:
Alternatively, you can optimize at initial startup. In that case, use the following command:
wso2server.bat –optimize -Dprofile=api-publisher
This command also needs to be executed for all profiles.
Custom Profiles and Distributed Deployment
With the optimized settings you are now ready to continue with a Distributed Deployment. As previously stated, this is out of scope for this blog since it requires a substantial amount of work.
There is also a possibility to create your own custom profile to combine a specific setup, for instance Devportal and Publisher in one. It might not surprise you that this is also out of scope since this blog is already quite big and it is an advanced topic that would easily double the blog in size as to the number of words.
Conclusion
If you want to deploy the API Manager in a Distributed Deployment, the profile setup allows you to automatically remove or comment out the components that are not needed. From there on you can start configuring the Distributed Deployment setup. Ideally you would use a script so as to not having to do each configuration by hand.
Unfortunately, we could not cover custom profiles and Distributed Deployment. In our training about the API Manager, we do however cover Distributed Deployment and custom profiles (under construction) so if you are interested in the topics, take a look at our training schedule.
