Dru Sellers

Business Primitives (2/2)

drusellers — Thu, 04 Feb 2010 11:18:50 GMT

Ok, so now that we have talked about the Business Primitive concept lets go through some of the actual examples. Let's take an example of a 'Loan' class.

public class Loan
{
    public int Id { get; set; }
    public int InterestRate { get; set; }
    public DateTime TradedOn { get; set; }
    public DateTime SettledOn { get; set; }
    public decimal Principal { get; set; } 
}

After some small tweaks.

public class Loan
{
    public int Id { get; set; }
    public Rate Interest { get; set; }
    public DateTime TradedOn { get; set; }
    public DateTime SettledOn { get; set; }
    public Money Principal { get; set; }
}

Already the code feels more robust to me. The dates aren't that interesting to the business other than they are dates so they haven't yet been uplifted into 'business primitives' but Interest has been converted to 'Rate', which immediately helps with math and providing meaningful math like methods, as well as Principal which is now 'Money' which also helps with math and the more pernicious rounding issues.

So how was 'Rate' implemented? What does it look like?

[DebuggerDisplay("{_rate}%")]
public class Rate
{
    int _rate;
    private Rate() { }
    
    //factory methods
    public static Rate FromWholePercent(int rate) { new Rate(){_rate = rate};}

    //equality overrides here
    //operator overrides here
}

First, we have the 'DebuggerDisplay' attribute which is my new best friend, it allows you to customize how the debugger displays your object in the debug view, very helpful. I have wrapped the previous rate value in a very simple fashion, and now we have a nicely centralized place to put math based functions (myRate = baseRate+riskRate). I have also added a factory method that help explain how this Rate object is being made. From whole percents such as 78% or 22%. Because we have hidden the way we actually store the value, we could also add support for 22.2% by adding a new factory method and changing the internal storage with out changing any other part of the code base. Very cool.

Ok, so what about saving these value objects and now I need to bind them to the UI how do I get at that hidden variable? I have taken quite a few paths when trying to implement this and the way that I do things now is a combination interface + base class. If you are anything like me you are thinking 'base class, yuck' and well I still do but this is the best way that I have come up with and I am open for suggestions. :)

So my 'business primitives' inherit from an abstract class called 'Primitive<T>' this class helps to streamline the creation of my business primitives. It also EXPLICITLY implements an interface called ValueObject<T> that exposes the underlying value, that can be used by UI controls and persistance frameworks with out mucking up my public API. I love that I don't see 'SetValue' and 'GetValue' unless I want to (yes, this could have been a property, not sure why I choose this). Here is the interface:

public interface ValueObject<T>
{
    void SetValue(T input);
    T GetValue();
}

and the base class

[DebuggerDisploy("{_primitiveValue}")]
public class Primitive<T> :
    ValueObject<T>
{
    T _primitiveValue;

    public Primitive()
    {
    }

    public Primitive(V primitiveValue)
    {
        _primitiveValue = primitiveValue;
    }

    void ValueObject<T>.SetValue(T input)
    {
       _primitiveValue = input;
    }

    T ValueObject.GetValue()
    {
        return _primitiveValue;
    }
        
    //equality stuff
}

I really wanted to do some tricky generics to try and implement the operator overloads in the base class as well, but the compiler wasn't to happy about that so those still have to be implemented in the 'Rate' class. Now my 'Rate' object looks like this:

public class Rate :
    Primitive<int>
{
    private Rate() { }
    private Rate(int value) : base(value){}

    //factory methods
    public static Rate FromWholePercent(int rate) { new Rate(rate);}

    //operator overloads should be implemented here

    public bool Equals(Rate other)
    {
        if (ReferenceEquals(null, other)) return false;
        if (ReferenceEquals(this, other)) return true;
        return base.Equals(other);
    }
}

For saving these buggers? Well, using NHibernate we can persist this as an 'int' using an IUserType, which makes things very simple and still manages to keep NH out of our domain.
Some links on implementing IUserTypes

Otherwise, with the interface you now have the means to get access to the value, so customize for your needs!

Now that we have addressed the saving aspect, what's a good way to present these 'business primitives'? Because

inputLoanPrincipal.Text = loan.Principal.ToUiString();

