Michael Hunger wrote: > Great ideas, thanks for the input. > > What about using the "different roles" of an entity to model either the > different places it can be (and so having > different view on the same message) i.e. draft, outbox, inbox, trash. So you > just add a interface and mixin and use > Entity.cast to supply it with the different states the views require.
Yup, that's the idea, although I think a regular Class.cast() will be enough (as already outlined, I still don't understand how Entity.cast() is supposed to work and am almost in favor of removing it until we figure it out). > The same seems to be possible with the topic. Just add another Composite > interface for the properties related to topic > and then use that as required. Perhaps topic is only one of many message > attributes that we have to look at (see the > QoS, Security & co aspects that also could be done with Concerns or > SideEffects). When you say Concerns and/or SideEffects, I assume that is on the message sending service. The Message itself will be fairly dumb as I see it, but will definitely have interfaces to declare QoS, Security and so on. > If you look at emails in your email system. These are really instances of an > email type which is created at the sender, > stored in draft then outbox and sent if some condition holds true (server > available, time to send, manual sending). Then > the message keeps living in the outbox and a separate view (or entity state > copy) of it is serialized and transferred > over the wire over lots of stations which use other concerns to evaluate > (spam) route and finally deliver the email > entity to the recipients system. There the last service (entity store) makes > it available for the client which queries > the entity store (using imap or pop3) for new messages every x minutes > polling (or is pushed the messages actively by a > service - blueberry). Then at the receivers client there is a local entity > store (inbox) which holds the messages and > can be queried (keyword filtering etc, attribute sorting & filtering etc.) by > the user. Pretty much agree with the above. > Sound perfectly fitting. With business busses you add more QoS, Reliability > and Transactions, Security to the picture. > But in general it keeps the same. > Regarding multicast; publish/subscribe etc. these are just concerns that can > be added to the message as needed. As above, descriptions of publish/subscribe etc. are added as mixin types to the message, but the actual implementation is either in the EntityStore or as Concerns on the EntityStore if possible. > Perhaps looking at Gregor Hohpe's Enterprise Integration Patterns would help > to identify the most important properties > we have to support? Good point. Here's the link, for reference: http://www.eaipatterns.com/ And again, I'm a total newbie with messaging, so any help would be appreciated. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
