Jonathan Oliver

In SOA, events facilitate loose coupling. One of the primary tenets of SOA is that services define schema and contract not class or type. For this reason it is good to keep the event definitions separate from your code. In fact, Udi recommend keeping this separation to the utmost—by having totally separate source control repositories for the event definitions and another for the service implementation. One issue that we've experienced in strongly typed, compile-time friendly . »

There are a number of large benefits to referencing the jQuery libraries hosted on the Google and Microsoft CDNs. But there are a few drawbacks as well. The primary drawback being: what happens if Google is down. The event is unlikely, but not without precedence. I have seen a number of posts out there that try to address the issue of CDN failover—where, if Google is down, the Microsoft version is loaded, but there are a few small problems: »

Almost a year ago I wrote a post called Why I Love CQRS. Little did I realize how far that post would go. It ranks # 1 in Google for the term CQRS and # 2 in Bing. Since that same time I have been wanting to post my thoughts on NServiceBus…and here they are: From the Mind of Udi Dahan For anyone that has had the privilege of listening to Udi Dahan it becomes immediately apparent that he knows what he's talking about. »

Almost two months ago I went to Montreal to visit Greg Young and get some clarification on a few lesser-known points of his DDDD (CQRS+DDD+Event Sourcing) style of programming and preachment. He's really great to talk to but it can sometimes be like sipping from the fire hose. This is a good thing. One key point that Greg kept hammering on was his dislike of frameworks. Not all frameworks, per se, but just our general inclination as . »

A few weeks ago I blogged about implementing optimistic concurrency control using the Dynamo clone storage engines. I need to give an update to this technique that is specific to Riak. Riak supports an "if-match" header that allows you to implement OCC out of the box. The only quirk with this technique—per my understanding—is that it is single-node based. In other words, if I have two concurrent writers that are updating a particular value and they are operating against two different nodes, the " »

This week I went to Montreal where I was able to participate in a three-day workshop. There were about nine people there including Greg. The workshop was great. I really enjoyed listening to Greg go into significant depth regarding both the technological and business perspectives behind CQRS. I had never fully considered the business advantages of the architecture, but they are very compelling. Here are a few pictures from the workshop. »

My last blog post generated a fair amount of activity in the twittersphere. In many ways I was expecting that because it's fairly controversial. To think that someone would take a nice scalable storage solution and put it back under the thumb of an RDBMS is nuts. But that's exactly what my previous post talks about. If it's so crazy, why blog about it? I agree, it's pretty crazy to want to put a Dynamo instance under the thumb of an RDBMS. »

There are a number of great NoSQL implementation each with their own set of unique advantages and quirks including maturity of the project, size of the community, and technical merit. While not discounting the unique ways in which each NoSQL project fills a specific set of requirements, I consider one group of NoSQL projects to be a cut above the rest—the Dynamo clones. While HBase, BigTable, CouchDB, and MongoDB are wonderful and have various levels of acceptance along with installed user base, the Dynamo clones seem to have something else. »

One of the main concerns that may be expressed in reviewing my previous blog post about idempotent messaging patterns is that of disk usage. The concern is about retaining every. single. message we ever publish. That's a lot of messages. That's a lot disk space. Before we dig into one plausible solution, let's first look at a few mitigating factors. First, disk space is cheap. Really cheap. We're moving into the sub-$100 for 2 TBs of disk space. »

One of the guarantees behind messaging is guaranteed delivery. Most of us don't give any additional thought to the subject. Until we get into production. While messages may be guaranteed deliverable, have we ever considered that a message may be delivered more than once? When I first started seriously looking at and investigating messaging solutions a number of years ago one of the things that baffled me was how to ensure exactly-once delivery of messages. »