sucks. I would suggest some extension methods on your UI controls that take Primitive<T> as the type and can then cast to the ValueObject and get access to the value. Or extending the UI binding much in the way FubuMVC has, seems like a really solid way to approach things too.

I hope this helps :)

-d

Business Primitives (1/2)

drusellers — Wed, 27 Jan 2010 12:53:39 GMT

Understanding the business has been stated time and again as being an important part of the development process. In order for me to better support the business one of the 'little' things that I am finding greater and greater love for is the 'business primitive', a very small object, often containing only a single field, that completely encapsulates one small, well defined idea of the business. This is most often a specific type of data, like 'Money'.

This does a couple of things for me right off the bat. One, my methods can now ask for these 'business primitives' rather than a language primitive which means there is more meaning in my methods so that they need less documentation and that I am less likely to pass the wrong string into the wrong position on a multi-parameter method. Two, I tend to stop talking in 'developer-speak' and start talking in the language of the business. "Ahh, so an Instrument is identified by a CUSIP!"

This is also a very easy way to start experiencing the benefits of DDD's 'Ubiquitous Language', as you build up a collection of business primitives your ability to discuss the business problem with the business people in the terms of the business should improve. After all, your business partners don't think in terms of 'strings', 'integers', or 'booleans' rather they think of their business process in terms of 'real world things' like 'Loans', and 'Investments' and most complex things are built up of smaller objects like 'Money', 'InterestRate', and 'CUSIP' your company's concept of primitives.

As the use of business primitives grows, your understanding of the business should start to stabilize, and should gain some sense of consistency with the business. For instance, if you have a 'Money' class then you have a perfect location to deal with money rounding issues.

