MQ-ing and design

Well, as you may have seen from recent comments, a kind soul provided me with some documentation for the Websphere MQ Java classes (thanks again Nuno! Rest assured, if I'm near you in Belgium, there will certainly be a beer or two).

Eventually, and quite by accident, I also found an on-line source for the documentation at IBM's site — buried I might add. It took a particularly esoteric search query in Google to find it. Anyway, it's all fun, and I'll post some Domino / MQ Java one day if anyone would find it useful. Once I've done the next step of course…

The solution I'm working on entails connecting to MQ, picking up an XML file, and parsing it, all in Notes 5. Clearly this requires a Java agent of some sort. My initial idea for the overall design, given that there will be two different types of XML to process, is this:

  • Create an interface or class that encapsulates the mechanics of picking up the file from MQ
  • Create sub-classes (or if the above is an interface, implement it), in two scheduled Java agents

I wonder if that makes sense, what with being an object-oriented design novice and all. The latter classes / sub-classes will contain the Domino Java code for parsing the XML into Notes documents, but it'd be nice to tuck away all the guff about connecting to MQ and readying the XML. The issues here are whether this basic design makes sense, and whether the best route for the MQ stuff is an interface or a class. I'm particularly interested in the latter question because (a) I haven't done much at all with interfaces "in anger" and (b) I've read various 'blogs, articles and opinion pieces about interfaces vs. classes. For example:

Allen Holub: Why extends is evil.


  1. In a project where we did something similar with what you want (with the difference that we generated the XML file in Notes and then passed it on to MQ) I remember that one of our developers found an example of a Java MQConnect application that basically did the whole thing.

    He copied/pasted that into a Notes Java agent scheduled to run on the server and it worked perfectly.

    The MQLSX was pretty good as well, but it's not supported by Lotus anymore (only Java).

    Regarding your program: unless you really want to use this opportunity to get into Java (which is generally a good idea), why not parse the XML using LotusScript? Get the file using Java, store it in some database and then run a LotusScript agent to parse it?

    A limitation to this could be how far R5 goes in supporting DXL - funny how fast you forget the past versions' limitations ;-)

    Have fun doing it! (And I'll be waiting for that beer)Nuno Pereira#
  2. Thanks for the comment! There are some good bits of example code out there. So far I've done this, and it seems OK:
    • Created a class which handles the connection to MQ (per details in config doc in Notes).
    • Created another class called by the agent which instantiates the above class and calls the getMessage() method. The agent then parses the results into Notes.
    To answer your other points, this is in R5, so no nice Lotusscript objects to parse the XML, and I was last in Belgium in 1994: I'll try and be quicker next time. ;-) Ben Poole#
  3. How?

    Its been more than I year since I looked at this, but all I was able to get from IBM was the latest mqjava jar, which required a 1.3 JVM. This didn't work on our R5 server, as it used a 1.2 JVM. I was told by the MQ support folks that they would soon be moving to a 1.4 codebase, and therefore would break our 1.3 based R6 server before we even had it in production.

    I'm curious how you've managed to avoid this issue. I'm not even working at the client that had this issue anymore, but I still find it curious. Ed Wrenbeck#
  4. Ben,

    For a big project at work I was asked to parse various XML files in R5 as well. My first idea was Java too, but since we were almost late delivering the application, the project manager suggested Lotusscript. (Yes, this means I'm still slower in Java compared to Lotusscript ).

    Without having XML parser classes available in R5, I went down to write my own. It turned out to be a simple yet powerfull class. The XML template messages I store in the application configuration. There I could totally change the complete structure of the XML message and how it relates to the Notes fields on documents without changing one line of code. So when one of those expensive SAP consultants tell me they changed their business API, I grin and am ready for it in 5 mins.

    For the sake of learning Java more, Ill eventually rewrite it though….just sharing :)Ferdy Christant#
  5. Wow Ferdy, that's going it some! You need to get a weblog or something and share that with us ;-) When it comes to this solution though, it has to be Java for a variety of reasons - XML parsing is the least of my worries! I've done Java XML parsing before, so I'm just leveraging some old code for that part…

    Ed, take everything IBM say with a BIG pinch of salt. The JAR file we're using is, and it works with Notes 5 (Java 1.1.8). I'm not sure what version of MQ Series we have, but it won't be the most up-to-date, and it all works in our environment, promise!Ben Poole#
  6. Ed, you may find this thread over at the LDD of interest:


    Having looked into things further, I can confirm that the package I mentioned in the original post, downloaded from IBM (the fabled MA88 zip file), was the most current 5.2x release one, and therefore incompatible with Notes 5 (it requires a 1.3.0 JVM as far as I know). The code will compile, but you get a exception at run-time (that class doesn't exist in the 1.1.8 Java release).

    In typical style, IBM do not provide earlier versions of the MQ packages on their website, so I had to resort to hunting around our network for the relevant package… which I found! So hurrah for that.

    And boo-sucks to IBM. Quite how they justify (a) the discontinuation of the MQLSX and (b) then only providing a package that's compatible with ND6, I don't know.Ben Poole#

Comments on this post are now closed.


I’m a software architect / developer / general IT wrangler specialising in web, mobile web and middleware using things like node.js, Java, C#, PHP, HTML5 and more.

Best described as a simpleton, but kindly. You can read more here.