Wrappers are a double-edged sword. On the one hand, it becomes easier to implement some quick and dirty simple interfaces by setting up defaults within the wrapper. On the other hand, wrappers tend to be very non-standard. In addition, the wrapper configuration that makes sense when it is created may not be the best choice for all applications, or all configurations. Very often, you end up having to "tune the wrapper".
Fortunanately, Java and C++ allow you to write very simple subclasses, and you can simply extend the classes. Many people looking for a simpler adapter will use something like the AMI adapter, or one of the support packs. Fortunately, there are some very nice source code programs in C, which can be used to help understand how to create settings in Java, C++, or Cobol. More often, it's better to build a framework. The advantage of the framework is that you have some prototypes and templates, but you can tune the parameters to your specific application as needed. The J2EE environment is a good example of using patterns and frameworks to maintain a relatively simple high-level API, while still preserving the flexibility of the lower level APIs. The most common problem with the wrapper is that someone ends up trying to reinvent the wheel. I've had more than one time when someone used a wrapper to MQSeries, then tried to manually code the equilalent of coordinating by correlation ID, routing, or distribution lists. Generally, it's better for people to use the standard interface than to have to reimplement the entire application because you have to remove the wrapper later on. "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 10/18/2002 10:03:27 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: MQ Wrapper I think wrappers are a good idea. The bigger the audience, the better the idea. Ideally, yes, I would love it if all the programmers here learned the API and actually understood what all the implications are of the various options. But in today's day and age where I got a dozen project going on at the same time, new apps on the horizon, legacy apps switching to MQ to do their work, I can't possible expect that all these people are going to go to a 5 day MQ class, absorb everything, adhere to all the best practices etc. So I wrote the wrapper. First problem was how do you make a set of code that will work for everyone yet one that maintains a simple interface? What I did is had my wrapper go out to a database to find an application's particular row whenever the wrapper was called. This row on the database has about 90 columns. Expiry, Persistence, Queue Name, Syncpoint, Message Format, Pass-CorrelId Option,etc. Anything you could possibly choose to do when calling MQ, broken down by MQ call. So the first column in the table has Queue Manager name, and that takes care of the MQCONN call, since that is the only thing you can specify for that call. Then the next few columns have all the MQOPEN stuff. Queue name, Fail If Quiescing, etc. So on and so forth. The main body of the program is then the same for all. Based on what options were set in the database determines how this pass thru the wrapper will execute. Same set of code that theoretically can execute 10s of thousands of different ways. Now, you can't code everything on the table always. A replying app can't have its expiry value on the table if it is replying, nor should it be tied to a specific queue name for the reply. Or the CorrelId of the reply needs to be the message id of the request. So the I opened up about 6 parameters that a calling app can pass in that will override anything on the database. Now when a new app calls up our group, I add a row into the database. I have complete control on syncpoint, and persistence, and Fail if quiescing, etc. I don't have to worry if they are going to botch up my infrastructure with 4 meg persistence message going who knows where with unlimited expiry under syncpoint. I meet with the group, get their requirements, code the rows, create the queues, and give them the key they should pass in, along with a doc that explains the simple interface to the wrapper. A day later they are happily MQing in a way that I have complete control over. The wrapper sends back completion codes for each and every MQ call, so they can see exactly what didn't work. I also made a hi level completion code and give them the key to decipher that in plain English. Do they really care that they got a 2018? No. But when they see a "CF" error, their chart says the Connection call failed. They also do have that 2018 code so when they call me, so I know exactly what the problem is. But I tell you what, errors are few and far between, since I control how they call MQ. I haven't once seen an Invalid Options error! And no one has wasted time trying to debug that error. I also added stuff like logging that I can turn on and off thru the database. I made a version for IMS, CICS and Batch (all basically the same, just compiled differently) and all call the same database. A VB person cloned my wrappers for that environment. In production for 2 years now. Is it worth writing a wrapper for a small company with a couple MQ apps. Heck no. Big company with hundreds of MQ apps? I wouldn't consider anything but wrappers. Plus, writing a comprehensive wrapper will have you learn more about MQ than any other exercise. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -----Original Message----- From: Peter Heggie [mailto:Peter.Heggie@;US.NGRID.COM] Sent: Friday, October 18, 2002 8:35 AM To: [EMAIL PROTECTED] Subject: Re: MQ Wrapper Hey Randy, This is one of those classic IT problems - how to gain the benefits of code re-use without sacrificing flexibility. There is no easy answer. IBM has provided a middle ground solution in the MQ AMI. It doesn't totally satisfy either side, but it does remove a layer of complexity. While there is still additional administration, it does remove the need to actually re-code a wrapper every time an application needs a different set of parameters. Does it do what you want? Judging by your notes I would say no. Also, usually a wrapper provides a lot of benefits..one of them is that if something in the infrastructure changes, there is only one place that needs to be changed. Thats not true here.. The MQI is not going to change. Personally, I like the 'intelligent' wrappers I have seen here that figure out if you have already connected and/or opened a queue, and just perform the Put or Get. Now your developers can get on with their application code, and send or receive their data, without having to stop to design the application interface to MQ. But hold on there - now you are taking away their need to think about the MQ interface.. is that good?? Now we hit the other classic IT problem - do we provide everything for the programmer (protect them from themselves?) or have them work with all the details. At one company I put in a new mainframe change management system... they wanted a front-end, to avoid dealing with the complexity (flexibility!). When the batch job runs, they just want to see a condition code 0 or 4 - no need to look further! Its the same problem as above. I put in the front-end, and then I kept getting calls from programmers when their job ended with anything higher than a 4. If they had just bothered to look at the output, they would see the perfectly obvious error messages.. but NO! I think it is better that a programmer think about the interface to MQ, so that they make decisions about persistence, syncpoint, reporting and error handling. Sometimes I have to pick my battles.. sometimes there is no overriding, important project (that uses MQ) that allows management to tell developers to dig in and figure it out. No management direction means less interest in doing something different.. And unfortunately, those developers who actually like doing new things are trying to use HTTP and web services to communicate between machines/platforms.. MQ seems to be getting squeezed into a smaller space - just for high availalability/integrity operations.. but thats a different topic. To finish my rambling... I've gone the wrapper route in many cases because it got MQ in use; otherwise MQ would not be as widely used as it is. I would love to have 20 to 30% of the developers here to be reasonably fluent in MQ, but thats not going to happen soon, given the current application development projects. There are only four developers here fluent in MQ and I'm one of them. Hope this helps Peter Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
