I use NHibernate and LINQ to SQL on a site that supports millions of end users. Murray Gordon, an Architect Evangelist at Microsoft, has written a nice synopsis of the Entity Framework Vote of No Confidence debate so far. More than anything else I've read on the subject, this article brings together facts and opinions that seem to ring true from my deep experience.

I'd like to go on record and say that the way this is being handle by the MVPs who signed the petition is unprofessional, in my opinion. Microsoft MVPs are not required to tow the line and agree with everything that Microsoft says and does. But there are ways to communicate with Microsoft that are constructive and there are ways that would make any corporation, including Microsoft, digs its heels into the dirt. This petition used the latter strategy unfortunately. In particular, Microsoft MVPs have channels that the rest of us don't have. They should use them and not the blogosphere to make plain there grievances.

In some sense, I feel as though the signatories of the petition feel like they are playing Continental Congress against King George. But there's no Boston Tea Party here. Microsoft didn't raise any undue taxes from any of us. They simply put out a framework that's clearly a v1.0 product. Microsoft doesn't win with v1.0 products. It wins with version 4 products because as a corporation, it knows how to get the first down (an American football term meaning the team gets to stay on the offensive).

I say let Microsoft run the ball for a few plays and let's see how they do.

Databases are just awful. I don't mean the products themselves but the concept of databases. Stop and think about how absurdly we behave when we write modern software. We generate scads of information in the course of our daily lives. (A scad for me is about 2Gb the last time I checked. May be more or less for you.) Much of this information approximates the lives we lead and the obligations we must honor. But rather than putting that information into a system that has the tools necessary to model the real world from which the data originally emanated, we usually choose to keep it in a place that does an efficient job of storage. When we need to put it back into the real life approximation engine, we shuttle the information in and out of our application servers as necessary. It's been estimated that as much as 50% of the time we spend in development is in bridging the gap between data storage and the business logic of our applications. That number may be an extreme, low or high. But even if this kind of work accounts for only 25% of our time, why would we choose to spend our development budget this way? Data is so simple. It should just be there, fully accessible to me all the time.

Some operating systems do a better job of closing the gap between code and data than others do. For example, the Pick System, originally developed by Dick Pick in the late 1960s uses a hash-based file system to create associative arrays that are super-efficient for many query operations. The only data type in the Pick System is the string. And most importantly, the Pick database engine is not relational. It is a multi-valued instead, meaning that any attribute that needs to have multiple values can just declare them. In the Pick mind, there's never a need to create related tables and join them for query or reporting. A platform that implements this type of database also typically ships with a Pick BASIC compiler which allows for direct manipulation of the query engine and the associative arrays it produces. The BASIC code runs right there in the database, not on a foreign system. Embedded Pick BASIC is not like the SQL CLR. The SQL CLR, for lack of a better term, is bolted onto the side of SQL Server. You can't do any real data manipulation in the SQL CLR. However, in Pick BASIC, you can freely manipulate schema and data directly. Forget for a moment that it's BASIC and you've got something great there. Compiled code running in the database that can manipulate database objects natively. Way cool and circa 1965.

IBM and InterSystems, among other vendors, still sell these databases like hotcakes today because they solve very real business problems for which relational databases are not ideally suited. First of all, they're fast. And I mean smokin' fast for many types of operations, especially high-volume transaction processing applications. This is partially due to the fact that because there are no join operations (in the classical sense), there's usually less work to do to obtain the data you're seeking. But even when there is a sub-select operation that is required to get what you're looking for, the efficiency of the underlying hash-based file system pays off handily. In database terms everything in the database is indexed, always.

My students and colleagues often hear me say that, "Databases are an unfortunate consequence of history." I say this (and believe it) because if you could travel back in time to 1948 and give the ENIAC developers at the University of Pittsburgh a handful of 4Gb DIMM chips and the necessary plans to connect them to their invention, relational databases like Oracle and Microsoft SQL Server would simply never have evolved. I think that the development path would have been more like what Dick Pick envisioned and built instead. Given enough memory early in computing history, associative arrays, set operations and in-memory manipulation of large data sets would have been the norm. However, as we know, memory was severely constrained in the early days of computing. In fact, it's only been in the last few years as new technology has allowed for memory prices to drop dramatically that it has been feasible to conceive of a solid-state database at all. Oracle's TimeTen and Microsoft's Project Code Name Velocity are leading-edge concepts in a new market-segment that will, one day, fully realize Dick Pick's vision, in my opinion. I predict that accessing data from distributed, in-memory databases will become the norm within my lifetime.

