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.
---------------
Before we move on from WLM I wanted to ponder the collection name classification attribute just a bit more. I think there’s some interesting possibilities here. First let’s quickly review.
In TWAS the collection name was automatically assigned using the cluster short name. You could choose to also classify using a transaction class picked based on attributes of the request. Everything that got dispatched had an enclave created for it and thus went through classification.
In Liberty the collection name defaults to the name of the server but can be configured to anything you like. In order to get work dispatched with an enclave you must assign a transaction class based on attributes of the request. Work without an assigned transaction class doesn’t get an enclave.
For TWAS we spend a lot of time talking about using the classification XML file to do very clever things to select a transaction class. But I think the truth is that a lot of shops just ignored all that and used the cluster name (collection name) to classify anything running in that cluster into the same service/report class. Anybody running one application per server might feel perfectly safe doing that and it makes a lot of sense. No reason to muck around with transaction class names if it just complicates things unnecessarily. Even customers running multiple applications per server tended (not always, but tended) to run ‘like’ things together and classifying them the same way made sense.
In Liberty we force you to select a transaction class name to get the work classified at all, but with a single wild-carded rule you can just assign all the work to the same tran class and you can safely ignore it. You don’t even have to mention it in your WLM classification rules. Just because we provide it to WLM doesn’t mean the rules in the policy use it.
That would allow you to basically do the same thing you might have done in TWAS and just classify with the collection name. Except….
Unlike in TWAS you can pick the collection name. It isn’t tied to the cluster name. Oh sure, you can have servers that are all the same and use the same collection name. But you’ve actually got more flexibility than that. You can assign the same collection name (maybe via a config element that gets included into appropriate servers) to whatever servers host applications that you want classified the same way. This ‘name’ is essentially the name of a group of things that have the same goal (service/report class).
Remember also that WLM classification rules allow some wild carding so you could have a careful convention for your collection names with perhaps a sort of line-of-business root and an application suffix or something. Now that the collection name isn’t forced to be tied to any of the server’s names you can do whatever you want with it.
But be careful out there..