This is basically a preview of the first chapter of Don's new book, or so DBox says...

Brad Cox (author of Objective C) had a good metaphor:
Objects = Software Intergrated Circuits
Software can be plugged in to other scenarios not originally anticpated by the originalauthor of the object.

Integrated Circuits are:
 --Small 
 --Fast
 --Cheap

OO premise: making new abstractions is cheap. The goal of OO designers is not to writeprograms, it is to develop new abstractions.

The average user does not do field replacement of IC's anymore -- they're soldereddirectly to the board, coupling the IC chip to the hardware. OO is a good metaphorfor software when your comfortable with "soldering" your components to the largersystem. When you need "sockets", OO breaks down.

Time makes abstraction expensive. As soon as that abstraction gets published, there'san implicit commitment to keeping that abstraction consistent. This becomes extremelydifficult to do in practice. COM taught us this. The MIDL compiler made it reallyeasy to make new abstractions, but it didn't really make it easy to for people toagree on what those abstractions meant.

Distance makes abstraction expensive. The lesson of DCOM.

Extensibility makes abstraction expensive. The interaction between multiple and unknownfuture extensibility is impossible to manage. Unbounded extensibility is dangerousand unpredictable. Interesting side note: the .NET context architecture is a deadend.

Standardization makes abstraction expensive. The exemplar: XSD. The result of design-by-committee:XSD is dumber than the dumbest person on the standards body. Too much design workwithout implementation experimentation leads to crud. The last thing you want is astandards body with an agenda -- one that creates science projects instead of product-orientedtools.

SOAP is the industry's response to these lessons. SOAP limits the number of abstractionsnecessary to make interop works to a FIXED set of constrained abstractions that everyoneagrees on. This is part of the moved to Service-Oriented Architectures. SOA is abouthaving a small set of fixed abstractions and no more.

SOA 101:
- services create very few new shared abstractions.
- services assume a minimal shared/stable kernel that doesn't change.
- XML 1.0, HTTP, SOAP
- services assum high-lantency/low-fideleity communication channel
- Not only between the software, but between the developers!
- services compose at coarse-grained message boundaries
- The message routing becomes the primary extensibility model
- services share schemas and contracts, but not types!

XSD and SOA:
- XML SCHEMA IS NOT A TYPE SYSTEM!
- All schemas are relative! They are not the absolute truth. The absolute truth iswhats on the wire.
- XML schema is a relative interpretation that helps you deal with what's on the wire.The help that your system needs is different than the help that someone else needs.
- Schemas are not types -- types are abstractions, which services don't share. Theyare machine-readable validation instructions that define the legal inputs and outputsto the system.