Rhino Service Bus
Building Distributed Apps with NHibernate and Rhino Service Bus
The first part of a two parts article about NHibernate and Rhino Service bus in now on MSDN.
Handling production errors in a messaging environment
So, today I got the first L2S Prof order. As you can imagine, I was pretty excited about that. However, it turned out that I had actually missed something when I built the backend for handling L2S Prof ordering. The details about what actually went wrong aren’t important (and are embarrassing). But I logged into the server and checked out what was going on: One of the major design criteria that I had with Rhino Service Bus is that it should be dead easy to handle production. As you can see in the screen shots,...
Using a service bus for queries
Yep, another forum question. Unfortunately, in this case all I have is the title. Even more unfortunately, I already used the stripper metaphor before. There are some questions that I am really not sure how to answer, because there are several underlying premises that are flat out wrong in the mere asking of the question. “Can you design a square wheel carriage?” is a good example of that, and using a service bus for queries is another. The short answer is that you don’t do that. The longer answer is that you still don’t do...
On PSake
James Kovacks introduced psake ( a power shell based build system )over a year ago, and at the time, I gave it a glance and decided that it was interesting, but not worth further investigation. This weekend, as I was restructuring my Rhino Tools project, I realized that I need to touch the build system as well. The Rhino Tools build system has been through several projects, and was originally ported from Hibernate. It is NAnt based, complex, and can do just about everything that you want expect be easily understandable. It became clear to me very quickly...
The complexity of unity
This post is about the Rhino Tools project. It has been running for a long time now, over 5 years, and amassed quite a few projects in it. I really like the codebase in the projects in Rhino Tools, but secondary aspects has been creeping in that made managing the project harder. In particular, putting all the projects in a single repository made it easy, far too easy. Projects had an easy time taking dependencies that they shouldn’t, and the entire build process was… complex, to say the least. I have been somewhat unhappily tolerant of this so...
Rhino Service Bus: DHT Saga Sate Persisters Options
Rhino Service Bus comes with two default implementations of saga persistence (OptimisticDistributedHashTableSagaSatePersister & DistributedHashTableSagaSatePersister). Both of them rely on the Rhino DHT to actually handle the persistence, but they have quite a different behavior when you start looking at them. The persistence mechanism is the same, but the difference between them is how they handle concurrency. OptimisticDistributedHashTableSagaSatePersister is very simple to reason about, it uses optimistic concurrency. If you have a concurrency conflict, it will throw and force re-evaluation of the message. You need to opt in to the OptimisticDistributedHashTableSagaSatePersister by extending the marker interface SupportsOptimisticConcurrency. DistributedHashTableSagaSatePersister is...
Rhino Queues, Take 6
As I stated before, I started writing a queuing system a few days ago, loosely based on my previous efforts in this area, but aimed to create a production ready queuing infrastructure that I can use in my own applications. The decision to build this was not made lightly, but I wanted a queuing system that met my needs, and was flexible enough to extend at needs. The design goals stated for Rhino Queues were: XCopy deployable Zero configuration Durable Supports System.Transactions...
Understanding Code: Static vs Dynamic Dependencies
Patrick Smacchia (NDepend) has a good post about this topic. I have an issue with his assertion that "Static Structure is the Key": The idea I would like to defend now is that when it comes to understand and maintain a program, one need to focus mostly on the static dependencies, the ones found in the source code. Knowing dynamic dependencies (who calls who at runtime) can make sense for example to profile performance or to fix some particular bugs. But most of the time invested to understand a program is generally spent in browsing static dependencies. The problem...
More disposal subtleties and framework bugs that stalks me
This one was a real pain to figure out. Can you imagine what would be the result of this code? 1: var queue = new MessageQueue(queuePath);
2: queue.Dispose();
3: var peekAsyncResult = queue.BeginPeek();
4: peekAsyncResult.AsyncWaitHandle.WaitOne();
If you guessed that we would get ObjectDisposedException, you are sadly mistaken. If you guessed that this...
Rhino Service Bus: Concurrency Violations are Business Logic
Concurrency is a tough topic, fraught with problems, pitfalls and nasty issues. This is especially the case when you try to build distributed, inherently parallel systems. I am dealing with the topic quite a lot recently and I have create several solutions (none of them are originally mine, mind you). There aren’t that many good solutions our there, most of them boil down to: “suck it up and deal with the complexity.” In this case, I want to try to deal with the complexity in a consistent fashion ( no one off solutions ) and in a way that...
Rhino Service Bus: Concurrency in a distributed world
I have talked about Rhino DHT at length, and the versioning story that exists there. What I haven’t talked about is why I built it. Or, to be rather more exact, the actual use case that I had in mind. Jason Diamond had pointed out a problem with the way sagas work with Rhino Service Bus. Are BaristaSaga objects instantiated per message? If so, can two different instances be consuming different messages concurrently? The reason I ask is because it looks like handling the PrepareDrink message could take some time. Is...
Rhino Service Bus: Saga and State
In a messaging system, a saga orchestrate a set of messages. The main benefit of using a saga is that it allows us to manage the interaction in a stateful manner (easy to think and reason about) while actually working in a distributed and asynchronous environment. In Rhino Service Bus, I built the notion of sagas from the beginning. And I initially went with the approach that mix the saga’s behavior and the saga state in the same class. That did not turn out so well. While it works for simple matters, anything of sufficient complexity started to bring...
Rhino Service Bus: Field Level Security
One of the requirements that came up on my current project was the need to secure specific fields in a message during transit. I thought about it a while before I decided that this is something that should be made explicit in the message contract. Here is an example from the tests: 1: public class ClassWithSecretField
2: {
3: ...
System.Security.SecureString annoyances
SecureString has exactly one purpose. Take information from the user and pass it to unmanaged function. anything else that you would try to do with it seems to be incredibly hard to do. I wanted to extend Rhino Service Bus so a message that contained SecureString members would be automatically encrypted on the wire. It seemed like a nice & easy option to provide field level security for messages. However, it doesn’t seem to be a viable option, because working with SecureString is such an awkward task. I have created a WireEncryptedString class and I’ll just use that instead....
Rhino Service Bus: Understanding a Distributed System
One of the major hurdles in distributes systems is trying to understand how they work. Different parts are running at different places and sometimes at different times. Standard debugging usually breaks down at this point, because no one has even invented a non sequential debugger that would make sense to humans. We are left with trying to understand what is going on in the system based on a pretty old notion, the system logs. With Rhino Service Bus, this was one of the things that I really cared about, so I made this into a first class concept. And...
Rhino Service Bus: The Starbucks example
Yesterday I finally completed the Starbucks sample for Rhino Service Bus. It is surprising to see how many aspects that little sample required. There are several of highlights in the sample. There are three actors in the application: Barista Cashier Customer There is zero setup necessary, Rhino Service Bus will create the queues if they don’t already exists. Again, the idea of reducing moving parts. All three...
Rhino Service Bus: Locality and Independence
One of the main design goals for Rhino Service Bus was locality and independence of the end point. What do I mean by that? Well, a Rhino ESB endpoint should have no dependency on any external service in order to operate. Examples of common external services are things like subscription services, timeout managers and error reporting. I already discussed how I handle errors, timeouts and subscriptions with Rhino Service Bus. So the question is why independence is such an important concept. The answer is quite simple: reduce the number of moving parts. If I need to have a...
Rhino Service Bus: Managing Timeouts
I was first introduced to the notion of time as an explicit concept in Udi’s writing. The notion of being able to send a message in the future was, like most of the things that Udi talks about, simple in terms of implementation, but profound in conceptual terms. Rhino Service Bus supports this explicitly by specifying a time in which a message will be received. The implementation for that is quite interesting, I think. Again, we are making use of a subqueue to minimize the additional requirements that RSB has. So when we send a message to the...
Errors are part of your experience
The NH Prof website is running on Rhino Service Bus. I decided that this is a great time to test Rhino Service Bus for real, and I built the website on top of it. Even the order processing is done on top of RSB. But that isn't what I wanted to talk about today. I wanted to talk about errors, and how important they are. In this case, I screwed up when I build the error reporting capability for NH Prof, which means that if you tried to report an error back, you would get a nasty 404 and I...
Subscriptions: Mass Transit vs. NServiceBus vs. Rhino ServiceBus
For a pub / sub system, managing subscriptions could be classified as important. All three service buses has some notion, subscriptions are important. I find it interesting to trace the way that each of them is handling this scenario differently. NServiceBus deal with this as a pluggable strategy. NServiceBus tend to do things that way :-) The two options that come out of the box with it are database backed subscription storage or a queue backed subscription storage. Just to make things interesting, for queue backed subscription storage, you now have several deployment options at your hand (private subscription storage...
Dropping Data Structures into the Pit of Success
As part of the work that I am doing for Rhino ServiceBus, I am also creating a few data structures. No, I haven't gone mad and decided that it is a good idea to write my own linked list, but I have discovered that there are several patterns that I am using that require some potentially tricky coding, so I decided to gather them into a single place so I wouldn't have to do this again. It is important to note that those are not actually data structures that I am using inside Rhino ServiceBus, rather, those are...
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...