Specifically, the systems architectures that have grown out of the ubiquity of OOP languages and high level API frameworks. Why is it nobody tells you what these this actually are, and just rambles on about the sorts of things they claim to do? Recently I've been looking at Service Oriented Architectures (SOA), Enterprise Service Busses (ESB) and Web Services.
As far as I can tell, SOA just means "It's a good idea to have well defined, autonomous and reusable components that communicate over well defined, stable interfaces". Haven't we known that since at least Unix was developed? Actually, reading SOA documentation reminds me an awful lot of the microkernel debates. Again they're arguing against large single heavily integrated systems in favour of more flexible components. Again it sounds good in theory, but I wonder if the overhead of messaging will prove as deadly for SOAs as it did for μkernels?
ESBs are a bit harder to pin down. They appear to be basically where all the nasty stuff to enable a SOA happens. Depending on who's asking, it's everything from a messaging interface, through queuing, to data transformation services and a basic transaction processing monitor. Exactly what's in or out depends on the vendor. It also appears to be the "man behind the curtain", just being drawn as a magic box on high-level architecture diagrams, without worrying about the effort needed to correctly define the messaging structures, ensure reliably delivery and distribution and most critically coping with exception conditions. I also still don't see what the real difference is between an ESB and various messaging and TP monitor frameworks that were around 10 years ago (and more). The best I can come up with is that they've shifted a chunk of the integration effort from the application into the framework.
People seem keen to use XML for all this. Why? The times I've seen it attempted as a messaging encapsulation, it's been very expensive to parse and requires a lot of metadata for the amount of data transmitted. Since both endpoints need to understand the XML schema used, why not use an easier to parse format for marshalled data? Is it just because XML is fairly human-readable so message formats are simpler for people to handle? (Seriously, does anybody know why?)
Web services are another odd one. That feels like a hammer/nail problem. Everybody had a web server, so it becomes convenient to talk over HTTP, regardless of the suitability of the protocol for the task. As a result people start transferring XML all over the place, and HTTP/XML combined becomes effectively an inefficient, inappropriate but widely deployed and interoperable presentation layer protocol. Wouldn't it have been easier to stick with CORBA?
Overall, it looks like SOA is an attempt to formalise fairly good design principles, it's nice to have standards for component interoperability. You might be able to reduce messaging overhead adequately by not going over-the-top on componentising your systems. However I remain deeply unconvinced by the implementation. If you were starting out to design one of these, I don't think you'd come up with what's evolving from the bits that happened to be lying around. I suspect that it might be all a result of a there being no common cross-platform standard, so people built one on the one set of interfaces that were available on both Microsoft and Linux/Unix platforms. I don't know much about .NET, but vaguely get the feeling it's meant to deliver similar stuff?
It also appears that I won't be able to change the world by just observing the fact it's all crap, so had better continue to learn about what is available. Unless anybody feels like getting together to produce a whole new cross-platform multi-language application services infrastructure that's much more lightweight, robust and reliable than the existing stuff? We could make a fortune, if we could produce it by next week and convince a bunch of people to start using it.