Middleware Matters

It failed on the Internet, Steve. Come on, you should know me by now! 8-) All my technical posts are implicitly prefaced by "on the Internet", since I think that's the more general - and therefore, more interesting and more high value - problem to solve.

CORBA succeeded in its original design center - a closely-coupled world. CORBA can work in a loosely-coupled world also. However, all the people who would have written the CORBA/loose-coupling specs moved over to write the same thing in the WS-* space. So, if there is a failure, it is in marketing and organization, not technical.

I disagree with your assertion that WS-* is loosely coupled. In fact, compared with tried and true Internet scale systems like email and the Web, WS-* has shown itself to be about as tightly coupled as CORBA.

OK. Let's say CORBA and WS-I are tightly-coupled. And let's say email/web is loosely-coupled. With those assumptions, getting back on topic, I say if CORBA "failed" in a loosely-coupled world , it was an organizational and marketing problem - not technical.

You could say that the sales pitch misrepresented the technical capabilities of the architecture, or you could say the technical capabilities failed to live up to the claims of the sales pitch(*). I don't think there's a preferred frame of reference that makes one view the "right" one, but I don't think it's correct to assert that the technical deficiencies were inconsequential.

Hmm, I do not recall using the word "inconsequential." Getting back on topic, addressing the word "failure" - I've had a bit of contact with a number of successful CORBA deployments. It seems that CORBA is quite successful in its design center. It also seems that CORBA could do quite well on the web - but most of the new REMOTING action has shifted to "web services" stacks. The fundamental building blocks of a remoting system - see my PEPT architecture http://haroldcarr.net/pept/ - are the same whether you are doing XML encodings and protocols over HTTP or doing CDR encoding and IIOP protocol over TCP/IP. My main point is that the people who build these systems seem to be doing it in the context of web services rather than CORBA. The reasons for doing the work in one system versus another were originally more organizational/marketing than technical reasons.

I agree with Mark that CORBA has failed on the Internet. We simply don't see public integration using CORBA among companies. Instead, 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. Sure, I can send CORBA messages over the Internet. But that's not the crux of the question. It's much more a question of whether unrelated parties use CORBA (or WS) to communicate: one party provides the server, and an unrelated party then uses the server, much like a person using a web browser accesses a web server. And I don't see either CORBA or WS being used that way (other than for trivial toy applications).

I also agree with Mark that 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. This is the famous "the receiver can ignore what it doesn't understand" argument. I see many problems with this argument:

- This idea of loose coupling passes the buck to the application. Basically, the sender sends a message that can have all sorts of data in it, and then the application, at run time, has to make sense of it somehow. This is a recipe for bugs because type checking is not enforced by a compiler, and not enforced by the distribution infrastructure.

- We have WSDL. 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. There seem to be contradictory messages and intents here.

- Yes, I can define WSDL that makes things optional and types them "loosely", in some sense (just as I can define IDL that does that). But if I do this, the value of having a type system in the first place diminishes, and I'm back to passing the buck to the application, which then again has to figure out at run time (instead of at compile time) whether a particular received message actually makes sense. And note that it is the *application code* that is responsible for this, not the distribution technology, so I get to write type checking code in my applications over and over and over again...

- Even if I do define WSDL that is "loose" and makes lots of things optional, that typically doesn't help me. Loose coupling isn't of interest just for its own sake, but is of interest because people are looking for a way to solve the versioning problem: how can I evolve a distributed application over time without breaking everything that is deployed already, and without having to recompile and redeploy the universe? If I define WSDL that is "loose" to start with, so I get the loose coupling I so much need, by implication, I know in advance how the application will evolve: I put the "loose" bits in the WSDL definitions where I expect future variation in the data. But real life doesn't work that way. None of us is prescient and, as a rule, what makes the versioning problem so hard is that we *don't* know how an application will evolve in the future. In other words, people who say that I can solve the problem by writing "loose" WSDL are kidding themselves: the real world is not cooperative enough for this to work.

- The old argument of "the receiver can ignore what it doesn't understand" is fallacious. For 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. Second, the assumption that things will work just because the receiver can "ignore what it does not understand" is very naive. What I don't know can hurt me as much as what I do know. (Would you sign a contract that I put in front of you when several paragraphs are written in a language you cannot understand?)

