BOOL Message Center

It’s been a while since I’ve waded in BOOL waters. As always, there are periods of strong interest and periods — often quite long — of dormancy. Finally solving most of the implementation problems of the language triggered a period of disinterest. That and some uncertainties about exactly how to implement Action Methods, especially the “new” method.

But I recently did have some fun with a BOOL/OS subsystem, the Message Center Service. I roughed out a crude working version in Python that provides a flavor of the real thing’s architecture.

The main module is the BoolMessageCenter class, the centerpiece of which is the dispatch method. A BoolWorkSpace (WS) instance requires a BoolMessageCenter (MC) instance to handle messaging. The MC manages a collection of BoolMessageQueue instances, each of which manages its own queue of BoolMessage objects.

The MC groups multiple Queues under a key to a BoolProcess, so there is a list of Processes, each of which can link to multiple Queues. The MC also has a list of all Queues.

Each Queue is therefore owned by a Process, and all inter- and intra-process communication is between Queues. No Process can communicate (or accomplish anything) except through Queues. The BOOL/OS is message-based, so all system requests and responses move through Queues.

Process Queues include:

  • System — required, system commands, hi-priority processing
  • Command — required, default Queue for requests
  • Log — can automatically log Process activity
  • Inbox — input Queue for request responses
  • Outbox — output Queue for request responses
  • Data — used by Process to stash objects

There can be any Queue a Process desires, but the System and Command Queues are required for any Process. In some cases, the Command Queue is the alias of the System Queue. In general, the MC allows multiple Queue records for a Process to link to the same physical Queue object in the MC.

Queues support the notion of callbacks. A Process can register an Action to handle Queue Messages when they are received. The MC thread invokes a new thread to run the Action (under the Process account).

Messages have four key fields: Source, Destination, Caption, and Content. They also have a MessageId, a TimeStamp, an ExpireTime, plus Status and Priority fields and some other properties.

The Source and Destination fields link to the sending and receiving Message Queues. In a working system, the values are opaque keys that link to Queue records managed by the MC.

The Caption field is a string that labels the Message (and is used in listings). The Content field contains the Message Object — which can be any object expected by the receiving Process. Pragmatically, a Message is a collection of namevalue pairs where the names and values can be any object.

The MC dispatch method is normally bound to a BOOL/OS Port. The MC, of course, has its own set of Queues, and other applications can communicate asynchronously with the MC via its Command Queue. The faster, preferred, method is via the Port, which is synchronous. (Ports block and return a reply, but they are required to have very low latency. A Port request with longer latency returns a “Check back later” response along with a “Coat Check” ticket. The Process uses the ticket to request a status after waiting.)

An MC Port request contains up to four fields: Command, Target, Sender, and Properties. The Command specifies the type of request, and the Sender is a Queue belonging to the sending Process. The Properties field is optional and is for additional data used by various commands.

The Target field varies depending on the command, but basically identifies the destination Queue. With Queue management commands, the Target is the Queue ID — with Queue Message commands, it’s usually the Queue Connection ID.

Queue Commands include:

  • QLIST namespec src-id: returns list of Queues
  • QFIND taglist src-id; returns list of Queues
  • QADD name src-id properties; returns queue-id
  • QGET name src-id; returns queue-id
  • QCLR queue-id src-id
  • QSET queue-id src-id properties
  • QRST queue-id src-id
  • QDEL queue-id src-id
  • QOPEN queue-id src-id properties; returns connection-id
  • QCLOSE connection-id src-id
  • MADD connection-id src-id message; returns send-receipt
  • MGET connection-id src-id properties; returns message

The MC also maintains a list of Queue Connections, which are links between a sending or receiving Process and an “open” Queue. (To send and receive, a Queue must be “open” on a Connection.) A Process that no longer needs a Queue should close the Connection.

%d bloggers like this: