Messaging Only

(via Bill de hÓra)

I agree with the observation...

Messaging APIs are dying on the vine, ws-* stuff just redefines the existing APIs with ws-* APIs and transports but does nothing to simplify the life of a programmer.

...but not the cure...

Messaging is just state, state should be managed the same way whether its state from a message or state from an inmemory database like ObjectGrid or state from a relational database... messages should not be orphans in your data model

I think there is a time and place for in-stream, "continuous query" capability, but those a few and far between. Rather a simple Javaspace-like or Erlang-like pattern matching on individual messages should be sufficient for messaging, keeping the query stuff out of the stream and in memory or disk-based database-like thingies.

The biggest problem with messaging for Java (sans Javaspaces), and most other non-Erlang languages, is that creating and using even the simplest of inter-process message queues is a relative pain in the tush. Just creating another process is painful.

JSM and locking messages matched by queries joined from other (mutable) objects? Ugh. No.

Better?

How about making it easy to create a new process and automatically giving each process its own inbox and outbox supporting simple pattern matching? Some of these inexpensive processes could be storing up data and doing all kinds of queries over that using JPA or whatever floats your boat.

In Erlang and in Gambit Scheme, every thread (in Gambit, process in Erlang) automatically has its own inbox and outbox. In Gambit those are not automatically inter-process. Unix processes are the same way, but still not as easy to do, esp. remotely, as in Erlang.

Someday we'll look back and say, "Remember when starting a process was hard, and communicating with them was harder?"