- Trying to achieve loose coupling at the protocol level is simply the wrong place in the abstraction hierarchy: the protocol is about moving bits back and forth, and about doing this reliably and efficiently. Loose coupling is about dealing with application-specific data types and interfaces and whether it's possible to gracefully evolve these over time. I don't see why I have to have a "loose" protocol in order to enable loose coupling.

If we are interested in loose coupling, multiple interfaces are a far better approach. Instead of trying to define one interface that is loose enough to accommodate all the possible variations, I define several interfaces, each of which accommodates exactly one variation. That way, each interface is strongly typed, but, collectively, all the interfaces together are loosely typed because they offer several alternatives for sending a message. Given that, what I need is a mechanism to select the interface that best suits my job, and a mechanism that lets the receiver of a message know which version is being addressed by the sender. Put those mechanisms into the distribution platform, so applications don't have to reinvent them all the time, and you have a workable answer to the "loose coupling" dilemma that doesn't require me to sacrifice static type safety, and that doesn't throw on-the-wire bandwidth and CPU cycles around as if they were growing on trees.

This idea works very well, and isn't new either: COM supports multiple interfaces, where a single object with a single object identity can present different personas to the world, and Ice has a mechanism called "facets" that allows versioning of distributed applications.

Cheers,

Michi.

Having thought long and hard about this question, I have come to a few tentative conclusions. My opinion only, no hard evidence, YMMV.

1. CORBA was never marketed very well (some would say, at all). No big analyst ever wrote it up appreciatively; indeed, their failure to understand how CORBA even worked played right into Microsoft's desire to bury it. I only ever saw one single comparative review of CORBA products - and DCOM! - in a PC magazine or newspaper. It focused heavily on the user interfaces, presumably because the journalists didn't know how to test CORBA itself.

2. The firewall problem was never satisfactory solved, in spite of a few good starts like Iona's WonderWall. AFAICS, the technical problem was almost identical to that of Web Services security, but it didn't get one-hundredth of the investment in time and money. There is a big industry sector emerging, devoted purely to Web Services security and management; the same could easily have been done for CORBA, but no one wanted to make it happen. Of course, the original Web Services idea was "just let's drive it all straight through port 80/443, and never mind the firewall administrator's tantrums" - a perfect example of irresponsible, know-nothing short-termism.

3. Microsoft had a fever-induced delusion that somehow it could make COM rule the world. The Internet and the Web came as two most unpleasant hammer-blows to its intention of sewing up the entire world market in computing, and using COM to infiltrate and subvert them no doubt looked tempting. Hence Microsoft took every chance to bash CORBA - or, preferably, exclude it from discussion altogether. Ironically, the number of useful distributed systems ever built around DCOM can be counted on the fingers of one hand, AFAIK.

4. Bottom line: CORBA failed signally to boost the bottom lines of the big hardware and software vendors. Look at what happened: today some of the best ORBs are open-source, and free to acquire! What kind of way to run a business is that? I once heard that the cost of entry to IBM's ComponentBroker program was about $1 million - nice business, but how many do you suppose they sold? Now consider WebSphere...

It's odd that CORBA should end up being sidelined by most of its original supporters, in favour of a supposedly simpler and cheaper system that ends up being frantically complicated (well over 100 related specifications, and counting) and far more expensive. But that's business for you!

Sorry for misrepresenting your position, Harold, but I thought that when you said "not technical" that meant that the technical issues were inconsequential, at least when compared to the "organizational and marketing" ones.

I checked out PEPT a while ago, but didn't see much there that would be useful to me. Perhaps that has something to do with your belief that "The fundamental building blocks of a remoting system [...] are the same whether you are doing XML encodings and protocols over HTTP or doing CDR encoding and IIOP protocol over TCP/IP". That's not the case, since you're talking about different layers of the stack there; HTTP is an application protocol, while IIOP or TCP/IP are not. This means that the payload being encoded is very different. For example, with HTTP your payload is just a document, while with IIOP it's a document wrapped in an operation/destination wrapper.

Wow, I agree with Michi almost entirely, except where he said;

"Trying to achieve loose coupling at the protocol level is simply the wrong place in the abstraction hierarchy: the protocol is about moving bits back and forth, and about doing this reliably and efficiently."

Application protocols are not about "moving bits back and forth". Bit moving is a sub-application layer responsibility; for example, HTTP depends on TCP/IP for that. Application protocols play the role of the "connector" in software architectural terms; that architectural entity which binds components. And I do think the connector plays an important role in determining the degree of coupling that components exhibit.

Hello Mark. I won't try to convince you of the value of PEPT, other than to say that I have found it useful in structuring remoting systems.

