* UnitOfWork-like - i.e. any "result messages" are not sent until everything is completed successfully.
Initial thought: Messages should be sent as part of completing a UnitOfWork. Currently a UnitOfWork is delegating to a list of relevant EntityStores updating Entities. Maybe it is about time to think of a UnitOfWork committing to relevant XXXStores handling XXXComposites (with XXX being either Entity or Message) ? This way a UnitOfWork could be regarded as similar to an XA transactionmanger handling multiple XAResources (stores). The need for configuring a messagesender (MessageStore?) will probably be much similar to configuring an EntityStore. Another analogy (not quite compatible with above) could be to regard AplicationEvents as @SideEffect of a composite - and Messages as @SideEffect of a UnitOfWork - but I think the MessageStore-as-similar-to-an-entityStore is more relevant. /Kent Den 17-06-2015 kl. 05:46 skrev Niclas Hedhman: > Gang, > I have been thinking a bit about a "Messaging" abstraction, similar to the > "Storage" and "Indexing" abstractions, and looked at my own implementations > how they are done, and see if we can come up with an Extension mechanism > that is suitable for a whole range of Messaging Extensions, such as > > * Restlet > * Jersey > * JMS(?) > * Kafka > * Storm (?) [1] > > There are a few initial "requirements" that I have written down on my white > board; > > * UnitOfWork-like - i.e. any "result messages" are not sent until > everything is completed successfully. > * "Destination" concept - the entry point for event request processing > * Hierarchical delegation - think "paths", "routing", "intercepts" > * Request Parameters - think "headers" in HTTP or other metadata > * Request Payload > * Payload objects - converted into ValueComposites through mapping > * Binary payloads - byte[] blob > * Message Receiver is created per request. Factory implementation from > user. > * Optional Response Messages - probably part of a return type. > * Usecase metadata for Request Parameters, possibly lazy deserialization. > * Message Destination injection, for outgoing messages. Possibly a new > Composite meta type. > * Visibility - some messaging may be internal to the application, using > the same abstraction. So Visibility should be used as usual. > * Capable of distinction between Load Balanced Queues, Pub/Sub and > Peer2Peer Queues. > > In very, very broad strokes, we are looking at something like this (Kafka > used as an example); > > > ___________ +----------+ ___________ > O partition O--| Kafka ME |--O partition O > ----------- +----------+ ----------- > | ^ > v | > +--------------------+ +------------+ > | Qi4j Messaging SPI | <--serves--| MC Factory | > +--------------------+ +------------+ > | ^ | > v | | > +----------------------+ | > | MessageComposite (MC)|<--instantiates--+ > +----------------------+ > > > This picture doesn't involve the many options required to be handled, but > should serve as a mental model to help understand where I am coming from. > > Before I start looking at how this could be done, does anyone have any > input on the topic (pun intended, as Topics are part of the problem domain > somehow, but I haven't worked that out yet) > > > > [1] Getting an abstraction right, which allows Zest/Qi4j applications to be > part of the Storm topology would be awesome.