Many of the current Object/Relational Mapping (O/RM) debates are centered around my database evolution postulate because O/RM tools attempt the inverse of what the Pick OS does to achieve the same effect. O/RM tools essentially pull as many database semantics (sans execution) into the application tier as possible where the logic of the program is codified. Whether we run Pick BASIC in the database or use an O/RM to marshal data close to our C# code, the desired outcome is the same. But pulling data into an external execution engine as O/RM tools do is pretty close to nightmarish, to be frank. In fact, Ted Neward, whom I greatly respect, calls O/RM the Vietnam of Computer Science today, meaning a quagmire from which one cannot possibly be extricated and for which there is no good outcome. Ouch! What a stinging rebuke from a guy who's singularly qualified to make an assessment in this space. Even Ayende Rahien's blog post from earlier today reveals a sense of desparation about the state of O/RM technology. What a mess we've gotten ourselves into! No O/RM suite that I know of addresses the real problem at hand, i.e. making data access so transparent that you don't even know you're doing it.

We use both NHibernate and Language Integrated Query (LINQ) to SQL at SnagAJob.com for O/RM. They make life easier in some ways but so much more difficult in others. I cannot begin to count up the hours we've spent tuning the session management code in NHibernate to deal with authentication and transaction management issues. And you don't burn up welterweight programmer resources on that kind of work. Your heavy hitters need to be deeply involved because there are architectural design issues at every turn. Every minute that your senior developers and architects are distracted with this kind of stuff, they aren't focusing on what you thought you hired them for. LINQ is better than HNibernate in a couple of ways, chiefly because of the expressiveness afforeded by the IEnumerable<T> extension methods and the query comprehension syntax. But deploying LINQ to SQL or LINQ to Entities in a real-world environment is still not as simple as it should be. And the real goal of transparent data access is still far, far way using NHibernate or LINQ.

If you know of an O/RM suite that makes accessing SQL data more Pick-like as I've described, i.e. more transparent, I'd like to hear about it.

