Hey, I was supposed to go and get a diving certificate today, but the Berjaya Air pilots decided to strike this morning, so that's off. Oh well. But, while in the car back from the airport I started thinking about a topic that we haven't touched upon yet, and which I think is very important: the messiness of messaging (pun intended).
Crazy thoughts ahead. You have been warned! One of the problems is how messaging sending is going to be dealt with in coordination of UnitOfWork. Preferably, if application code generates a message in a UoW, then it should only be sent if the UoW actually completes, i.e. the message sending has to work together with the entity management stuff, preferably using transactions as the way to decide what to do. Also, one of my plans is to make it really easy to create rich clients, which can work with the domain model. But then, if the application rules involves creating messages as side-effects of domain method invocation, then these messages will be created on the client, and not the server. How are they going to be sent? Especially, if the rich client is working in disconnected mode (which I also want to allow), then how will the messages be stored on the client and then sent when it connects back to the server? And finally, from what I've seen from message sending API's so far they are far too low-level for most application code. There's too much error handling and nitty-gritty going on. So what if the JMS server is down, send it later. I don't care if I have the wrong password to the SMTP server, get it fixed and send it later, etc. I want message sending to be like going to the post office: if I manage to get there and hand it over to the clerk, I don't care exactly where and how it gets to the stated address, as long as it does so. As I was thinking about these problems I had this idea: what if sending a Message was the same thing as creating an Entity. Then all of the above problems would go away! * Creating a Message as an Entity in a UoW is trivial, and the semantics are automatically correct: if the UoW completes, the messages are actually created and sent off by doing prepare() on the message storing EntityStore. * If the send doesn't work immediately, then they are simply stored locally temporarily (at which point it would be possible to actually retrieve them using EntityStore.getEntityState() and possibly cancel them, just like a Draft folder in email). * Having disconnected rich clients is no problem. The Messages would be created locally in the client, and stored so that they could be sent later when the client connects to the server. * If the EntityStore cannot be generically configured, i.e. to send a message it has to know where and how to connect for each Message, this can be put in an Entity referenced by the Message (like "Account settings" in email), which can be trivially accessed. All the details about how to use each message sending transport could then be put into an EntityStore. Maybe one store for each type of transport, or maybe even just one store with multiple configurable transports. What say ye? Does this sound reasonable? I am a relative newbie with messaging so maybe this is not practical. If this is a good idea, then there are interesting things we can do with EntityFinder on the message consuming end as well... >:-) But one thing at a time. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
