Before I get into this, let me say that the SOA discussion overall is increasing the ability to make better servers. And I think I could demonstrate that most of the benefits of SOA still apply to this, with the exceptions I mention below.

Let us assume that SOA is absolutely the best way to move data between servers and clients.

Let us assume that we want to write clients in an object-oriented system most or all of the time.

Will we then need a whole new class of tools to translate between raw message data and objects with behavior to build such clients? Consider the well-known impedance mismatch between object and relational data. Isn't this a very similar situation from the client's point of view?

I just discovered Joel on Software's "The Business of Software" forums. Some interesting conversations.

I had to throw in my two cents on this when I saw an unfortunate sales guy trying to figure out how to hire a quality developer and saying all the wrong things.

Like this gem: "All I expect is for work to get done when it is promised. You estimate...you deliver if it takes 45 hours I would hope you stay. This is not an art class where you have the luxury of procrastination."

And then I started writing and evidently just couldn't stop...

A persuasive article by Joel Spolsky with some interesting numbers to back it up.

When building a distributed application, should you use a Thick Client or a Thin Client?

Rockford Lhotka explains, better than I could, another option. It's strongly influenced several of my posts, and if you find my n-tier concepts wacky, you need to read about Lhotka's Mobile Object model.

Short version: A way around many of the limitations of the thick or thin clients is to allow the objects to move freely between the middle tier and the client. Not the data. The objects.

NUnitForms may be what I'm looking for. I've certainly built far too much of this type of thing by hand and never quite been satisfied with it, but this seems to be a complete package along the same theme.

As a part of the experiment I mentioned earlier, I found myself trying to update my user interface techniques to work with the new Whidbey beta.

It's been a somewhat frustrating experience, but I think I've found something I can be content with. It's definitely a huge improvement over what's been packaged in the box before - but it's still not all I'd like. (That blog will come on another day.)

So, while I was reading up on interface design, I stumbled across this gem of a moderated discussion between Kent Beck and Alan Cooper. They seemed to genuinely respect each other's techniques and yet repeatedly failed to reach a consensus on how to use both of their techniques together.

Steve Eichert points out Jeff Perrin's interesting discussion on how O/R mappers could use attributes instead of XML to store metadata. Paul Wilson of the Wilson O/R Mapper adds his comments, and doesn't agree. Both have some good points.

Having the mapping metadata in an attribute form keeps the code and the mapping in the same place. Since changes to one often involve changes to the other, I rate that as good. And I kind of like the idea of being able to lock down a mapping at compile time. A potential downside is that, to export the mapping, though, you'd need to build a custom tool to extract toolable XML.

I've got a little experiment going...

I've just read a lot of Fowler's Patterns of Enterprise Application Architecture, and it cleared up a lot of the questions I had after reading Evans.

PofEAA was not nearly as accessible as Evans, but it's highly rewarding. I seem to recall that Fowler's writing was very accessible in Refactoring, but PofEAA is dense, dense stuff. That's why I hadn't gotten far in it before! But even for simple things like Optimistic Offline Locking, just having a common name makes it easier to think about. And there are a lot of things that I hadn't seen in this specific form like his method for handling a Unit of Work. I like it a bunch.

Deploying rich client applications is expensive and time consuming, right?

That's why we need to replace them all with web applications, right?

This just doesn't have to be the case.

Why is it that certain literature assumes that n-tier != fat client?

So, let us assume that deploying rich clients is expensive.

If it's costing a lot of time=money to do by hand, then automate it. (Somehow, we intuitively understand this for our users, but sometimes miss it for ourselves.) In 1996, I built a system that combined single-sign-on for users, centralized application-based security for managers, and centralized deployment (xcopy deployment, dare I say?) for developers. Everybody saved time. And it just wasn't that complicated a tool.*

IKVM looks to me like it could darn near replace Web Services.

My beef with Web Services is that they're just data. No matter how well you organize data, it's dumb. It doesn't know how to do anything.

A Web Service that can be called by anything just means that any common, domain-specific behavior that is needed on the client side needs to be reimplemented by every bloody caller.

Don't get me wrong. It's a good start. But we need to distribute the objects.

Enter IKVM:
It only does two things (that I know of). It can produce Java proxies to allow Java to call .NET libraries. And it can translate Java libraries into .NET libraries.