Speaking of protocols - the terms protocols and transports get used to mean the same thing in many discussions. PEPT regards something as a transport if PEPT is not involved in writing/reading headers. If headers are read/written then PEPT considers something a protocol.

For example: PEPT considers IIOP a protocol since it explicitly writes various fields (e.g., more fragments, length). It then gives the header and encoded data to TCP/IP transport. TCP/IP is definitely a transport in this case since PEPT does not read or write TCP headers.

The HTTP case has more gray area. PEPT may choose to read/write HTTP headers - in that case HTTP is a protocol and TCP/IP is the transport. However, if some other component (say, built into the language library) handles HTTP headers and all PEPT has to do is give that component the data to send, then PEPT would consider HTTP to be a transport.

Somebody has to say it ...

While I agree that WSDL, or at least the way it is used most of the time, basically leads to tightly-coupled systems (built on an infrastructure inefficient for this purpose), it's entirely possible to build loosely-coupled systems using Web services standards (with or without WSDL). And unless you've been sending along hierarchically structured lists of key-value pairs or maps using CORBA, this is clearly a difference.

Mark said:

> Application protocols are not about "moving bits back and forth".

Right, I was a bit sloppy here. Maybe I should have said "moving messages back and forth." At any rate, the point I was trying to make was that I believe that using the protocol to try and deal with versioning or loose coupling is wrong because that's at far too low an abstraction level. The loose coupling is very close to the application-specific types and interfaces, and exactly what should be "loose" and in what way depends entirely on each specific application. By the time we get down to the protocol level, we have lost all application-specific knowledge, so the protocol can't do this very well. Versioning, or loose coupling (or whatever you want to call it) will always be closely linked to application semantics, and should be dealt with at that level (or a level very close to it).

Cheers,

Michi.

Nope, we're still disconnected Michi.

It's called an *APPLICATION* protocol for a reason; it's an application layer connector which binds components together and makes interoperation (document exchange, in the case of HTTP) possible. I can think of no other architectural element which more greatly impacts the degree of coupling exhibited by components of an architecture, than the connector/application-protocol(s) in use.

Mark, you say you are still disconnected with Michi. Could you make you statements more concrete with an example? Thanks.

Hmm, ok. Consider that any HTTP client can get data from any HTTP server, while not every IIOP client can get data from every IIOP server.

With IIOP, there needs to be *additional* agreement between the components on the actual application interface exposed by the server (and implemented by the client(s)) for the exchange of data to occur. Application protocols like HTTP, FTP, SMTP, IMAP, etc.. provide that additional layer of agreement.

As an explorer on the expanding frontier of ignorance. I've had a chance to see successful projects done using OSI based ROSE and ASN.1.

I've also seen more successful projects done with CORBA and CORBA IDL. Now we have some successful projects using various combinations of XML, XML Schema, SOAP, WSDL over various type of IPC using JMS, HTTP, IIOP, etc...

I've enjoyed the various architectures too. n-Tiered approaches, SOA, REST, MEST, etc...

I've read where the ITU has developed specifications for an XML Schema to ASN.1 mapping with XML Encoding Rules. Sun even has a article devoted to this titled Fast Web Services ( http://java.sun.com/developer/technicalArticles/WebServices/fastWS/ ). I suspect even more successful projects will use these new ITU specifcations.

So back to the Future.

The only failures I've seen with CORBA were in ambiguity of the OMG specifications or implementation errors, but these happen in software and specifications. You have to validate, test and then move to the next level.

Most of the whining about CORBA comes from groups that stopped keeping pace with the specifications.

I would like to see an OMG CORBA version 4, 5, and 6. I'm anxiously waiting for the Internet to completely convert to IP version 6 and the embrace of eXpress Transfer Protocol (XTP).

I see YAML Syntax taking over from XML and making things easier for me to read using vi. Also it sounds cool when I say YAML (rhymes with camel) (www.yaml.org). :)

Mark,

> Hmm, ok. Consider that any HTTP client can get data from any HTTP server, while not every IIOP client can get data from every IIOP server.

Thats very interesting. Let's think about *why* this is so. With HTTP, any old browser can contact any old server and get data from it, and then render the data correctly. But why? As far as I can see, this only works because the browser knows and understands all the tags that are contained in the reply, knows their semantics, and then can render the screen accordingly.

