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.
---------------
The Liberty classification rules for HTTP requests allow you to use the URL for the request (basically the application you want to run, or maybe the part of it) and convert that into a Transaction Class string that WLM will use to classify into a service and report class. How will that work for Message Driven Beans (MDBs)?
Well, how does a message get picked up by Liberty in order to drive an MDB? You configure an activation specification (act-spec to its friends). When a message shows up for the act-spec the onMessage method in the MDB is called and provided the message to process. So it would seem that we would want to classify MDB execution according to the activation specification.
Generally an act-spec points to a message queue and might specify a selector to control what messages to take off that queue. A queue might get messages for several different applications (maybe an ATM puts messages all on one queue for the various ATM actions you can take: deposit, withdrawal, balance check, etc). There is probably some property of the message (or several properties) that can be used to determine which messages from that queue need to go which MDB. Our ATM might specify an ‘operation’ property that is used to decide which MDB should get the message (via different activation specifications).
Thus you might think that we would have WLM classification rules that specify the queue the message came from and the selector string that controls which messages are selected from the queue and match that to an MDB. There were two problems with that. The first was that we would basically be totally reproducing the selector-string processing that is done when messages are pulled from the queue which seemed unnecessary, complicated, and likely to end up with quirky little differences. The second problem is that you could then set up totally different classification rules than the activation specification selectors. So the same MDB might be driven but get different WLM classifications. There’s probably some case where that makes sense, but it seemed to us like it would just make things more confusing.
But if we didn’t do that, how would we tie WLM classification to message selection? Well, like every other configuration element in Liberty, the activation specification has an ‘id’ or identifier attribute. If you don’t specify one, it generates a value. But an activation specification probably has one and it is easy to specify one if you didn’t. And you could just tell the WLM classification for an MDB which activation specification this classification rule was for. As a message arrives, Liberty knows which act-spec is processing this message so it is easy for it to go through any WLM classification rules in the Liberty configuration and find the matching Transaction Class for it using the configuration id.
This leads to a nice one-for-one classification to activation specification mapping. Once configured, all the messages being processed through a given activation specification will be classified with WLM using the same Transaction Class name.