If you find that this would be hard to start doing, I find that it is easier with primitives that are defined outside of the business itself. For example at the bank there is a concept of a ‘CUSIP.’ This is a industrywide identifier used to identify financial securities. It has a set of rules about how it can be composed. (http://en.wikipedia.org/wiki/CUSIP). You are going to have to conform to these standards anyways you might as well put all the rules in one place.

If you are familiar with DDD then I also want to be clear that 'business primitives' are VALUE TYPES, like a string or an integer, their value is their identity. One instance of CUSIP 'CUSIP 912827XN7' is equal to (==) another instance of CUSIP 'CUSIP 912827XN7', which makes sense, their identity is their value. This is distinctly different than the DDD ENTITIES where they are not equal based on the their values, but by their ID, so 'Loan' with value $100 would not equal another loan that also has a value of $100.

In closing, why is 'primitive envy' (the overuse of programming language primitives in place of real objects) such a pervasive problem? I think that it has a lot to do with UI control binding. When we are building some of our first programs we need to send a string to the screen so we can see 'Hello World', we don't build out a 'Message' object and then send that to the screen through a ViewModel abstraction. But these behaviors that we build early in our careers can be a deep seated habit that is hard to break out of. Its just too easy to think about the UI and that its going to need a string for the name text box, and then code the 'name' as a string in your object. So push back, reclaim so OO love and work with your team to build some real business primitives.

My next post will show how we can implement this process.

Being Business Focused: Risk

drusellers — Thu, 22 Oct 2009 11:08:26 GMT

'Being Business Focused' is going to explore various business concepts and how we can use them to explain the bottom line impact of our decisions.

Don't forget we learned roi = (fv-iv)/iv

Now I want to talk about another fundamental concept at the bank and how it can affect overall ROI. Today's word is 'Risk'. In the world of finance risk has a very real and measurable impact. You can see that impact very easily in the interest rates charged for loans. The riskier the loan the higher the interest rate. There is a financial model that we can use to discuss the different elements of risk and its impact on the cost of financing a project. The specific one I want to talk about is the 'Capital Asset Pricing Model' (CAPM). I like this model because it is simple and demonstrates a few things that I think are interesting about risk.

Ok, so what is CAPM? CAPM states that the expected return (Ri) is equal to the risk free rate (Rf) plus the beta coefficient (Beta) multiplied by the risk premium, where the risk premium is the market risk rate (Rm) minus the risk free rate.

Ri = Rf + Beta*(Rm - Rf)

So what does all that mean? Risk free price/rate is the price for the THING if there is no risk involved. The market price/rate is the price for the THING on the street, this price is usually higher than the risk free rate because it includes a 'premium' to account for the risk involved, ie "You mean I might lose my money, then I want a bigger payout!" The beta coefficient I can only explain as the volatility in the market, if the market is making wild swings then any risk you take will be magnified by it and therefore affects the expected return.

This next section is not entirely accurate and is used only to show how playing with the risk levers can change the ROI. NOTE: You probably won't use the model directly, but understanding the different components of this model has been helpful for me when talking to the business.

When we start to talk about buying and selling money, my brain starts to hurt. I am going to buy money...with money? owwwww... What I have noticed is that the smart guys with the finance knowledge talk about the price of money as the rate that you borrow it at, the money borrowed is called capital, and the CAPM helps us analyze the rate. To show its impact on ROI I am going to substitute it for the initial value since it kinda represents the price we borrow money at.

WARNING: Dru is getting jiggy with the math

roi = (fv - capm)/capm

Now that we have a game plan, lets plug some numbers into CAPM and see what happens. In the financial world government bonds tend to be the benchmark of risk free money, so lets say that gov bonds are going for 0.05, and the same bond offered by your company is going for 0.07 (these are totally made up numbers), and for the beta lets assume a 1 (so that we can ignore it for now, hit me up on email for more info).

0.05 + 1 * (0.07-0.05)
0.05 + 1 * 0.02
0.05 + 0.02
0.7

We can see now that we have a risk premium of 0.02, and that if we can find a way to reduce that risk premium it will have a direct affect on our ROI calculation above. Like the financial world anything we do to try and reduce risk is going to cost us something, so its nice to know that your cost (increase initial value) of the mitigation is less than its return (future value). Let's say that something happens and we can now offer that same bond at 0.06, with negligible impact on initial value.

0.05 + 1 * (0.06-0.05)
0.05 + 1 * 0.01
0.05 + 0.01
0.06

So we see the price lowered. Not a big surprise since we were able to magically lower it, but we did it by targeting the risk premium and we can now see its impacts on ROI. By lowering CAPM in our ROI calculation we have increased ROI (lowering the bottom number and increasing the top number).

Before

roi = (x - 0.07)/0.07

After

roi = (x - 0.06)/0.06

Ok, so what are some examples of developers lowering risk? As developers we do many things to reduce risk in our projects. I know one thing that I like to do is put the risky parts of my code base behind an interface. That way I contain the risk of that section to just that section. In financial terms I am limiting my exposure to the risk. Maybe the risk is that the business hasn't decided something, like which payment gateway to use. When building a system that kind of unknown brings an implementation risk to the project, but we can effectively nullify a large chunk of that by simply coding against an interface that we will implement once the business has decided.

So what is the take away? Lowering risk can lower your effective initial investment, which will then increase your return on investment.

I hope that you find this helpful

-d

Message Granularity

drusellers — Sun, 18 Oct 2009 00:39:00 GMT

So, how big is a message? What all should you include in a message? What if you are in a bigger company, how do you roll messaging out across an enterprise? Honestly, I am still learning here too, but here are some rules of thumb I have picked up along the way:

You want more than one uber message for the whole company
You want a canonical message model (this means that messages aren't tied to any one application)
- This one I am still not 100% sure on, but I am pretty sure its correct
Each message should be a distinct unit or event
It should represent a business transaction as an atomic, self-contained and self describing unit of work (don't pass primary keys around)
Don't worry about the size of the message unless you have to. I don't even think about it anymore. The size (bytes) of the message should be considered as it can affect how fast your message can go across the wire. If this level of speed isn't a concern, then I wouldn't worry about it. ie if you can wait 0.10 of a second or more than I wouldn't sweat it.

Fine grained messages create more overhead from a management perspective so each one needs to earn its place.

Governance
- Build a way to track your messages. Even if its in excel.
- Once a message is deployed, be careful about upgrades. I try to follow Udi's advice that instead of modifying the message I make a new one.
- Make sure that only one system / department owns the message. This will make changes a bit clearer to see who can initiate them.

Links:
http://www.eaipatterns.com/CanonicalDataModel.html
http://fuzzypanic.blogspot.com/2005/04/canonical-message-format-and-xml.html
http://fuzzypanic.blogspot.com/2006/05/eda-lessons-learned-canonical-message.html

Being Business Focused: ROI

drusellers — Fri, 16 Oct 2009 01:01:25 GMT

'Being Business Focused' is going to explore various business concepts and how we can use them to explain the bottom line impact of our decisions.

At work I am usually challenged to show the business value of the various things that I want to do. Improve a system, use some new technology, etc. Though its frustrating (because of course my idea is a good idea ;) ), it has made me think through what the actual return on the investment would be.

The first thing I had to do though was learn how do we calculate the return on my work? For that I had to crack open my dusty undergrad college textbooks (and wikipedia). The rate of return, or return on investment (ROI) can be calculated simply with the following equation. Rate of Return equals the Future Value of an Investment minus the Initial Value of an Investment divided by the Initial Value of the Investment or:

roi = (future_value-initial_value)/intial_value

So some obvious things are now apparent. If we can lower initial value (aka cost) or increase final value (aka benefit) we can increase roi. (The trick is to actually show the numbers). Armed with this knowledge you can start to look at your input to the software development process a bit differently. We can start to ask ourselves questions about where we are contributing our efforts and that is really the key thing that my business is asking me. Of course they would love me to be able to quantify, but at this point I am just happy to say "I think I am lowering initial cost and here's why".

So what would an example be of us choosing to impact ROI?

This example is extremely simple and merely serves as an example it purposefully excludes many other important factors to overall roi

As the developer you could use a for-fee tool, like MSSQL, and raise the initial value of the equation (less roi) or use a free database,like PostgreSQL, and lower the initial value (increased roi). Conversely, you could choose to implement high value features and raise the final value (increased roi) or implement low value features and lower final value (less roi).

So there we have the basic calculation of ROI and some ways we as software developers can choose to effect it. So the next time you have a decision to make you can take a step back and think about its impact on the ROI of your product. Is it going to improve the future value? or lower the initial cost?

Next up, how our ability to lower risk increase ROI even though it can usually mean an increase in initial value.

-d

warmup

drusellers — Sat, 26 Sep 2009 02:29:23 GMT

http://github.com/drusellers/warmup

because I was bored and I am sick and tired of setting up stupid VB.Net projects

I am trying to setup some standards, but standards documents only gather dust so now I have a dirt simple way for people to setup new projects that will follow our standards and will also save a chunk of time since we won't have to clean up all the shiat that VS puts into a VB.Net project.

set the config file to your source location

<add key="source_control" value="[your scm url]" />

Command Line once warmup is on your path

warmup [template name] [name to replace with]

example

warmup web FHLBank.AwesomeWebSite

This will go to your SVN (and soon GIT) repo and do an export/clone of that directory then replace the '__NAME__' with your supplied name

So now you can build a templated solution with projects and third party libs just name the stuff to be replace with '__NAME__'

I still need to work on some GUID updates. I am sure I will run into other little issues, this is about 60 minutes worth of work so don't be too harsh.

-d

Complex vs Complicated

drusellers — Fri, 25 Sep 2009 11:25:00 GMT

Just a quick reminder for myself

It is ok if something is complex so long as it is not complicated.

complex: composed of many interconnected parts; compound; composite

complicated: difficult to analyze or understand

Many problems require complexity to solve. Calculating the discounted value for a 30 year financial instrument using a predicted rate model with a monthly granularity requires a lot of work. You have to generate the rate model, calculate the cash flows from the instrument, then apply the discount to the flows. If this seems simple to you its because you understand the reasons behind each one of these steps.

I don't think any problem requires 'complicatedness' in order to be solved. This is like the reoccuring geek joke, "Well we could call the RateManager and then send the results in a JSON document in an email to the InstumentClass that then faxes the ... and finally a suite of monkeys types the result on your screen". Does your problem need that kind of solution?

Anyways, nothing new, just a note to me.

Further Reading: http://christopherdeweese.com/christopherdeweese.com/blog/post/Complexity-Simplicity-and-Elegance.aspx

Composed Events

drusellers — Sat, 19 Sep 2009 17:44:46 GMT

One of the ideas in an event based architecture that I really like is the idea of composed events. A composed event is an event that is defined in terms of other events. For example, in my previous post I mentioned a 'PossibleBruteForceAttack' event. This event is defined as having occurred when 3 or more failed login attempts occur for the same username. One of the things I like most about this is how it mirrors reality. How many times have you been able to accurately describe a system failure based on correlated events? Its the kind of experience that the long timers can have for specific systems, but instead of it being a 'gut feeling' we make it explicit. By making it explicit we can test it for accuracy over time. So what does this technique do for us? Well beyond being able to define these kinds of complex events it also lets us extend our systems without actually modifying the system, since we can simply compose these events by subscribing to them and then publishing a new event. You could take a system that produces events on the changing price of a financial instrument and then have a new component that watches this stream of events for large swings in price. This could then be announced as new CrazyMarket event. This is also another way you might look to use the blogjecting watchdog pattern to monitor system health by correlating fault messages to the server logs. Anyways, I just think it is cool. :) -d

Complex Event Processing

drusellers — Wed, 09 Sep 2009 12:12:00 GMT

For the last couple of nights I have been trying to implement a very simple Complex Event Processor for MassTransit. I am happy to say that last night I have something that works. Its not fancy, and its barely even alpha (note to self don't use it in production, yet), but it works and I am super stoked. Although I must admit I don't fully understand what is going on in all the LINQ soup, but lets take a look.

from a in PossibleAttack
from b in PossibleAttack
from c in PossibleAttack
select new PossibleBruteForceAttack(a, b, c)

This is saying that if the parser sees three possible attacks in a row, then that means there might be a brute force attack in progress. Possible attack looks like.

from m in MessageStream
where m is FailedLogin
select m

MessageStream here represents, at the moment just a list of objects, the stream of messages coming out of the MassTransit service bus (ideally any bus NSB, Rhino, etc). So here I am just doing a type check to see if the message fits my type pattern.

Once I have this nailed for IEnumerable I can then shift to the Rx framework. Instead of being a list, we can implement IObserver and IObservable stuff from Rx, and we can now react to the real message stream from the bus. :) But before I do all that fun stuff, I need to implement a few more pattern matching helpers and we should be ready to rock.

For those curious, its based on this, and the whole concept of achieving CEP was inspired by Rx and some conversations had with @dahlbyk and @phatboyg while at the St. Louis Day of Dot Net. My thoughts on CEP have been inspired by talking to @udidahan, @phatboyg and @gregyoung and reading 'The Power of Events'.

code is buried in magnum

Thoughts?

-d

Why Messaging #6: Why not ...

drusellers — Tue, 08 Sep 2009 22:51:48 GMT

As I have been writing this series I have been asked a couple of times why I didn't use technology X. I have tried to respond in the comments, but for those of you that may not be following the comments I have tried to summarize my thoughts here.

Why not BizTalk?

Actually I did consider BizTalk and ruled it out for a couple of reasons. 1. I have heard more horror stories than success stories 2. The price tag, I just couldn't make the case for that much money on a concept that was still in the initial testing stages. 3. I am no BizTalk expert, but I was concerned about the testability of such a program. 4. I didn't want to have to install BizTalk onto my dev machines.

Why not Tibco, SonicESB, etc?

See BizTalk

Why not Sql Server Service Broker?

1. Overall longevity of system, its a child product of Sql Server not its own product like BizTalk. 2. Like BizTalk I was worried about the testability of the system. 3. My SQL Servers do enough work as it is, and I would prefer not to put more stuff on them, especially business logic.

Why not NServiceBus?

Probably the best question for me really. At the time it seemed complex (it is a complex problem). Used a lot of verbage I wasn't familiar with (unicast / multicast, I just want a message). Was tied to Spring.Net (not anymore). I wanted a simple NSB for use in my shop (as I said its not a simple problem though), in the beginning MT was very small and easy. Although as Chris and I have been working MT it is getting more complex, to handle the complexity in the problem. I am starting to appreciate the complexity that adding this architecture brings to a project (because it is explicit complexity which is helping to clarify the overall problem) but I also see the tremendous value it brings as well.

Lastly: In the end it was a means for me to learn, I enjoy coding and thinking about problems. It has made asking questions about the problems easier as I can phrase them now in the NSB world and the MT world. Its not a path I recommend for just anyone but it worked for me.

Events are awesome

drusellers — Tue, 08 Sep 2009 02:00:35 GMT

"I find that services are much more composable when they emit events rather then send requests. Since this way the coupling between services is reduced"
Arnon

I really like this statement because, well its what I am working on, but also because it talks about events as a first class thing. I have been enjoying thinking about my current company in this light.

All business action has an external stimulus. Something happens outside the company, and this causes the company to do something. A customer calls or the market shifts, either way something happened and now you need to react. I like to think of these as events, and as such I have decoupled the event itself from the system that wants to respond to it. In the past the event would have been embedded in the system, flipping this around means multiple systems can respond to the 'exact' same business event. Neeeeeaters. :)

