thinking-out-loud

Concurrency in .NET

Last year around this time I posted about the comming need for multi-threaded applicaiton architecture.  Just recently Caleb sent me an aritcle by Sam Gentile on Parallel Computer in .NET that communicates the need/opportunity better. 

On the ASP.NET side of things, IIS is already multi-threaded so you get a lot of concurrency benefits automatically.  But in high-volume request environments, you may want to free up your threads when doing I/O.  Jeff Prosise has an article on Asynchronous Pages, HTTP Handlers, and Modules that raises awareness of what's possible there.

In WinForms, I've had several people ask me why background threads can't update controls on a form.  Craig Neuwirt of Improving covered this topic at the Dallas C# SIG meeting a few months ago and showed off his Facility in Castle to handle if invoke required logic transparently through inversion of control.  Craig's source code demonstrating the difference in complexity between handling the delegation explicity vs using Castle is available here labeled Containing Complexity, mismarked as May 2006 instead of 2007.

Fun with Post-It Notes

This looks like a fun project. Long live the King!

The Ajax Architecture

In case you haven't heard, AJAX stands for Asynchronous JavaScript and XML and is a nice architectural tool, a browser-to-application interaction pattern if you will, that makes web-based applications more responsive and therefore more feasibly interactive. For more detail, check out Jesse James Garrett's full description of the technique.

I found this crafty Ajax.NET library that adds AJAX support to ASP.Net apps via simple attribution. The package comes with a single DLL that you reference from your WebApp, as well as a complete usage guide. The author, Michael Schwarz, has a blog and is even lobbying to get AJAX support added to Whidbey, which would be very cool, but not likely at this date.

The implications of Ajax are wide reaching. Most obviously, groovy applications like Google Maps can be made.  But many of the standard web controls we're used to could also be made more interactive with the server without requiring traditional page postbacks. And, where one might struggle with whether or not to query a large result set from a web page due to potentially slow information retrieval, Ajax brings the possibility of paging through data and retrieving each chunk via an XML request instead of a postback and page refresh.

More .NET TDD and Reflector

In my recent post on TDD (and other .NET) resources, I mentioned that I would like for Reflector to be a VS.NET add-in. If I had a dollar for every time I posted something like that and then realized that it was already available later the same day, I would have *at* *least* ten dollars! Check out the .NET Reflector Add-ins GDN Workspace. Silly me.

Might want to check back soon, because there appear to be some recently checked in files by JdH related to the type treemap. Treemaps are a very cool visualization technique. I think I have posted this before, but here it is again:

One of my favorite implementations of the treemap visualization technology is sequoiaview. SequoiaView uses "squarified treemaps," which try to keep the rectangles as square as possible. Another interesting one: SmartMoney.com's MarketMap.

Treemaps seem like one of those hammers that turns everything into a nail. One idea I had along those lines was to create a treemap view of a small world network where the tree is organized by the number of relations.

.NET TDD Resources

I was doing a little browsing and ran across several items of interest.

First, let me join the voice of many who love Lutz Roeder's .NET Reflector. This tool absolutely rocks. I wish it were a visual studio add-in replacement for the "Go To Definition" and "Go To Reference" options, because it is sooo much nicer.

There is an add-in (yes, Reflector has an add-in api!) by Jonathan de Halleux called Reflector.Graph. You can see some snapshots of what it can do on his blog. His blog is excellent reading material. Apparently, Microsoft took notice, because they recently hired Jonathan.

