DEV Community: Philip Braham

UMM plays chess

Philip Braham — Thu, 09 Jul 2026 07:35:55 +0000

Universal Message Manager is a publish and subscribe system. So a sender of a message is detached from the receiver and the receiver is independent of the sender. So in a chess game we have these components:

A chess board and the ability to move pieces. This is an html gui client.
An agent (which is a UMM term for an application that sends or receives messages) to determine valid moves and to determine checkmate and other conditions. This is the legel-moves agent.
An agent (which may the same as 2) to play a move. This is the chess-engine.

Agent 3 is optional if there are just two players

The game is run as follows:

A board sends a message with the initial state of the pieces
When a piece is touched a message is sent with the current position.
The legal-moves agent receives this message and sends a message with all the legal moves this piece can make. These options are then shown on the screen.
When a piece is moved the move is sent as a message.
If two players are playing, the other board receives this message, updates its screen and waits for return play.
If the other player is the chess-engine it receives the message and sends a message with its play.

The important point here is that playing a human or playing a machine is no different as far as the system is concerned.

Similarly, there can other boards set to simply show the current state of play and they update their pieces on the board when receiving the messages.

All these messages can be monitored and then played back. As far as a board is concerned the played back messages are identical to messages sent from another board or from the chess engine.

See online here: UMM plays chess

Using AI for coding

Philip Braham — Fri, 26 Jun 2026 11:27:23 +0000

I've been using AI - Claude - to code and it seems apparent to me that programming in the way we are doing it at the moment will be obsolete within a year for the most part. At the moment you would still need an understanding of programming and design skills to prompt AI and to refine the results. I'm sure that will become less necessary in time.

However, there are some caveats to using AI.

Any complex system is made up of interrelated modules that perform certain functions: logging to, or retrieving data from, a database; monitoring sensors; A gui to interact with users; the list is varied as any systems designer would be aware. So there are two issues: one is how do we integrate Ai written modules with existing systems, and that's for another post, and the other I want to address here.

If we are designing a completely new system we could, conceivably, give the complete specification to AI and let it build the project. Except, of course, that we can't design a complete system from scratch and expect it to work. We could go through an iterative process that will eventually get us to where we need to be by going, as it were, in ever decreasing circles. Using agile design, prototyping and other methods. These presume that the system can be broken down into modules that can be defined, demonstrated and tested stand-alone. For instance, we have to be able to show a gui to a user without the working system the provides the data for the gui.

Even if we could specify the project to the point where we could simply tell an AI system to go ahead and code, the resultant system would be extremely difficult even for an experienced programmer to understand. And why should anyone take the trouble to understand it? In one sense it defeats the purpose of getting AI to build it. So here lies a problem: if something goes wrong you are dependant on AI fixing it. Modules may be so integrated that making a small change to one module could result in unforeseen effects elsewhere.

The solution is to break any complex system into easily definable and testable modules. UMM (Universal Message Manager) is a publish and subscribe system that connects modules - called agents. An agent receives messages of a certain type, performs certain actions, and (usually) sends messages of a certain type. These messages can be sent from tools supplied with the system so any agent can be easily specified, monitored and tested. Even a complex system can be easily maintained and understood.

Unlike client / server where the client and the server must be built together and are inherently conjoined, publish and subscribe works on the basis that the receiver of a message doesn't know the sender and the sender doesn't know the receiver or receivers. In UMM not only are the senders and receivers separated but also the messages are self-describing so the data in the message is not dependant on a receiving agent expecting data in a particular format.

Of course a client / server modal can be built on top of the UMM infrastructure but even here the usual dependancies disappear. For instance all messages between client and serve can be logged and a server can be replaced mid-session with no loss of data.

If this is of interest, take a look at UMM. We welcome any comments.

Integrating legacy systems

Philip Braham — Tue, 23 Jun 2026 10:23:02 +0000

One very successful way of integrating legacy systems with each other, and with modern technology, is through the use of middleware. A layer that on one side uses APIs to collect data from the legacy system and on the other integrates with other systems.

Imagine a building with key-card access and lift controllers, air-conditioners and alarm systems all by different manufacturers. With middleware each system acts as an agent for a control system that can, for instance, ensure that the air-conditioner is turned off if there is no one in the building, the lifts are returned to the ground floor, the alarm system is enabled and so on.

UMM is middleware and API agents can be very easily written and configured.

See UMM as middleware.

Teaching programming

Philip Braham — Mon, 22 Jun 2026 05:48:50 +0000

UMM (Universal Message Manager) was originally designed for control systems. When we released the finished version we realised that we had something that was extremely powerful and had uses way beyond those we originally envisaged. One use that became apparent was as an aid in teaching programming and system design.