This is why integration via events is just so much easier.

I have also started to think about what it would mean to develop a system 'event first', and then you can look at what needs to be done when these events happen. It builds completely different systems, based on some initial drawings.

-d

dropkick - an idea for deployments

drusellers — Fri, 29 May 2009 12:01:46 GMT

Still very rough, but I have the DSL compiling and looking at making file copy work. This is more than anything an exercise in building a framework that uses the same structure as the MassTransit Sagas.

    public class TestDeployment :
        Deployment<TestDeployment>
    {
        public static Part Web { get; set; }
        public static Part Db { get; set; }
        public static Part Service { get; set; }

        //dropkick r:role(web,db,service | full)
        static TestDeployment()
        {
            Define(() =>
                {
                    During(Web, (p) =>
                        {
                            p.OnServer("WebServer")
                                .IisSite("Apps")
                                .VirtualDirectory("dashboard")
                                .Verify()
                                .CreateIfItDoesntExist();

                            p.OnServer("SrvTopeka19")
                                .Msmq()
                                .PrivateQueueNamed("mt_subscriptions")
                                .CreateIfItDoesntExist();

                            p.CopyFrom(@".\code_drop\dashboard\**\*.*").To(@"\\webserver\apps\dashboard\")
                                .And((f) =>
                                    {
                                        f.WebConfig
                                            .ReplaceIdentityTokensWithPrompt()
                                            .EncryptIdentity();
                                    });
                        });

                    During(Db, (p) =>
                        {
                            p.OnServer("sql")
                                .SqlInstance(".")
                                .Database("dashboard")
                                .Verify()
                                .BackupWithLightspeedTo(@"\\sql\\backsups\")
                                .RunTarantinoOn(@".\code_drop\dashboard\sql");
                        });

                    During(Service, (p) =>
                        {
                            p.OnServer("WebServer")
                                .WinService("dashboard service")
                                .Verify()
                                .Do(() =>   //auto-stop
                                    {
                                        p.CopyFrom(@".\code_drop\dashboard").To(@"\\webserver\apps\dashboard-service")
                                            .And((f) =>
                                                {
                                                    f.AppConfig
                                                        .ReplaceIdentityTokensWithPrompt()
                                                        .EncryptIdentity();
                                                });
                                    });        //auto-start
                        });

                });
        }
    }

Why messaging #5 - Bus vs Broker

drusellers — Fri, 29 May 2009 11:53:38 GMT

I have in the past gotten in a tizzy about message brokers and message busses. I pretty much say, busses rule and brokers drool. This stems from the fact that I view them as filling the same role, the intermediary between applications. Because of this view point, I see the broker as being a central point of failure and I see the bus as being a distributed equivalent, that overcomes much of the problems of centralization. I often dismiss the simplicity of centralization in this area from an academic snobbery vibe, which is just not the right way to go about it. So I decided to do something about it.

It was while rereading EIP for this series I realized that the authors actually classified the two patterns into two different categories (they do not fill the same role!). The bus is a channel for message sending and the broker is a message routing mechanism (well crap, I have to abandon my old assumptions). With this realization, what does that mean for my previous assumptions?

So, just how does the EIP define these two patterns?

Message Broker - a means to decouple the destination of a message from the sender and maintain central control over the flow of messages (inside cover of EIP).

Message Bus - enables separate application to work together but in a decoupled fashion such that applications can be easily added or removed without affecting others. (inside cover of EIP).

Well, hmmmm? Could it be that its possible for a software package to be both? It seems like it. Lets review. While working on MassTransit I feel that I have successfully accomplished the message bus pattern, but the broker pattern? Decouple the destination of a message from the sender and maintain central control over the flow. Well we have decoupled the sender from the receiver by following the publish / subscribe model, but the central control of flow? Well no, but do I want that? ... Centralization == single point of failure. hmmmm.... "the message broker pattern only tells us to develop a single entity that performs routing. It does not prescribe how many instances of this entity we deploy in a system at deployment time." (EIP, pg 324) So does mean that the MassTransit SubscriptionService and Client are a broker pattern built for a more distributed system? It certainly seems possible. The Subscription Service lets you control in one point where messages go (the flow). Ok, well slap my biscuits looks like I am a fan of the broker model. That's what I get for basing my snobbery on a one time read. ;)

-d

Why Messaging #4 - So hows it going?

drusellers — Thu, 14 May 2009 14:40:27 GMT

Its been over a year since I went down the messaging path and how has it been? What have a learned? What has sucked? The following are some thoughts on my experiences with deploying MassTransit

Although explaining the benefits of a messaging based system has been easy, trying to apply some of the new paradigms that Udi and Greg Young have been trying to pound into my skull has not been so easy. This includes a slew of things like message idempotence, worrying about message timeout (and elevating its importance in the whole system), what to do when a message doesn't get where its supposed to go, figuring out how to rerun a messaging system, and others has been a bit of a mind warp. And figuring out how to test a messaging system...that took a while too. My team has pushed pretty hard in these areas and although it took a little while I think we are starting to see the seeds of our effort. I guess the take away here is that its just going to take time

I know that I am still in the early stages of use for this pattern / style of development and further more as a developer of the framework I can get a bit excited about using it, but at times I think I am treating the tool a bit like a 'hammer and that everything is a nail' but its hard to know when it makes sense and when it doesn't. My hope is that I continue to experience more and more use, that I can find that line sooner rather than later. Its like, oh that could be a useful event that the accounting system is closed. Then we build it up as an event and broadcast the account totals out to our systems that are interested. Right now we have just one system and my coworkers and I kinda stand back and say "Really?" that could have just been a file transfer. I know though as soon as we get that second system we will be very happy.

Another thing that seems to be happening is that I am writing an awful lot of windows services. One to broadcast the message and one to receive the message. Not really sure if this is good or bad or anything, but it did allow me to sit back and create Topshelf an OSS library for writing windows services (imagine that), and from what I have heard it seems to be working out quite well for people. But its something that is new to me, and I just don't have the experience writing that kind of code. But it seems to be going well, it just adds a lot of stuff that I am not used to watching. Thankfully log4net is quickly becoming a very near and dear friend.

As I imagine writing all of these services, so that I can integrate all of my organization I am also starting to wonder about how in the heck I am going to manage this multitude of services. Documentation will help alot, but I am lazy and don't want to write documentation. So how can I expose information about our systems with out having to keep it in sync with the word docs? This is where I have started to look into the concept of metadata. Basically, i want an MT service to tell me something about itself. Where is it installed, how many messages is it handling per minute, error count, etc. I feel that if I can get this baked into MT and exposed to us in some sort of dashboard, managing this beast will get a lot easier.

Well, I hope this was helpful. I will try to write another one when it seems to make sense.

-d

Why Messaging #3 - What did I read?

drusellers — Sat, 02 May 2009 16:03:00 GMT

I just finished presenting at the Iowa Code Camp and one of the little change ups that I did in this presentation was talk about the various books that I have read. So, if you have decided to pursue messaging as an architectural style to use, here are some reads for your next steps. These sources are also usually going to be the source of information for the following posts. Please leave additional resources you like in the comments. :)

-d

Books

People

Udi Dahan
- His Best Hits
- There is no IDog2
Arnon
- Blog
Ayende
- on Rhino.ServiceBus
- on Rhino.DHT