Now let's consider SOAP. Is the same true here? I don't think so. For one, a client would have a hard time getting data back from any old WS server: in order to get a reply other than an error, the client not only needs to know the URL of the target, but also the web method name, and what parameters are expected by the method. But let's assume the client knows that, and gets a reply. Can the client make sense of the reply without a priori knowledge? I don't think so. That's because the reply contains arbitrary nodes with arbitrary names and meaning. So, the best the client could do is show me a representation of the XML tree: "here is a node, and it's tag is such and such, and it's value is such and such," etc.

This is *not* the same as your HTTP example. The crucial difference is that the HTML that is returned has universally-accepted syntax and, more importantly, universally-accepted *semantics*. With SOAP, the XML that is returned has unserversally-accepted syntax, but does *not* have universally-accepted semantics.

> With IIOP, there needs to be *additional* agreement between the components on the actual application interface exposed by the server (and implemented by the client(s)) for the exchange of data to occur. Application protocols like HTTP, FTP, SMTP, IMAP, etc.. provide that additional layer of agreement.

I think the additional agreement you mention here for IIOP has to be in place just as much for SOAP/XML. Without that agreement, I won't be able to make sense of the data (beyond it's structure). Sure, I can get the data off the wire and parse it into a tree, but that doesn't do me any good unless I know what to make of the data in terms of its semantics.

So, as far as I can see, the difference is one of syntax. With IIOP, we encode the data as binary, so it's not possible for me to interpret the data without a priori knowledge of its encoding. With XML, we encode the data in a universal syntax, but it is *also* not possible for me to interpret the data without a priori knowledge; not of its encoding, but of its semantics. What I am getting at here is that the ability to get an XML message off the wire without type-specific knowledge doesn't fundamentally alter the core issue, namely, that the receiver must have knowledge of the *semantics* of the data in order to do something useful with it; whether the data is encoded as binary or XML seems to be a second-order issue. In other words, the agreement you mention goes way beyond mere syntax.

Now, back to loose coupling... I'm arguing that 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. All the clever and self-identifying syntax in the world does not help me when it comes to loose coupling: the issues around loose coupling are semantic. For example: "Is it valid for someone to place an order if there is no purchase order number in the order?" The data encoding cannot help me answer that question. Either the purchase order number is there or it isn't, and I have to decide which is acceptable. XML (or IIOP, or the Ice encoding) is entirely irrelevant in determining the answer to that question.

So, I can see a few points that seem relevant:

- Encoding the data as XML does not solve the loose coupling problem at all.

- Using XML as an encoding causes a very large hit in terms of CPU cycles and bandwidth compared to a binary encoding.

- Not all applications require loose coupling.

- Applications that don't need loose coupling get hit by the performance penalty for no functional gain.

- Applications that do need loose coupling get hit by the performance penalty too, but don't get the loose coupling they need (other than in a superficial syntactic way that doesn't fundamentally alter the problem.)

So, where is the benefit?

Cheers,
Michi.

I don't know why people say CORBA failed. One of the largest electronic commerce services that I know about does millons of transactions a week. It uses the ATIS (www.atis.org) OBF interfaces. CORBA was selected so everyone participating could use a common interface specification language and inter-operable exchange protocol based upon internet standards. Many different types of CORBA implementations involved. Many different languages involved Java, C++, COBOL. CORBA provide the open specifications as a wide and deep inter-connection technology.

I read these quotes and articles about CORBA failure with some disbelief and skepticism of a technology that I use on a regular basis.

I have to think that most of these people must have cast there opinion with the CORBA 2.0 or lower specifications and stopped at that point. The OMG went farther with the later specifications. They hardenend and made it more robust.

This exchange is just another example of the "CORBA failure" expression. ( http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=327 )

The statments I read and hear that loose coupling and Web Services are somewhat related I think is naive thinking. XML Schema change is pain area that has derailed some projects and their release schedules.

I think you have to realize that people are using JAXB, XSD.exe and other XML to language binding tools. Most application programmers don't want yo implement dynamic data binding logic. They want a serializeable object with access methods. You start changing XML schema and now you cause a cascade of JAXB, XSD.exe code-gen and who knows maybe logic changes. I don't know maybe XQuery and other XML binding dialects will make this problem go away. I've made mention of using using "Any" types but howls of horror are heard when I make mention of dynamic data binding.

Maybe web services and xml will achieve a critical point like is described on this ASN.1 web site (see italics) http://asn1.elibel.tm.fr/en/index.htm