UMM systems are built around small applications (agents) that perform tasks. These may be very simple (such as turning on or off a pump) or quite complicated (such as looking up data in database). Agents are triggered on receiving messages, they perform a function, and then (usually) send messages.

Students as a group can design a full system, design the agents and the messages that need to be sent and received by each one, then groups of students or individuals build each agent according to the specifications. Each agent can be tested stand-alone simply by sending the designated messages and monitoring the behaviour and the messages being returned. The agents are then integrated into a running system.

In the system as supplied we have two examples: a tank monitoring system and more complex parcel sorting machine that show working UMM designed systems.

The basic system is written in Python but agents can be written in any language.

UMM is free for educational use.

Visit our website for more information.

The history of UMM

Philip Braham — Sun, 21 Jun 2026 00:57:37 +0000

In the mid 1990s I was working at Realtime Software on a project to automate an aluminium smelter. One of the problems was that there were many disparate elements of the system that needed to communicate with each other:

Control of the smelting reduction cells (called pots) that produce the metal is done by raising and lowering the anode into a smelting pot which is a cathode.
There are temperature sensors to measure the temperature in the pot.
There are ammeters to measure the current through the pot.
Operator screens show the current state of each pot line (there are 186 pots per line and 3 lines in just one of the smelters).
A database records each activity - movement of an anode, topping up and emptying of a pot etc.

Ian Jamieson, MD of Realtime, produced an idea that would make this easy to control. It was a publish and subscribe system that we called Message Director. Applications controlling each aspect of the system communicated through messages that were handled by a central 'director' application. An application that controlled movement of the anode, for instance, received messages that directed it to move. These messages could come from an application that controlled anode movement by monitoring current and temperature through the pot but could also come from an operator console where an operator could override the system movement. A database application also received these messages and logged the movements to a database.

The project was finished (under time and under budget with only 3 people!). Unfortunately, after the project was finished Ian died in a car accident whist driving to the smelter.

I realised that this concept was world beating. There was one deficiency, however. In Message Director, the receiver of a message had to know the data format of a message it received. For instance a message that directed the movement of an anode had a particular message format, in this case a structure with a pot number, a movement amount (+ or -) and some other data. Similarly, each message had a format that that any receiver of the message needed to know. This diminished the universal concept of publish and subscribe in that a publisher shouldn't care who receives the messages and the receiver shouldn't care who published it.

I moved to Queensland to work on a smelter there and around 2000 got funding from the Queensland Government to develop Universal Message Manager. (As it happens, this was in the same office where WiFi was developed.) We had students from the University of Queensland working on the project, and also developed a layer to work over Bluetooth in its early days. However, I couldn't get a suitable company interested enough to fund the project to the point where it was marketable. I needed a team of programmers who could understand the concept deeply enough to build it properly — and for years, that team never came together.

This year, that changed. Working with Claude, I finally had the team I needed. Claude suggested Python to build it initially, though the design allows agents written in any language to be plugged in. I directed the design throughout — the architecture, the FSM model, the layered addressing, decisions grounded in twenty-five years of industrial automation experience — and reviewed, tested, and corrected the implementation at every stage. Claude did most of the actual coding and a large part of the documentation under that direction, and grasped the concepts quickly enough to spot potential in the design I hadn't fully seen myself, including its value as a teaching tool. The result is a genuine collaboration: a concept I'd been unable to bring to life for two decades, finally built to a level of completeness that would have taken a small team of human programmers years to reach.

Find out more

Universal Message Manager

Philip Braham — Fri, 19 Jun 2026 10:50:34 +0000

Back in the early '90s we were working on automating an aluminium smelter in Australia. We developed a system called Message Director: a publish and subscribe system that allowed applications to communicate on bus where messages were published, and subscriptions made to, a director application. All messages were logged and applications could be changed or added to without effecting other applications. It was incredibly successful. We finished the automation with a team of 3 people within time and under budget.

In a publish and subscribe system, senders and receivers of messages are ideally not associated. However, the problem with the original system was that because data was binary data a receiver of a message had to know the format of the messages it was receiving.

Subsequently I went on the develop the concept into a more universal system called Universal Message Manager (UMM). In UMM all messages are self-describing. Small apps (called agents) can be written that have a simple task: receive these messages, do a task and send those messages. In one example that comes with the project. we have a tank monitoring system. A tank monitoring agent sends messages on the tank level, a pump agent receives messages when the tank level is below 10% and above 90%, switches on and off accordingly, and sends out confirmations messages. These messages can be seen on the screen, logged and a database application logs them the a database.

UMM is ideal for teaching as the agents are self-contained but can be used together to form a complex system. Another example on our website is a parcel sorting machine. The agents in the project are written in Python with a C option available. Agents can be written in any language.

The UMM project and documentation can be downloaded from https://umm.braham.net. It is free for non-commercial use.

We're particularly interested in people who want to use UMM for teaching.