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.
---------------
What are some things to think about if you’ve got a WLM classification file used by your traditional WAS servers and you’re moving that workload to Liberty on z/OS?
First of all, remember that while TWAS required everything to be classified with WLM, that’s optional with Liberty. It is perfectly acceptable to run work inside Liberty that is invisible to WLM and just give the whole server a velocity goal. It might not be a good answer as far as your performance requirements go, but technically it is a thing you can do. At the very least you probably want to make sure it doesn’t happen by accident if you don’t want it to.
Secondly, while, again, everything in TWAS was classified with WLM, in Liberty only HTTP and MDB workloads are classified. That’s probably everything you’re running, but maybe not. So, a thing to consider.
The hard part, then, is converting your TWAS classification rules to into Liberty rules. You’re probably going to want to put the same work into the same service and report classes, so you want the same stuff to end up using the same transaction class names you used in traditional.
The tricky part is that TWAS allowed you to nest rules where Liberty just goes right down the list until it gets a match. If your TWAS rules are simple and all on the same level (by work type) then those map very nicely into Liberty rules matching the same things in the same order. If you’ve nested things, you’re going to have to unfold that and figure out what it needs to be to work in a linear search.
For HTTP work you probably classified using the URI, but you can also classify with the host/port which are very likely not the same in Liberty as your TWAS servers, so be careful.
MDB work classification is complicated in TWAS because there are several different mechanisms available (message listener port, activation specs, etc). In Liberty it is just classified by reference to the activation spec receiving the messages, so it should be relatively easy to map if you were using activation specs in TWAS and are using them the same way in Liberty.
Lastly, in TWAS it was possible to classify work using the collection name which was the (short) name of the cluster. In Liberty by default that will be the server name (the name of the directory where server.xml lives) but you can set it to anything you like in the server configuration. If you only classified by collection name in TWAS, you could set the collection name in Liberty to that same name and end up in the same WLM rules. But remember that Liberty won’t classify at all without a transaction class name being set. So even if you don’t use it in your WLM classification rules, you’ll need to have a catch-all rule in the Liberty configuration to assign some TC string.
TWAS also let you classify ‘internal’ work which was essentially the controller region talking to the servant. Since Liberty doesn’t have that situation, you don’t need to migrate that part of your TWAS WLM classification over to Liberty.