"With HTTP, any old browser can contact any old server and get data from it, and then render the data correctly. But why? As far as I can see, this only works because the browser knows and understands all the tags that are contained in the reply, knows their semantics, and then can render the screen accordingly."

I'm just talking about getting the data to the client, which obviously has to happen before - and therefore independently of - the actual contents of the data. So to reiterate my point, with both ends speaking HTTP, you get the ability for a client to request data from a server for free. With both ends speaking IIOP, you don't because IIOP provides no application semantics for requesting data; that has to be agreed on separately by the two parties.

I certainly agree that there's coupling issues with the data, and I'd be happy to consider SOAP & XML offline (I mostly agree with your points about the data), but I'd like to just focus on this one critical architectural point here.

Another way to say what Mark says in the comment right above this one is that HTTP has a fixed set of verbs, while CORBA has an infinite set of verbs. Any HTTP client can talk to any HTTP server because they agree on the verbs, whereas in CORBA, the client and server have to agree a priori on the verbs.

I'd take issue that any old browser with any old server can communicate and render data correctly.

Maybe this was true in the past, before javascript and other plug-in items were introduced into browsers.

The HTTP will like transfer the data, but the client logic may not know how to render it as intended. I don't know maybe all web server sites compute all possiblilites of all HTTP user-agent capabilities and send only what that agent is capiable of rendering.

A nice idea but rarely implemented in my experience.

Right-o, Steve. That's why the application protocol is relevant to the degree of coupling.

A little bit offtopic:

A few weeks ago I wanted to start getting a taste of Web Services. I had heard that a promise of WS is interoperability. But then I found out that not only different vendors implement WS specs differently, but there're even competing specs for specific problems and each of these specs are being written by different organizations.

For example, there are different specs for discovery. Or different specs for security. What happens if different organizations choose different discovery specs? Uninoperabilty, I guess.

But the CORBA specs are all written by OMG. And a single CORBA spec covers different aspects of communication that in the WS world each one has its own spec.

Am I missing something here or what? How can WSes be interoperable in such an ecosystem?

