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
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:
Content. They also have a
Priority fields and some other properties.
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.
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
value pairs where the names and values can be any object.
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 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.
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.