My strategy for implementing session messages - and the half a dozen still nonexistent components which it depends on - is to start with a walking skeleton. This is the approach recommended in the GOOS book which I wrote about in Design for Integrability. In this episode I will explain my strategy and implement the outline of the walking skeleton.
Actually this is the second time during this project that I've used a walking skeleton. The first walking skeleton included receiving a login request and responding to it with a login failure. The first skeleton let me put in place these components: system startup, application loading, networking, authentication and the controller-actor architecture. This second skeleton will produce: unique timestamps, session IDs, worker thread handling, application APIs to listen for and send session messages, executing tasks in application code, sending session messages and committing transactions.
P.S. I wonder whether these may technically be called the first and second walking skeleton, since they don't include all main architectural components. This system has lots of essential complexity, so I prefer taking as small steps as possible. You could say that at first I implemented the legs of the walking skeleton (the controller-actor achitecture), now I implement the hands of the walking skeleton (task execution), and later I will implement the head of the walking skeleton (persistence).
