polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent SĂžlvsten <kent.soelvs...@gmail.com>
Subject Re: Messaging abstraction (for 3.0)
Date Wed, 17 Jun 2015 09:25:53 GMT
  * 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.


Mime
View raw message