Subjugating Temporal anomalies to satisfy software’s Prime Directive
Having just read one of Howard Dierking’s latest posts regarding how we reason about time when it comes to software, I am reminded about the benefits that one way messaging and publish / subscribe can bring to the table. It stands to reason that we all want our code to execute faster and our applications to respond to their users in a timely fashion; ‘slow’ is not a word users or developers alike want to hear when discussing or describing their systems. Howard’s post is a discussion that came out of his reading a book by Steven Seow titled “Designing and Engineering Time: The Psychology of Time Perception in Software”. I personally haven’t read the book however my interest in doing so has certainly been raised. I am interested here in turning the architectural spotlight onto the strategies for managing time.
Howard includes the following table in his post (the first two columns), demonstrating how perceptions of time in software / human interaction can be managed effectively. As my mind turned to thinking about publish subscribe and one way messaging I decided to add another column to this table clarify my thinking.
| Performance Dimension | Management Strategy | One Way Messaging Pub / Sub Strategy |
| Actual Performance – the precise time durations for completing a task | Operational Management – purely technical strategy (e.g. change the way it works to make it faster) | Let’s push aside algorithmic tweaking designed to speed up computation for just a moment and consider this aspect from a scaling / throughput perspective. In systems that attempt to address this through stateless web services, the strategy is one of scaling out the web servers. If we bring durable queuing into the focus then we can rather more cheaply apply divide and conquer, with patterns such as ‘competing consumer’. In terms of NServiceBus the Distributor is an excellent choice here. Again this is looking at it from an architectural viewpoint. |
| Perceived Performance – the approximate duration for completing a task as experienced by the user | Perception Management – make the task feel like it takes less time (examples include distractions, progress indicators, etc.) | Sending commands or messages to the server for processing and distract the user by maintaining UI state as though the command had been processed. One example is showing blog comments to the submitting user only, whilst waiting for the moderator to approve it. |
| User Tolerance – based on expectations, the approximate duration threshold where anything beyond will be considered slow by a user | Tolerance Management – focus on making users more tolerant of a longer duration when it cannot be shortened or “disguised” | Initial immediate response followed by a subsequent response via a different channel than that sent the message / request. Examples such as Amazon purchases that provide an immediate response and then provides confirmation email. |
In request / response systems, often the focus goes into that described in row 1 column 2 above; that is we tend to narrow in on speeding up our code, substituting for faster implementation technologies or even scaling up our hardware. In the case of stateless Web Services it’s also common to scale out the web servers. With one way messaging and NServiceBus we can increase our throughput and speed (both real and perceived) by scaling out our services and what’s more this can be achieved relatively cheaply with commodity hardware.
It’s also worth noting that the effects of implementing durable queues play’s into the Reliability aspect of the system and when those queues are placed physically adjacent with task based smart client applications that both send and receive messages, then it’s possible to create the perception that work is submitted immediately; potentially it may be repudiated later if there is something wrong with the submission itself. Maintaining a low number of these repudiated work submissions (command / messages) can increase the tolerance levels and the perceived improvement in speed in getting through the work itself.
Oslo, SOA and BizTalk - Speaking from the inside out now!
I am spending more and more time with my head wrapped around BizTalk in one way or another and very recently I am glad to say that I successfully navigated the MCTS exam and certified as a BizTalk specialist. Does this mean that I expect to do a lot of work in BizTalk from this point on? Good question. Well I do expect to do some yes and I am hoping that I will be able to offer the measured position of being from the camp that does not reach for BizTalk to solve every SOA problem looking for a solution.
There are alternatives
I do appreciate many of the features of BTS 2006 but I must confess that sometimes I do hear some absolutely mad assertions coming from those who would throw BizTalk at every problem where messaging was a clear choice. I have heard 
voices hold forth that ALL business rules should be managed in one central location (in BizTalk) and that all applications and line of business applications should make BizTalk their messaging target endpoint. I remember objecting to this idea firstly on the grounds that it was out of alignment with the budget constraints of a given project and secondly that it was clearly propagating fallacy number eleven of the fallacies of distributed computing. Now in this particular case my argument was pretty solid but I should also point out that it’s not always that cut and dry. BizTalk may well be the right architectural and financial choice in many cases where we know that scaling out on mass wont be a future consideration coupled with a short delivery window imperative or perhaps a business lacking in the capability to maintain a considerable software team required to maintain a complex custom SOA application. This does not exhaust the list no doubt but gives an idea.
SOA without the bells and whistles
I may want to build my own very light weight SOA framework or use NServiceBus, either option affording me the option to deploy multiple versions of the same service at different geographical points across my LAN. In this scenario my rules should stay with my service, I don’t fancy the idea of wearing the expense of BTS for every long running (or otherwise) service I write and I have all those nicely designed domain entities that have come out of my having been Domain Driven all along the way! Heck I may even be using WCF and WF in the most out of the box fashion and even then it makes very little sense to put all my business rules in one place just because I can. Centralizing things in my architecture expose me to a single point of failure, which we know isn’t a great idea. Some will argue that it’s easier to maintain in one place and if our environment is lacking in complexity then there are times where that does hold true, but over time as developers and architects begin to pile things into one place things might start to unravel. Imagine a BizTalk environment that begins to exhibit as a massive repository for your organisations business rules! Hmm, if I change this one rule here what happens to all the logic that uses my other 1300 rules and which one of them have dependencies on the rule I just changed? I should clarify here: I am not ready to throw out the baby with the bath water just yet however, I wouldn’t even begin to consider for a moment the notion that I should build tools for mapping or adapters for some of the LOB applications out there, these very mature aspects of BizTalk can exist very nicely behind my services rather at the front of my design.
Figure 1.0
Oslo is certainly suggesting architectural decisions like that exemplified above, where the BizTalk hosting environment continue to be used for integration services and the ‘Dublin’ Server be used for application services. This distinction has me curious; will Oslo’s process server be similar to BizTalk with respect to being a Broker? In the meantime as I become more adept at using the product, I feel more at peace with making up my mind about why, when and where BizTalk makes sense.
Udi Dahan SOA and DDD training not to be missed!
It has just recently come to my attention that Udi will soon be running his advanced distributed systems design course in Austin Texas with Jeffrey Palermo’s crew at Headspring. I was fortunate enough to take this very course earlier this year in Australia and I can truly say that my thinking, planning, designing and output have all been enhanced in the most profound ways since doing so, it was one of those great eye opening experiences that can move you to another plane of thinking.
Judging from the course outline on Udi’s site, it would appear that some new material has found it’s way onto the syllabus (I’m jealous), which covers Ultra High scaling possibilities by leveraging REST and after hearing Udi’s podcast on that topic I think I have a feel for what that promises and can only say that I wish I could make the trip to the US to be there.
Whilst I gained enormously from the SOA and DDD content, I also took away some wonderful stuff from the ‘Smart Client’ sections of the training. My team have been using our own home grown MVP framework for some time now and Udi certainly expanded our thinking there, particularly with regard to multi threading issues - greatly useful stuff.
When I had the privilege of sitting through this training I did so with my team and cant say enough about how it invigorated, improved and turbo charged the mind-set and output of all who attended. Udi is a very skilful presenter and a wonderful teacher and significantly has amassed some great wisdom that anyone who is serious about building Service Oriented systems should go out of their way to experience and imbibe. If your in Austin Texas or anywhere in the United States for that matter, I thoroughly recommend you take this course, it is worth far more than the advertised price. Prepare to have some of your beliefs challenged and come with a spirit of learning and you will enjoy the rewards - I know I have and so have many of my colleagues. I know that I personally often find enormous value in listening and learning from people of the quality of Udi and Randy, so imagine spending a week in the company of one such teacher!!!