I think the network effects of HTML/BROWSER/URI open source were the really makers of the world wide web and coincidental to all this is HTTP. I remember Gopher. After reading these responese did some digging and found this paper on "Who Killed Gopher?; An Extensible Murder Mystery" by Rohit Khare (http://www.ics.uci.edu/~rohit/IEEE-L7-http-gopher.html). I thought it brought up some interesting points about social network effects of people using the browser and that making the Web and HTTP the political force it is today. The browser vendors have introduced serreptitous features like cookies by using social network effects and bypassing the IETF. But this has side-effects. (i.e. This site only supports such and such browser.) How many sites have you noticed this on ?

My thoughts with regard is general inter-operability on web is driven by social networking clout not so much by what is standard.

This is a very interesting topic indeed.

Some over-simplified reflections from an amateur in the distributed-whatever domain (objects is probably a dangerous word here):

I've done a limited nr of CORBA-based solution architectures and implementations a while ago. My feeling is that CORBA definitely is not a failure. I even see 2 big success areas: technological and analytical.

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.

One of the great values of OMG/CORBA that hasn't been mentioned yet, is the extensive analysis of what's needed for distributed applications. I have the feeling that lots of "new" paradigms arriving later can be seen as re-implementations of the CORBA standards/services etc.

Of course, with some specific variations, e.g. messages with some arbitrary text format that happens to be parseable by an XML-parser (and where lots of other acronyms can be applied to flabbergast any interested reader) i.o. a binary format.

In the web services domain, people are only starting to discover what's needed for a complete architecture stack.

There's a big chance that the result will indeed be a system that has similar services as CORBA, but this time with human-readable messages and the ability to flow through port 80.

Humans can imagine valid semantics for these messages. But is this really valuable? I agree with Michi Henning that in applications, semantics can not be derived/invented at run-time anyway, they have to be a-priori known (and coded), whether the msg is binary or text-based (with or without standard tools to parse the text).

The fact that people now seem to be willing to wait for a nr of years for this web services platform to stabilize and become more complete, and for tool/server providers to build more-or-less interoperable systems (e.g. MS and rest-of-world), seems to be more a new mindset in the SW-world than to be based on technological reasons.

I'm sure it would have been much easier/faster to provide interoperability on IIOP, but at the time MS could not do that as they were still positioning (D)COM as the holy grail.

But now, XML has such a huge mindshare that everyone is willing to invest in technological interoperability...

Byte-streams didn't have the same sex-appeal... ;-)

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

erwin

Erwin, loose coupling is not an absolute, because there's always additional constraints that can added which separate different concerns and therefore provide more loose coupling ... at least for the contexts in which such a separation is of value.

What we do know though, is that giving all components the same interface provides a significant degree of loose coupling over that of an architecture where interfaces are unconstrained (e.g. CORBA, Web services). This is because the concerns of "type" (e.g. stock-quote providing service, order processing service, ...) and "interface" are separated; that is, since all components have the same interface, then their type can vary without their interface changing.

I also see this separation of concerns as "completing", in a sense, the well known separation of concerns of interface and implementation, since the type of service is an aspect of its implementation. But you needn't agree with me on that point to see that REST is more loosely coupled than WS/SOA, and that HTTP plays *the* critical role in separating those concerns (as I was trying to explain to Michi above).

"The HTTP will like transfer the data, but the client logic may not know how to render it as intended. I don't know maybe all web server sites compute all possiblilites of all HTTP user-agent capabilities and send only what that agent is capiable of rendering.

A nice idea but rarely implemented in my experience."

You know, Google does a good job at retrieving data from all servers & figuring out something interesting to do with that data. Not just HTML - there's PDF, GIF, RSS, blah, blah, blah. An no IDL was injured in the process.

The style of corba vs SOAP differs fundamentally in that corba makes fine-grained interaction possible when in fact coarse-grained interaction is warranted.

This is significant because the developer works within the mental model of the architectural style. An Object-Oriented developer decomposes a problem into objects and messages. The SOAP style is to send one message.

Interfaces defining many kinds of messages imposes unncessary coupling, when what is required is for documents to be thrown over the other side of the wall, leaving the other party to decide what order to parse and process the document.

"Interfaces defining many kinds of messages imposes unncessary coupling, when what is required is for documents to be thrown over the other side of the wall, leaving the other party to decide what order to parse and process the document."

Amen to that.

Slightly off topic, but I wonder why none of the CORBA implementors had ever approached a hardware manufacturer in building a CORBA aware hardware router.

This would have embedded CORBA in the network and made it part of the network stack. The whole CORBA community would have benefited.

These guys are doing it with XML and look how well it works out for them: http://www.datapower.com/

Cheers,
Marat

Marat - I've tried to push this twice - once in 2000 and once recently. The idea was shot down. Interesting that hardware vendors are now doing this with WS and XML.

On the CORBA failed topic. Sigh, it makes me tired discussing this one over and over. There are so many variables.

I think that CORBA did have some technical challenges - mainly smart enough people to use complex features like POA and enterprise features. Another problem was developers using fine grained interfaces see my recent post on IP Babble (http://www.ipbabble.com) called The old new thing - SOA.

But there is also the frivolous nature of the middleware fashion industry. Analysts, System Integrators all need to have something fresh to say to the customers. Platform vendors all trying so hard not to be #3 or #4 or lower in a market, so they invent something new.

You don't think WS is the last distrubited computing/integration technology do you???

I've put a bunch on comments in my blog entry here: http://kendes.blogspot.com/2005/10/loose-coupling-corba-vs-ws.html

To summarise, I don't think much of the technical details matter, loose coupling is a support / management commitment more than a technical ability (similarly SOA). If you really want it, you have to plan for it. With decent people, you can do it with any toolkit. I think XML/WS is easier, mainly due to debugging ability (it *is* important that people can read the messages, having a binary equivalent is only important for speed after everything else works), but also because vendors are more serious about interop and devs are more familiar with the tools (how many decs would like to patch embedded IP addresses inside an IIOP packet).

Oh, well, IMHO the greatest pain with CORBA were the language mappings.
I see the reason for their existence, but they made the system terribly complex to learn and implement.
With WS, you have just specifications of wire data formats and file formats; like if CORBA just specified IDL and IIOP, and then said to ORB vendors: "be gentle to your users, and give them a nice API to handle this".
I know this position is a bit extreme, but it seems this is what happened: each software tool has its own APIs to handle SOAP, WSDL and everything, and if you need only SOAP, you could almost play with XML with no additional library to help you, and still have it working.
With CORBA, the C++ language mappings were hundreds of pages, all just to specify which bits of memory must be released by each call or type ("_var", "_ptr", and those nightmares).
With WS all of a sudden developers had simpler APIs, and a user readable wire transfer format.
This, IMHO, is the real difference between the two worlds!