techMusings

Middleware Matters: CORBA did what?

There's a pretty good discussion going on the comments thread of this posting, generally around the topic of loose coupling. Of course, I think what causes most of the need for discussion on this is the fact that people don't define loose coupling -- the requirements aren't set, I may put that in my next post. Bits will be eluded to below though.

I think Michi Henning's comments provide much of meat (though a a couple of others are included); I will respond to a bunch of points here...

WS is no more loosely coupled than CORBA. WS proponents claim that loose coupling is achieved by using XML, because XML can be parsed without a priori knowledge of the contents of a message

While I agree with the first statement, XML does make it easier, since the non-type based usages (ie non-statically bound types) are easier to cope with / debug. The human readable aspect is important -- debugging two CORBA impl's that aren't working is a real mare -- I have to admit not really using CORBA in anger since 2.1/2.2, so things may have changed, but I haven't kept up.

CORBA is typically used for communication among application components that are developed by the same team, but is not used by companies to offer a public remote API that anyone could call

This means loose coupling is generally not an issue then -- or at least it's in no way the beast that it is for cross team / org / company.

But WSDL ends up creating type definitions that are just as tightly-coupled as IDL ones. (And everyone seems to agree that WSDL is important.) But, where does that leave loose coupling? We have XML at the protocol level, which is loose, and we have WSDL at the application level, which is not loose.

True -- though it's more accepted to use looser types in XML than DynAny's in CORBA. Actually it's not quite WSDL that's the major problem, XSD is the stickler -- it doesn't work for validation in a loosely coupled system. Dave Orchard has written endlessly about this one.

versioning and loose coupling are not about just being able to send additional data, but also about changing existing data, operations, parameters, and exceptions. Moreover, real-world versioning is sometimes not about changing interfaces or data types but about changing *behavior*: it is common for someone to want to change the behavior of an operation for a new version of the system, but without changing any data types or operation signatures

Changing behaviour of a single component is the *goal* of many SOA / loose systems. The trick is doing it without breaking anything else.

Loose coupling is about dealing with application-specific data types and interfaces and whether it's possible to gracefully evolve these over time

Exactly.

multiple interfaces are a far better approach

True, however there's an overhead, particularly in a statically bound system (ie one node) of maintaining multiple interfaces. It's a necessary approach but you want to avoid it for every possible change if you can. XSD / IDL is pretty painful here, actually RMI/Java can be much more forgiving.

trying to put loose coupling into the encoding of the data (i.e. using XML) is at too low a level precisely because loose coupling is *semantic* issue, not a syntactic one

Debug debug debug is about all I can say.

Most application programmers don't want yo implement dynamic data binding logic. They want a serializeable object with access methods

True, however, depending on the interface size / change rate and flexibility of the binding this is simply not worth the effort. Actually, XMLBeans is pretty good at tolerating XML 'noise' robustly. Are there any similar ORBs?

Technologically speaking, CORBA offers a robust and complete stack with a clear and well-documented approach on designing and implementing distributed solutions.
Only disadvantage : tool/server providers were not really interested in providing true interoperability...

The firewall issue is a fake argument.

Robust: yes. Well-doc'd: yes for RPC, no for loose coupled systems. Interop: bad, trying to get Visibroker or Orbix to talk across more than a sub-version of the same vendor's product was generally horrible. It remains to be seen how this shapes up in the WS world.

Firewalls were a big problem with CORBA, both lack of good HTTP transports and the issue of embedding IP addresses inside the IIOP packets, which then get VERY confused when going through the many NAT layers of DMZs etc. Again, lack of visibility due to binary formats and ease of translation of IP addresses made CORBA miserable to work with in NAT environments.

Loose coupling will never happen, at least not before we have application components with reasoning capabilities.

It happens today. Most people will not see it until they admit it's more than a technical feat however. It's (probably mostly) a management / control cost trade-off issue.

Appologies for lack of accurate attribution, if anyone complains I'll go back and fix it. Read the whole thread, there's a bunch of good stuff in there.