<< On RYO vs. NIH | Home | Java & Spring: Impressions From a non coding perspective >>

Event Broker Spiking

Just spiked a test implementation on an Event Broker (similar to the CAB), basically support for loosely coupled events / commands. Took about... 40 minutes :-)

My understanding of the functionality in the CAB is based around:

  • [EventPublication], [EventSubscription]
  • [CommandHandler]

As far as I can see the separation between the two is main artifical, and based on whatever this is your code or a third party. Since both rely on events as the underlying mechanism, I don't see a reason to separate them out.

Biggest issue: string equality is a bummer.

I might do a live coding screen cast, showing how it can be done. Tried it now, but it is 2:28 AM right now, and I sound like a drunk sailor. I got tired of apologizing of slipping to Hebrew, and cut the recording.

That 40 minutes mark is starting to freak me, to tell you the truth...

Print | posted on Friday, May 25, 2007 2:31 AM

Feedback

Gravatar

# re: Event Broker Spiking 5/25/2007 3:45 AM Jay Flowers

There are ways to over come the string keys. A combination of things like external polymorphism, generics constraints, reflection, and reflection emit can get you there. Note you may not need them all. Take the reflection emit, you only need this if performance becomes and issue. So don't think that I am saying that you need to use them. I am saying they are tools at your disposal to solve problems that tend to arise in that domain.

Gravatar

# re: Event Broker Spiking 5/25/2007 7:11 AM Chris Khoo

ooh, can't wait for this one - would love to get your perspectives on it :-).

Chris

Gravatar

# re: Event Broker Spiking 5/25/2007 8:12 AM Bil Simser

It's interesting. Between you and Jeremy, you'll single handly build a version of CAB but is this really the point of this excercise? Is the issue is that CAB is large and unweildly and the guys that follow what P&P is pushing should look towards more lean and mean implmentations like this? Are you guys saying that the current CAB is good in concept but poor in implemenation. Just trying to figure out the intentions behind these excercises.

Gravatar

# re: Event Broker Spiking 5/25/2007 1:00 PM Ayende Rahien

> the point of this exercise?
I, at least, am having fun. There isn't much to it otherwise.

I am saying that the CAB has a lot of good idea, but I don't like the direction that it takes. This is different than saying that I don't like the implementation.
Implementation == code, direction == overall design goals of the system. IMO, the CAB has a too intrusive approach, which makes things a lot harder to deal with for the end user.

Gravatar

# re: Event Broker Spiking 5/25/2007 3:32 PM Bil Simser

Fun is always high on my checklist when building software, so have at it. I still don't see how CAB is intrusive so it'll be interesting to compare your end result with CAB (specifically around the pieces you implemented only) to see how intrusive either is. I personally don't see the intrusion myself.

Gravatar

# re: Event Broker Spiking 5/25/2007 4:44 PM Nate Kohari

I've implemented an Event Broker in a messaging add-in for Titan as well, which also uses string identifiers for channels. Since the rest of Titan is much more intelligent than that, I'm interested in anyone's ideas to alternatives. The real difficulty is that I want to be able to set up the pubs and subs declaratively via attributes, and you can't get much more intelligence in attributes other than constants...

Gravatar

# re: Event Broker Spiking 5/25/2007 9:20 PM hammett

I'm not familiar with event brokers. Is this something similar to the Event Bus pattern?

Gravatar

# re: Event Broker Spiking 5/25/2007 9:24 PM Ayende Rahien

This is basically an event registry, you can register to an event, and something else can invoke it.
The idea is that I can register to "Customer-Added" event, and someone else can raise it. This is limited to a single app model, since the underlying model is .Net events, basically.

Gravatar

# re: Event Broker Spiking 5/25/2007 9:25 PM hammett

Is it different from the Castle's event wiring facility?

Gravatar

# re: Event Broker Spiking 5/25/2007 9:32 PM Ayende Rahien

Yes, somewhat.
The Event Wiring facility assumes that you know in advance all the subs & pubs in the system, since you need to configure them.
The event architecture that I am talking about is basically raising an event "into the cloud", and something else handles the wiring to the end result.
Best shown with code:

public class CustomerService {
[Subscriber("event://CustomerAdded")]
public void CustomerAdded() {... }
}
public class CustomerView
{
[Publisher("event://CustomerAdded")]
public event EventHandler CustomerAdded;
}

Neither one need to know of each other, but raising the event from the view will call the method on the service.
I don't think that this is particularly good example, BTW.

Gravatar

# re: Event Broker Spiking 5/25/2007 9:40 PM hammett

Ah, cool. That's more Event bus really. The event bus catches the events and dispatches it using some interesting logic, and possibly filters. Very useful for desktop applications!

Gravatar

# re: Event Broker Spiking 5/26/2007 1:02 AM Bil Simser

Two things I"m curious about. First, why do you say the last example (CustomerAdded event) is a bad example? Second, if you don't like string equality then why not use real objects, much like how Rhino does mocking (way better than how NMock2 did wtih it's string method and object names). I mean, if you're setting out to build a similar mousetrap that's simpler then the CAB implementation, why not build a better one for the same cost (okay, using objects and maybe reflection is n+ more effort than comparing strings, but I don't think it's a huge effort is it?)

Gravatar

# re: Event Broker Spiking 5/26/2007 1:16 AM Ayende Rahien

Actually, I meant the business concerns in the sample itself is not a good example.
About strings, that is an issue that I have to take with the CLR team. Attributes can accept a limited number of parameter types. Basically int, long, string and System.Type. This limits the ability to do anything _really_ interesting with attributes.

Gravatar

# re: Event Broker Spiking 5/26/2007 7:00 AM Bil Simser

Ahh, wasn't aware of the implemenation. Good to know. And 3.5 doesn't address this? Pity.

Gravatar

# re: Event Broker Spiking 5/26/2007 1:37 PM Ayende Rahien

No, 3.5 doesn't address that, a huge pity.

Comments have been closed on this topic.