This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Can Indigo be my bus?
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
You'd think that with Indigo/WCF/WinCom out now, people like me who develop distributed systems would be overjoyed. Finally, a single technology stack to deal with, right?
Well, maybe if the API wasn't so cumbersome.
I know that Indigo tries to be almost everything to all people through its pervasive extensibility model, but I'd really like to have my (rather simple) needs handled well, without having to special case a lot of the low-level mechanisms.
The thing is, I've already found a much better API. The reason its turned out so simple is the result of accepting a certain way of working - the SOA way. Once you give up the desire to tightly couple, the fog clears. You start to see the following simple elements combining in well defined ways...
The only data that goes between services are messages. In other words, any class that implements the IMessage marker interface. If you want XML or SOAP serialization, that class should probably be serializable.
The thing you use to send message implements the IBus interface. IBus exposes the following methods:
There is one more interface to mention, and that is IMessageHandler where T : IMessage. It has a single method - void Handle(T message);
Before we get too mired down in the details, you'll probably notice that the "Send" methods don't take a destination parameter. That's because there's no way in hell that application code can/should know where a message should go. Here's the reasoning:
A message schema, a group of classes that implement IMessage, aren't just available. An autonomous service "published" that schema, in essence saying "this is how you speak to me". The corrollary of that statement is that an instance of one of those classes should always be sent to an endpoint of that autonomous service. The implementation of the bus, probably with a config file, will know which endpoints are for which message type.
Another thing you'll probably notice is that there's no "Receive" method. What happens is this:
Since the bus implementation will deal with the underlying technology, it will know when a message has arrived. It now needs to inform the application of this. While it could expose a MessageReceived event, what we'd really like it to do is to dispatch that message to the appropriate message handler. The bus could easily reflect on the generic type parameter of the message handler in order to build a map from message types to message handler types.
When we start to think about message handlers, they really are one shot deals. There's no reason to keep them in memory when they're not handling messages. So, the bus would do per-message instantiation. Since the communication is based on asynchronous messages, there really is no meaning to the term "session". Even more importantly, with multiple threads handling multiple messages, we definitely don't want to weigh down on MessageHandler developers by demanding them to write thread-safe code.
And about the messages - there really isn't any need to decorate their fields with attributes or anything, is there? All the data is passed, always.
The "Reply" method is there so that a message handler, as a part of its logic, can send a message back to the client that sent it the request. Alternatively, it could just "Send" one of its own messages (like CustomersUpdatedMessage) to all clients subscribed.
How would we know that a client subscribed? Simple - it has a message handler for a message defined as belonging to someone else (the autonomous service). The client bus could then send its own specific subscription messages to the bus running on the service, which would then save that subscription.
I could go on, but I think that you can see that Indigo wasn't designed to make this kind of scenario easy. Of course it's possible to implement this on top of, and inside of Indigo, but, to put it mildly, its a bitch. The hard part is getting rid of the need to use all those ugly attributes.
The real thing that gets under my skin is having to explain to technical business types why we aren't using Indigo either as an API or implementation. It's just too much complexity! Look at all the examples out there on the blogosphere, did you see how much techno-crap you have to write to get something working. And the resulting application level code is mired in technologically specific details. Yuck. I barely have enough time to develop the system itself without wasting any on debugging infrastructure code just to find out I forgot yet another attribute (YAA). How's that for a replacement for WCF?
Just to fill in the description of the API, the LoadTypesFromAssembly method scans a given assembly and loads and maps all the types that implement IMessage and IMessageHandler. The Start method tells the bus to start listening for messages - in essence spawning the appropriate number of worker threads. For client side buses, you probably only need a single worker thread. Service buses will probably have more.
The Send method that accepts the callback and cookie is used so that when the bus receives a response message (possibly identified by a correlationId field, but that's an implementation detail), it would activate the callback passed before. The cookie is there so that the initiator can differentiate between different messages that it sent. For instance, if we had two CustomerDetailsForms open, and from each we initiated an update, when we get two responses back, we need to know which response goes with which form. If we were to pass the form object in as a cookie, which we'd get back in the callback, that would be just dandy. The errorCode passed in the reply would also be passed to the callback.
This asynchronous request/response pattern, combined with pub/sub - event-based communication is at the heart of loosely coupled systems. The API I described does a fine job of enabling it in a technology neutral fashion. Indigo does a much poorer job, in my opinion.
So, I'm afraid that I'll have to keep using my MSMQ implementation - it seems that Indigo never really wanted to be a bus anyway. Although it does a fine job of uniting the technology stacks that were previously out there, WCF/YAA appears to have a long way to go.