Wrapper programs around the WebSphere MQ (WMQ) interface have become ubiquitous. They range from small programs that perform only single function calls using business application-provided parameters to highly complex applications that abstract the entire process, from queue identification to setting all the options based on previously identified application design specifications.
Wrappers can be used to:
• Create a standardized interface for all applications using messaging
• Eliminate the hard coding of WMQ parameters and options
• Restrict access to certain MQ calls, reducing errors in calling WMQ and handling errors
• Provide statistics
• Allow developers to concentrate on the business requirements and not the WMQ Application Programming Interface (API).
Sometimes, a wrapper can provide additional features such as standardized security, data compression (although WMQ now provides that natively), and error handling at the expense of even more complexity.
On the surface, this is all logical. After all, those are mostly the reasons high-level programming languages were created. But are those reasons valid for creating a wrapper application? Wrappers can become straitjackets. The more they’re expected to do, the stronger the straitjacket can become. It’s easy to create a short-term wrapper application, but for a successful long-term wrapper, many decisions must be made.
First, it’s necessary to determine what functions the wrapper will perform and what functions will be left to the application. These requirements could be determined by a fact-gathering committee from requirements of the applications planning to use WMQ, dictated by a governance board, or just specified by an omniscient architect. There are strengths and weaknesses in either approach. The last two are good if you want a strongly standardized interface (e.g., no application can ever use non-expiring, persistent, request-reply messages, and all messages must be shorter than 1MB), but it could stifle business requirements.
The fact-gathering committee would obtain current business requirements, but who would define the requirements for future applications? Can you easily add a Publish-Subscribe (Pub-Sub) feature, provide load balancing for an online application that outgrew its environment, or build the code for an application picked up in an unexpected corporate merger that requires an Open Transaction Manager Access (OTMA) interface? Many wrappers have fallen by the wayside by not sufficiently meeting the needs of the applications that are expected to use them.
Second, who will design and build the wrapper? Wrappers can range from complex, supervisor-driven, multi-program applications that attempt to provide—from a file or database—all the parameters and options, and build and remove the headers for all callable functions, to individual programs that issue simple calls using the data and headers passed to them. Does the administration team have the necessary programming skills in languages appropriate for each platform to construct a stable wrapper application, or must the job be contracted to either another in-house programming group or outside consultants?
The more functions the wrapper is expected to absorb, the more maintenance it will require to encompass the increased functionality of each WMQ release. How will that be accomplished over the expected life of the wrapper, especially if the eventual wrapper “owner” loses the skills that were available when it was created or originally outsourced? Meeting the requirements of a new application after its target production installation date is problematic. How would the expected lifetime of a wrapper even be determined? As applications mature to “legacy” status, their owners become more resistant to migrating to newer wrappers.
Third, how many variations of the wrapper application need to be built? On the mainframe, will generalized, reusable modules for the batch, CICS, and IMS environments be used or will unique, environmentally customized modules be created? In CICS, the programs can pass addresses and dynamically change storage area lengths as needed for efficiency. However, it isn’t as easy to do the same in a batch environment, and the instructions are much different.
At a minimum, the mainframe programs must be link-edited with the proper WMQ stubs for each environment. Does the change management system allow different load modules of the same source program link-edited with the different WMQ stubs to have the same name? How do you accommodate the same thing for applications on UNIX or Windows? Java and some vendor products provide native WMQ APIs, which would have to either be accommodated by the wrapper or become an “anything goes” precedent. Also, a strong change control process would be needed to keep all servers synchronized with the same version.