After much goading from Dominic, I implemented a RSS version of this weblog last night. I am yet to try it through an RSS reader, so I'm not sure how legit my interpretation of rss 0.91 is.

Total elapsed time was 70 minutes, but most of this was refactoring - the actual RSS implementation is a single XSL file.

Great msdntv from Don Box, with the central themes “objects make abstraction cheap” and “abstraction is expensive”:

• Time makes abstraction expensive (object abstractions are published, and hence create a commitment to holding abstraction for as long time)
• Distance makes abstraction expensive (the location transparency problem)
• Extensibility makes abstraction expensive (the contract specification problem)
• Standards make abstraction expensive (the design by committee problem)

I’m inclined to agree, but compelled to qualify:

Yes and no. At one extreme, we publish no interfaces. We stay off the network. We never integrate. This pretty much means we don’t write software. At the other, we publish lots of object interfaces and remain captive to them forever.

Neither of these are a great place to be, but it is important to understand we must publish something, and we should publish as little as possible. So if my granule of reuse is an object, then I am likely going to feel the pain at one extreme, because objects manage complexity by breaking it right down. If my granule of reuse if something higher up the stack, I can feel much more comfortable, because components and services tend to compose those bitty interfaces into a larger unit.

Ignoring the technology differences, there is a big overlap between the dreams of component development and web services here: they both want to put more of the implementation beneath the water line. At the web services level, the big advantage is that I am only committing to a message format and a message exchange pattern, which is a really minimal contract.

Give me a distributed object, messaging or service technology, and I can use that technology for good or for evil. Web services can offer a better technology model, a better infrastructure for implementing distributed computing, and a more coherent approach to security, but it can’t stop anyone repeating the sins of bad distributed design.

As far as learning the lessons from DCOM, I’m willing to bet there are plenty of customers out there who don’t realise how much hardware they are using just because of the joys of location transparency. Getting tangential for a minute, msft does a great job with IDE support for web services, but it is scary that the proxy looks so much like the ‘real’ (server-side) class. I can’t argue with the ease of use, but I wonder how many developers are ‘losing’ server-side object state between invocations.

Interfaces are a great way to enable implementation substitution, but where is the semantic contract? This is a problem that would have been partially solved by DBC if anyone actually used it (and I love DBC), but I suspect the rigor of actually thinking about this is too much.

From my own limited experience of seeing people build on my code, there can be a big difference between “compiles ok” and “ok”. And with all the comments, unit tests, interface definitions and naming conventions in the world, I am pretty powerless.

I have no idea.

So what are web services going to do for us? I think there are a couple of copper bullets in web services that are hugely beneficial:

Technology - The basic profile technologies are a fairly simple. This means they have a pretty good chance of working. They also leave a lot of the implementation up to the platform, which means those details aren’t leaking up into the specs.

Granularity - If I publish an object API, even a small one, I am committing to several methods, fields, properties etc. Once this is out in the wild, I stand no chance of ever getting control back.

Web services don’t proliferate so easily: they are usually related to fairly large business processes, because of the cost of communication as well as the nature of integration points (inter-department, inter-organisation).

This doesn’t kill the problem of object reuse, because that will continue to occur intra-department and intra-organisation, but it provides a solution to the inter- scenario.

Security - It is still easy to screw up on security when implementing a web service. But a very significant security feature of web services is that, unlike shared object systems, a type is no longer traveling across the wire and executing in my process. This type migration can be secured, but I would prefer not to have to think about it. I don’t even want that option.

Web services assume that interacting systems operate with no trust. And if this functionality is going to be networked on the internet, that is the only sensible starting point.

Fact: All web site architecture can be sketched as three blobs labelled “presentation”, “business logic” and “data access”. Functionality is strictly partitioned between these blobs, and they are deployed across distinct machine tiers.

OK, so this might not be true of every system, but it is a pretty common approach.

The problem is that this high-level view isn't very good at answering some very sensible questions:

Do we have to implement ALL business logic on the middle tier? Surely it is more efficient to stick it close to the presentation process? Why are we taking a performance hit to go through the middle tier to access the database? What about putting business logic in stored procedures?

Rather than sticking with the (admittedly short) description above, I like to think of 3-tier as a collision of a few patterns:

Scale out - So why don’t we use one big machine? Scaling out allows us to increase our non-database processing linearly with cost. We offload as much processing as possible to this cheap processing resource, and try to minimise the usage of our expensive scale-up database resource. This also gives us cheap fault tolerance across our scale-out machines.

N-layer logical architecture – Layering is a fundamental organising principle of software. In this case, the crucial distinction is that logical separation doesn’t imply physical separation.

Remote application tier – Lastly, a security pattern. If we are already scaling out our non-database functionality, why partition our processing again between web and application servers? The web is a hostile place, and the remote application tier is an attempt to put as much distance as possible between our sensitive data and the web. So by partitioning a web application into several physical tiers, we can put multiple firewalls in place to protect that sensitive data.

It takes a lot to make me pause incredulously and re-read an article. But the recent ABC piece Amish reality show canned after protests left me wondering how much further can this reality thing go?