While the Freemantle Correction sounds snappy, I don’t think it bears scrutiny.
Ok, if I understand correctly, the kind of indirection being discussed is adding an abstraction layer (SCA over EJB, RMI, JAXWS).
simple - on the surface this should be solved, providing one interface instead of three
transparent - ok, for this kind of indirection, the problem can’t be solved: by definition. The purpose of the abstraction layer is to hide underlying detail
easy-to-use code - again this should be solved
Freemantle’s justification boils down to it being harder to fully understand what’s going on. But isn’t this a need-to-know thing?
Ok, a real-world analogy. Yesterday I fitted a new exhaust pipe to the air conditioner. Not a difficult job at all, but I did have to go through processes like buying the right kind of piping, and having a hot glue gun at hand helped. The obvious layer of indirection for this would have been to employ an expert to fit the pipe. All I’d need to know was a phone number and the request “fix the thing”. That would have been considerably simpler & easy-to-use, but not particularly transparent.
There would have been a cost involved to employing an expert - the obvious financial one (analogous to the cost of new code) to, plus that of the risk involved in trusting that particular expert. There was a collateral gain in fixing it myself, in that if something like it needs doing again I’ll be better prepared (increased net transparency).
Back to software I’d suggest it really boils down to how sure you can be that the abstraction is going to work well (analogous to the risk above). If leaks are rare enough not to be taxing, debugging below the indirection layer shouldn’t be needed, and transparency isn’t necessary.
Freemantle says: “Something that was designed to simplify and unify programming models should have a simple description.” Absolutely.
“Unfortunately, because of the above reasons, that just isn’t possible.” I disagree, I’d say it depends on the specific case. This is back to need-to-know, e.g. I can’t remember the last time I had to look inside a packet, or for that matter look at the circuit of a network card. It may be desirable to see what’s on the wire, but when did you last attach an oscilloscope or check the voltages? (Ok, strictly speaking that’s down to hardware, but it’s still part of the conceptual stack).
The obvious layer of indirection for this would have been to employ an expert to fit the pipe.
It may be just me, but who does the work is orthogonal to the work to be done.
A better analogy would be to say that instead of attaching to the pipe directly to the air conditioner, whomever does the work will connect the pipe to an adapter, and then connect that adapter to the air conditioner. In most cases, when such approaches are taken the result is additional points of failure.
“who does the work...” - well ok, it was only an analogy.
An adaptor between the pipe and the wall fitting (the A/C end was ok) may have introduced an additional point of failure, but would have saved me teetering on a chair with a hot glue gun ;-)
... but only if the adapter was installed.
Furthermore, my experience frameworks like EJB, RMI, and JAXWS are that they aren’t adaptors per se, but rather they are adapter factories.