Eventual consistency. Given enough time, the system will become consistent.
When no updates occur for a 'long' period of time eventually all updates will propagate through the system and all of the replicas will be consistent.
Where I work the app that was driving me nuts at work was our General Ledger. It would take up to three days to become consistent. It wasn't until I started to explore the topic of EC that I started to build a mental model that could handle the GL being inconsistent.
It can be very helpful to talk to your users about consistency, and what does it mean when they say they need it now. Is half a second acceptable? This is where the 'long' from before can be a bit funny. To a computer half a second is a long time 500 milliseconds (a 2 gigahertz processor cycles about 2,000,000,000 instructions a second, 0.5 seconds is 1,000,000,000 instructions [the math may not be exactly right, but the I think the point is still made])
Another interesting question for me is "What if I can give you consistency today but for yesterdays data?" At work, we have a lot of processes that aren't quite ready for messaging, so some of our processes will be upgraded and others will be quite legacy. So its interesting to see how these two styles come together. Users also have a hard time seeing the shift that can be made by embracing more of this Event Driven style.
-d
Message Handlers
So having been working on a small app using Mass Transit 0.2 I am trying to come to grips with how I want message handlers to be named and used. Do I call them consumers, do I call them handlers? What about some of the things Grey Young has been saying about message handlers being actual objects? I want to think about these things like MonoRail Controllers but I am not sure that is the best way to think of them. They stay around for one message and process that message then go away, which seems like a controller. However, if we are sending to domain objects, then they are going to have state which I think is bad.
hmmmm.. thoughts?
Well today Chris and I decided that MT had reached another milestone of functionality. After having several people review our efforts we have tried to take a lot of the feedback into the system and really polish it up.
This release shows a lot of improvement towards embracing the IoC container quite a bit more. I think that it still has some rough edges around it, but it is an excellent start that should help us to now see where we can further embrace it.
We cleaned up the subscriptions quite a bit, and squashed some bugs that were causing some chatty exchanges. We are also working on a single click install of the subscription manager.
As has been noted previously we are also working on a dashboard that will let you see 'into' the system a bit more, and will be the focus of my work along with automating some more intensive tests. Going to explore just what TeamCity can really do.
Some of the new tests that we are running, and I am looking forward to automating include a load test, load request/reply test, and a load batch test. These three tests have been awesome for ironing out bugs at higher stress levels. I am looking forward to running these on a more automated basis as well as finding new types of tests to create.
The 'host' project has been rewritten to fit a style more comfortable to us as a developer. You basically write a then console program in your project and add a few lines of code to it and off it goes. Much easier to debug into than the old style.
Another new feature and a flavor that Chris will be working on going forward is a Distributed Subscription Cache using memcached that should be a very interesting part of the project to see how it grows and influences the rest of the project.
Batching was rewritten and is now quite a bit smoother, I upgraded the systems at work to include this new API and it reads quite a bit better now.
Not a lot of progress on the build support, which should make working with msmq in your deploy scripts a bit easier to work with.
XML serialization was dropped as it just didn't seem to work as well as we would like. If anyone has a better XML serializer I am all ears. :) The JSON serializer is still in there, but at this point is likely to see little use. The binary serializer is quite nice.
And lastly the project structure has been cleaned up quite a bit, and I look forward to cleaning up and automating even more of the Mass Transit experience. So, pull it down and let us know what you think!
-d
Just wanted to drop a note to say that Chris is on fire! He has written a whole chunk of awesomeness today that should make handling some of our concerns quite easy. We have a new dispatcher sub-system which is quite awesome and will provide a one stop shop for bullet proofing the code to handle errors in a totally awesome way. :)
We are working on the Health Monitoring pieces as well so that you can respond to downed endpoints. How cool would it be that when an endpoint goes down, if you could some how do a NET STOP and NET START as a way to automatically heal (?) a down service.
We are also looking at how we can better integrate an IoC container into the system as well, which should make some of the things we are doing quite a bit easier. :)
So, if you get some time, you should check out the mainline and let us know what you think.
-d
I am curious to know what everyone is researching into. Below is a list of items that I am actively discussing, reading, or trying to use.
- Immutable Objects: Trying to write an application where the domain objects are immutable
- Object Oriented Databases: Trying to write a small sample app with db4o
- Non-Relational Databases: Discussing where these might be a good fit
- memcached: Discussing where this tool might be a good fit
- TypeMock: How does this tool work, and when would I use it over Rhino.Mocks
- Lean Software Development: Reading two books
- Erlang: Reading Programming Erlang
- Messaging
Just wanted to let you know that Chris laid down some phat beats on Mass Transit this weekend.
- Cleaned up the unit tests
- Tweaked the load tests
- Improved the threading code
- Cleaned up MT internals around message sending
- Updated the Samples
- Added a MonoRail Sample
- Cleaned up subscription code
That's some pretty sweet stuff. For more information check out his blog post
Just started working with db4o this week, and I must say that in the very small way that I am using it, its a pretty slick little database. XCopy deployable, no install required. Its just a file, and it can support client, server supposedly, but I am not sure how much I really care about that.
This kind of database is really nice for prototyping because all I have to do is throw the objects in there and they are persisted, bam! You query out using .net Predicate<T> or you can query by example, but I am really enjoying the predicate stuff.
Also, as I move to 'one db per application', this kind of database is becoming more and more attractive to me, because its so lightweight. I still don't know what its like to have one of these in production with an issue in it. So if you know, toss a comment my way.
-d
Currently playing in iTunes:
Prayer of the Refugee by Rise Against
So chris and I have been working on a lightweight service bus similar to NSB called Mass Transit. When Chris and I originally encountered NSB it had a style that didn't really fit the way that I was approaching development at the time and so I decided that, if for nothing else, I would start trying to build one myself to learn more about the concept of an ESB. The concept seemed simple at the outset, but I knew that if I was going to get this right I would have to borrow heavily from experts such as Udi Dahan, Greg Young and the many books I have now read.
It has been a very interesting road, and I am now happy to say that Mass Transit (MT) has reached a 0.1 release. It can send messages to and from endpoints, it has publish/subscribe capabilities, and it has a console/windows service host. Its not much at the moment, but that is a part of its goal (To be simple). One of the goals is that MT should be a very lightweight infrastructure, that is easy to get started with but works as reliable as a lightswitch.
In the near future you will be seeing some API changes between 0.1 and 0.2 as Chris and I continue to make the system easy to use and extend (and play with different names of things). We will also continue to focus on enabling xcopy deployment scenarios, on the testability story, and making it as non-intrusive as possible.
Also, there are some samples of using Mass Transit as well in the SVN repo under, samples
If you have any time, your review of the code or patches will be greatly appreciated. I have taken much from the OSS community and this is one of the ways I hope to contribute back.
Thanks,
-d
Many of us have now become comfortable with how to best build a layered system with the typical UI, biz, and data layers. But as I started to write my first application that took messaging as a pretty central concept I found that I didn't really know how I wanted to parcel out my system. So here is a closer look at what I have been playing around with in this area.
Project Setup
- Solution Name
- Domain
- Domain.Tests
- Domain.Messages
- Persistance
- Domain.Persistance
- Domain.Persistance.Tests
Ok some notes: This is still very proto but I wanted to get it out there. I have taken to putting the repository (ala DDD) interfaces in the domain itself, and then implementing them in Domain.Persistance with tests that test its ability to work. On the project that I am trying all of this out on I am also trying db4o so this has been a great way to keep the db4o junk out of my domain (imagine that, heh).
Its also important to note that I am currently struggling with how I want to implement the message consumption. I currently see that there are two main ways that you can write your message handlers. One of these is as a service layer above the domain layer and manipulate it. This would map easily to web pages and I am fairly comfortable with this pattern, but I am not to sure how much I am really digging it. There is another flavor which says that your objects should consume the messages directly, however I want more infrastructural support for this specific format than I can currently find. Most of the OSS projects seem to support the first method quite easily, and the second seems a bit more of a hack to make happen. I hope to fix that.
Let me know what you are thinking.
-d
Well lets see. I think on of the big things it does is encourage a lot of interfaces in my code. I think it encourages the use of an IoC Container. I think a lot about my code and refactor little things often to get the names right. It has me looking into message based systems as a way to build more loosely coupled systems. It has me looking at various parts of my application and wonder "is this really a service that could be off on its own and then I can just be a customer of?"
I tend to move out of analysis paralysis because I know that I can always change my mind. There are times where I hit a spot and I am like damn, that refactoring is going to take all day, but afterwards the code is almost always in a better position for the long run, and if it is painfully it usually means I was doing something wrong from an SoC standpoint anyways.
It has me favor infrastructure that doesn't infect my domain, that way I can swap out infrastructure later, which is a huge benefit.
Hows that sound?
After Alt.Net had wrapped up for the day on Sunday there were a few stragglers left in the hotel lobby talking about all manner of things. After hanging out for a while (which included a spontaneous group effort to get schema support added for SQLite in NHibernate (r3478). We eventually migrated over to the Claim Jumper for dinner.
Where I was pleasantly surprised by Roy announcing that TypeMock would be sponsoring dinner! We proceeded to order dinner, and a pleasant conversation (2 actually) started up. Again, after MVP and Alt.Net many of the participants were pretty wiped out, but I came away with the goal of trying out TypeMock. And with the free license that Roy handed out at Alt.Net it will be quite a bit easier. :)
So Roy, I hope to be able to provide you the feedback you want very soon as I just started a little personal project where I can explore TypeMock in all of its glory.
-d
I want Spec#
For more see these posts:
Roy's Blog
Greg's Blog
Evan Hoff has been digging into the BerkelyDB lately and this stuff is pretty interesting. He sent me some good links that I thought I would share.
Google Case Study:
http://www.oracle.com/customers/snapshots/google-oracle-berkeley-db-casestudy.pdf
Flash Overview:
http://oukc.oracle.com/static05/opn/oracle9i_database/34313/050306_34313/index.htm
I thinking that this could be a good data store for Mass Transit. No install for the client which is a huge win, and its fast as all get out. With the HA stuff, I can even mirror the DBs.
I also want to bring this up, because this is a non-relational database. Until Evan had showed me this I hadn't really thought about why I choose my database engines, which I tend to just treat as dead object storage. By exploring these options I can find better tools for me and my users to employ for the most benefit.
Now if I can just get my head around the Distributed Hashtables Greg and Chris keep telling me about.
-d
Lately Evan Hoff and I have been discussing the concept of '-ilities' which we use to communicate the qualities of the software we develop. As a developer I have always valued certain qualities in the code that I write and in the software I develop but I hadn't really thought about this concretly before. Some sample '-ilities' are scalability, availability, testibility, and so on (basically anything with an 'ilitity' on the end of it). Some of the qualities I have been focusing on lately are reversability (how can I write my code in such a way that I can reverse out a decision easily), decomposability (how can a structure my program so that it can be worked on by multiple teams) and testibility.
By choosing these qualaties I am making an important statement about what I am willing to trade off in favor of these. I can then take this to the customer and ask them how important do they think this is and we can start to have a disscussion about their software in a non-techincal context.
I encourage you to do the same. If you would like to read more about this I would recommend reading the book Software Architecture in Practice, which contains a better and longer discussion on the topic.
It was such an awesome game. I just want to take a second and say thank you to the team for an awesome season.
I am in, or just outside of this photo: Photo of Mass