Two of the goals I have for the Moxie messaging system is to use the Tuple Space architecture and to have completely autonomous messages; that is, messages not tied to a particular transport and not necessitating a request/response architecture. I’m not sure now, however, that this can be done to the ideal that I had in my head.
For one thing, I’m not going to have an Internet distributed Tuple Space. I never planned to, mind you, but it seems that if I don’t, then I really don’t have Tuple Spaces. The problem here is that a Tuple Space, regardless of how many machines make up that space, is supposed to act like a virtualized memory store. Spanning such a system across the Internet is probably not doable.
That’s okay, what I wanted was a local Tuple Space (TS) that can post messages to and receive messages from other TSs. More accurately, my original conception was to have senders post their message to any TS, along with the address of the TS it is expecting replies to be sent to. This is easy enough to visualize.
However, I also want to support message intermediaries. That is, any number of other processes could sit in the message flow without anyone necessarily knowing. This is the primary driver for autonomy and pulling what is normally at the transport level up into the message.
In thinking about this, though, it seemed it would be more straightforward, and would make securing Moxie servers easier, if “particpants” read from and wrote to the same Moxie server. If any messages were intended for a foreign server, then the first could route it on. This is analogous (exactly the same, really) to how email MTA’s work today.
This allows me the latitude, should I need it, to have one protocol for local Tuple Spaces — at least for reading from them (ala IMAP or POP), and another for interconnecting Moxie servers (ala SMTP). This, of course, raises the question of why invent email all over again. Well, I’m not, I’m inventing Message Oriented Middleware all over again, but this time with XML and without the baggage of SOAP and WSDL and UDDI.
Up next: The Moxie Message Format.