WebSphere MQ API (or MQAL)

WebSphere MQ (or simply "MQ") is a messaging system made by IBM. If you've never used any message-oriented middleware, it might be a good idea to take a look at wikipedia first. Anyway, the basic problems that I had to solve in the component I'm posting are not specific to MOM systems. Thus, I hope you can extract some value from it in any case.

So, let me introduce you to the problem. About one year ago, I had to develop an application that extensively uses MQ to exchange messages with other applications. This technology was kind of new to me and I had to learn the basics. To oversimplify, the idea is to connect to a queue manager, then connect to a queue, and finally put (or get) a message to (or from) the queue. The way that this process is made using the MQ API for .NET seemed very awkward to me. Then, I decided to write a component to encapsulate it and provide a simpler interface.

Fisrt, I've tried to find a design pattern to fit the component in and I choosed to follow the way that database connections are handled in the .NET framework. Then, I've started to make some analogies. To start, a queue manager connection could work pretty much like a database connection. Both of them have parameters like server, port, user name, password, and database name / queue manager name. To summarize, here are some of the analogies I've made:
- A queue manager is like a database;
- A queue manager connection is like a database connection;
- A queue manager connection parameters is like a database connection string;
- A queue is like a table (or a view);
- A queue connection is like an database command;
- A message is like a table row;
- A put message action is like an execute insert command;
- A get message action is like an execute select and delete command;
- A browse message action is like an execute select command.

Ok, you must have gotten the general idea. I won't get in much detail here, but let me list some of the problems I had to solve in order to implement this:
- Translating a queue connection string into queue manager connection parameters. I solved this by coding a connection string parser using regular expressions;
- Implement queue transactions. This wasn't a requisite at the time, but MQ provides transactions and I felt like I had to offer a way to use them;
- Inherently use a queue connection pool under the covers. The tests that I've made using the MQ API showed that it doesn't had a connection pool. I would had to either make the user of my component keep connections for longer (in order to avoid opening and closing them too frequently) or code a connection pool and let the user enjoy all its benefits. This was pretty interesting to do and probably deserves a post of itself. For now I'll let you with the source code.

By the way, I didn't touched this code for awhile now and I see that I've let some items on a TODO list, so I won't say it's a final version. Anyway, it's running in a production environment somewhere for months and it have not failed once.

Feel free to download the source code here.

Microsoft Parallel Extensions CTP released

In the past years, evolution of computing is turning to the grounds of high level concurrecy. Processors are becoming faster by being multi-core, and not by having higher frequencies. The time is coming so that even simple programs will be concurrent too. Parallel programs are harder to code, harder to test and can cause pseudo-random bugs that can drive programmers crazy. The best solution for this, as to many problems, is a dependable library and/or language support.

There are several types of problems that require specific solutions. Making a responsive UI, for instance. How many application have you seen that simply stay frozen while it's processing something? I've made some of them myself. And the programmer cannot be blamed, most projects don't have the time (and money) to invest on a responsive UI. The WPF framework solves this in a very neat way. Its interface engine is fully concurrent. But that's a subject for other post.

Yesterday, Microsoft released another CTP of its Parallel Extensions (PFX) library. You may get the details at their blog or at MSDN. In case you're not familiar with it, I'll give a short brief here. Basically, the library's comprehended by three parts:

- Task Parallel Library
Provides some imperative ways to express parallelism. The simpler one is the Invoke method. It receives a set of actions in the form of delegates and executes them concurrently, returning after all the actions have completed. If you have a loop in which iterations may run in parallel, you can use the For or the ForEach methods. When the problem requires a little more elaboration, there's the Task system. It's a set of classes that works somewhat like what the ThreadPool class does, but with much greater flexibility and control.

- PLINQ
It's a implementation of LINQ that allows anyone to easily make declarative parallel queries. All it's needed is to transform the IEnumerable<t> into a IParallelEnumerable<t> using the AsParallel() extention method. It's not optimized yet, but it certainly can boost many applications with almost no code change.

- Coordination Data Structures
It has a group of synchronization classes that enhance those that currently exists in the framework. Also, there are some thread-safe collection classes. Coincidently, they've created a ConcurrentQueue class that serves the same purpose as the one I've posted!

A detail that you can't avoid noticing in this framework is the extensive use of delegates. LINQ itself is based on delegates being passed to other functions. This type of construct is called a higher-order function. Another construct that is present in PFX is the continuation. Also, there are recurrent remarks in its documentation about side-effects and why they have to be avoided. All these characteristics are usually associated with functional langagues. No surprise some of the samples are in F#.

Functional programming has lived almost only at the academic world, but its future looks different. It holds a lot of interesting and useful concepts. The disturbing part is that very few programmers really know these concepts. Do you know any skilled/experienced/old programmer that can't understand OO programming? Well, can you really understand functional programming? I don't. At least not yet.