Going back to our earlier discussion.... As outlined in the quoted
message, the goal was to create a distributed EventManager (note that
class names are different from what was designed in June). Distribution
of events across VMs is done by creating instances of EventBridge
subclasses. Each instance links a local EventSubject with remote
subject. EventBridge can work in a one way mode (send or receive) or
two-way. There is a default mechanism to translate local subject to
remote subject, so when all communicating applications are using
Cayenne EventManager locally, there is no need to worry about remote
subjects). Using explicit EventBridge instead of distributing all
events allows fine grained control.
There are two working implementations of EventBridge - JMSBridge and
JavaGroupsBridge. I evaluated both JMS (using OpenJMS as provider) and
JavaGroups for remote notifications, and I totally agree with Holger
now - JavaGroups is much simpler to use and with its auto-discovery
features requires virtually no configuration. JMSBridge works, but has
the following shortcomings:
1. Generic implementation requires configuration via JNDI to discover
JMS topics and connections.
2. Generic implementation does not allow to create topics (subjects) on
the fly. You have to do it using server management tools. I had to
create an OpenJMSBridge subclass to use OpenJMS admin features to
create topics in the code - not very portable.
3. JavaGroupsBridge was much easier to code.
For our immediate needs of distributing cache synchronization events, I
am planning to use JavaGroupsBridge by default. Users will have a way
to switch to JMS or anything else they want programatically. There are
a few more things to do here, but at least on the events side I think
we are in a good shape.
So here we go - Cayenne now has a generic multithreaded and distributed
event mechanism, that is not tied to Cayenne persistence features in
any way and can be used in any application. Sweet.... ;-)
Andrus
On Jun 27, 2003, at 7:39 PM, Andrus Adamchik wrote:
> On Friday, June 27, 2003, at 06:29 PM, Holger Hoffstätte wrote:
>
>> Oh, just curious - any reasons why you are going for JMS directly?
>> JavaGroups really is nice since it works at an higher level,
>> automatically
>> creating master/peers, taking care of delivery, removing dead peers
>> and
>> reelecting a master etc. Have a look at the HSQLDB
>> replication/clustering
>> whitepaper, it's really sweet.
>
> I will definitely look at the whitepaper. Now I am kind of researching
> the options. What I came up with is an adapter between "local" and
> "remote" messaging which is a transport independent abstract class
> (JMS adapter being its first implementation). It will work like this:
>
> 1. To make an event (or rather - subject) distributed, an instance of
> DistributedNotificationAdapter is registered with EventManager just
> like any other listener would.
>
> 2. When a DistributedNotificationAdapter receives an event from
> EventManager, it resends it outside (using whatever transport it
> implements)
>
> 3. When a DistributedNotificationAdapter receives an event on its
> "external" interface (say a JMS message), it recasts the event into a
> local event and posts it via EventManager.
>
> This makes "distribution" feature external to the EventManager. I kind
> of like it. Not sure if this approach has any inherent limitations. I
> will definitely need to do some research.
>
> I started with JMS (and not JavaGroups) since JMS is part of J2EE1.3
> and is therefore ubiquitous, and does not require Cayenne to bundle
> extra dependencies (and of course if notifications are disabled in an
> app, no J2EE installation is required). Wanted to see how this works.
This archive was generated by hypermail 2.0.0 : Fri Nov 21 2003 - 13:42:09 EST