<Interesting Related Story> In 1993 while working for Datastorm Technologies, Inc., I attended Comdex in Las Vegas. At lunch one day, two fellows joined me at the table. The older fellow to my right introduced himself as Dick Pick. I asked him what he did for a living and he graciously and eagerly explained the Pick OS, it's simple power and beauty and a smallish version of his life story. I was impressed but didn't really get it at the time partly because the fellow seated across the table introduced himself as Phil Katz, the inventor of the PKZip file compression utility. For me, Phil Katz's fame overshadowed Dick Pick's because I didn't know any better. So, I didn't engage with Dick in conversation to the degree that I really should have. History, it seems, hasn't been all that respectful to Dick Pick either. Phil Katz has a detailed Wikipedia article about him yet Dick Pick doesn't, for example. Googling for Dick Pick yields scads (there's that word again) of Dick's Pick's Grateful Dead references and nearly nil related to the computer science genius of our time. In retrospect, even being seated with a legend like Dick Pick was a real honor. I wish I had known to take advantage of the opportunity that was given to me. Live and learn. </Interesting Related Story>

Dave Balter has released an e-book entitled The Word of Mouth Manual: Volume II. I am not a marketer but I am familiar with concepts like Dunbar's Number and how the spheres of influence in a community dictate the rate of spread for a message. The popularity of social networking has everyone talking about viral marketing these days. "Let's attach our product to this social network or that one and drive new traffic by word of mouth," seems to be the buzz.

I don't think most people realize how improbable a successful Word of Mouth (WoM) campaign is. Dave Balter's premise in this book is that while you can and should do things to get into a WoM stream, getting into a WoM river is much harder. In fact, he says that when the timing's right, the opportunity picks you, not the other way around. That's some wisdom I think.

In the sphere of influence in which I participate, the real trust zone is very small. This is happening on a wide scale I think which results in the fact that, "Marketers are spending more and more money delivering messages that consumers are trying harder and harder to avoid." WoM marketing is all about raising the influence of the dollars spent. But with such a small zone of trust, can it deliver?

What does this have to do with software architecture, Kevin? Well, as the liaison between the business and technical groups at my company, it's difficult to count how many meetings I've endured where someone touts the brilliance of the latest viral marketing idea they've come up with. And there are real business resources at stake here. Every moment we spend chasing down a bad idea that seems good keeps us from spending time on those that are truly worthwhile. I need the vernacular that lets me challenge those ideas in a constructive way and I found Dave Balter's book instructive to that end.

Download the free e-book from the link above (or click on the book cover to check out Dave's blog) and decide for yourself. It's a quick read. Hey, look at that! The distribution of the book is viral. Pretty cool, huh?

It says it right there in the documentation. But somehow I had never picked up on it.

If you enable Web-garden mode by setting the webGarden attribute to true in the processModel element of the application's Web.config file, do not use InProc session state mode. If you do, data loss can occur if different requests for the same session are served by different worker processes.

We've been using ScaleOut StateServer for some time now. Aside from annoyances like not being able to see performance statistics for the in-memory cache, ScaleOut StateServer is a good product for managing state data in a large web server farm. (Read about my solution to the missing performance counters problem.) We followed most of the best practices for setting up StateServer. But as we approach the 11 million user mark at SnagAJob.com, we have been seeing more and more issues that point to ScaleOut being the root cause of some serious performance issues on our site during peak load.

We were using ten virtual machines running IIS6 with five IIS worker process instances per server. That's fifty worker processes. Not a huge web server farm but not puny, either. In any case, after speaking with ScaleOut support and learning that many of their customers report networking problems while using vmware ESX to host Windows Server and IIS, we decided to go back to InProc session state management for a while. To do this, we had to enable one of the session persistence modes on our load balancers which is far from ideal. Doing that makes things quite a bit less fault tolerant and slows down the deployment process considerably. But we had to do something and this seemed fairly low risk.

When we switched back to InProc session state management mode, we started noticing strange behavior for logged in users. Tests confirmed that the multi-instance web gardens were the culprit. We downgraded to one IIS worker process instance per server and everything is beautiful.

It's completely counter-intuitive to me (and to everyone else I've spoken) that multiple IIS worker process instances operating as a single web garden don't share InProc session state. Logically, it's one server, right? And Microsoft has had support for memory-mapped files in Win32 for more than a decade. Well, as I said, it's right there in the documentation. But an event log warning on application startup would have been nice in this case.

By the way, even though I like ScaleOut StateServer, our fifty IIS worker process instances have been reduced to three (yes, 3) and we are handling our normal volume nicely. We know that our networking environment isn't ideal. Any company that has to be meet the PCI Security Standards is going to jump through some intricate networking hoops. But there's little reason to deploy fifty server instances to solve a scaling problem when three will do.

For twitter.com users, the near perfect depiction of the series of poor architecture choices leading to the current state of affairs shows twitters (birds) airlifting a seemingly blissful whale by threads over the sea. Aside from the fallacy of bliss in losing access to one's tribe, no image could be more apropos for indicating that twitter is down. Twitter is over capacity in so many ways.

I've been thinking and writing code in the personal connectivity space for a decade or more. I even have a patent in the peer presence space. I joined a freaky little start-up that Intel Corporation invested in called The Palace. Time Warner and SoftBank were in that mix, too. In the late 1990s, we had high hopes of turning our vision of inter-personal connectedness into a cash cow. There were distance learning angles, entertainment angles, etc. All painfully 1990s thinking in retrospect.

We made so many mistakes. However, the technology wasn't the real problem. It was our thinking that was specious. Even as our pens stroked out the patents on paper and our keyboards tapped those ideas into great code, we couldn't imagine the power of the tribe that services like twitter.com evoke in the average user. Our Palace code was built very much like twitter. Centralized message dispatch. It did OK at intranet scale but when it came to thousands or millions of users, it was just the wrong way to build the thing.

Success can be a powerful enemy. Hubris, it seems, is a much greater threat to any technology-oriented business. The scale of the Internet guarantees that. As Andy Grove taught me, Only the Paranoid Survive. Paranoia, like hubris, is an equally self-interested set of emotions. But paranoia is sigularly devoid of vanity. And vanity distracts us from truthful ideas like, "It's probably not smart to build a hub-and-spoke protocol for something that has to scale to millions of users."

I agree with Scott Hanselman that microblogging should not be centralized. Except for SMS and directory access, there's just no reason to make any other parts of a system like that centralized.

This was the first time I gave this talk but the attendees seemed to be very receptive. The concerns about security in Silverlight, especially related to the protection of Intellectual Property (IP) and account access are really on peoples' minds. Based on the thoughtful question I received here and in Roanoke 2 weeks ago, I have decided to dedicate a whole chapter in my new book to Silverlight security principles.

In this talk, I discussed the various methods by which a Silverlight application can access remote web services. We didn't have time to get into RSS/Atom syndication but I'll be sure to cover it in a future talk. We also discussed cross-domain policy, another hot security topic, as it turns out. I showed how to enabled a WCF web service for RESTful delivery and then showed how to consume SOAP-based services from Silverlight. We closed by looking at the use of an in-domain, SOAP-based WCF service to act as a proxy for a cross-domain RESTful service that does not allow cross-domain access by policy. Here are the slides and sample code:

WCFRESTDEMO20080517.zip (18.89 kb) - sample code that shows how to make a WCF service RESTful; a Silverlight control is included that demonstrates how to use it; there is also a Digg.com downloader that demonstrates cross-domain functionality from Silverlight.

Twitter20080517.zip (25.59 kb) - sample code that shows how to consume an in-domain SOAP-based service from Silverlight; that SOAP-based service is really a proxy to a RESTful service at Twitter.com. And since Twitter.com's cross-domain policy doesn't allow access from my domain, this example shows how the server-side WebClient class can be used to circumvent the policy limitation.

Silverlight and WCF - NOVA Code Camp 2008.1.pptx (199.39 kb) - my PowerPoint slides from this discussion.

Accessing web services with SOAP can be just as easy as using REST with all the enterprise-class features you've come to expect from WSDL and SOAP. Who says that the cycle of metadata and proxy generation should be so hard? I gave a talk at the NOVA Code Camp 2008.1 that shows how by using the CodeDOM, and the ServiceModel.MetadataImporter, you can generate proxy code dynamically.

In this talk, I also showed how IronPython can be used to add a dynamic "lower edge" to a C# application to make it much more dynamic feeling. Finally, we finished with a discussion about features that may be added to Visual Studio 10 and the C# 4.0 language sprecification to make SOA achievable for many more developers. It was a lively discussion with lots of great questions. Here are the slides and the demo code:

ProxyGen20080517.zip (20.86 kb) - Sample code that demonstrates the use of IronPython and some custom CodeDOM code to avoid generating proxies for WCF integration via SOAP/WSDL. IronPython 2.0 Beta 1 or newer is required to compile this code.

Simple SOA with SuperSOAP by Kevin Hazzard.pptx (208.46 kb) - my PowerPoint slides from this discussion.

I stumbled on a quote today by Antoine de Saint-Exupéry, the famous aviator and author of The Little Prince which I think describes good software architecture. Here's the quote:

A designer knows he has achieved perfection not when there is
nothing left to add, but when there is nothing left to take away.

Software architecture, in my experience, is about having a passion for obscuring complexity in favor of simplicity. Apple knows this at the macro level, for sure. I wonder if they really know that down to the smallest turtle that they can perceive. I don't think so. But they are further along than most. Juval Löwy often says, "For the beginning software architect, there are many choices. For the master, there are but few." This quote expresses the same sentiment as de Saint-Exupéry's thought. Perfection in the design of anything can only be achieved when the designer is willing to strip the thing to it's essentials. Then the creation becomes a tool that will resonate with the craftsman that uses it.

At the risk of making this look like an IDesign plug, Michele Leroux Bustamante says in her Learning WCF book, "Little SOA enables Big SOA." Great book, by the way. She could not be more on target. It really is turtles all the way down. Elegance in software design at any level begets more elegance. There are few right ways of doing things and when you do them consistently at all levels of your design, you can approach perfection.

Is perfect software really achievable? Perhaps. I know that when I wrote scads of assembly language code decades ago, I achieved absolute perfection for one or two algorithms. But nowadays, I think that many people use SOA as a crutch, a tool for hiding imperfections in their designs. We wouldn't scramble to building façades all the time if this weren't true. WCF helps because it strips away so much of what Juval calls "the plumbing", allowing for a level of abstraction in the delivery of information that was previously difficult to attain. It's an exciting time to be a software architect.

One of the easiest ways to deal with cross-domain issues in Silverlight is to write a WCF service that acts as a proxy for the calls you want to make. For example, in my Twitter control, I want to be able to load XML from the RESTful Twitter service at the following address:

http://twitter.com/statuses/user_timeline/wkh.xml

However, when invoking the RESTful Twitter service from a WebClient in Silverlight, I get the dreaded "Download Failure" error when I call DownloadStringAsync. This is because the Twitter.com site doesn't have an entry in its clientaccesspolicy.xml file for my test domain. And that's never going to happen, right? To solve this problem, consider exposing a WCF service from the site from which the Silverlight control emanated. The WebClient class can be used on the server side without the same cross-domain control being applied by Twitter.com. For the example outlined above, I called my service TwitterProxy. The ITwitterProxy couldn't be simpler:

The service implementation is also quite simple. It uses the WebClient just as I would from Silverlight (if I could):

Expose an SVC file on the server to host the new service. In this example, the URL to invoke the new service is:

http://localhost/WebSite/TwitterProxy.svc

So, to invoke this service from Silverlight, add a proxy to the Silverlight control, using the service address and invoke it like this:

The dreaded "Download failure" error is gone. Nice. of course, the potentially bad side effect of this technique is that all of the Twitter service traffic will be flowing through the server that's hosting the TwitterProxy. Think about that before using this technique.

These are the slides and source code that I used in my Richmond Code Camp 2008.1 presentation called "Look Ma! No Proxy!". This presentation concerns the problems related to proxy generation for traditional web services development. In this presentation, I propose a model for the future where proxies are no longer needed, at least not pre-built proxies as we use today. A bit of dynamic code generation, some C# client code and a bit of IronPython to glue things together. Mmm, mmm, good!

Look Ma No Proxy by Kevin Hazzard.pptx (197.46 kb)

ProxyGen20080426.zip (818.56 kb)