Advanced Unit Testing is a collection of tools, practices, and patterns for unit testing, especially focused on .NET. Core to AUT is the MBUnit testing framework by (again) Jonathan de Halleux. Jonathan also has a production grammar framework, some graphing libraries (implemented on top of AT&T Research's GraphViz), unit test generation tools, and more. Very, very good stuff.

Marc Clifton created AUT, and he has a number of articles on Unit Testing over at Code Project. Good stuff as well.

Finally, Roy Osherove has an interesting article that extends some ideas ideas presented in James Newkirk, et al.'s Testing in Microsoft.NET to leverage Enterprise Services in database testing to rollback any changes that are the result of the test.

In my experience, even in organizations that are aware or actively trying to adopt test-driven development or *at* *least* implement decent regression test suites for their applications, there is a constant struggle to develop the tests. In my experience, the amount of test code necessary to test a component well is 2-3 times the amount of code necessary to implement the functionality. it is good to see so much activity in this area in terms of helping people understand best practices and providing tools to automate some of the more redundant bits can help narrow the gap. Of course, tools alone won't necessarily make the job easier. You must properly apply them. But all of the infrastructure certainly lowers the barrier to entry to increasing the quality of code.

I was talking to a one-time cohort about TDD a while back, and he influenced how I think about it. He basically said (paraphrased) that TDD is not so much a testing method or a coding method as it is a *design* method.

I hope you had a nice weekend.

Entity Aggregation Pattern

Ramkumar Kothandaraman published an article on entity aggregation in the MSDN .NET Architecture Center. Definitely a good read.

Clemens Vasters also has an excellent, detailed post on data services (with pictures!!!) that includes an entity aggregation example. I personally take issue with the notion of data services (whether the service contains business logic is an implementation detail that isn't expressed in the service contract, so the notion seems flawed), and I think there is some logical inconsistencies in his message about data ownership compared to an earlier post of his regarding why he wants wsdl to die, in that a service owning its own data requires more than a single operation to fully manage the lifecycle, which suggests that an autonomous service *has* *to* *have* more than one operation. Despite that, as I said before, he really makes me think about service orientation, so I don't consider this a bad thing. He is one of the few people out there that gives enough substance to differ with, it seems.

OORam revisited

Todd recently posted about OORam. It is a sophisticated modeling technique that deals well with separation of concerns. The process was originally documented in a book that is out of print, but you can obtain an online copy of it directly from the author's website. Note to the downloader: It is a large pdf (400+ pages).

Early in the book, the author discusses the distinction between class and role. There is an interesting excerpt from that section:

In an OOram role model, patterns of interacting objects are abstracted into a corresponding pattern of interacting roles.... The corresponding objects will belong to the same class if they have the same properties; they will belong to different classes if they have different properties. The role model abstraction belongs to the realm of modeling. The class abstraction belongs to the realm of implementation.

This is a distillation of the essence and motivation of Craig Larman's Information Expert Pattern. The information expert pattern states something along the lines of "assign the responsibility to the object that has the most information necessary to solve the problem at the point in time." I had the great fortune to work with Craig at ObjectSpace. We used to teach that the expert pattern was the responsibility assignment pattern of choice 90% of the time. This scales up well to architectural concerns, but that is another discussion.

Craig's book on Object Oriented Analysis and Design is a must read for anyone working with objects, which is practically everyone in software today.

What many people may not realize as being significant about the OORam is that the primary author, Trygve M. H. Reenskaug, not only contributed this great-but-often-overlooked process to the world of software, but he also invented the much referenced, much bastardized Model-View-Controller UI architecture in his early work as one of the designers of Smalltalk. MVC is arguably the most used architectural pattern in existence, the current, impressive real-and-hype wave of SOA notwithstanding.

IT, meet Business

Software dorks are all about patterns. I received my copy of Design Patterns: Elements of Resuable Object-Oriented Software in January 1996 when I started working at ObjectSpace [the best job I have ever had, amazing people, had a problem called "business direction of the month", hit the pooper, R.I.P.]. An early history from Kent Beck's perspective provides some insight into the early patterns movement (I Am Behind Yet Another Thought Leader Entry).

For me, especially at that time, the Design Patterns book is worth the entire price just for section 1.6 in the introduction. Back then, I committed the 24 (23? Yeah... 23) patterns to memory, and could recite them chapter and verse. I occasionally still check to see if I can even name them all from memory.

I seldom can. My memory stinks. For instance, I just tried to iterate the Creational Patterns, and I remembered Factory Method, Abstract Factory, and Prototype, but neglected to remember Builder and Singleton, even though one of my favorite refactorings is "Remove Singleton." But I have google, so all is good.

It always surprises me which ones I have forgotten, and they are often ones that I use without thinking today (e.g. the beloved Template Method). And when I go back to the book (or the table of contents on amazon), and realize which ones I forgot, my mind harkons delightfully back to geeky times of applying the pattern in this or that project, or teaching this or that pattern in ObjectSpace's OO analysis and design course, and I would realize that I am a DORK. That would trigger an ADD-like episode in which I remember feeling a sense of solidarity at the end of Revenge of the Nerds, where Louis "comes out" about being a nerd and being damn proud of it.

Or something like that.

Forward to Present: Patterns are spreading like wildfire, and they aren't limited to Christopher Alexander and the architecture or Gamma, Beck and the software monkeys. For instance, I was recently doing some research on Porter's Value Chain, and I ran across Mercer Management's profit patterns recently. The PP are a collection of business strategy patterns that cover value chains, customer, product, knowledge, channel, organization, and "mega" categories of patterns. They also drill down and expand on brand patterns, variants of their "Product to Brand" pattern.

Now.

All of that to say, enterprise architecture was conceived as a means to align what IT does with what Business does and wants to do. Now, as with most grand schemes, many every enterprise architecture efforts failed-and-how. Each time they failed, the next generation explained away why they failed in terms of problems for which said new generation now how solutions. Of course, those had better success, but ultimately, did not achieve the lofty goals laid out by the calling of enterprise architecture, as a recent BPTrends article by David Ritter on enterprise architecture discusses:

To understand how Enterprise Architecture has matured, it is helpful to look at how Enterprise Architecture has been utilized in the past. Enterprise Architecture efforts were almost always driven by the IT organization. Not surprisingly, these Enterprise Architecture efforts focused their attention on developing an inventory of IT assets, and the tools employed to capture these Enterprise Architecture models were system modeling tools that focused heavily on collecting technical system artifacts. This thorough analysis of system and technology components did allow Enterprise Architecture teams to reduce the complexity within their IT organization. Enterprise Architecture projects frequently achieved operational efficiency benefits, such as standardizing technology platforms or eliminating incongruent systems. However, the ultimate goal of business and IT alignment was seldom achieved.

Well, folks, we are on the new, false horizon. That doesn't mean we shouldn't try to crest it.

SOA, MDA, DSL, BPM -- All of these are solutions looking for problems, and none of these is the silver bullet. But they are more and better tools in our toolkit, and they make it possible to get our heads around larger problems. Of course, as another brilliant Thought Leader once wrote, "By solving problem number 1, you promote problem number 2." The next wave will come, and we'll try to deal wth it, and our hindsight will elucidate the failures of the above-mentioned TLAs, and we will woefully regret the mistakes.

For the aspiring or otherwise enterprise architect, it behooves you to gain a base understanding of how your business people think about the problems your business addresses, so that you can align your IT efforts with their needs and you can speak their language. Read the profit patterns. Read business books. Get an MBA. Find out write drives your business. Meet them more than halfway.