This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
One of the great things about Liberty is the ability to configure it to just start the features that your application needs. This allows the server to start faster and use less memory because there’s not a lot of stuff going on you don’t need.
The flip side of that, of course, is that you have to figure out what features you actually need. We have a chart that shows the available features (that we jokingly call the ‘periodic chart of Liberty’ because it has sort of a resemblance to the chemistry period chart). That chart breaks the features up into a few different groupings.
I tend to think of them mostly as either ‘application’ or ‘operational’ features. Application features are essentially programming model things, like servlets or MDBs, and so on. Operational features are more about security or monitoring, etc.
You can expect the application developers to determine which application features they need, although even that isn’t as simple as you might think. Every feature has a version that goes with it (so it isn’t just the ‘servlet’ feature, it is servlet-3.0 or whatever). Defining the required application features means deciding what level of that feature you need. It is likely the most recent one available, but of course, over time, that may change and the version you are using becomes quite old. The Liberty zero-migration rules mean that you can keep using that older level even as you move up to newer levels of the Liberty code. That’s a good thing. Changes to newer versions of application features usually require code changes to the application.
Furthermore, there are ‘convenience’ features that group together a whole set of features at compatible levels. There’s a feature for Jakarta EE 8, for example, that includes all the Jakarta EE features at their various levels that were current as of EE 8. That matters because newer versions of features can be incompatible with older versions of other features. So if you have an application using servlet-3.0 along with some other feature at some other level, and your developers decide to move to servlet-3.1 that might require a change to the levels of that other feature too. The convenience features always include compatible levels. But, of course, they drag in a bunch of features you might not actually need.
The choice of more operational features (like security and monitoring, etc) are probably selected by a different group. The applications folks probably don’t really care if you are classifying work with WLM or not, for example. A lot of these sorts of things won’t matter in development/pre-production servers, but will be a factor in production.
This split contributes to the need to have separate bits of the configuration for a single server because different people/groups will be involved in determining what gets configured. We tend to think of the feature manager block in the configuration as a single thing right at the top of server.xml, but in reality it can broken up into different segments included from different places with access granted to different groups appropriately.