Hi Derek,
On 3/17/2014 11:39 AM, Derek Abdine wrote:
Scott, thank you. Regarding messaging, I have two chief use cases:
1. Operational / Control messages. Expected to be low-velocity. Expected
to have a degree of persistence, scale, failover, etc.
2. Data messages. Expected to be high to very/extremely high velocity
(thousands+ messages per second). Need for persistence is optional.
Fire-and-forget (no ack) support, etc.
Based on my knowledge of messaging those concerns fall mostly on the
underlying message implementations (activemq/rabbitmq/kafka/etc.)
themselves, rather than a client API. So, intuitively (and albeit naively
as I haven’t done a full analysis yet) I’d assume I can use the event
admin abstraction for both cases and swap out the underlying message
implementations depending on independent concerns.
WRT ECF's work...yes...that's exactly correct. The Distributed
EventAdmin abstraction (and any OSGi standardization that
my/could/hopefully will occur in future for such an abstraction)...is in
our impl loosely coupled/separate from the messaging implementations
(wire protocols+msging apis).
That being said, I’d be
inclined to just use it until such time that it doesn’t work (for example,
the event admin implementation adds too much overhead, creates too much
coupling to the OSGi platform or doesn’t support some level of message
metadata that I’d need — these are all made-up examples). However, if you
have walked this path before and have any pointers I’d greatly appreciate
it!
Sadly I can't give you direct pointers. There have been consumers of
the distributed eventadmin work in ECF...but so far these consumers have
chosen to not make us (ECF committers) publicly aware of what they have
done...in terms of their specific use cases, customization decisions
(e.g. underlying msging impls), app deployment choices, etc. Of course
that's their right...and I understand how it could make sense for
them...e.g. for competitive reasons.
Since you may be interested in more direct dialog about ECF in
particular and this is not the right list for such a dialog, please
consider joining/posting to this mailing list [1].
Scott
[1] https://dev.eclipse.org/mhonarc/lists/ecf-dev/
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
