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.