Rhino Service Bus. First, I need to justify why I am doing this. In the past, I have evaluated both NServiceBus and Mass Transit, and I have created applications to try both of them up. Both code bases have enlightened me about the notions of messaging and how to make use of them. That said, they are both of much wider scope than I need right now, and that is hurting me. What do I mean by that? Right now I am introducing a whole lot of concepts to a team, and I want to make sure that we have as few moving parts as possible. If you go through the code, you'll see that I liberally stole from both ideas and code from Mass Transit and NServiceBus. The current code base is tiny, ~2,550 lines of code, cohesive, and well designed (I believe). Some of the highlights: C# 3.0 & MSMQ 4.0 - taking advantage of features such as sub queues, async queue receiving. Let me try to go over each item and explain what I mean in it.
The next two points are sort of contrary to one another. And in order to start the bus: <? Lightweight Service Bus frameworks. The application environment I work on needs an architectural fundament capable of a loose-coupled integration. There's a reference handbook on integration patterns, the "Enterprise Integration Patterns" by Hohpe/Woolf (also take a look at the "Integration Patterns" book from Microsoft Patterns & Practices group). Anyway, there are four major integration patterns: File Sharing - where application share data by exchaning files Shared Database - where applications are build around a single database Remote Procedure Calls - where applications expose their data through remote interfaces Messaging - where applications exchange messages with the help of a centralized component (called a "Service Broker" when the messages are processed synchronously or the "Enterprise Service Bus" when a messaging component is used to store and handle messages) which acts as a backbone of the application environment [
Playing with Mass Transit - Publish/Subscribe. Discussions at ALT.NET and with Greg Young made me realize that I need to get more into messaging so I thought I’d start with a piece of work I’m doing now that is ripe for a bit of messaging. The piece of work relates to domain events, when an event happens in the domain (e.g Customer becomes active) we generate a message which subscribers can pick up. Generating an MSMQ message and sending it to subscribers seems sensible. The obvious framework to look at was NServiceBus but Mass Transit is an alternative which I decided to try.
Whilst playing with it I thought I'd write up my discoveries in the hope that someone might be useful and also produced a little sample project which you can download here. First I should add some caveats: Note that this sample contains a copy of some the Mass Transit code, I've done this to make it easier to setup/debug but the code will quickly go out of date so it is certainly worth downloading the latest copy. Running The Sample Message Delivery Options.
Building Our Own ESB - Publish Subscribe Part 1. Rhino Security Overview: Part I. A few months ago I spoke about how I would build a security infrastructure for an enterprise application, I went over the design goals that I had and the failing of previous attempts. Since then, I got a few requests to implement that, and since this is really neat piece of work, I decided to go ahead and build it. The main goals, allow me to remind you, are: Flexible Performant Does not constrain the domain model Easy to work with Understandable No surprises You can read the post about it to get a feeling about what I had in mind when I thought it up. When it came the time to actually implement them, however, it turn out that as usual, the implementation is significantly different than the design in all the details. The main part that we have here is the security model, but notice that the application domain model is off to the side, and have very little to do with the security model. The use of IEntityInformationExtractor<TEntity> is an interesting one.