Michi Henning weighs in...

I'd like to chime in here with a perspective that comes from nearly 25 years as a programmer and designer.

Most things start out simple. That's because most ideas, at least at their core, are simple. For example, someone comes up with the idea of doing a file transfer protocol: "All we really need is a server that has a stash of files, and a client that asks for one of those files, and then we open a TCP/IP connection to transfer the file." That's what's at the core of ftp, and it is just one example of many ideas in computing that start out with a simple requirement, an idea to meet the requirement, and basic approach to solving the problem.

CORBA, web services, or any other kind of middleware come from a similarly basic idea: "All we need is a server that can accept a remote procedure call with its parameters, and return a reply with the results."

So, why is it that CORBA, DCOM, WS, etc. have turned out to be so complex? I can see several reasons:

- The basic idea is often not sufficient to really solve the real-world problem. In case of ftp, complexity is introduced by the need to make the protocol work through client-side firewalls that don't permit incoming connections, the desire to restart failed transfers where they failed instead of retransmitting the entire file, the need for authentication, etc. In case of CORBA, complexity is introduced by issues such as partial failure, guaranteeing at-most-once semantics, the need for location transparency, etc.

In other words, there are legitimate requirements that must be addressed in order to make the solution work in practice. The additional requirements add extra complexity.

- Design by committee (and even design without committee) often leads to features that would better be left out. In case of CORBA, the specification is full of things that are useless and don't contribute any function points to the overall platform, simply because someone said "Wouldn't it be nice if it could do X..." The extra features add complexity at two levels:

- in the implementation, because it requires more code, more APIs, more complex protocols, or more complex <you name it> to support the feature,

- in the APIs, because extra features require more complex APIs,

- in the architecture, because features rarely stand in isolation and often interact with each other semantically, adding yet more complexity.

The third point is particularly important because it means that the increase in complexity of the system for n features that each add m units of complexity is not n x m, but is determined by some higher-order function. (I could cite numerous examples in CORBA where a feature in one part of the platform interacts in surprising and very complex ways with a seemingly unrelated feature in a completely different part of the platform.)

- Political consideration often dominate the agenda, rather than technical ones. Certainly, in the OMG, many decisions are made on grounds of maneuvering for market share, playing dominance games, kow-towing to a particular customer, or through sheer ignorance and bloody-mindedness. The technical results of this are not pretty at best and downright abominable at worst.

- Finally and, in my opinion, most importantly, design failures cause complexity to rise far quicker than what would ordinarily be expected by the addition of a particular feature. What I mean by that is bad design, pure and simple. The computing world is full of design ideas that are poorly executed and result in a mess of APIs that are complex, slow, error-prone.

This final point is what so often spells the downfall of a technology (and, in the case of middleware, so far, has spelled the downfall of DCE, CORBA, and DCOM, and (this is my personal prediction) will spell the downfall of web services. In CORBA, the design mess, more than anything else, has completely destroyed the functionality that people were initially trying to provide. Examples are numerous: the messed-up protocol design, the insanely complex interfaces to the trading service with their botched semantics, the complexity of the C++ mapping, the complexity of the POA API, etc, etc.

Personally, I'm convinced that the complexity beast can be tamed. What it takes is clean design, clean and orthogonal abstractions, the ability to say "no" to a feature, a clear vision of what a system is meant to do and not meant to do, and the ability to leave power games aside. Unfortunately, it takes experience (and lots of it) to arrive at the necessary clarity. As is so often the case, the third or fourth system that we come up with is the one that gets it right, and the previous ones we built simply so that we could learn from our mistakes. It is unfortunate that we are in an industry where the customers bear the brunt of that learning curve...

I don't want to push my own barrow too much here, but people might be interested in Ice (www.zero.com). It's a CORBA-like middleware platform that is faster, simpler, more fully-featured, and much easier to use than CORBA. The reason for this isn't that the people who built Ice are so much more brilliant than the rest, but that more than ten years of experience and hard-learned lessons have gone into Ice, coupled with a focus on design goals and architectural integrity.

I also find it interesting that most (if not all) truly brilliant systems in computing seem to have been implemented by a small number of people who had vision, excelled in their area of expertise, and had the stamina to see an idea through without losing integrity along the way. In comparison, I can't think of anything brilliant that came from a large number of people, whether they were part of a large development team, an international consortium, or even a large open source effort. (All the brilliant bits of open source that have large numbers of contributors still seem to be controlled by a small group of true experts who say "yay" or "nay".)

I guess the above is a long way of saying that a poorly-design system will inevitably fail, that it takes time to come up with the right design (and execution of that design), and that people often cannot detach their emotions and ego sufficiently from their work.

Cheers,

Michi.

I'm betting on WS-Security, WS-Policy, WS-Addressing (when will we see more intermedaries? - Is this a hardware opportunity?), WS-Transfer, and a Pipeline/Filter bus.

Doesn't seem all that complicated to me. Nope, it's definitely not CORBA.

Rather late to the party but go see www.connectivelogic.co.uk